Comment gérer plusieurs agents Claude Code sans chaos ?

Avec un centre de commande simple, vous gardez le contrôle sur plusieurs agents Claude Code. L’enjeu n’est pas d’ajouter un outil de plus, mais de partager le contexte, clarifier les objectifs business, suivre les blocages et sécuriser les passages de relais.

Pourquoi le parallèle déraille-t-il ?

Le parallèle déraille rarement à cause du modèle seul. Il déraille quand plusieurs sessions Claude Code avancent chacune avec leur propre contexte, leurs propres hypothèses et une visibilité limitée sur ce que font les autres.

Le premier problème est humain. Si je pilote trois agents en même temps, je passe mon temps à recharger mentalement le sujet de chaque session. Un agent travaille sur les migrations SQL, un autre sur l’API, un troisième sur les tests. À chaque retour, il faut relire, vérifier l’intention, comparer avec le plan initial et décider quoi faire. Ce basculement de contexte permanent finit par coûter plus cher que le parallélisme gagné.

Le deuxième problème est la perte de suivi. Une session peut avoir corrigé un bug, changé une convention de nommage ou supprimé un cas limite. Si cette décision reste dans le fil de discussion local, les autres agents ne la voient pas. C’est ce qu’on appelle la fragmentation du contexte : chaque agent ne connaît pas automatiquement les décisions prises ailleurs, sauf si elles sont écrites, centralisées et partagées.

Le troisième problème est la duplication d’efforts. Deux agents peuvent résoudre le même problème avec deux approches différentes. Par exemple, l’un ajoute une validation dans le contrôleur, pendant que l’autre crée une validation dans le service métier. Localement, les deux réponses sont défendables. Globalement, le code devient redondant, plus difficile à maintenir et plus ambigu pour la suite.

Le quatrième problème est plus discret : les consignes contradictoires. Une consigne trop technique peut pousser un agent à optimiser un détail au détriment de l’objectif réel. C’est la dérive des objectifs, ou goal drift : l’écart progressif entre l’intention business initiale et ce que l’agent finit par optimiser. Si je demande “Réduis la latence de cette requête” sans préciser les contraintes produit, l’agent peut supprimer des jointures utiles, casser un filtre métier et produire une réponse rapide mais fausse.

Exemple classique : un agent modifie la couche d’accès aux données et renomme une méthode getActiveCustomers en findBillableCustomers. Pendant ce temps, un autre réécrit un service dépendant avec l’ancienne interface. Aucun des deux n’a tort dans sa session. Mais à l’intégration, la compilation casse, les tests échouent et le temps gagné disparaît.

Symptôme	Cause probable	Conséquence business
Travail difficile à valider	Contexte dispersé entre sessions	Décisions plus lentes et risque d’erreur accru
Deux solutions pour le même problème	Absence de plan partagé	Dette technique et maintenance plus coûteuse
Résultat techniquement correct mais inutile	Dérive des objectifs	Fonctionnalité livrée en décalage avec le besoin réel

À quoi sert un centre de commande ?

Un centre de commande sert à éviter une situation simple : plusieurs agents Claude Code travaillent, mais personne ne sait vraiment sur quoi, pourquoi, ni dans quel état. Son rôle est de rendre le travail visible, persistant et coordonné.

Concrètement, ce centre peut être un fichier markdown dans le dépôt, une page Notion, une base Airtable, un document partagé ou une petite application interne. Le support importe moins que la règle : l’état doit rester lisible, à jour et consultable par tous les humains comme par les agents.

Une structure kanban suffit dans la majorité des cas. Kanban désigne un tableau de suivi où chaque carte avance de colonne en colonne selon son état.

Colonne	Rôle	Question à poser	Action humaine attendue
Backlog	Stocker les objectifs à traiter.	Est-ce vraiment prioritaire ?	Clarifier, prioriser ou supprimer.
In Progress	Montrer ce qui est en cours.	Qui travaille dessus maintenant ?	Limiter le nombre de sujets ouverts.
Blocked	Signaler un blocage.	Quelle décision manque ?	Débloquer, arbitrer ou fournir du contexte.
Review	Contrôler le livrable.	Le résultat répond-il au besoin ?	Relire, tester et valider.
Done	Archiver ce qui est terminé.	Le résultat est-il utilisable ?	Fermer ou documenter la suite.

La règle centrale est simple : chaque carte doit représenter un objectif business, pas seulement une micro-tâche technique. Une mauvaise carte ressemble à “Modifier user.service.ts” ou “Corriger la fonction validateEmail”. Une bonne carte ressemble plutôt à “Réduire les erreurs d’inscription liées aux emails invalides” ou “Permettre au support de retrouver une commande en moins de 10 secondes”.

Chaque carte doit contenir assez de contexte pour qu’un agent avance sans inventer la moitié du besoin.

• Objectif business : Résultat attendu côté utilisateur, équipe ou produit.
• Contexte : Pourquoi ce sujet existe et ce qui a déjà été décidé.
• Fichiers concernés : Chemins probables dans le dépôt.
• Agent responsable : Agent chargé de produire le livrable.
• Statut : Backlog, In Progress, Blocked, Review ou Done.
• Critères d’achèvement : Conditions vérifiables pour dire que c’est terminé.
• Dépendances : API, décision, accès ou autre carte nécessaire.
• Décision attendue : Arbitrage humain si l’agent ne peut pas trancher.
• Liens vers les livrables : Pull request, commit, document, logs ou démo.

Un modèle simple peut ressembler à ceci.

<ul>
  <li><strong>Objectif business :</strong> Réduire les abandons pendant l'inscription.</li>
  <li><strong>Contexte :</strong> Les erreurs email ne sont pas assez explicites.</li>
  <li><strong>Fichiers concernés :</strong> src/auth, src/components/signup.</li>
  <li><strong>Agent responsable :</strong> claude-agent-auth.</li>
  <li><strong>Statut :</strong> In Progress.</li>
  <li><strong>Critères d’achèvement :</strong> Tests ajoutés, message clair, parcours validé.</li>
  <li><strong>Dépendances :</strong> Validation UX du wording.</li>
  <li><strong>Décision attendue :</strong> Choisir entre blocage strict ou avertissement.</li>
  <li><strong>Liens vers les livrables :</strong> PR, capture, rapport de test.</li>
</ul>

Quels prérequis faut-il préparer ?

Avant de multiplier les agents Claude Code, je prépare l’environnement technique. Sinon, le centre de commande ne pilote rien : il documente seulement le chaos, avec des tâches qui se recouvrent, des décisions perdues et des agents qui travaillent sur des hypothèses différentes.

Les prérequis sont simples, mais non négociables. Claude Code doit être installé, authentifié et fonctionnel selon la documentation officielle d’Anthropic. Le dépôt du projet doit avoir une structure lisible. Un dossier doit centraliser le contexte partagé. Les fichiers doivent suivre une convention de nommage. Les prompts doivent être structurés. Et un support kanban doit donner une vue opérationnelle du travail en cours.

• Claude Code fonctionnel : Cela évite de découvrir les problèmes d’installation, de permissions ou d’accès au modèle au moment où plusieurs sessions tournent déjà.
• Dépôt structuré : Une arborescence claire réduit l’ambiguïté. Un agent comprend plus vite où lire, où modifier, où créer, et ce qu’il ne doit pas toucher.
• Dossier de contexte partagé : Ce dossier conserve les objectifs, les décisions, les hypothèses, les résultats et les passages de relais. Sans lui, chaque agent reconstruit une partie de l’histoire.
• Convention de nommage : Des noms prévisibles évitent les doublons et les fichiers fourre-tout comme notes-final-v2-ok.md.
• Prompts structurés : Un prompt structuré précise le rôle, le périmètre, les fichiers concernés, le résultat attendu et les contraintes. Cela limite les interprétations divergentes.
• Kanban : Un kanban est un tableau visuel avec des colonnes comme À faire, En cours, En revue et Terminé. Il donne l’état réel du système, pas seulement une liste d’intentions.

Une arborescence minimale suffit. L’objectif n’est pas de créer une bureaucratie, mais de donner aux agents un état partagé minimal.

project/
  src/
  tests/
  docs/
  context/
    00-objectifs.md
    01-hypotheses.md
    02-decisions.md
    03-handoffs.md
    04-revues.md
  prompts/
    agent-backend.md
    agent-frontend.md
    agent-review.md
  README.md

Avant de lancer plusieurs sessions en parallèle, je vérifie cette courte checklist.

• Claude Code est installé, authentifié et testé sur une tâche simple.
• Le dépôt contient une structure compréhensible par un humain pressé.
• Le dossier context existe et contient au moins les objectifs et les décisions connues.
• Les prompts indiquent le rôle, le périmètre, les fichiers à consulter et le livrable attendu.
• Le kanban reflète les tâches réelles, avec un responsable ou un agent par carte.

Comment formuler les bons objectifs ?

Un bon objectif ne dit pas seulement quoi faire. Il décrit le résultat business attendu, les contraintes importantes et les critères d’achèvement qui prouvent que le travail est terminé.

Dire à un agent Claude Code “Réécris cette requête SQL” reste trop tactique. L’agent peut optimiser la syntaxe, déplacer le problème ailleurs ou casser un comportement existant. Un objectif plus solide ressemble à ceci : “Éliminer le risque d’injection SQL sur le flux de recherche client, sans changer le comportement utilisateur, avec tests automatisés et revue humaine”. L’injection SQL désigne une faille où une entrée utilisateur modifie une requête envoyée à la base de données. OWASP, référence reconnue en sécurité applicative, classe l’injection parmi les risques majeurs de sécurité web.

Les critères d’achèvement sont les conditions observables qui permettent de dire : “C’est fini”. Ils doivent être vérifiables par un humain, un test ou une commande. Quand plusieurs agents travaillent en parallèle, ils deviennent indispensables : ils réduisent les interprétations, évitent qu’un agent annule le travail d’un autre et simplifient la revue finale.

Un prompt utile doit donc cadrer le travail dès le départ :

Objectif business :
Sécuriser le flux de recherche client contre les injections SQL, sans modifier le comportement visible pour l’utilisateur.

Contexte :
L’application Node.js utilise PostgreSQL. Le flux concerné est la recherche client dans l’interface admin.

Périmètre :
Inspecte uniquement le code lié à la recherche client.
Ne modifie pas les autres endpoints.
Ne change pas le schéma de base de données.

Fichiers à inspecter :
src/routes/customers.js
src/services/customerSearch.js
tests/customerSearch.test.js

Contraintes :
Utilise des requêtes paramétrées.
Conserve les messages d’erreur existants.
Évite les refactors non nécessaires.

Critères de réussite :
Toutes les entrées utilisateur utilisées dans les requêtes SQL passent par des paramètres.
Les tests existants passent.
Un test couvre une tentative d’injection SQL simple.
Le comportement de recherche nominal reste identique.
Le diff reste limité au périmètre défini.

Format de sortie attendu :
Liste des fichiers modifiés.
Résumé court des changements.
Commandes de test exécutées.
Risques restants ou points à revoir.

Consignes de handoff :
Documente les choix techniques.
Signale toute zone ambiguë sans la corriger hors périmètre.
Laisse un état propre pour une revue humaine.

Ce niveau de précision évite les agents “créatifs” au mauvais endroit. Il transforme une demande floue en contrat de travail vérifiable.

Tâche technique	Objectif business	Critères d’achèvement
Réécrire une requête SQL.	Réduire le risque d’injection SQL sur le flux de recherche client.	Requêtes paramétrées, tests verts, test d’injection ajouté.
Refactorer un service.	Rendre le traitement plus maintenable sans changer le comportement utilisateur.	Diff limité, tests existants conservés, documentation du changement.
Corriger un bug.	Empêcher une erreur de validation qui bloque les commandes valides.	Cas nominal testé, cas d’erreur testé, aucune régression constatée.

Comment réussir les passages de relais ?

Un passage de relais réussit quand un autre agent Claude Code peut reprendre sans relire toute la conversation précédente, ni vous demander de reconstruire le contexte. Le but n’est pas de tout raconter. Le but est de transmettre juste assez pour continuer proprement.

Une bonne note de handoff doit contenir les éléments suivants :

• Objectif initial : Ce que l’agent devait produire ou corriger.
• Décisions prises : Les choix techniques retenus, avec la raison si elle compte.
• Fichiers modifiés : Les chemins exacts, pas une description vague.
• Limites connues : Ce qui n’a pas été traité, ou ce qui reste fragile.
• Tests exécutés : Les commandes lancées et leur résultat.
• Points bloquants : Ce qui empêche d’avancer sans arbitrage humain.
• Prochaine action recommandée : Ce que le prochain agent doit faire en premier.

Les statuts évitent les faux progrès. Blocked signifie que l’agent ne peut plus avancer sans arbitrage. Review signifie que le livrable existe, mais doit être relu avant intégration. Done signifie que les critères d’achèvement sont satisfaits, testés et documentés. Sans ces statuts, un ticket peut sembler actif alors qu’il est juste confus.

Statut	Usage correct
Blocked	Décision requise, dépendance absente, ambiguïté métier.
Review	Code prêt, mais validation humaine ou technique nécessaire.
Done	Objectif atteint, tests passés, contexte mis à jour.

<p><strong>Handoff</strong></p>
<ul>
  <li>Objectif initial : ...</li>
  <li>Décisions prises : ...</li>
  <li>Fichiers modifiés : ...</li>
  <li>Tests exécutés : ...</li>
  <li>Limites connues : ...</li>
  <li>Statut : Blocked | Review | Done</li>
  <li>Prochaine action recommandée : ...</li>
</ul>

Exemple d’échec : “J’ai avancé sur l’auth, il reste deux trois trucs à vérifier.” Cette note ne dit ni où regarder, ni ce qui a changé, ni si le travail est utilisable.

Version corrigée : “Objectif initial : corriger l’expiration des sessions. Décision : centraliser la durée dans config/auth.ts. Fichiers modifiés : src/auth/session.ts, config/auth.ts. Tests exécutés : npm test auth, succès. Limite connue : pas testé sur Safari. Statut : Review. Prochaine action : relire la logique de refresh token avant merge.”

En pratique, je mets à jour la carte dès qu’un statut change ou qu’une décision structurante est prise. J’écris dans le dossier de contexte les décisions, les chemins de fichiers, les limites et les commandes de test. Je relance un agent seulement après avoir partagé ce nouveau contexte, sinon je recrée exactement le chaos que je voulais éviter.

Et si vos agents travaillaient enfin dans le même sens ?

Faire travailler plusieurs agents Claude Code en parallèle peut accélérer un projet, mais seulement si le contexte, les objectifs et les passages de relais sont maîtrisés. Le centre de commande joue ce rôle : il rend les travaux visibles, clarifie les priorités, limite la dérive des objectifs et documente les décisions. Pas besoin d’une usine à gaz. Un kanban simple, des cartes orientées business, des critères d’achèvement précis et un dossier de contexte partagé suffisent souvent pour reprendre le contrôle. Le bénéfice pour vous : moins de reprises manuelles, moins de contradictions et une production IA plus fiable.

FAQ

• Qu’est-ce qu’un centre de commande pour Claude Code ?
  C’est un espace de pilotage partagé qui centralise les objectifs, les statuts, les blocages, les décisions et les livrables des agents Claude Code. Il peut prendre la forme d’un kanban dans Notion, Airtable, un fichier markdown ou une application interne simple.
• Pourquoi plusieurs agents Claude Code peuvent-ils se contredire ?
  Chaque session peut avancer avec un contexte différent. Sans état partagé, un agent ne connaît pas forcément les décisions prises par un autre. Résultat : doublons, modifications incompatibles, priorités divergentes et passages de relais incomplets.
• Quel outil utiliser pour piloter plusieurs agents ?
  L’outil importe moins que la discipline de pilotage. Un fichier markdown bien tenu peut suffire. Notion ou Airtable deviennent utiles si vous voulez filtrer les cartes, suivre les statuts, ajouter des champs structurés et partager la vue avec une équipe.
• Comment éviter la dérive des objectifs ?
  Il faut formuler les demandes en objectifs business, ajouter le contexte utile, préciser les contraintes et définir des critères d’achèvement vérifiables. L’agent doit comprendre le résultat attendu, pas seulement la tâche technique à exécuter.
• Que doit contenir un bon passage de relais entre agents ?
  Un handoff utile résume l’objectif initial, les décisions prises, les fichiers modifiés, les tests effectués, les limites connues, les points bloquants et la prochaine action recommandée. Un autre agent doit pouvoir reprendre sans reconstruire tout l’historique.

 

 

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 process business et le SEO/GEO. J’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer vos usages IA et automatisation sans perdre le contrôle opérationnel, contactez-moi.