L'auteur de « Tochki nad II » a remplacé Notion et son CRM par des agents : plus de 80 skills au lieu de services

Alors que tout le monde débat de la meilleure modèle, l'auteur de la chaîne « Tochki nad II » a montré à quoi ressemble une journée de travail construite autour d'un agent. Ce n'est pas une liste d'applications préférées, mais l'organisation d'un poste de travail : une seule fenêtre avec un agent (IDE, terminal ou application native) ayant accès à tous les projets et dépôts. Tout le reste, selon lui, n'est que l'habillage de cette fenêtre.

Au centre : agents et abonnements

La base, ce sont Claude Code et Codex sur les abonnements principaux. Il les utilise aussi bien dans les applications que dans le terminal iTerm. Orca permet de lancer plusieurs agents en parallèle dans une seule fenêtre, avec ses propres abonnements. Gemini et Cursor sont également payés, mais l'auteur avoue les garder surtout pour les démonstrations pendant le camp. Il ouvre parfois Dots d'OpenAI.

La voix et le navigateur s'articulent autour des agents. MacWhisper transcrit les vidéos et les appels, et range lui-même le résultat dans le Second Brain. Pour la dictée, il y a « Klava ne vinovata » (« Le clavier n'y est pour rien »), une version personnalisée de Handy réalisée par un abonné de la chaîne. Dans le navigateur Comet vivent les agents-extensions d'OpenAI et d'Anthropic.

Ce stack n'est pas monogame : deux abonnements principaux, plus un agrégateur, plus des clés distinctes selon les projets. C'est une pratique courante pour ceux qui travaillent avec des agents tous les jours et ne veulent pas dépendre d'un seul fournisseur.

Code, infrastructure et API

Tout le code est hébergé sur GitHub. Les bots Telegram tournent sur Railway. Le backend est construit sur Supabase via MCP ; Neon est parfois utilisé pour les bases de données. Les démos sont publiées sur Netlify et Vercel, Mux gère la vidéo, et les vidéos sont enregistrées avec Screen Studio.

Côté API, le schéma est le suivant : OpenRouter avec une seule clé pour presque tous les modèles, plus des clés distinctes OpenAI, Gemini et Kimi pour des projets précis. Quand l'agent doit récupérer un site entier, Firecrawl entre en jeu.

Le point commun de cet ensemble est que presque chaque service peut être piloté depuis l'agent via API ou MCP. L'agent ne se contente pas d'écrire du code : il déploie, connecte la base de données et récupère les données lui-même.

Des skills à la place des services

Le plus intéressant dans le post, ce sont les skills. Il y en a déjà plus de 80, et beaucoup remplacent des services entiers. Parmi les exemples :

• des présentations dans le style du camp ;
• des carrousels et des posters ;
• un générique pour le direct et des timecodes pour les cours ;
• la traduction et la mise en page de guides PDF ;
• contrat, facture et acte pour les participants du camp ;
• l'analyse d'un appel dans le CRM à l'intérieur du Second Brain ;
• l'audit SEO et GEO d'un site ;
• le diagnostic d'un Mac qui ralentit.

Résultat, selon l'auteur : il a quitté les générateurs de présentations, les trackers de tâches, le CRM et Notion, remplacés par des micro-services personnels et d'équipe pour une multitude de petites tâches.

Si l'on met ces éléments bout à bout, on obtient une chaîne claire. L'appel avec un participant est enregistré et transcrit par MacWhisper, le texte arrive dans le Second Brain, un skill analyse l'appel dans le CRM, et un autre prépare le contrat, la facture et l'acte. Auparavant, cela exigeait plusieurs services et des copier-coller manuels entre eux.

Limites et ce qu'il faut retenir

Précisons d'emblée : c'est un post-inventaire, pas une étude. Il n'y a aucun chiffre sur les économies de temps ou d'argent, et le coût des abonnements n'est pas indiqué. Le stack est taillé pour une seule personne qui fait du contenu, de la formation et des camps ; il ne conviendra pas tel quel à un développeur ou à un product manager. Un agent ayant accès à tous les dépôts pose aussi une question de droits et de sécurité, dont le post ne parle pas. Enfin, 80 skills doivent être maintenus, sinon ils deviennent obsolètes et se mettent à faire des erreurs.

On peut formuler une conclusion pratique sans copier la liste :

• notez les tâches récurrentes pour lesquelles vous payez un service uniquement pour un modèle ou un formulaire ;
• transformez la plus fréquente en skill pour agent et comparez le résultat avec le service ;
• connectez l'infrastructure via MCP ou API afin que l'agent puisse mener la tâche jusqu'au bout ;
• prenez une clé d'agrégateur comme OpenRouter, et des clés distinctes uniquement là où vous avez besoin de contrôler le projet ;
• décidez à l'avance à quels dépôts et données l'agent aura accès.

L'idée principale du post est simple : aujourd'hui, la valeur ne tient pas à la collection d'abonnements, mais à la quantité de tâches routinières que vous avez su transformer en skills et retirer des services tiers.