Comment coordonner plusieurs agents Claude Code ?

En créant un AI Command Center simple, vos agents Claude Code partagent le même contexte, les mêmes priorités et les mêmes critères de fin. Le gain n’est pas magique : moins de dérive, moins de doublons, plus de visibilité sur le travail en cours.

Pourquoi les agents Claude Code dérapent-ils ?

Les agents Claude Code dérapent surtout parce qu’ils travaillent en parallèle sans contexte partagé, sans objectifs assez précis et sans statut commun. Claude Code est, d’après la documentation officielle d’Anthropic, un outil d’IA agentique conçu pour aider au développement logiciel depuis le terminal et l’environnement de travail du développeur. Dit simplement : il peut lire le code, proposer des modifications, exécuter des commandes et aider à avancer sur des tâches de développement.

Le problème apparaît quand plusieurs sessions Claude Code tournent en même temps, dans des terminaux ou des onglets séparés. Chaque agent voit une partie du projet, mais pas forcément les décisions prises ailleurs. Résultat : le travail avance vite en apparence, puis coûte cher à recoller.

Les symptômes sont généralement très concrets :

• Perte de contexte : Un agent ignore qu’une décision technique a déjà été prise dans une autre session.
• Duplication d’efforts : Deux agents corrigent le même bug avec deux approches différentes.
• Corrections contradictoires : Un agent simplifie une fonction pendant qu’un autre ajoute une couche d’abstraction au même endroit.
• Surcharge de coordination : Vous passez plus de temps à relire, comparer et arbitrer qu’à construire.
• Oubli des décisions : Un agent revient sur un choix déjà validé, faute de mémoire projet commune.

Quatre causes reviennent souvent. La première est la fragmentation du contexte : chaque agent possède sa propre vision locale du projet. La deuxième est le goal drift, c’est-à-dire la dérive progressive de l’objectif initial. Un agent commence par “corriger la connexion”, puis finit par refactorer toute la couche utilisateur. La troisième est l’absence de visibilité sur la file de travail : personne ne sait clairement ce qui est en cours, terminé ou bloqué. La quatrième concerne les échecs de handoff, le transfert de travail ou d’informations d’un agent vers un autre.

Prenons un projet web. Un agent modifie l’authentification pour ajouter une expiration de session. Un deuxième change les routes API sans savoir que le format du token a évolué. Un troisième met à jour les tests avec l’ancien comportement, parce qu’il n’a pas connaissance des décisions précédentes. Aucun agent n’a forcément “mal travaillé”. Ils ont juste travaillé sans contexte partagé, c’est-à-dire sans mémoire projet lisible par tous.

À partir de plusieurs agents, la coordination ne peut plus reposer sur votre mémoire ou sur des messages éparpillés. Il faut un système centralisé qui garde les objectifs, les décisions, les statuts et les passages de relais au même endroit.

À quoi sert un AI Command Center ?

Un AI Command Center sert à transformer plusieurs agents Claude Code isolés en un système coordonné avec des objectifs, des statuts et des règles de passage clairs.

Dans la pratique, je le vois comme un tableau kanban persistant, léger et compréhensible par un humain comme par un agent. Kanban est une méthode de visualisation du travail qui aide aussi à limiter le travail en cours, comme le rappellent The Kanban Guide et les ressources pédagogiques d’Atlassian. Le principe est simple : chaque élément avance dans des colonnes explicites.

• Backlog : Travail identifié, mais pas encore lancé.
• In Progress : Travail en cours par un agent assigné.
• Blocked : Travail bloqué par une dépendance, une décision ou une erreur.
• Review : Travail terminé côté agent, mais à relire ou tester.
• Done : Travail validé, intégré et conforme aux critères de fin.

Ce centre peut être un simple fichier Markdown dans le dépôt, une base Notion, Airtable ou une petite application interne. L’outil compte moins que la discipline de mise à jour. Si le statut n’est pas fiable, les agents prennent de mauvaises décisions, doublonnent le travail ou modifient des fichiers sans connaître les dépendances.

Chaque carte doit représenter un objectif business, pas une micro-tâche technique. Par exemple, “Permettre à un utilisateur de réinitialiser son mot de passe” est plus utile que “Modifier auth.ts”. L’agent comprend le pourquoi, peut arbitrer correctement et évite de produire une solution localement correcte mais globalement incohérente.

Une carte utile contient peu d’informations, mais les bonnes. Le minimum opérationnel tient en quelques champs.

Élément	Rôle	Exemple
Objectif	Décrit le résultat attendu	Réduire les erreurs de paiement côté utilisateur
Contexte	Explique le pourquoi et les contraintes	Les échecs Stripe ne sont pas affichés clairement
Périmètre	Fixe ce qui est inclus ou exclu	Frontend checkout uniquement, pas de refonte backend
Fichiers concernés	Réduit les conflits entre agents	checkout.tsx, payment.service.ts
Dépendances	Signale ce qui bloque ou influence le travail	Validation du message d’erreur par le support
Agent assigné	Clarifie la responsabilité	Agent Frontend
Statut	Rend l’avancement visible	In Progress
Critères de fin	Définit quand le travail est terminé	Tests passants et message affiché en cas d’échec
Risques	Anticipe les effets secondaires	Régression sur les paiements mobiles
Prochain handoff	Prépare le passage de relais	Transmettre à l’agent QA pour tests de non-régression

Le handoff, ou passage de relais, évite qu’un agent reprenne un sujet à l’aveugle. Avec ce niveau de clarté, Claude Code ne travaille plus seulement sur du code. Il contribue à un flux de livraison lisible, contrôlable et aligné avec votre objectif produit.

Comment formuler les bons objectifs business ?

Il faut formuler les objectifs en résultats attendus, pas seulement en tâches techniques. Quand plusieurs agents Claude Code travaillent en parallèle, une consigne trop locale crée vite des décisions incompatibles : un agent optimise une fonction, un autre modifie le contrat d’une API, c’est-à-dire l’interface utilisée par d’autres systèmes, et un troisième ajuste l’interface utilisateur sans savoir quel comportement final préserver.

L’erreur fréquente consiste à demander : “modifie ce fichier”, “corrige cette fonction” ou “ajoute ce composant”. La tâche est claire, mais le résultat ne l’est pas. Pour l’agent, il manque le pourquoi : quel problème utilisateur résoudre, quel risque produit éviter, quelle métrique business améliorer. Sans ce cadre, chaque agent comble les blancs avec ses propres hypothèses.

Une bonne formulation donne plus d’autonomie à l’agent tout en réduisant les décisions contradictoires. Le bon format tient en six éléments simples :

• Contexte : Expliquer le problème, le parcours concerné et les fichiers ou services probablement liés.
• Résultat attendu : Décrire le comportement final côté utilisateur, produit ou business.
• Contraintes : Préciser ce qui ne doit pas changer, comme le contrat API, la sécurité ou les performances.
• Critères de fin : Indiquer les tests, la documentation ou les vérifications attendues.
• Zones à éviter : Nommer les fichiers, modules ou décisions réservés à un autre agent.
• Dépendances connues : Signaler les équipes, services, données ou tickets liés.

Objectif faible	Objectif fort
Ajouter un cache à l’API.	Réduire les appels répétitifs sur l’endpoint de recherche, c’est-à-dire la route appelée par le front-end, sans changer le contrat API, avec tests de non-régression et documentation du comportement de cache.
Corriger le bug de login.	Permettre aux utilisateurs existants de se connecter après expiration de session sans perdre leur panier, en conservant les règles de sécurité actuelles.
Ajouter un composant de filtre.	Permettre aux utilisateurs de filtrer les résultats par statut et date, sans dégrader le temps de chargement ni modifier la pagination existante.

Avant de lancer un agent Claude Code, je vérifie cette mini-checklist :

• Le résultat utilisateur ou business est explicite.
• Les contraintes techniques et produit sont écrites.
• Les critères de validation sont testables.
• Les zones interdites ou sensibles sont nommées.
• Les dépendances avec d’autres agents sont visibles.

Quels prérequis faut-il préparer ?

Il faut préparer Claude Code, le dépôt projet, un espace de contexte partagé et une convention de prompts avant de paralléliser les agents. Sans ces bases, vous gagnez du temps au lancement, puis vous le perdez en conflits Git, en consignes contradictoires et en reprises manuelles.

Les prérequis pratiques restent simples. Claude Code doit être installé, authentifié et capable de lire, modifier, tester puis committer le projet. Le dépôt doit être clair et navigable, avec des dossiers compréhensibles, des scripts de test identifiés et un README à jour. Si plusieurs agents travaillent en même temps, prévoyez des branches séparées ou des zones de travail isolées, par exemple une branche par fonctionnalité ou un répertoire par expérimentation.

• Un dossier de contexte dans le dépôt, versionné comme le reste du code.
• Un fichier kanban persistant pour suivre les tâches, les blocages et les responsables.
• Une convention de nommage pour les branches, les cartes et les fichiers de handoff.
• Des prompts structurés, avec objectif, périmètre, contraintes, fichiers concernés et définition du “terminé”.
• Un outil visuel optionnel, comme GitHub Projects, Linear, Trello ou un simple tableau local, si l’équipe en a vraiment besoin.

Le contexte projet stable et le contexte de tâche ne servent pas au même usage. Le contexte stable regroupe ce qui change peu : règles d’architecture, conventions de code, décisions produit, contraintes de sécurité, dépendances techniques et préférences de tests. Le contexte de tâche décrit ce qui est en cours : objectif précis, dépendances, fichiers touchés, statut, blocages et prochain passage de relais.

/ai-command-center/board.md	Liste des tâches, statuts, priorités, agent assigné et prochain livrable attendu.
/ai-command-center/context.md	Règles durables du projet, conventions, commandes utiles et limites à respecter.
/ai-command-center/decisions.md	Décisions prises, date, raison, impact et alternatives refusées.
/ai-command-center/handoffs/	Notes de passage entre agents, avec ce qui a été fait, testé, bloqué ou laissé ouvert.

Modèle court de carte kanban.

Tâche	Corriger la validation du formulaire d’inscription
Statut	En cours
Agent	Agent-backend-01
Contexte	Fichiers auth, tests API, règle produit sur les emails uniques
Terminé quand	Tests verts, cas d’erreur couverts, PR prête à relire

Un système trop sophistiqué devient vite une charge supplémentaire. Mieux vaut commencer avec quatre fichiers, des noms cohérents et des prompts propres, puis automatiser uniquement les frictions qui reviennent souvent.

Comment gérer les statuts et les handoffs ?

Les statuts et les handoffs se gèrent avec des règles écrites, des critères de passage et un résumé obligatoire à chaque transition. Sans ça, plusieurs agents Claude Code peuvent travailler vite, mais aussi se marcher dessus, refaire le même travail ou prendre des décisions incompatibles.

Un Kanban, c’est un tableau visuel qui montre l’état réel du travail. Chaque colonne doit avoir un rôle clair, sinon elle devient une zone grise.

• Backlog : Objectifs prêts à prendre ou encore à clarifier. Une carte ne devrait y rester que si le résultat attendu est compréhensible.
• In Progress : Travail actif. Un agent est responsable de l’avancement et doit indiquer la zone du code concernée.
• Blocked : Travail bloqué par une dépendance, une décision produit, une question de sécurité ou une contrainte technique non tranchée.
• Review : Travail terminé côté agent, mais en attente de validation humaine ou de relecture par un autre agent.
• Done : Travail terminé, critères vérifiés, tests utiles passés et décision documentée.

Le protocole de handoff, c’est-à-dire le passage de relais entre deux agents ou entre un agent et un humain, doit tenir en cinq points simples.

• Ce qui a été fait : Résultat obtenu, pas seulement liste d’actions.
• Fichiers modifiés : Chemins précis, par exemple src/auth/session.ts.
• Décisions prises : Choix techniques ou fonctionnels, avec la raison courte.
• Points incertains : Risques, hypothèses, tests manquants ou comportement non vérifié.
• Prochaine action recommandée : Étape concrète pour la personne ou l’agent suivant.

Pour éviter les conflits, je limite le nombre d’agents sur la même zone du code. Deux agents sur le même module d’authentification, c’est souvent une fausse bonne idée. Les dépendances doivent être visibles dans la carte, surtout si une tâche attend une API, une migration de base de données ou une décision d’architecture. Avant de passer une carte en Review ou Done, une note de sortie est obligatoire.

Exemple court et exploitable : Authentification OAuth ajoutée côté backend. Fichiers modifiés : src/auth/oauth.ts, src/routes/login.ts. Décision : utiliser PKCE pour réduire le risque d’interception du code d’autorisation. Incertain : tests manuels Google OK, GitHub non vérifié. Prochaine action : relire la gestion des erreurs et tester GitHub en staging.

Quand deux agents proposent des choix divergents, l’humain reste responsable des arbitrages produit, sécurité et architecture. L’agent peut accélérer l’analyse, mais il ne porte pas la responsabilité finale du risque.

Statut	Signal d’alerte	Action recommandée
Backlog	Objectif flou ou critères absents	Clarifier le résultat attendu avant assignation
In Progress	Deux agents modifient les mêmes fichiers	Découper la tâche ou désigner un seul responsable
Blocked	Décision manquante depuis trop longtemps	Escalader à l’humain responsable
Review	Pas de résumé de handoff	Refuser la revue jusqu’à note complète
Done	Critères non vérifiés	Rouvrir la carte et ajouter les preuves de validation

Et si le vrai sujet était la coordination ?

Multiplier les agents Claude Code ne suffit pas à accélérer un projet. Sans contexte partagé, les gains partent vite en doublons, conflits et corrections inutiles. Un AI Command Center remet de l’ordre : des objectifs business clairs, un kanban simple, des statuts visibles, des critères de fin explicites et des handoffs propres. Je préfère commencer avec un fichier markdown bien tenu plutôt qu’un outil complexe mal utilisé. Ensuite seulement, l’automatisation devient utile. Le bénéfice pour vous est concret : mieux piloter vos agents IA, réduire les erreurs de coordination et livrer plus vite sans perdre la maîtrise du projet.

FAQ

• Qu’est-ce qu’un AI Command Center pour Claude Code ?
  C’est un espace centralisé qui permet de piloter plusieurs agents Claude Code avec les mêmes objectifs, le même contexte et les mêmes statuts. Il peut prendre la forme d’un tableau kanban, d’un document markdown, d’une base Notion, d’un Airtable ou d’une petite interface interne.
• Pourquoi plusieurs agents Claude Code peuvent-ils se contredire ?
  Chaque session peut travailler avec un contexte incomplet. Si les objectifs sont flous, deux agents peuvent interpréter différemment le besoin, modifier les mêmes zones du code ou prendre des décisions incompatibles. Le problème vient rarement d’un seul agent : il vient surtout de l’absence de coordination.
• Faut-il un outil complexe pour coordonner des agents IA ?
  Pas au départ. Un fichier markdown bien structuré dans le dépôt peut suffire. L’important est d’avoir des colonnes claires, des objectifs business, des critères de fin, un contexte partagé et des règles de handoff. L’outil visuel devient utile quand le volume de cartes ou d’agents augmente.
• Quelle est la différence entre tâche technique et objectif business ?
  Une tâche technique décrit souvent une action à exécuter, par exemple modifier un composant. Un objectif business décrit le résultat attendu, par exemple améliorer le parcours de connexion sans casser le panier utilisateur. L’objectif business donne à l’agent le contexte nécessaire pour prendre de meilleures décisions.
• Comment savoir si un agent Claude Code a terminé son travail ?
  Il faut définir des critères de fin avant le lancement : résultat attendu, tests ou vérifications nécessaires, fichiers concernés, documentation à mettre à jour et résumé de handoff. Une carte ne devrait passer en Done que si ces critères sont validés ou explicitement signalés comme non vérifiables.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor sur des sujets où la donnée, l’automatisation et l’IA doivent produire des résultats mesurables. Si vous voulez structurer vos workflows IA, automatiser vos process ou former vos équipes, contactez-moi.