En mars 2026, Matt Van Horn a publié un long post sur la plateforme X, au titre direct : "Toutes les astuces Claude Code que je connais". Ce post a finalement atteint 913 000 vues, et les commentaires sont devenus une véritable foire d'empoigne.
Ce qui a enflammé la polémique n'était pas une instruction spécifique ou un paramètre de configuration, mais une affirmation qu'il a faite dès le début : "No IDE". En décrivant son flux de travail, il a mentionné qu'il n'avait jamais ouvert d'éditeur graphique une seule fois, et que toutes les opérations de développement se déroulaient dans le terminal en ligne de commande et dans un fichier nommé plan.md. Certains, après lecture, ont trouvé cela absurde et lui ont demandé comment il faisait pour lire, déboguer ou refactoriser son code ; d'autres ingénieurs expérimentés ont commenté : "C'est exactement le mode de fonctionnement que je cherchais".
Deux mois plus tard, le développeur chinois meng shao a publié une compilation de cette méthode et des pratiques dérivées de la communauté, sous le titre "Guide complet des astuces pratiques pour l'ingénierie d'agents". Ce n'est pas un test d'outils, mais un ensemble de principes opérationnels organisés autour de la boucle "Research → Plan → Work", étayés par 22 astuces concrètes, reproductibles ou discutables.
Cet article compile certains des guides opérationnels de flux de travail avec IA les plus discutés en ligne, dans l'espoir d'en dégager des éléments communs.
En fermant l'IDE, qu'est-ce qu'on perd vraiment ?
Un IDE graphique offre bien plus qu'une simple zone d'édition de code. C'est un système sensoriel complet : la coloration syntaxique permet de distinguer d'un coup d'œil variables et mots-clés, les messages d'erreur en temps réel signalent les problèmes dès la frappe, le débogage avec points d'arrêt permet d'observer l'évolution des variables ligne par ligne, l'arborescence des fichiers et le fil d'Ariane aident à ne pas se perdre dans les grands projets. Ce mécanisme complet de rétroaction visuelle constitue un postulat par défaut : la personne qui écrit le code a besoin de *voir* l'état de chaque ligne.
Le flux de travail "Terminal en ligne de commande + fichier Markdown" retire cette coquille de protection visuelle. Vous n'avez plus qu'un curseur clignotant et un fichier de plan que vous avez écrit. Pas de soulignage rouge pour les erreurs, pas de fenêtre pop-up d'auto-complétion, pas d'arborescence. Matt Van Horn a utilisé le terme "No IDE" dans son tweet. Sa véritable signification n'est pas de rejeter tous les outils graphiques, mais de faire passer la logique de contrôle du développement de "confirmation manuelle ligne par ligne" à "exécution par délégation groupée".
Boris Cherny, responsable de Claude Code, a partagé fin 2025 / début 2026 sur Threads et d'autres canaux sa propre façon d'utiliser Claude Code. Son approche est "CLI-first", en utilisant le "plan mode" comme point de départ pour toutes les tâches. Cela diffère fondamentalement de la mentalité de l'IDE : dans un IDE traditionnel, l'humain est le producteur de code actif, et l'IA n'est qu'une assistance ; dans le flux de travail piloté par plan dans le terminal, l'humain est le stratège et le validateur, tandis que la génération du code et le chemin d'exécution sont choisis de manière autonome par l'Agent.
Abandonner l'IDE, c'est perdre le sentiment de sécurité de "taper chaque ligne de code soi-même". Cela peut sembler être une perte, mais pour les développeurs expérimentés qui ont subi de nombreux changements de contexte dans de grands projets, c'est aussi un soulagement. Parce que vous n'avez plus besoin de sautiller constamment entre la lecture, l'écriture, la recherche de documentation, le changement de fichier... Il suffit d'expliquer clairement un besoin, puis de confier le processus d'exécution à un groupe d'Agents fonctionnant en parallèle.
Le cadre proposé par meng shao dans sa synthèse est "l'humain guide la direction, l'Agent exécute". À l'ère de l'IDE, l'humain devait à la fois guider la direction et exécuter les détails, ces deux rôles étaient imbriqués. Le nouveau flux de travail tente de les séparer, l'humain ne faisant que la première partie.
plan.md n'est pas un document, c'est un contrat
Le nom de fichier le plus récurrent dans ce flux de travail est plan.md. Ça ressemble à de la documentation de projet, mais sa fonction est totalement différente.
Le README d'un projet ou la documentation de développement sont destinés à être lus par des humains, pour expliquer les décisions d'architecture, enregistrer les conventions d'interface, aider les nouveaux arrivants. Le principal lecteur de plan.md n'est pas l'humain, c'est l'Agent. Sa structure s'articule autour de trois éléments : la définition du problème, la description de la solution, et une liste d'exécution sous forme de cases à cocher. Meng shao a résumé cette relation de manière très claire dans son tweet : le rôle de plan.md est de "contraindre l'Agent à ne pas être paresseux".
Les LLM ont un problème connu dans les sessions longues, que la communauté appelle "corruption du contexte". Lorsque l'historique de la conversation s'allonge, l'attention du modèle pour les objectifs initiaux s'atténue naturellement. Il peut oublier en cours de route les limites de la demande initiale, ou sauter paresseusement certaines étapes de vérification. Un projet communautaire nommé "洁癖.skill" se concentre spécifiquement sur ce problème, fournissant des méthodes pour organiser automatiquement les fichiers de session et mettre à jour une bibliothèque de mémoire persistante. Sa conclusion clé est que la performance à long terme d'un Agent ne dépend pas de la qualité d'un seul prompt, mais de l'existence d'un mécanisme de mémoire externe stable.
plan.md est cette mémoire externe. Il est persistant sur le système de fichiers, il ne disparaît pas avec la fin de la session. Chaque nouvelle session d'Agent peut recharger le contexte à partir de ce fichier, au lieu de dépendre de l'historique de chat déjà corrompu du tour précédent.
Compound Engineering est le plugin open-source central qui soutient ce flux de travail, développé par Kieran Klaassen de Every Inc. Il fournit un ensemble d'instructions en ligne de commande, dont /ce:plan peut générer automatiquement un brouillon de plan.md à partir de l'entrée du développeur. Après génération, le travail du développeur est de revoir et de corriger : l'Agent peut avoir des hypothèses erronées sur les choix technologiques, sous-estimer la complexité d'un module, ou complètement mal comprendre la logique métier. L'intervention humaine à ce stade n'est pas de peaufiner le code, mais d'injecter dans le fichier de plan les connaissances du domaine que l'Agent ignore, puis de redonner le plan corrigé à l'Agent pour exécution.
Cette conception est en parfaite adéquation avec un point souligné par Boris Cherny dans ses principes d'utilisation de Claude Code : concentrer le jugement de l'expert humain sur ce seul nœud de revue du plan, plutôt que de le disperser à chaque étape de l'exécution. Selon ses propres mots, si à chaque étape il faut que l'humain surveille et confirme, cela ne diffère pas fondamentalement du codage manuel.
Un plan.md efficace n'est pas long. Il contient généralement des critères d'acceptation clairs, chacun correspondant à une case à cocher. Ces cases sont des points d'ancrage d'exécution pour l'Agent, et des critères de validation pour l'humain. Après la phase de Work, le développeur ne lit pas le code, il vérifie que ces cases sont cochées une par une.
Les trois états d'un besoin : Research → Plan → Work
L'ossature la plus centrale de ce flux de travail est la boucle fermée constituée des trois phases Research, Plan, Work. Elle n'est pas compliquée, mais les outils de support et le mode d'intervention humaine de chaque segment ont une répartition claire.
L'objectif de la phase Research est de permettre à l'Agent d'établir un avantage informationnel avant d'agir. La méthode courante consiste à utiliser l'instruction /ce:brainstorm ou à charger des packages de compétences Research spécifiques. Matt Van Horn a ouvert une compétence appelée last30days-skill, dont les étoiles GitHub dépassaient les 10 000 fin mars 2026. Sa fonction est de permettre à l'Agent de récupérer en parallèle du contenu lié à un sujet spécifique publié sur Reddit, X, Hacker News, etc., au cours des 30 derniers jours, puis de produire un résumé d'analyse structuré. Supposons que vous lanciez un projet impliquant une nouvelle pile technologique, votre Agent peut rapporter en quelques minutes les derniers retours de la communauté sur cette pile, les pièges connus, les alternatives recommandées, au lieu de vous obliger à ouvrir manuellement une douzaine d'onglets de navigateur.
Le résultat de la phase Research n'est pas la réponse finale, c'est une entrée d'information. Ces informations entrent dans la phase Plan, devenant la matière première pour générer le plan.md.
La phase Plan utilise l'instruction /ce:plan. L'Agent, basé sur les découvertes de la phase Research, les besoins initiaux saisis par le développeur et le contexte du code existant du projet, génère un brouillon de plan.md. La philosophie de conception de Compound Engineering est de consacrer 80 % du temps à la planification et à la revue, et 20 % à l'exécution. Ce ratio semble radical à première vue, mais la logique est directe : un plan clair, aux limites bien définies et aux critères d'acceptation spécifiques, peut réduire au minimum le coût des retouches lors de la phase d'exécution.
Ce que le développeur doit faire lors de la phase Plan inclut : corriger les hypothèses erronées de l'Agent sur les solutions techniques, ajouter les contraintes métier que l'Agent ignore, ajuster la granularité de la décomposition des tâches et l'ordre d'exécution, inclure dans les cases à cocher les cas limites que l'Agent a tendance à sauter. Ce processus de revue est en soi une "injection de mémoire externe", car c'est à ce moment que l'humain inscrit dans le fichier de plan les connaissances implicites difficiles à faire émerger naturellement dans la conversation.
La phase Work utilise l'instruction /ce:work. L'Agent lit le plan.md, divise les tâches en sous-tâches et les délègue à des sous-agents pour une exécution en parallèle. Boris Cherny a partagé un chiffre : en utilisant ce flux de travail piloté par plan, il a produit 259 PR en un mois. Ce chiffre ne parle pas de la qualité du code, mais montre que lorsque le pouvoir décisionnel de la phase d'exécution est délégué à l'Agent, le goulot d'étranglement humain n'est plus la vitesse de frappe.
Il y a un point clé, facilement négligé, entre les trois phases : les phases Research et Plan peuvent être itérées plusieurs fois. Si l'Agent révèle des lacunes d'information lors de la phase Plan, on peut à tout moment revenir au mode Research pour compléter. Si une erreur est découverte après le début de la phase Work, on peut aussi revenir à la phase Plan pour la corriger. Cette boucle n'est pas un flux linéaire en cascade, c'est un cycle qui autorise les retours en arrière et les ajustements.
Six astuces que vous pouvez essayer immédiatement
Parmi les informations actuellement rendues publiques, les six astuces suivantes ont des sources claires et suffisamment de détails pour qu'un développeur puisse les essayer directement. Ce ne sont pas des principes abstraits, mais des opérations concrètes du type "que taper dans le terminal", "quoi écrire dans le fichier", "quel outil utiliser".
Astuce 1 : Générer un plan dès qu'une idée surgit, ne pas commencer à réfléchir seul dans sa tête.
Meng shao a placé celle-ci très tôt dans son post original. Sa logique est que le cerveau humain est bon pour revoir, pas pour construire de toutes pièces une structure arborescente complexe et complète. Face à un nouveau besoin, les développeurs ont l'habitude de réfléchir mentalement au chemin de mise en œuvre, mais ce processus est très inefficace car la capacité de la mémoire de travail est limitée. La bonne approche est de laisser l'Agent générer une première version du plan dès qu'une idée émerge, même si elle est grossière, erronée et nécessite de nombreuses corrections. Réviser un plan imparfait est beaucoup plus facile que d'écrire un plan parfait à partir de zéro.
Astuce 2 : Ne pas lire le plan soi-même, demander à l'Agent de le résumer en quelques phrases.
Lire un long fichier de plan est en soi une tâche coûteuse. L'une des 22 astuces de Boris Cherny est d'utiliser une instruction en langage naturel pour que l'Agent fournisse un résumé (TLDR), ou utiliser "eli5" pour qu'il explique les points essentiels du plan de la manière la plus simple. Si vous avez 5 minutes pour réviser, passez les 3 premières minutes sur le résumé de l'Agent, et les 2 dernières uniquement sur les parties que vous jugez risquées. L'essence de cette astuce est de déléguer aussi la "compréhension de la lecture", l'humain ne lisant que ce qu'il doit absolument voir.
Astuce 3 : Paralléliser sur plusieurs terminaux.
Matt Van Horn a mentionné dans son tweet qu'il ouvrait simultanément 4 fenêtres de terminal ou plus, pour que différentes instances d'Agent traitent différentes sous-tâches. L'une fait une page frontend, une autre écrit une API backend, une autre exécute des tests, une autre récupère de la documentation. Cette pratique transforme le développement traditionnel mono-thread en une planification multi-thread. Le prix à payer est que vous devez gérer vous-même les sorties et états des différents terminaux, aucun espace de travail graphique ne vous aide à les surveiller de manière unifiée. Pour les développeurs habitués à avoir une vue d'ensemble dans une seule fenêtre d'IDE, il y aura au début un sentiment d'anxiété : "Je ne sais pas d'où vient l'erreur".
Astuce 4 : Utiliser la voix au lieu du clavier pour les instructions d'architecture complexes.
Meng shao mentionne l'utilisation d'outils vocaux comme monologue. La méthode concrète est, face à une réflexion sur la conception d'un système nécessitant une longue description, de ne pas la taper au clavier mot par mot, mais d'expliquer toute la réflexion à voix haute, et de laisser l'outil de reconnaissance vocale transposer le contenu dans le terminal ou le fichier de plan. Matt Van Horn appelle cela "Get Voice-Pilled". Il pense que la voix facilite le maintien de la cohérence d'une réflexion architecturale complexe plus que la frappe, car le débit de la parole et le rythme naturel du flux logique sont plus compatibles. L'efficacité réelle de cette astuce pour les développeurs chinois manque encore de retours suffisants, et la capacité de prise en charge du chinois par monologue reste à confirmer.
Astuce 5 : Déclencher des tâches asynchrones par e-mail.
Matt Van Horn a partagé un scénario spécifique dans un tweet d'avril 2026 : alors qu'il endormait son enfant, il a envoyé un e-mail à son instance Claude Code via l'outil agentmail, déclenchant une tâche de construction de code à distance. Lorsque l'enfant s'est endormi, la construction était terminée et le résultat l'attendait dans le terminal pour validation. Cela revient à libérer l'activité de développement de la contrainte physique "devoir être assis devant l'ordinateur", permettant à l'Agent de travailler en arrière-plan de manière continue. La condition préalable est que vous ayez suffisamment confiance en l'Agent pour le laisser s'exécuter de manière autonome sans voir l'écran.
Astuce 6 : Utiliser la stack d'outils comme un marché de compétences.
Des projets comme AgentSkills diffusent une idée centrale : les développeurs n'ont pas besoin de construire à partir de zéro chaque capacité d'Agent. La gestion de fichiers, la veille d'actualités, le scraping web... ces capacités génériques ont déjà des packages de compétences maintenus par la communauté que l'on peut charger. Dans un flux de travail en terminal, charger une nouvelle compétence s'apparente à installer un plugin ; il suffit de déclarer la source et les paramètres du package de compétences dans la configuration, et l'Agent peut automatiquement acquérir la capacité d'appel d'outil correspondante. Claude Code Video Toolkit, en tant qu'exemple de pratique communautaire, a ajouté la capacité de compréhension du contenu vidéo à l'environnement CLI. Bien que ses cas d'application soient encore assez verticaux, il montre que le périmètre de capacités d'un Agent en terminal peut être étendu continuellement via des packages de compétences.
Quand ce flux de travail peut-il se retourner contre vous ?
Ce flux de travail ne manque pas de détracteurs. En synthétisant les discussions communautaires, les problèmes se concentrent principalement dans trois directions.
La première est la limite du public concerné. Les 22 astuces de Boris Cherny comportent elles-mêmes un présupposé implicite : l'utilisateur doit avoir une capacité suffisante de décomposition d'architecture et de formulation de contraintes dans ses prompts. Une personne capable de concevoir un système seule sait où se situe la frontière entre "ce que l'Agent doit faire" et "ce qu'il ne doit pas faire". Pour un développeur qui a encore besoin des messages d'erreur, de la coloration syntaxique et du débogage pas-à-pas de l'IDE pour comprendre la logique du code, fermer l'éditeur graphique équivaut à fermer les canaux d'information auxquels il est habitué. Il ne s'agit pas d'un problème de niveau de compétence, mais d'une différence dans les canaux sensoriels dont dépend le mode de travail. Les développeurs débutants construisent leur modèle mental du fonctionnement d'un programme via le débogage ligne par ligne, et ce processus d'apprentissage n'a pas de solution de remplacementsatisfaisante dans le flux de travail en terminal.
Le deuxième problème est la concentration des risques. Dans un IDE traditionnel, les erreurs sont exposées progressivement lors du processus d'exécution : erreurs de compilation, incompatibilités de type, exceptions à l'exécution. L'humain a la possibilité de les détecter et de les corriger à chaque étape. Dans le flux de travail piloté par plan, toute la revue des décisions est comprimée en un seul nœud, la phase Plan. Si la revue humaine à ce nœud n'est pas suffisamment approfondie, les erreurs seront amplifiées de manière fidèle et efficace par l'Agent lors de la phase Work. Lorsque vous le découvrirez, plusieurs fichiers auront peut-être déjà été contaminés par une logique erronée.
Le troisième problème a été soulevé par Matt Van Horn lui-même, il l'appelle "AI Psychosis". Ce terme ne désigne pas un problème de l'IA, mais un problème humain : construire des boucles d'Agent génère en soi une forte satisfaction intellectuelle, similaire au feedback positif de l'optimisation continue dans un jeu de stratégie. Le développeur peut se laisser absorber par l'affinage du flux de travail d'Agent lui-même, essayant constamment de nouvelles astuces, ajoutant de nouveaux sous-agents, optimisant la structure du Plan, en oubliant une question fondamentale : quelle valeur livrez-vous réellement à l'utilisateur ? L'outil devient une fin, le besoin passe au second plan.
Ces trois problèmes pointent vers la même conclusion : le flux de travail en terminal piloté par plan.md est un amplificateur d'efficacité conçu pour les personnes qui "savent clairement ce qu'elles veulent", ce n'est pas un outil d'apprentissage pour ceux qui "sont encore en train d'explorer ce qu'ils doivent faire". Sa limite d'application ne réside pas dans le choix de la pile technologique, mais dans le stade de l'utilisateur. Si vous êtes celui qui a déjà dessiné sur papier l'architecture complète d'un système, ce flux de travail peut rendre votre vitesse d'exécution un ordre de grandeur supérieur. Si vous utilisez encore l'écriture de code pour comprendre le problème lui-même, alors le système de rétroaction visuelle de l'IDE est une béquille que vous ne devriez pas encore abandonner.
Actuellement, les composants clés de ce flux de travail incluent la couche d'environnement d'exécution avec Claude Code CLI ou Codex CLI, la couche de gestion de processus avec le plugin Compound Engineering, et la couche d'extension de compétences avec des projets comme last30days-skill et agentmail. Tous évoluent rapidement, et il est possible que les formats d'instruction, les conventions de fichiers et le système de plugins changent. Les développeurs qui adoptent cette approche maintenant doivent accepter un fait : les problèmes que vous rencontrerez n'auront peut-être pas encore de réponse de la communauté, car l'ensemble du flux est encore à un stade de pratique précoce, loin d'avoir atteint le standard d'une "chaîne d'outils stable". Mais c'est aussi précisément la fenêtre d'opportunité pour ceux qui ouvrent la voie d'établir un avantage cognitif.
