Comment piloter plusieurs agents Claude Code ?

Pour piloter plusieurs agents Claude Code, je centralise objectifs, contexte, statuts et blocages dans un command center. L’enjeu n’est pas d’ouvrir plus de sessions, mais d’éviter les doublons, les dérives et les transmissions ratées entre agents.

Pourquoi les agents se désorganisent-ils ?

Les agents se désorganisent parce qu’ils travaillent en parallèle sans contexte partagé, sans statut visible et parfois avec des objectifs trop vagues. Le problème ne vient pas du fait d’utiliser plusieurs agents. Il vient du fait de leur demander d’avancer vite sans leur donner un cadre commun.

Claude Code est un outil d’Anthropic qui permet de déléguer des actions de développement dans un dépôt de code, à partir d’instructions en langage naturel. La documentation officielle le présente comme un outil de codage agentique utilisable dans le terminal, capable d’aider à comprendre une base de code, modifier des fichiers et exécuter certaines tâches de développement. Source vérifiable : docs.anthropic.com/en/docs/claude-code/overview.

Quand plusieurs sessions Claude Code tournent en même temps, chaque agent voit surtout son propre fil de travail. Le contexte se fragmente. Un agent peut corriger une fonction pendant qu’un autre écrit des tests sur l’ancienne version. Un troisième peut appliquer une instruction contradictoire, parce qu’il n’a pas vu la décision prise dix minutes plus tôt.

Les problèmes apparaissent vite :

• La duplication d’efforts, avec deux agents qui résolvent le même sujet différemment.
• Les contradictions entre instructions, surtout quand les objectifs métier ne sont pas explicités.
• La surcharge humaine, car quelqu’un doit lire, comparer, arbitrer et recoller les morceaux.
• Les pertes au passage de relais, quand un agent termine sans laisser d’état clair sur ce qui a changé, pourquoi, et ce qui reste à faire.

La parallélisation utile n’est pas “plus d’agents”. C’est “plusieurs agents avec un périmètre clair”. Chaque agent doit savoir quel résultat business produire, dans quelle zone du dépôt, avec quel contexte de départ et selon quels critères d’acceptation. Un critère d’acceptation est une condition vérifiable qui permet de dire : “Oui, le travail est terminé et correct”.

Prenons un cas simple. Deux agents travaillent sur la sécurité SQL. Le premier remplace des requêtes construites par concaténation de chaînes par des requêtes paramétrées. Le second ajoute des tests contre les injections SQL. Aucun ne sait ce que l’autre a modifié. Résultat possible : les tests ciblent une ancienne signature, une régression passe inaperçue, ou la revue devient impossible parce que le diff mélange correction applicative, refactoring et tests incohérents.

Avant de chercher à automatiser davantage, il faut donc rendre le travail visible. C’est exactement le rôle d’un command center : donner un état partagé, lisible et actionnable à tous les agents comme à l’humain qui les pilote.

À quoi sert un command center ?

Un command center sert à transformer plusieurs sessions Claude Code isolées en système de travail coordonné. Sans lui, chaque agent avance dans son coin, avec son propre contexte, ses hypothèses et ses oublis. Avec lui, le travail devient visible, partageable et vérifiable.

Le modèle le plus simple reste un tableau kanban persistant avec cinq colonnes.

• Backlog contient les objectifs à traiter, mais pas encore lancés.
• In Progress regroupe les objectifs sur lesquels un agent travaille maintenant.
• Blocked rend visibles les sujets bloqués par une dépendance, une décision ou une information manquante.
• Review rassemble les changements terminés côté agent, mais pas encore validés par un humain ou par les tests attendus.
• Done contient uniquement ce qui est livré, vérifié et accepté.

Le point important : chaque carte doit représenter un objectif business, pas une micro-tâche technique. Une carte comme “Corriger la requête SQL ligne 84” enferme l’agent dans une solution. Une carte comme “Réduire le temps de chargement du dashboard finance sous 2 secondes” lui donne le pourquoi métier. Quand Claude Code rencontre une ambiguïté, ce contexte l’aide à choisir entre plusieurs options techniques sans perdre le résultat attendu.

Une carte bien structurée peut ressembler à ceci.

• Objectif business : Réduire le temps de chargement du dashboard finance sous 2 secondes pour les utilisateurs internes.
• Contexte : Le dashboard dépasse souvent 6 secondes sur les gros comptes, ce qui ralentit la clôture mensuelle.
• Fichiers concernés : app/dashboard/finance.tsx, api/reports.ts, db/queries/revenue.sql.
• Agent assigné : Agent Performance.
• Statut : In Progress.
• Dépendances : Accès aux métriques de production anonymisées.
• Critères d’acceptation : Temps de chargement inférieur à 2 secondes sur un compte de test avec 100 000 lignes.
• Blocages : Aucune donnée de benchmark validée pour l’instant.
• Lien vers les changements : Branche git perf/finance-dashboard.
• Note de handoff : Vérifier d’abord la requête revenue.sql, puis comparer avec le cache existant.

Ce modèle reprend les pratiques kanban reconnues : visualiser le travail, limiter les travaux en cours si nécessaire, et rendre les blocages explicites. The Kanban Guide et les ressources Atlassian sur les tableaux kanban documentent bien ces principes, sans imposer un outil particulier.

Élément	Rôle	Erreur à éviter
Carte objectif	Donner à l’agent un résultat métier clair à atteindre.	Créer une carte pour chaque micro-action technique.
Colonne Blocked	Montrer immédiatement ce qui ne peut plus avancer.	Laisser un agent tourner en boucle sans décision humaine.
Colonne Review	Séparer le code produit du code réellement validé.	Considérer qu’un changement est terminé dès qu’il compile.
Note de handoff	Permettre à un autre agent ou à un humain de reprendre sans repartir de zéro.	Écrire une note vague comme “à continuer”.
Contexte partagé	Aligner les agents sur les mêmes contraintes, décisions et priorités.	Laisser chaque session Claude Code reconstruire seule l’historique.

Quels prérequis faut-il préparer ?

Il faut préparer Claude Code, le dépôt, le contexte partagé et une méthode de prompting suffisamment structurée. Sans ces quatre éléments, plusieurs agents peuvent travailler vite, mais pas forcément dans la même direction.

Claude Code doit d’abord être installé et opérationnel, selon la documentation officielle d’Anthropic. Cela veut dire que l’outil se lance correctement, qu’il accède au bon dépôt, qu’il peut lire les fichiers utiles et que les commandes nécessaires sont disponibles dans l’environnement de travail.

Le dépôt doit aussi être navigable par un agent. Des conventions simples aident beaucoup : noms de fichiers explicites, dossiers cohérents, README à jour, scripts de test identifiables, commandes de validation documentées. Un agent ne doit pas deviner si npm test, pnpm test, pytest ou make test est la bonne commande.

Le point critique reste le stockage partagé du contexte. Une session d’agent ne doit jamais être le seul endroit où se trouve une décision importante. Les décisions, contraintes, blocages, hypothèses et critères d’acceptation doivent être persistés dans un espace commun. Sinon, chaque nouvel agent repart avec une mémoire partielle, ce qui augmente les risques de doublons, de contradictions et de corrections inutiles.

Option	Quand la choisir
Markdown dans le dépôt	Quand vous voulez rester proche du code, versionner les décisions avec Git et permettre aux agents de lire directement le contexte.
Notion, Airtable ou outil visuel équivalent	Quand la coordination implique plusieurs personnes et qu’un tableau lisible côté équipe devient plus pratique qu’un fichier texte.

Une structure simple peut suffire. Elle reste adaptable selon votre projet, mais elle donne un point d’ancrage commun aux agents :

/ai-command-center/board.md
/ai-command-center/context.md
/ai-command-center/handoffs/
/ai-command-center/reviews/

Le fichier board.md peut contenir des cartes de travail standardisées. Plus le format est stable, plus les agents produisent des sorties comparables.

Carte : Optimiser la validation du formulaire

Objectif :
Réduire les erreurs côté utilisateur avant l’envoi du formulaire.

Contexte :
Le formulaire actuel valide surtout côté serveur. Une validation côté client existe, mais elle est incomplète.

Contraintes :
Ne pas changer l’API existante.
Conserver les messages d’erreur actuels.
Ajouter des tests si le projet le permet.

Agent :
Claude-Agent-Frontend

Statut :
En cours

Critères d’acceptation :
Le formulaire bloque les champs invalides avant soumission.
Les tests existants passent.
Le comportement serveur reste inchangé.

Handoff :
Documenter les fichiers modifiés, les choix techniques et les points à vérifier en review.

Cette préparation paraît basique, mais elle évite le principal problème du multi-agent : des assistants compétents, mais mal synchronisés.

Comment formuler les bons objectifs ?

Les bons objectifs décrivent le résultat attendu, les critères d’acceptation et les contraintes, pas seulement l’action technique à exécuter. Avec plusieurs agents Claude Code, cette précision évite que chaque agent optimise localement une tâche sans comprendre le résultat global attendu.

Une consigne faible ressemble à : Corrige les requêtes SQL. Elle pousse l’agent à chercher du SQL, modifier du code, puis s’arrêter dès que quelque chose semble corrigé. Une consigne forte ressemble plutôt à : Réduire le risque d’injection SQL sur le module de recherche client, sans régression fonctionnelle, avec tests automatisés et note de revue sécurité. Là, l’agent comprend le risque, le périmètre, la contrainte de non-régression et la preuve attendue.

Les critères d’acceptation sont les conditions vérifiables permettant de dire que le travail est terminé. Ils doivent être concrets, observables et faciles à relire par un humain ou par un autre agent.

• Les tests automatisés passent.
• Les fichiers modifiés sont listés.
• Le risque d’injection SQL est traité sur les entrées concernées.
• Le comportement utilisateur reste inchangé.
• Un commentaire de revue explique le risque corrigé et les limites éventuelles.

Je préfère découper un objectif business en cartes orientées résultat, pas en micro-tâches techniques. Par exemple, Sécuriser le parcours de recherche client peut devenir : audit des entrées utilisateur, correction des requêtes exposées, tests de non-régression, puis revue finale. Chaque carte laisse à l’agent une marge d’exécution, tout en gardant un livrable clair.

Un prompt agent efficace suit une trame simple. Elle réduit les ambiguïtés et facilite le passage de relais, aussi appelé handoff, c’est-à-dire la transmission propre du contexte à un autre agent ou à un humain.

Contexte : Le module de recherche client utilise des paramètres utilisateur.
Objectif : Réduire le risque d’injection SQL sur ce module.
Périmètre : Recherche client uniquement, sans modifier le parcours de connexion.
Contraintes : Aucune régression fonctionnelle, conventions du projet respectées.
Fichiers à examiner : Routes, services, requêtes SQL, tests liés à la recherche.
Sortie attendue : Diff clair, fichiers modifiés, justification sécurité.
Critères de validation : Tests passants, cas dangereux couverts, comportement inchangé.
Handoff : Résumer les choix, les risques restants et les points à relire.

Formulation faible	Problème créé	Formulation forte	Bénéfice multi-agent
Corrige les requêtes SQL.	Périmètre flou et validation subjective.	Réduire le risque d’injection SQL sur la recherche client, avec tests.	Un autre agent peut vérifier le résultat sans deviner l’intention.
Améliore les tests.	L’agent peut ajouter des tests peu utiles.	Couvrir les cas de recherche nominale, vide et entrée malveillante.	Les responsabilités entre correction et validation restent claires.
Refactorise ce module.	Risque de changement inutile ou de régression.	Simplifier le service sans changer l’API ni le comportement utilisateur.	Les agents travaillent sur le même contrat fonctionnel.

Comment gérer les relais entre agents ?

Les relais se gèrent avec des notes de handoff courtes, persistantes et vérifiables, jamais avec la mémoire implicite d’une session. Une session Claude Code peut contenir beaucoup de contexte, mais ce contexte disparaît vite, se déforme ou reste inaccessible au prochain agent. Le travail fiable se transmet par écrit.

Un handoff est une transmission structurée d’un travail d’un agent à un autre, ou d’un agent vers un humain. C’est souvent là que les projets multi-agents échouent : l’agent suivant ne sait pas pourquoi une décision a été prise, quelles commandes ont été lancées, ni ce qui reste risqué. Résultat : il refait le travail, casse une hypothèse ou valide trop vite.

Une bonne note de handoff doit rester courte, mais complète sur les points qui évitent les erreurs. Voici le minimum utile :

Champ	Contenu attendu
Objectif initial	Ce que l’agent devait accomplir.
Décisions prises	Les choix techniques et leurs raisons.
Fichiers modifiés	Les chemins précis des fichiers touchés.
Commandes lancées	Les tests, scripts, migrations ou builds exécutés.
Résultats obtenus	Ce qui fonctionne, avec preuves si possible.
Blocages restants	Les problèmes non résolus ou incertains.
Hypothèses	Ce qui est supposé vrai, mais non prouvé.
Prochaines actions	Ce que l’agent suivant doit faire en priorité.

Les colonnes Blocked et Review jouent un rôle simple. Blocked sert à rendre un problème visible au lieu de le laisser enfoui dans une session. Si une API manque, si un test est instable ou si une décision produit un risque, la carte doit y passer. Review sert à vérifier le résultat avant de considérer la carte comme Done. Une tâche terminée par un agent n’est pas forcément prête à être fusionnée.

Exemple concret : l’agent A analyse le code et identifie trois requêtes SQL risquées dans src/billing/report.ts. Il ajoute à la note les lignes concernées, explique le risque d’injection SQL, puis déplace la carte en Review. L’agent B lit la carte, écrit des tests de non-régression, lance npm test — billing, puis ajoute les résultats et les cas encore non couverts. L’agent C prépare la revue humaine : il vérifie le diff, résume les changements, signale une hypothèse sur le format des identifiants clients, puis recommande soit la fusion, soit un passage en Blocked.

Avant de lancer un agent, je vérifie ces points :

• La carte contient un objectif clair et borné.
• Les fichiers ou zones du code à inspecter sont indiqués.
• Le résultat attendu est vérifiable.

Pendant l’exécution, je garde ces réflexes :

• Les décisions importantes sont écrites dès qu’elles sont prises.
• Les commandes lancées sont notées avec leur résultat.
• Les hypothèses non vérifiées sont visibles.

Avant le handoff, la note doit permettre à quelqu’un de reprendre sans deviner :

• Les fichiers modifiés sont listés.
• Les blocages sont explicitement déplacés en Blocked.
• Les prochaines actions sont ordonnées.

Avant de passer en Done, je demande une dernière vérification :

• La carte est passée par Review.
• Les tests utiles ont été exécutés.
• Le résultat correspond à l’objectif initial.

Votre équipe est-elle prête à déléguer sans perdre le contrôle ?

Piloter plusieurs agents Claude Code ne consiste pas à multiplier les fenêtres ouvertes. Le vrai levier, c’est la coordination : objectifs business clairs, contexte partagé, tableau kanban, statuts visibles, critères d’acceptation et notes de handoff. Avec ce cadre, chaque agent sait pourquoi il travaille, ce qu’il doit produire et comment transmettre proprement son résultat. Je préfère une orchestration simple, lisible et maintenable à une automatisation spectaculaire mais opaque. Le bénéfice pour vous est direct : moins de doublons, moins de dérives, des revues plus rapides et une meilleure maîtrise du travail délégué à l’IA.

FAQ

• Qu’est-ce qu’un AI command center pour Claude Code ?
  C’est un espace centralisé qui rend visible le travail de plusieurs agents Claude Code. Il peut prendre la forme d’un tableau kanban, d’un fichier markdown ou d’un outil comme Notion ou Airtable. L’objectif est de suivre les objectifs, statuts, blocages, dépendances, critères d’acceptation et transmissions entre agents.
• Pourquoi éviter de donner seulement des tâches techniques aux agents ?
  Une tâche technique décrit quoi faire, mais pas toujours pourquoi le faire. Un objectif business donne le résultat attendu, le contexte et les critères de validation. L’agent peut alors mieux gérer les ambiguïtés, éviter les corrections hors sujet et produire un résultat plus facile à relire.
• Quelles colonnes utiliser dans un tableau multi-agent ?
  Une structure simple suffit souvent : Backlog pour les objectifs à traiter, In Progress pour le travail en cours, Blocked pour les sujets bloqués, Review pour les résultats à vérifier et Done pour ce qui est validé. Ces 5 colonnes donnent une visibilité immédiate sans complexifier le pilotage.
• Que doit contenir une note de handoff entre agents ?
  Une bonne note de handoff indique l’objectif initial, les décisions prises, les fichiers modifiés, les commandes ou tests lancés, les résultats obtenus, les blocages, les hypothèses et les prochaines actions recommandées. Elle évite qu’un agent reparte de zéro ou contredise le travail précédent.
• Faut-il un outil complexe pour coordonner plusieurs agents Claude Code ?
  Pas forcément. Un fichier markdown dans le dépôt peut suffire au départ, surtout si l’équipe veut garder le contexte proche du code. Un outil visuel devient utile quand plusieurs personnes doivent suivre les statuts, priorités et blocages sans fouiller dans le dépôt.

 

 

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 métier 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 vos usages IA, automatiser vos workflows ou fiabiliser vos données, je peux vous aider à passer d’expérimentations isolées à des systèmes réellement exploitables. Contactez-moi.