Équipes d'agents Opus 4.6 : mon guide complet de configuration

Équipes d'agents Opus 4.6 : mon guide complet de configuration

J'ai passé jeudi après-midi dernier à regarder six agents IA se disputer sur le pattern de gestion d'état d'un composant React. Un agent pensait que useReducer était la bonne approche. Un autre insistait sur Zustand. Un troisième avait déjà commencé à coder avec du simple useState et se fichait de l'avis des autres. Le chef d'équipe — lui aussi un agent IA — a dû intervenir, prendre une décision et remettre tout le monde sur la même longueur d'onde.

Ce n'était pas une simulation. C'étaient six instances indépendantes de Claude Code, tournant dans des sessions de terminal séparées sur ma machine, communiquant via une boîte de messages partagée, collaborant sur la construction d'une vraie application. Bienvenue dans les équipes d'agents — la fonctionnalité d'Opus 4.6 qui a discrètement changé toute ma façon de travailler avec l'IA.

J'utilisais les sous-agents de Claude Code depuis des mois avant ça. Ils sont solides pour des tâches isolées. Mais dès que j'avais besoin que deux agents se parlent vraiment de ce qu'ils construisaient ? Tout le système s'effondrait. Je vais te montrer exactement pourquoi dans un instant, et surtout, comment les équipes d'agents résolvent un problème de coordination qui hante les workflows multi-agents depuis la naissance du concept.

Ce que les sous-agents faisaient bien (et où ils se sont heurtés à un mur)

Avant l'existence des équipes d'agents, je m'appuyais fortement sur les sous-agents pour tout ce qui nécessitait du travail en parallèle. Le modèle mental était simple : lancer une mini-session, lui confier une tâche délimitée, récupérer un résultat. De la délégation propre.

Ma configuration typique ressemblait à ça. La session principale gère les décisions d'architecture et l'orchestration. Le sous-agent #1 parcourt une base de code et en extrait les endpoints API. Le sous-agent #2 génère des fichiers de test basés sur un cahier des charges que je fournis. Le sous-agent #3 s'occupe de la documentation. Chacun opère dans sa propre fenêtre de contexte — ce qui est en fait une force, parce que ça signifie qu'ils ne polluent pas la mémoire de travail des autres.

Le problème est apparu dès que les tâches n'étaient plus totalement indépendantes.

Imagine ce scénario : je construis une API avec un middleware d'authentification. Le sous-agent #1 génère les gestionnaires de routes. Le sous-agent #2 construit le middleware d'authentification. Les deux tâches semblent indépendantes. Mais le middleware a besoin de connaître le format de réponse utilisé par les gestionnaires de routes, et les gestionnaires de routes ont besoin de savoir ce que le middleware injecte dans l'objet de requête. Aucun des deux agents ne sait ce que l'autre fait.

Mon palliatif était moche. Je lançais l'agent #1, récupérais sa sortie, collais manuellement les détails pertinents dans le prompt de l'agent #2, puis revenais mettre à jour le travail de l'agent #1 en fonction de ce que l'agent #2 avait produit. L'« orchestrateur » dans ce workflow, c'était moi — copiant-collant entre les fenêtres de terminal comme une sorte de bus de messages humain.

Certaines personnes configuraient des dossiers de projet partagés ou des fichiers de notes dans lesquels les sous-agents pouvaient écrire et lire. Ça fonctionne, mais c'est lent. Tu construis essentiellement un système de messagerie basé sur des fichiers sans communication en temps réel. L'agent A écrit une note, l'agent B vérifie s'il y a des notes, la récupère peut-être à la prochaine itération, peut-être pas. J'ai essayé cette approche pendant environ deux semaines. La surcharge de coordination a bouffé la majeure partie du temps gagné en ayant plusieurs agents au départ.

C'est le vide que les équipes d'agents ont été conçues pour combler. Et la différence n'est pas incrémentale — elle est structurelle.

L'architecture derrière les équipes d'agents

Voici comment les équipes d'agents fonctionnent réellement, sans le langage marketing.

Quand tu lances une équipe d'agents, une instance devient le chef d'équipe. Considère-le comme ton chef de projet. Il n'écrit pas de code directement (même s'il le peut). Son travail principal est de créer des coéquipiers, d'assigner des tâches, de surveiller la progression et de synthétiser les résultats. Le chef d'équipe maintient la compréhension globale de ce dont le projet a besoin et prend les décisions quand les agents ne sont pas d'accord ou sont bloqués.

Les agents restants sont les coéquipiers. Chacun dispose de sa propre session de terminal entièrement indépendante avec sa propre fenêtre de contexte. Ils peuvent lire des fichiers, écrire du code, exécuter des commandes — tout ce qu'une session Claude Code normale peut faire. Mais voici la différence avec les sous-agents : les coéquipiers ont accès à deux ressources partagées qui changent complètement la donne.

Premièrement, il y a la boîte de messages partagée. N'importe quel agent de l'équipe peut envoyer un message à n'importe quel autre agent, directement. Pas d'intermédiaire basé sur des fichiers. Pas d'attente que l'orchestrateur relaye l'information. Quand l'agent #3 découvre que le schéma de base de données a une incohérence de nommage, il envoie un message à l'agent #1 (qui construit la couche ORM) immédiatement. L'agent #1 le reçoit et ajuste sans que personne n'ait besoin d'intervenir.

Deuxièmement, il y a la liste de tâches partagée. Le chef d'équipe crée des tâches, les assigne aux coéquipiers et suit l'état d'avancement. Les coéquipiers peuvent marquer les tâches comme bloquées, terminées ou en cours. Ils peuvent aussi signaler des dépendances — « Je ne peux pas commencer l'authentification frontend tant que l'agent #2 n'a pas fini les routes API. » Le chef d'équipe voit tout ça et peut réorganiser les priorités en temps réel.

Tout cet état — la liste de tâches, la composition de l'équipe, les messages, la progression — vit dans un dossier local .dotcloud sur ta machine. Rien n'est envoyé à un serveur au-delà des appels API normaux. Tu peux l'inspecter, le versionner, et si quelque chose tourne mal, tu peux voir exactement ce que chaque agent faisait et disait.

Je veux être honnête sur un point, cependant. C'est une fonctionnalité expérimentale. Anthropic la livre désactivée par défaut, et tu dois l'activer manuellement avec un flag d'environnement. Les aspérités sont réelles — j'ai eu des agents qui rataient occasionnellement des messages de la boîte partagée, et le chef d'équipe essaie parfois de faire le travail des coéquipiers au lieu de déléguer. Ce ne sont pas des points bloquants, mais tu dois savoir dans quoi tu t'engages.

La mise en route est la prochaine chose que tu dois comprendre, parce que la configuration n'est pas évidente.

Activer les équipes d'agents (la partie que personne n'explique bien)

Voici la configuration pratique. Les équipes d'agents sont cachées derrière un flag expérimental. Tu ne trouveras pas de bouton dans l'interface de configuration de Claude Code — tu dois le définir en ligne de commande.

La variable d'environnement est :

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Ajoute ça à ton profil shell (.zshrc, .bashrc, ou là où tu gardes tes variables d'environnement) si tu veux que ce soit persistant entre les sessions. Puis redémarre ton terminal.

C'est tout. Pas de package npm à installer, pas de fichier de configuration à modifier. Une fois le flag défini, le framework d'agents de Claude Code reconnaît les commandes liées aux équipes.

Pour lancer effectivement une équipe, tu démarres une session Claude Code normale et tu lui dis de travailler en équipe :

Create an agent team with 3 teammates to build a task management dashboard

La session du chef d'équipe démarre en premier. Il analyse ta demande, décide comment diviser le travail et crée les sessions des coéquipiers. Tu verras de nouvelles fenêtres de terminal (ou onglets, selon ta configuration) apparaître à mesure que chaque coéquipier se connecte. Le chef d'équipe envoie les premières attributions de tâches via la boîte de messages, et tout le monde se met au travail.

Astuce pro : j'ai constaté qu'être explicite sur la répartition du travail dans ton prompt initial produit des résultats radicalement meilleurs que de laisser le chef d'équipe se débrouiller. Au lieu du prompt ci-dessus, essaie quelque chose comme :

Create an agent team to build a task management dashboard.
Teammate 1: Build the backend API with Express and PostgreSQL
Teammate 2: Build the React frontend components and state management
Teammate 3: Handle authentication, middleware, and database migrations

Ce seul changement — la définition explicite du périmètre — a réduit mes incidents « d'agents qui se marchent dessus » d'environ 80 %. Je t'expliquerai pourquoi c'est si important dans la section des bonnes pratiques plus loin.

D'abord, laisse-moi te montrer à quoi ressemblent les équipes d'agents en utilisation réelle. Parce que la théorie c'est bien, mais je n'ai commencé à faire confiance à cette fonctionnalité qu'après l'avoir vue résoudre de vrais problèmes plus vite que je ne le pouvais.

Test en conditions réelles #1 : revue de code et corrections en parallèle

Mon premier vrai test était volontairement simple. J'avais un projet Node.js avec environ quinze fichiers TypeScript — une API REST pour un projet client — qui avait besoin d'une passe de revue et de corrections de bugs avant le déploiement.

Normalement, je demanderais à Claude de revoir le code, j'obtiendrais une liste de problèmes, puis je les passerais en revue un par un. Selon la complexité de la base de code, ça prend entre quinze et trente minutes pour une passe approfondie. C'est séquentiel : trouver un problème, corriger le problème, passer au problème suivant.

Avec les équipes d'agents, j'ai configuré deux coéquipiers :

• Agent A : Revoir chaque fichier, identifier les bugs, les erreurs de typage et les failles de sécurité. Envoyer chaque découverte à l'Agent B via la boîte de messages au fur et à mesure.
• Agent B : Attendre les découvertes de l'Agent A. Corriger chaque problème dès qu'il arrive. Si une correction nécessite du contexte sur l'intention de conception d'origine, envoyer un message à l'Agent A pour demander.

Ce qui s'est passé était véritablement fascinant. L'Agent A a commencé à parcourir la base de code et en trente secondes, il a envoyé sa première découverte à l'Agent B : une vérification de null manquante sur un résultat de requête de base de données qui pouvait planter le serveur dans des conditions spécifiques. L'Agent B a reçu le message et a commencé à corriger pendant que l'Agent A continuait à revoir le fichier suivant.

Les échanges se faisaient en temps réel. L'Agent A a trouvé un format de réponse d'erreur incohérent sur trois gestionnaires de routes différents. Au lieu de simplement le signaler, l'Agent A a envoyé un message à l'Agent B avec un format standardisé suggéré. L'Agent B a répondu — via la boîte de messages — avec une question sur le fait que le frontend attendait ou non le format actuel. L'Agent A a vérifié le code frontend (il avait accès au dépôt complet) et a confirmé que le frontend était assez flexible pour gérer l'un ou l'autre format.

Cet échange — question, investigation, réponse, implémentation — s'est produit entre deux agents IA sans que je touche à quoi que ce soit. Le cycle complet de revue-et-correction qui me prend normalement vingt minutes s'est terminé en environ huit. Non pas parce que les agents individuels étaient plus rapides qu'une seule session Claude, mais parce que le travail se faisait en parallèle et que les agents pouvaient se coordonner sans que je serve d'intermédiaire.

La qualité du résultat m'a impressionné aussi. Parce que l'Agent A était dédié uniquement à la recherche de problèmes (sans changer de contexte pour aussi les corriger), il a attrapé des choses qu'une revue en session unique aurait ratées, j'en suis certain. Et parce que l'Agent B pouvait poser des questions de clarification en temps réel, les corrections étaient plus réfléchies que des patchs aveugles.

C'est le moment où j'ai arrêté de considérer les équipes d'agents comme une curiosité. Mais le test suivant est là où les choses sont devenues vraiment intéressantes.

Test en conditions réelles #2 : investigation de bug sous plusieurs angles

Une application React que j'avais construite avait un bug d'état intermittent. Les utilisateurs signalaient que les données du formulaire se réinitialisaient occasionnellement après soumission — pas à chaque fois, mais assez souvent pour être exaspérant. J'avais passé environ quarante minutes à essayer de reproduire et diagnostiquer le problème manuellement avant de décider de lancer l'équipe d'agents dessus.

Ma configuration : trois coéquipiers, chacun investiguant sous un angle différent.

• Agent A : Analyser la gestion d'état du composant de formulaire, spécifiquement les hooks useEffect et leurs tableaux de dépendances.
• Agent B : Tracer le flux de données depuis la soumission du formulaire à travers l'appel API et jusqu'à la mise à jour de l'état.
• Agent C : Vérifier les conditions de concurrence dans les opérations asynchrones — appels API qui se chevauchent, mises à jour d'état qui se déclenchent avant l'arrivée des réponses.

Voici ce qui rendait cette approche puissante. Chaque agent apportait un modèle mental différent au même problème. L'Agent A raisonnait en termes de bizarreries du cycle de vie React. L'Agent B raisonnait en termes de timing réseau. L'Agent C raisonnait en termes de concurrence. Une seule session Claude aurait investigué ces angles séquentiellement, portant la charge cognitive des trois et laissant potentiellement les biais d'une investigation polluer les autres.

En deux minutes — et j'insiste là-dessus, deux minutes — les trois agents ont convergé vers la même cause racine. Une closure périmée dans un hook useEffect. L'effet capturait une référence obsolète à l'état du formulaire au montage, et quand le callback de soumission se déclenchait, il lisait des valeurs périmées dans des conditions de timing spécifiques.

L'Agent A l'a trouvé du côté React. L'Agent C l'a trouvé sous l'angle des conditions de concurrence. L'Agent B a trouvé des preuves indirectes en traçant une soumission qui avait réussi côté serveur mais montrait des données périmées dans le gestionnaire de réponse. Ils ont tous envoyé leurs découvertes au chef d'équipe, qui a synthétisé les rapports et présenté un diagnostic unifié avec une correction.

Mon flux d'investigation habituel — tester une hypothèse, l'éliminer, essayer la suivante — aurait pris cinq à dix minutes par beau jour. L'approche parallèle a compressé ça à environ deux minutes et demie. Non pas parce qu'un agent individuel était plus intelligent, mais parce que trois agents peuvent couvrir trois hypothèses simultanément.

Voici la mise en garde honnête que je dois mentionner : ça a bien fonctionné parce que les trois chemins d'investigation étaient véritablement indépendants. Personne n'avait besoin de modifier des fichiers. Personne ne pouvait entrer en conflit avec le travail des autres. Le bug était une investigation en lecture seule. Quand j'ai essayé des approches parallèles similaires pour des problèmes qui nécessitaient que les agents modifient les mêmes fichiers simultanément... ça devenait le bazar. J'en parle plus dans les bonnes pratiques.

Test en conditions réelles #3 : construire une application complète à partir d'un seul prompt

Celui-ci était l'ambitieux. Je voulais voir si une équipe d'agents pouvait prendre un seul prompt détaillé et produire une application fonctionnelle multi-pages.

Le prompt décrivait un outil de gestion de projet avec quatre pages : un tableau de bord, une vue liste de projets, une page détaillée de projet avec des tableaux de tâches et une page de paramètres. Stack technique : Next.js 14 avec App Router, Tailwind CSS et une base de données SQLite via Drizzle ORM.

Le chef d'équipe a analysé le prompt et pris une décision à laquelle je ne m'attendais pas — il a créé six coéquipiers au lieu des quatre que j'aurais faits. Voici la répartition :

• Agent 1 : Phase de recherche. Vérifier les patterns de Next.js 14 App Router, vérifier la syntaxe de Drizzle ORM pour SQLite, confirmer les exigences de configuration Tailwind.
• Agent 2 : Mise en place de l'environnement. Initialiser le projet Next.js, configurer Tailwind, mettre en place le schéma de base de données et les migrations.
• Agents 3-6 : Construire une page chacun (tableau de bord, liste de projets, détail de projet, paramètres).

Les agents de recherche et de mise en place ont tourné en premier. Les agents 3-6 attendaient — marqués comme bloqués dans la liste de tâches partagée — jusqu'à ce que les fondations soient prêtes. Quand l'Agent 2 a terminé le scaffolding du projet et la mise en place de la base de données, le chef d'équipe a débloqué les constructeurs de pages et ils ont tous démarré simultanément.

Ce qui m'a fasciné, c'était la communication constante. L'Agent 3 (tableau de bord) a envoyé un message à l'Agent 5 (détail de projet) pour demander la forme des données pour les cartes de résumé de projet, parce que le tableau de bord devait afficher des aperçus de projets qui liaient vers la page de détail. L'Agent 5 a répondu avec le schéma, et les deux agents ont construit des interfaces compatibles sans que je coordonne quoi que ce soit.

L'Agent 4 (liste de projets) a découvert que le composant de navigation devait mettre en surbrillance la page active. Au lieu de construire une solution ad hoc, il a envoyé un message à tous les constructeurs de pages pour suggérer un pattern de navigation partagé. Le chef d'équipe l'a approuvé et a assigné à l'Agent 4 la construction du composant de navigation partagé avant de continuer avec sa page.

L'ensemble du processus a consommé environ 170 000 tokens à travers tous les agents. C'est significatif — environ 8-12 $ selon ton niveau de tarification. Une approche à agent unique utiliserait moins de tokens mais prendrait considérablement plus de temps et produirait probablement des résultats moins cohérents d'une page à l'autre.

Le résultat final n'était pas parfait. Quelques incohérences CSS entre les pages nécessitaient un nettoyage manuel, et une requête de base de données était sous-optimale. Mais l'application tournait. Les quatre pages fonctionnaient. La navigation était cohérente. Le flux de données avait du sens. D'un seul prompt à une application multi-pages fonctionnelle, construite par six agents IA coordonnés, en environ douze minutes.

Je construis des choses avec l'assistance de l'IA depuis plus d'un an maintenant. C'était la première fois que j'avais véritablement l'impression de gérer une équipe plutôt que d'utiliser un outil.

Les bonnes pratiques qui comptent vraiment

Après avoir fait tourner des équipes d'agents sur une vingtaine de projets ces dernières semaines, j'ai développé un ensemble de pratiques qui séparent les sessions productives des sessions chaotiques. Ce ne sont pas des théories — chacune provient d'un échec spécifique que j'ai vécu.

Définis le périmètre de chaque agent explicitement

C'est la pratique la plus importante, et je ne peux pas assez insister dessus. Quand tu dis au chef d'équipe « construis une application web », il doit décider comment diviser le travail. Parfois il prend d'excellentes décisions. Parfois il assigne des responsabilités qui se chevauchent et causent l'écrasement du code des uns par les autres.

La solution : spécifie les fichiers ou les limites fonctionnelles de chaque agent dans ton prompt. « L'Agent 1 est responsable de tout dans /src/api/. L'Agent 2 est responsable de tout dans /src/components/. L'Agent 3 est responsable de /src/database/ et des fichiers de migration. » Quand les agents connaissent leur territoire, les conflits tombent à quasi zéro.

J'ai appris ça après une session où deux agents avaient tous les deux décidé qu'ils étaient responsables du fichier de types partagé. Ils n'arrêtaient pas d'écraser les interfaces de l'autre. Vingt minutes de calcul gaspillées.

Assigne des tâches véritablement indépendantes

C'est lié à la définition du périmètre, mais distinct : les tâches elles-mêmes doivent être parallélisables. Si le travail de l'Agent B dépend entièrement de la sortie de l'Agent A, en faire des coéquipiers ajoute de la surcharge de coordination sans aucun bénéfice de parallélisme. Tu ferais mieux d'exécuter ces tâches séquentiellement dans une seule session.

Le sweet spot, ce sont les tâches qui sont majoritairement indépendantes mais bénéficient d'une communication occasionnelle. Construire différentes routes API qui partagent un format de réponse commun. Créer différents composants UI qui ont besoin d'un style cohérent. Investiguer différentes causes potentielles du même bug.

Gère la patience du chef d'équipe

Voici une bizarrerie qui m'a piégé plusieurs fois. Le chef d'équipe devient parfois impatient. Si un coéquipier met plus d'une minute ou deux sur une tâche, le chef d'équipe décide occasionnellement « d'aider » en faisant le travail lui-même. Ça a l'air utile, mais ça anéantit l'objectif de la délégation et peut créer des conflits avec le coéquipier qui travaille encore sur la même tâche.

Mon palliatif : dans le prompt initial, je dis explicitement au chef d'équipe d'attendre que les coéquipiers finissent et de ne pas commencer à travailler sur les tâches assignées lui-même. Quelque chose comme « Ton rôle est uniquement la coordination. N'implémente aucune tâche toi-même. Attends que les coéquipiers terminent leurs missions et synthétise les résultats. »

Cette seule phrase a réduit mes problèmes « d'interférence du chef d'équipe » d'environ 90 %.

Dimensionne les tâches au bon niveau

Les tâches trop petites créent plus de surcharge de coordination qu'elles n'en économisent. Si une tâche prend trente secondes à un agent, la surcharge de messagerie et de gestion des tâches s'accumule vite. Les tâches trop grandes risquent de gaspiller du calcul si quelque chose tourne mal et que l'agent doit être relancé.

Mon heuristique approximative : la tâche de chaque coéquipier devrait prendre entre deux et huit minutes de travail concentré. Assez court pour que les échecs ne soient pas catastrophiques. Assez long pour que le parallélisme apporte de vrais gains de temps. Pour une construction d'application web typique, ça signifie diviser par domaine fonctionnel ou par page, pas par fonctions ou composants individuels.

Surveille et sois prêt à intervenir

Les équipes d'agents sont expérimentales. Les choses dérapent. Un agent peut rester coincé dans une boucle, mal interpréter un message de la boîte partagée, ou produire du code qui ne correspond pas à ce dont l'équipe a besoin.

Garde ton terminal visible. Surveille le trafic de messages. Si un agent n'a rien produit depuis trois ou quatre minutes et n'a envoyé aucun message, il est probablement bloqué. Tue-le et réassigne la tâche. J'ai dû faire ça peut-être quatre ou cinq fois sur mes vingt et quelques sessions — pas fréquent, mais assez souvent pour que tu doives le prévoir.

Les chiffres qui comptent vraiment

Je suis les métriques depuis que j'ai commencé à utiliser les équipes d'agents sérieusement. Voici ce que les données montrent après environ deux douzaines de sessions :

Le temps d'investigation de bugs est passé d'une moyenne de cinq à dix minutes (agent unique, test d'hypothèses séquentiel) à deux à trois minutes (multi-agents, investigation parallèle). Ça ne s'applique qu'aux bugs où plusieurs angles d'investigation sont possibles. Les simples coquilles ou erreurs évidentes ne bénéficient pas d'une investigation en équipe.

Les cycles de revue de code se sont considérablement compressés. Une passe de revue-et-correction sur une base de code de taille moyenne (vingt à quarante fichiers) est passée d'environ vingt-cinq minutes à environ dix minutes. Le pattern parallèle de revue-et-correction que j'ai décrit plus haut est ma configuration d'équipe d'agents la plus utilisée.

La consommation de tokens est plus élevée. Significativement plus élevée. Une session à agent unique pour une tâche de complexité moyenne peut utiliser 30 000-50 000 tokens. La même tâche avec une équipe d'agents utilise typiquement 80 000-170 000 tokens, selon le nombre d'agents impliqués et l'intensité de la communication inter-agents. Au tarif actuel, c'est la différence entre quelques dollars et potentiellement huit à douze dollars pour une construction complexe.

Est-ce que ça vaut le coup ? Pour du travail urgent où mon taux horaire dépasse le coût des tokens ? Absolument. Pour de l'apprentissage exploratoire ou des projets sans deadline ? Un agent unique est probablement plus rentable. Je traite les équipes d'agents de la même manière que j'ajouterais des ingénieurs à un sprint — puissant quand le travail est véritablement parallélisable, gaspillé quand il ne l'est pas.

Ce que j'ai mal compris au début

Ma plus grosse erreur a été de traiter les équipes d'agents comme une version plus rapide des sous-agents. Elles ne le sont pas. Les sous-agents sont des outils. Les équipes d'agents sont... une équipe. Cette distinction compte pour la façon dont tu formules tes prompts, dont tu surveilles, et dont tu évalues les résultats.

Avec les sous-agents, tu donnes des instructions précises et tu attends un résultat précis. L'interaction est transactionnelle. Avec les équipes d'agents, tu définis des objectifs et des limites, puis tu laisses l'équipe trouver les détails d'exécution. Essayer de micro-gérer l'approche de chaque agent — spécifier les signatures de fonctions exactes, dicter les noms de variables, prescrire l'ordre des opérations — crée plus de surcharge que ça n'en économise et va à l'encontre de la force principale du système : la coordination autonome.

J'ai aussi sous-estimé l'importance du prompt initial. Avec un agent unique, tu peux rectifier le tir en cours de session. Avec une équipe d'agents, un prompt initial mal cadré envoie six agents charger dans des directions légèrement erronées simultanément. Le coût d'un mauvais départ se multiplie avec la taille de l'équipe. Passe deux minutes de plus à peaufiner ton prompt. Ça se rentabilise dix fois.

Une autre admission honnête : il y a eu des sessions où les équipes d'agents ont fait moins bien qu'un agent unique. Généralement quand la tâche était trop petite, quand trop d'agents devaient modifier les mêmes fichiers, ou quand la surcharge de coordination dépassait le bénéfice du parallélisme. Tous les clous n'ont pas besoin de ce marteau particulier. Apprendre quand NE PAS utiliser les équipes d'agents a été tout aussi précieux qu'apprendre à bien les utiliser.

Où ça va

Les équipes d'agents dans leur forme actuelle sont une preuve de concept qui fonctionne étonnamment bien pour une fonctionnalité expérimentale. Mais c'est la trajectoire qui m'enthousiasme.

La communication directe inter-agents est la primitive fondamentale qui permet une cascade de patterns plus sophistiqués. Aujourd'hui, c'est une boîte de messages partagée et une liste de tâches. Demain, ça pourrait être des agents qui se spécialisent et se souviennent de leur spécialisation entre les sessions. Des configurations d'équipe persistantes que tu peux lancer pour des workflows récurrents. Des équipes d'agents qui mélangent différents modèles — Opus pour la prise de décision du chef d'équipe, Haiku pour le travail de fond axé sur la vitesse.

Le changement de modèle mental est déjà en cours. Je me suis surpris à penser aux projets différemment. Non plus « que devrais-je demander à Claude de construire ? » mais « comment devrais-je constituer l'équipe de ce projet ? » Quels rôles doivent exister. À quoi les patterns de communication devraient ressembler. Où sont les dépendances.

C'est un changement fondamental dans la relation d'un développeur solo avec les outils IA. C'est la différence entre avoir un assistant vraiment intelligent et avoir une petite équipe d'ingénieurs qui vit dans ton terminal.

Ce à quoi je reviens sans cesse

Quand j'ai commencé cette expérience du jeudi — celle où six agents se disputaient à propos de la gestion d'état — je m'attendais à écrire un article sur une nouvelle fonctionnalité sympa. Au lieu de ça, j'ai fini par repenser tout mon workflow de développement.

La dispute sur la gestion d'état s'est résolue d'elle-même, d'ailleurs. Le chef d'équipe a examiné le raisonnement de chaque agent, a choisi Zustand parce qu'il avait le chemin d'intégration le plus simple pour les besoins du projet, et a notifié tout le monde. L'Agent #3 (celui qui avait déjà commencé avec useState) a refactorisé en environ quarante-cinq secondes. Pas d'ego. Pas de biais des coûts irrécupérables. Juste une équipe qui a communiqué, décidé et avancé.

Si tu utilises Claude Code comme outil à agent unique — et que ça marche bien pour toi — les équipes d'agents ne sont pas quelque chose que tu dois adopter demain. Elles sont puissantes pour les bonnes tâches. Gaspilleuses pour les mauvaises. Commence par le pattern de revue de code parallèle que j'ai décrit. C'est peu risqué, immédiatement utile, et ça te donne une idée de comment fonctionne la communication inter-agents avant de tenter quelque chose de plus ambitieux.

Définis le flag d'environnement. Lance deux coéquipiers. Regarde-les se parler. C'est le moment où ça fait tilt.

Travaillons ensemble

Tu cherches à construire des systèmes IA, automatiser des workflows ou faire passer ton infrastructure technique à l'échelle ? Je serais ravi de t'aider.

• Fiverr (constructions sur mesure et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io