Pendant des années, mon plaisir, c’était de bouffer du code. Mais avec les agents, une grande partie du travail s’est déplacée.
Fin avril, puis surtout début mai avec Claude Code, je commence à écrire beaucoup moins de code à la main. Je reste développeur, mais mes journées changent de matière : cadrer la tâche, découper le problème, relire le code, tester le résultat, reprendre la main quand l’agent invente, généralise ou casse un truc. L’agent peut sortir le code. Si le diff est mauvais, c’est quand même mon problème.
L’IA m’accélère, mais elle accélère aussi mes mauvais réflexes. À force de voir sortir des centaines de lignes correctes, il m’est arrivé de relire trop vite. Plus tard, je revenais sur un diff en me demandant : “what the fuck ?” Bug caché, code smell, choix d’architecture bancal. L’agent avait produit du code ; moi, j’avais arrêté de le traiter comme du code à relire.
Je commence à traiter mes prompts comme des tickets dont je reste responsable : comprendre le besoin, valider un plan, isoler le travail dans une branche ou un worktree, lancer les checks, relire le diff. J’appelle ça orchestration, faute de meilleur mot.
Quand les sous-agents arrivent
Avant les sous-agents, j’orchestrais déjà à la main : Markdown recollables, scénarios de ticket, custom slash commands. Je donnais une procédure à l’agent : lire ça, produire ça, vérifier ça, s’arrêter là.
Quand Claude Code ajoute les sous-agents personnalisés via /agents, le changement tient surtout à l’isolation : chaque sous-agent travaille dans son propre contexte. Il exécute une tâche, rend un rapport, puis disparaît. Je vois le truc : cadrer une tâche, l’envoyer dans un contexte jetable, récupérer un rapport, vérifier.
Dès le lendemain de la release, je pousse le truc trop loin : au lieu d’écrire un agent, j’écris un méta-agent qui lit la doc officielle, puis crache des agents spécialisés à la demande.
En une soirée, je me retrouve avec une trentaine d’agents spécialisés : front-end généraliste, front-end “UI state”, front-end “accessibilité”, back-end, base de données, “diagnostic tests”, “testeur Playwright”, “lint/format”, “CI triage”, “doc writer”, etc.
Sur le papier, ça ressemble à une petite équipe. Dans Claude Code, ça devient vite autre chose : une chaîne de transmission.
Moi, je donne une intention à l’agent parent. L’agent parent résume, choisit un sous-agent, lui transmet une partie du contexte. Le sous-agent travaille dans sa bulle, rend un rapport, puis disparaît. À chaque passage, quelque chose peut se perdre : contrainte oubliée, nuance aplatie, résultat trop partiel. Vous voyez où je veux en venir ? Encore le contexte, oui. Ici, c’est l’entrée qui conditionne la sortie.
Je recrée en miniature une cérémonie que je connais déjà trop bien : client, PO, architecte, dev, testeur, reviewer, tech lead, puis retour humain.
Le problème ne vient pas des agents eux-mêmes. Il vient du nombre de passages. Chaque rôle ajouté demande un cadrage, un passage de relais, une vérification. Dès qu’on multiplie les relais, on paie en coordination ; ici, ce coût passe par des résumés et des fenêtres de contexte.
Je voulais créer une équipe idéale. J’ai créé une bureaucratie.
Je taille dans le gras.
Je garde moins d’agents spécialisés, et je reviens vers des rôles plus généralistes. Le contexte reste le vrai levier : un agent généraliste avec un bon prompt s’en sort souvent mieux qu’un agent spécialisé avec une consigne pauvre.
Certains sous-agents gardent leur utilité, surtout pour explorer une piste, tester une hypothèse ou isoler une tâche. Mais l’agent principal devient le point de passage obligé : il cadre, délègue, récupère les rapports, puis me rend un état lisible.
De mon côté, je pose les limites : périmètre, critères de fin, validations, ordre de passage. À ce stade, je ne cherche pas encore le workflow parfait. Je cherche surtout à réduire le bruit pour continuer à expérimenter.
Mon workflow d’orchestration
Une fois le bruit réduit, il reste un autre problème : travailler avec les agents sans reconstruire une usine à gaz autour d’eux.
Je garde deux commandes au centre :
/issuepour parler à GitHub (créer, mettre à jour ou commenter des issues),/worktreepour créer des copies de travail parallèles, une par sous-tâche.
J’ai testé une approche plus lourde, avec beaucoup de scripts, de logs et de tests end-to-end. Je l’ai gardée assez longtemps pour voir où elle cassait : trop fragile, trop compliquée pour ce qu’elle apportait.
À ce stade, je ne tiens pas encore un workflow parfait. Je tiens surtout une surface plus petite : un prompt réutilisable qui décrit le déroulé attendu, les étapes, les actions possibles, et les moments où appeler /issue ou /worktree.
Ce n’était pas mon workflow pour toutes les tâches. Pour une correction simple, c’était beaucoup trop lourd. Je l’utilisais surtout quand la demande était assez floue pour mériter un détour par le cadrage : comprendre, cadrer, découper, vérifier.
Dans ma tête, ça commençait toujours avant le code. Je donnais l’objectif, le périmètre, les contraintes, et ce que “fini” voulait dire. L’agent lisait ensuite le projet, repérait les fichiers importants, regardait les tests, puis me disait ce qu’il avait compris. Je voulais voir sa compréhension avant de le laisser écrire.
Quand le sujet restait flou, on cassait les ambiguïtés. Je lui demandais une approche, parfois une ou deux explorations par des sous-agents, puis une version consolidée que je pouvais relire. À ce moment-là seulement, je lançais l’implémentation.
Pour une tâche simple, un agent travaillait dans un worktree dédié. Pour une tâche plus large, je découpais plus franchement : plusieurs worktrees, des morceaux bornés, et moins de mélange dans les diffs.
Ensuite venaient les vérifications : tests, lint, types, parfois architecture. Les erreurs repartaient dans une boucle courte. À la fin, l’agent me présentait le diff. Je relisais, je testais, je demandais des corrections. La PR ne racontait pas toute l’histoire : juste l’objectif, les changements, les checks, les issues liées.
Question ouverte, pas seulement IA : à partir de combien de relais le signal se dégrade plus vite qu’il ne se transmet ?
La règle qui commence à se dégager est assez simple : peu d’agents, des morceaux bornés, des relais lisibles, et des vérifications qui disent vite si le travail tient. /issue et /worktree restent utiles parce qu’ils rendent le travail observable sans ajouter trop de glue code : une demande, un espace isolé, un diff, une PR.
Crash‑test de la sur‑orchestration
Puis je tombe dans l’excès opposé : tout canaliser.
Très vite, je repars dans l’autre sens : je veux tout canaliser. Branches, worktrees, issues, PR, hooks, guards, workflows “sécurisés” : chaque action finit avec sa sous-commande, son chemin prévu, son petit wrapper autour de Git.
Au début, c’est rassurant. Tout a l’air cadré. Puis je passe des jours à itérer sur le dispositif lui-même : un chemin marche sur une machine et casse sur l’autre, un script devient pénible à debugger, une règle corrige un cas mais en ouvre d’autres, la doc grossit parce que le système n’est plus lisible sans elle.
Un cas typique : je décris le plan dans une sorte de YAML, avec les branches à créer, les worktrees à préparer, puis l’ordre de merge attendu. L’outil sait faire le scaffolding. Le problème arrive au moment où l’orchestrateur doit suivre ce plan dans la durée. Il lit la commande, mais l’interprète trop vite, saute une étape, ou traite une règle comme une suggestion. Je me retrouve alors à corriger l’agent au lieu de corriger le code.
Au-dessus de /worktree, j’ajoute /orc, ma commande d’orchestration. Elle classait la tâche, choisissait le niveau d’isolation, préparait les branches ou worktrees, puis essayait de suivre les étapes jusqu’à la PR.
À force d’itérer, je finis par voir un problème : les commandes existent, mais les agents ne les suivent pas toujours comme prévu. /orc, /worktree, les consignes de PR, les hooks, les guards : tout est écrit quelque part, et pourtant je dois souvent repasser derrière. L’agent saute une étape, interprète une règle trop vite, ou oublie pourquoi la commande existe. La friction n’est pas seulement dans l’outil. Elle est dans l’écart entre la commande écrite et ce que le modèle en fait.
Début novembre, je commence à couper. Des commandes spécialisées disparaissent. Le glue code posé autour de Git aussi. Je réduis aussi la documentation, parce qu’une partie ne sert plus à transmettre une idée : elle sert à rendre supportable un système devenu trop lourd. Quelques jours plus tard, je refais une passe sur les skills et les documents. Moins d’exemples, moins de scénarios “au cas où”, moins de stratégie figée dans des fichiers que l’agent relit sans toujours en avoir besoin.
Ce que je garde de cette coupe est plus simple : si l’orchestration ne réduit pas l’ambiguïté ou le coût de coordination, elle ajoute juste une couche. Elle ne remplace pas Git, les tests, la PR ou la CI. Elle sert à aider l’agent à savoir où agir, quoi vérifier, quand s’arrêter, et comment me rendre un état lisible.
À partir de là, je me méfie surtout de l’empilement. À force d’ajouter des commandes, des docs, des guards et des rappels pour garder les agents dans le cadre, je finis parfois par alourdir le contexte que j’essaie justement de protéger. Ce n’est pas un problème sur toutes les tâches. Ça casse surtout quand l’orchestrateur doit tenir trop de choses à la fois : planifier, répartir, suivre les worktrees, relire les retours, préparer la PR. Le cadre est censé l’aider ; à ce niveau de complexité, il devient une charge de plus. La sortie, je la trouve moins dans une commande magique que dans des tâches plus petites et des relais plus courts.
Ce qui survit, ce n’est pas le grand workflow. C’est la discipline. Une tâche plus petite. Un espace de travail isolé quand ça vaut le coup. Un relais court. Un rapport que je peux relire. Un diff qui raconte encore l’intention de départ. L’orchestration reste utile quand elle réduit l’ambiguïté ; dès qu’elle devient un système à maintenir pour lui-même, elle recommence à polluer le contexte.
Mise à jour (avril 2026)
Quelques mois après l’écriture de ce chapitre, je n’utilise presque plus le plugin d’orchestration comme workflow quotidien. Le repo existe encore : claude-code-plugins/orchestration, et je l’ai beaucoup fait évoluer pendant cette période, mais une partie de ce que je fabriquais à la main s’est déplacée : parfois dans les outils, parfois dans des pratiques plus légères.
Avec le recul, le plugin compte moins que le réflexe qu’il m’a laissé : garder l’orchestration légère, observable, et assez simple pour ne pas devenir elle-même le problème.