Comment coordonner plusieurs agents Claude Code sans chaos ?

En centralisant objectifs, contexte, statuts et décisions dans un command center. Sans ce point de contrôle, les agents Claude Code travaillent vite, mais peuvent diverger, dupliquer ou se bloquer. Voici comment structurer un pilotage multi-agent clair, orienté business et réellement exploitable.

Pourquoi les agents Claude Code dérivent ils ?

Les agents Claude Code dérivent surtout parce que chaque session travaille avec son propre contexte, ses propres interprétations et une visibilité limitée sur les autres travaux en cours.

Claude Code est un outil agentique en ligne de commande conçu par Anthropic. Concrètement, il aide à comprendre un codebase, modifier des fichiers, exécuter des commandes et travailler avec Git, comme le décrit la documentation officielle Anthropic Claude Code. Cette puissance devient un risque dès que plusieurs agents interviennent sur le même dépôt sans coordination explicite.

Le premier problème, c’est la fragmentation du contexte. Une session sait ce qu’elle a lu, ce qu’elle a modifié et pourquoi elle l’a fait. Une autre session ne le sait pas forcément. Résultat : des décisions importantes restent enfermées dans l’historique d’un onglet, au lieu d’être disponibles pour tout le système.

Le deuxième problème, c’est la dérive des objectifs. Une instruction donnée au départ peut être interprétée différemment selon les fichiers ouverts, les erreurs rencontrées ou les hypothèses prises par l’agent. Deux agents peuvent donc avancer sérieusement, mais dans des directions incompatibles.

Le troisième problème, c’est l’absence de visibilité sur l’état réel du travail. Le Kanban Guide 2020 rappelle que visualiser le travail et gérer le flux sont des principes de base pour piloter correctement une activité. Sans tableau partagé, personne ne sait clairement ce qui est en cours, bloqué, terminé ou à relire.

Le quatrième problème, ce sont les transferts incomplets entre sessions. Un agent peut découvrir une dépendance, contourner un bug, modifier une convention ou prendre une décision locale. Si cette information n’est pas transmise, le prochain agent repart avec une vision partielle.

Les symptômes sont faciles à reconnaître :

• Trop d’onglets ouverts et aucune vue d’ensemble fiable.
• Des instructions contradictoires entre deux sessions.
• Des tickets oubliés ou traités deux fois.
• Des corrections en double sur les mêmes fichiers.
• Des dépendances non signalées entre deux tâches.
• Des décisions perdues dans l’historique d’une conversation.

Le coût n’est pas seulement technique. Vous perdez du temps, vous baissez la qualité, vous introduisez des bugs et vous rendez le travail plus difficile à relire. La solution logique consiste donc à passer d’une collection de conversations isolées à un command center persistant, capable de garder la mémoire opérationnelle du projet.

À quoi sert un command center IA ?

Un command center IA sert à transformer plusieurs agents indépendants en un système coordonné, avec un lieu unique pour suivre les objectifs, les statuts, les blocages et les décisions.

Dans un projet avec plusieurs agents Claude Code, ce command center devient la mémoire opérationnelle de l’équipe. Je le vois comme un kanban persistant, c’est-à-dire un tableau de suivi qui reste disponible entre deux sessions de travail. Il peut prendre la forme d’un fichier markdown dans le dépôt, d’une base Notion, d’un tableau Airtable ou d’une petite application interne.

L’outil compte moins que la discipline de pilotage. Chaque agent doit lire le tableau avant d’agir, mettre à jour son statut après chaque étape significative et documenter les décisions prises. Sans cette règle, deux agents peuvent modifier la même zone du code, suivre deux consignes contradictoires ou refaire un travail déjà terminé.

Un flux simple suffit dans la plupart des cas. Les colonnes recommandées sont les suivantes :

• Backlog : Les objectifs à traiter, pas encore commencés.
• In Progress : Les travaux en cours, avec l’agent responsable clairement identifié.
• Blocked : Les tâches bloquées par une dépendance, une validation humaine ou une information manquante.
• Review : Les livrables prêts à être relus, testés ou intégrés.
• Done : Les éléments terminés, avec les décisions et résultats utiles pour la suite.

Colonne kanban	Rôle	Ce qu’un agent doit y écrire
Backlog	Centraliser les objectifs à traiter	Objectif attendu, contexte, priorité, contraintes connues
In Progress	Montrer qui travaille sur quoi	Agent assigné, action en cours, fichiers ou zones concernées
Blocked	Rendre visibles les dépendances	Cause du blocage, personne ou agent attendu, décision nécessaire
Review	Organiser la validation	Résumé du livrable, points à vérifier, tests effectués
Done	Conserver la trace du travail terminé	Résultat obtenu, décisions prises, liens vers commits ou documents

La colonne Blocked est souvent la plus importante en multi-agent. Un agent peut attendre le résultat d’un autre agent, une validation produit, un accès API ou une clarification métier. Si ce blocage reste dans une conversation isolée, le système entier perd en fiabilité.

Un tableau de tâches classique organise le travail. Un command center pour agents IA fait plus que cela : il préserve le contexte, évite les doubles consignes et fiabilise les handoffs, c’est-à-dire les passages de relais entre agents.

Pour que ce tableau fonctionne vraiment, les cartes doivent maintenant être formulées en objectifs business, et non en micro-tâches techniques.

Comment écrire de bonnes cartes kanban ?

Une bonne carte kanban pour agents Claude Code décrit le résultat business attendu, les contraintes de qualité et les critères de fin, pas seulement une commande technique à exécuter.

Partir du pourquoi avant le comment change la qualité des décisions. Un agent confronté à une ambiguïté doit arbitrer : modifier peu de code, refactorer, ajouter un test, demander une validation, ou s’arrêter. S’il connaît l’objectif final, il choisit plus souvent l’option utile.

Une mauvaise carte ressemble à ceci : Modifier les requêtes SQL dans le fichier auth. Elle donne une action, mais pas le risque à réduire, ni la limite à respecter. Une meilleure carte serait : Réduire le risque d’injection SQL dans le module d’authentification sans casser les tests existants. Là, l’agent comprend le résultat attendu et peut vérifier son travail.

Une carte exploitable doit contenir les éléments suivants :

• Objectif business : Expliquer le résultat attendu côté produit, sécurité, performance ou maintenance.
• Contexte : Donner les informations nécessaires pour éviter les mauvaises suppositions.
• Fichiers ou zones concernées : Indiquer le périmètre probable sans enfermer l’agent si une dépendance évidente apparaît.
• Contraintes : Préciser ce qui ne doit pas changer, par exemple l’API publique, les tests existants ou le comportement utilisateur.
• Critères d’acceptation : Lister des points vérifiables, pas des intentions vagues.
• Dépendances : Mentionner les cartes, migrations, revues ou validations nécessaires.
• Statut : Garder une trace claire de l’avancement.
• Agent assigné : Identifier qui travaille sur la carte.
• Notes de handoff : Résumer ce qui a été fait, ce qui reste à faire et les risques connus.

Les critères d’acceptation doivent pouvoir être testés ou relus. Par exemple : Toutes les requêtes sensibles utilisent des paramètres, les tests existants passent, une note de revue sécurité est ajoutée à la pull request.

L’injection SQL est une vulnérabilité où une entrée utilisateur mal contrôlée peut modifier une requête SQL. OWASP, référence largement utilisée en sécurité applicative, classe ce risque dans le Top 10 2021 sous A03:2021 Injection.

<p><strong>Objectif business :</strong> Réduire le risque d’injection SQL dans le module d’authentification.</p>
<ul>
  <li><strong>Contexte :</strong> Le module traite des identifiants utilisateur et exécute des requêtes sensibles.</li>
  <li><strong>Zones concernées :</strong> Module d’authentification, tests associés, documentation de revue sécurité.</li>
  <li><strong>Contraintes :</strong> Ne pas modifier le comportement de connexion existant.</li>
  <li><strong>Critères d’acceptation :</strong> Les requêtes sensibles utilisent des paramètres, les tests passent, une note de sécurité est ajoutée à la pull request.</li>
  <li><strong>Dépendances :</strong> Revue sécurité avant merge.</li>
  <li><strong>Statut :</strong> À faire.</li>
  <li><strong>Agent assigné :</strong> Agent sécurité backend.</li>
  <li><strong>Notes de handoff :</strong> Documenter les choix et les fichiers modifiés.</li>
</ul>

Cette granularité rend les handoffs plus propres, parce qu’un autre agent ou un humain peut reprendre le travail sans relire toute la conversation précédente.

Quels prérequis faut il préparer ?

Avant de lancer plusieurs agents Claude Code, il faut préparer l’environnement local, le dépôt, le stockage du contexte et les règles de prompt. Sans ce socle, les agents vont vite, mais pas forcément dans la bonne direction.

Claude Code doit être installé et fonctionnel localement. Chaque agent doit pouvoir lire le projet, modifier les fichiers, lancer les commandes utiles et retourner des résultats vérifiables. L’accès au dépôt projet doit être clair. Le dépôt Git sert d’historique partagé : chaque changement peut être relu, comparé et annulé si besoin.

La structure de fichiers doit être lisible. Un agent qui ne comprend pas où sont le code métier, les tests, la configuration et la documentation perd du temps ou modifie le mauvais endroit. Les tests doivent être disponibles. Même une suite minimale aide à vérifier qu’une modification ne casse pas une fonctionnalité existante.

Les conventions Git doivent être explicites. Branches, messages de commit, pull requests, règles de merge : mieux vaut les écrire avant. Les prompts doivent être structurés. Un prompt est une consigne donnée à l’agent. Il doit préciser l’objectif, les fichiers concernés, les limites, les critères de réussite et ce que l’agent ne doit pas faire.

Je recommande d’ajouter un dossier de contexte dans le dépôt, par exemple docs ou ai-context. Ce dossier peut contenir le tableau kanban, c’est-à-dire la liste des tâches par statut, les décisions prises, les conventions de code, les contraintes de sécurité et les notes de handoff, c’est-à-dire les informations transmises d’un agent à un autre. Comme ce contexte est versionné dans Git, les changements restent traçables et tous les agents travaillent sur la même base.

Option	Quand l’utiliser
Markdown dans le dépôt	Pour rester proche du code et versionner le contexte.
Notion ou Airtable	Pour une meilleure lisibilité côté équipe.
Application légère	Pour ajouter des contrôles spécifiques au workflow.

• Vérifier que Claude Code est installé et répond correctement en local.
• Vérifier que chaque agent a accès au bon dépôt et à la bonne branche.
• Vérifier que les dossiers du projet sont compréhensibles sans explication orale.
• Vérifier que les tests peuvent être lancés avec une commande documentée.
• Vérifier que les conventions Git sont écrites et partagées.
• Vérifier qu’un dossier docs ou ai-context existe dans le dépôt.
• Vérifier que les prompts indiquent l’objectif, le périmètre et les critères de réussite.

Ces prérequis ne servent pas à ralentir le projet. Ils évitent simplement que la vitesse des agents amplifie les erreurs d’organisation.

Comment lancer les agents sans perdre le fil ?

Pour lancer plusieurs agents sans perdre le fil, il faut imposer une boucle simple de travail : lire le command center, prendre une carte, exécuter, documenter, transférer ou clôturer.

Le command center est votre source de vérité opérationnelle : il centralise les objectifs, les cartes de travail, les statuts, les décisions et les blocages. Sans lui, chaque agent Claude Code avance avec une version différente de la réalité.

• Étape 1 : Définir les objectifs business avec des critères d’acceptation mesurables. Par exemple : “Le tunnel d’inscription doit accepter Google OAuth et afficher une erreur claire en cas d’échec”.
• Étape 2 : Prioriser le backlog. Les cartes les plus risquées, bloquantes ou proches de la valeur utilisateur passent devant.
• Étape 3 : Assigner une seule carte à un agent. Une carte doit avoir un périmètre clair, idéalement limité à quelques fichiers ou composants.
• Étape 4 : Fournir au prompt initial le contexte commun, la carte et les contraintes. L’agent ne doit pas deviner l’architecture ni les priorités.
• Étape 5 : Demander à l’agent de mettre à jour le statut et les notes de handoff. Le handoff désigne le transfert propre d’un travail vers un humain ou un autre agent.
• Étape 6 : Passer en Review avant Done. “Done” signifie terminé, testé et relu, pas simplement “le code compile”.

OBJECTIF
Implémenter la validation côté serveur du formulaire d’inscription.

CONTEXTE
Le projet utilise Next.js, TypeScript et Prisma.
Le command center contient la carte AUTH-12.
La priorité est de réduire les inscriptions invalides avant la création en base.

CONTRAINTES
Ne pas modifier le design.
Ne pas modifier les routes non liées à l’inscription.
Ne pas introduire de nouvelle dépendance sans justification.

FICHIERS À INSPECTER
app/signup/page.tsx
app/api/signup/route.ts
lib/validators/auth.ts
prisma/schema.prisma

CRITÈRES D’ACCEPTATION
Un email invalide est rejeté avec un message clair.
Un mot de passe de moins de 12 caractères est rejeté.
Les erreurs sont testées.
Le comportement existant reste inchangé pour les entrées valides.

PÉRIMÈTRE
Ne modifie aucun fichier hors périmètre sans demander confirmation.

HANDOFF
À la fin, produis une note avec le résumé des changements, les fichiers modifiés, les décisions prises, les tests lancés et les points à vérifier.

Quand un agent bloque, il ne faut pas le laisser improviser. Déplacez la carte en Blocked, écrivez la raison exacte, indiquez la dépendance et précisez ce qui permet de débloquer. Par exemple : “Blocked : impossible de finaliser AUTH-12, car le schéma Prisma ne contient pas encore le champ emailVerified. Déblocage attendu : décision produit sur la vérification email”.

Un bon handoff évite les reprises à zéro. Il doit contenir le résumé des changements, les fichiers modifiés, les décisions prises, les tests lancés et les points à vérifier. C’est court, factuel, exploitable.

Erreur	Conséquence	Prévention
Lancer trop d’agents sur les mêmes fichiers.	Conflits, régressions et pertes de temps.	Limiter une carte à un périmètre clair.
Utiliser des objectifs flous.	Résultats difficiles à valider.	Ajouter des critères d’acceptation.
Ne pas relire les changements.	Bugs silencieux en production.	Passer systématiquement par Review.
Oublier les tests.	Confiance artificielle dans le résultat.	Demander les tests lancés dans le handoff.
Ne pas documenter les décisions.	Contexte perdu au prochain relais.	Écrire les arbitrages dans le command center.

La coordination multi-agent devient fiable quand le command center devient la source de vérité opérationnelle.

Et si vos agents IA avaient enfin un vrai poste de pilotage ?

Faire tourner plusieurs agents Claude Code en parallèle peut accélérer un projet, mais seulement si le contexte, les priorités et les transferts sont maîtrisés. Le command center apporte cette structure : un kanban persistant, des cartes orientées business, des critères d’acceptation vérifiables, des statuts clairs et des notes de handoff exploitables. Ce n’est pas une couche de gestion en plus, c’est le minimum pour éviter que l’automatisation produise du désordre plus vite. En préparant votre dépôt, vos prompts et votre flux de revue, vous gardez la vitesse des agents sans sacrifier la qualité ni la lisibilité du travail.

FAQ

• Qu’est ce qu’un command center pour agents Claude Code ? C’est un espace de pilotage persistant, souvent sous forme de kanban, qui centralise les objectifs, les statuts, les blocages, les décisions et les notes de handoff entre agents.
• Pourquoi ne pas simplement ouvrir plusieurs sessions Claude Code ? Parce que chaque session peut perdre une partie du contexte global, interpréter différemment les consignes et travailler sans visibilité sur ce que font les autres agents. Le risque principal est de créer du travail incohérent ou dupliqué.
• Quel outil utiliser pour créer ce command center ? Un fichier markdown dans le dépôt suffit souvent pour commencer. Notion ou Airtable peuvent être pratiques pour une équipe. Le point clé reste que le command center soit lu, mis à jour et considéré comme la source de vérité.
• Pourquoi formuler les cartes en objectifs business ? Un objectif business donne le sens du travail. Si l’agent rencontre une ambiguïté, il peut arbitrer en fonction du résultat attendu, plutôt que d’appliquer mécaniquement une tâche technique trop étroite.
• Comment réussir un handoff entre deux agents ? Il faut documenter ce qui a été fait, les fichiers modifiés, les décisions prises, les tests lancés, les points incertains et la prochaine action attendue. Sans cette note, le second agent doit reconstruire le contexte et risque de repartir dans une mauvaise direction.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA dans les équipes et le SEO/GEO. J’ai travaillé pour des organisations comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer des workflows IA fiables, industrialiser vos automatisations ou former vos équipes, contactez-moi.