Comment piloter plusieurs agents Claude Code ?

En centralisant objectifs, contexte, statuts et passages de relais dans un AI command center. Sans ce point de contrôle, les agents Claude Code avancent vite, mais parfois dans des directions opposées. Voici comment garder la vitesse sans perdre la maîtrise.

Pourquoi les agents se désalignent ils si vite ?

Plusieurs agents Claude Code se désalignent vite quand ils avancent en parallèle sans mémoire partagée, sans statut visible et sans objectif formulé de façon vérifiable. Claude Code, d’après la documentation officielle d’Anthropic, est un outil agentique de développement en ligne de commande : il vit dans le terminal, lit le code, modifie des fichiers, exécute des commandes et aide à travailler sur une base de code. Ce n’est pas magique. Plus il agit vite, plus il faut cadrer ce qu’il voit, ce qu’il fait et ce qu’il doit produire.

La première cause est la fragmentation du contexte. Le contexte partagé désigne les informations communes dont chaque agent a besoin pour décider correctement : objectif, contraintes, décisions déjà prises, fichiers touchés, conventions du projet. Si chaque agent ne voit qu’une partie du dépôt ou de l’historique, il optimise localement. Le résultat peut être mauvais globalement.

La deuxième cause est la dérive d’objectif, ou goal drift. Le goal drift apparaît quand un agent commence avec une intention correcte, puis s’en éloigne progressivement. Par exemple, “sécuriser l’authentification” devient “réécrire toute la couche utilisateur”, parce que l’agent rencontre du code ancien et prend des initiatives non validées.

La troisième cause est l’absence de visibilité sur la file de travail. Une file de travail est la liste ordonnée des tâches à traiter, avec leur priorité, leur propriétaire et leur état d’avancement. L’état d’avancement indique si une tâche est à faire, en cours, bloquée, en revue ou terminée. Sans cette visibilité, deux agents peuvent traiter le même sujet, ou pire, travailler sur deux hypothèses incompatibles.

La quatrième cause est l’échec de handoff. Un handoff est un passage de relais entre agents : ce qui a été fait, ce qui reste à faire, ce qui est risqué, ce qui ne doit pas être modifié. Si ce relais est flou, l’agent suivant reconstruit l’histoire à partir du code, souvent avec des trous.

Un cas classique : un agent modifie l’authentification, un autre refactorise les routes API, un troisième écrit des tests sur l’ancien comportement de session. Chacun peut produire du code utile isolément. Ensemble, ils créent des doublons, des conflits Git, des tests contradictoires et des décisions d’architecture qui s’annulent.

Le gain de vitesse existe. GitHub a publié en 2022 une étude sur Copilot indiquant que les développeurs ayant utilisé l’outil ont terminé une tâche de programmation 55 % plus vite dans l’expérience menée par GitHub. Mais cette vitesse doit être encadrée, sinon elle accélère aussi les erreurs de coordination.

Symptôme	Cause probable	Risque projet
Deux agents modifient les mêmes fichiers.	File de travail invisible.	Conflits, pertes de temps, régressions.
Les tests ne correspondent plus au code.	Contexte partagé incomplet.	Validation trompeuse.
Un agent réécrit trop large.	Goal drift non contrôlé.	Scope qui explose.
Le relais entre tâches est flou.	Handoff insuffisant.	Décisions contradictoires.

À quoi sert vraiment un AI command center ?

Un AI command center sert à rendre le travail des agents observable, priorisé et transmissible. Sans lui, plusieurs agents Claude Code peuvent avancer vite, mais dans des directions différentes, avec des décisions implicites et des changements difficiles à relire.

Concrètement, ce n’est pas forcément un outil complexe. Cela peut être un document persistant, un fichier partagé dans le dépôt, ou une petite application de type kanban. Le principe reste le même : centraliser les cartes de travail, les statuts, les dépendances, les livrables et les décisions prises en cours de route.

Colonne	Rôle
Backlog	Les objectifs à traiter plus tard. Un agent doit y lire le besoin, le contexte et les critères de succès avant de prendre une carte.
In Progress	Le travail en cours. Un agent doit y écrire ce qu’il modifie, les fichiers touchés et les hypothèses prises.
Blocked	Les sujets bloqués. Un agent doit expliquer précisément ce qui manque : décision produit, accès, test cassé, dépendance externe.
Review	Les livrables prêts à être relus. Un agent doit indiquer comment vérifier le résultat et quels risques surveiller.
Done	Les objectifs terminés. Un agent doit laisser une trace exploitable : résultat obtenu, tests réalisés, décisions importantes.

Le point le plus important tient en une règle simple : chaque carte doit représenter un objectif business, c’est-à-dire un résultat attendu pour l’utilisateur ou l’entreprise, pas une simple tâche technique.

Une mauvaise carte ressemble à ceci : Refactoriser le module paiement. Elle laisse trop de place à l’interprétation. Un agent peut nettoyer le code, un autre peut changer l’architecture, un troisième peut modifier des règles métier sans comprendre l’impact attendu.

Une meilleure carte serait : Réduire les échecs de paiement liés aux cartes expirées avec un message clair et un test de non-régression. Cette formulation fixe le problème, l’utilisateur concerné, le résultat attendu et une preuve minimale de complétion. Les agents convergent donc vers le même but.

Cette logique reprend des pratiques connues du kanban : visualiser le flux de travail, limiter le travail en cours, rendre les blocages visibles. Le Kanban Guide et les ressources pratiques d’Atlassian insistent sur ces principes, notamment la visualisation du travail et la limitation du WIP, pour Work In Progress, c’est-à-dire le travail commencé mais pas encore terminé.

Une bonne carte doit toujours contenir ces éléments indispensables : objectif, contexte, fichiers concernés, critères de complétion, dépendances, statut, agent responsable et prochain passage de relais.

Comment formuler des objectifs business utiles ?

Un bon objectif business décrit d’abord un résultat mesurable, le contexte utilisateur et les critères de réussite. La solution technique vient après. Sinon, l’agent Claude Code risque de produire du code correct localement, mais inutile pour le besoin réel.

Une instruction technique dit quoi modifier. Un objectif orienté résultat dit pourquoi la modification existe, pour qui elle compte, quelles limites respecter et quand le travail est terminé. Les agents exécutent mieux avec ce cadre, car ils peuvent arbitrer sans inventer une priorité.

Une carte exploitable tient souvent en quelques champs simples :

• Objectif : Résultat business attendu, idéalement mesurable.
• Utilisateur concerné : Client, admin, équipe support, développeur interne.
• Comportement attendu : Ce qui doit changer dans le produit.
• Contraintes : Performance, sécurité, compatibilité, design, API existante.
• Critères d’acceptation : Conditions vérifiables qui prouvent que c’est terminé.
• Zones à éviter : Fichiers, modules ou contrats à ne pas modifier.
• Livrable attendu : Code, tests, note de handoff, c’est-à-dire passation au prochain agent ou humain.

Voici trois formulations faibles, puis leurs versions corrigées :

• Faible : Corrige le bug de paiement. Corrigé : Quand un client utilise une carte expirée, afficher un message clair, ne pas créer de commande et journaliser l’erreur sans donnée bancaire.
• Faible : Ajoute l’export CSV. Corrigé : Permettre aux admins d’exporter les commandes filtrées sur 30 jours, avec colonnes id, date, montant et statut, sans dépasser 3 secondes pour 10 000 lignes.
• Faible : Écris des tests. Corrigé : Ajouter des tests unitaires sur le calcul de remise pour couvrir panier vide, coupon expiré et cumul interdit, sans modifier la logique métier.

Les critères d’acceptation réduisent la dérive d’objectif. La dérive d’objectif arrive quand l’agent optimise une interprétation différente de celle attendue. Par exemple, il améliore l’interface alors que le vrai besoin était de sécuriser un flux critique.

<section class="agent-card">
  <p><strong>Objectif business :</strong> ...</p>
  <p><strong>Contexte :</strong> ...</p>
  <p><strong>À ne pas faire :</strong> ...</p>
  <p><strong>Critères de complétion :</strong> ...</p>
  <p><strong>Dépendances :</strong> ...</p>
  <p><strong>Handoff attendu :</strong> ...</p>
</section>

Avant de lancer plusieurs agents, je découpe les cartes trop larges. Une carte floue coûte plus cher en coordination qu’elle ne fait gagner en automatisation, surtout quand deux agents touchent les mêmes fichiers ou poursuivent deux interprétations différentes.

Objectif faible	Objectif exploitable	Risque évité
Optimise la page checkout.	Réduire le temps de chargement du checkout sous 2 secondes sur mobile 4G.	Optimisation vague et non mesurable.
Refais les tests API.	Couvrir les erreurs 401, 403 et 500 sur les endpoints de commande.	Tests inutiles ou hors périmètre.

Comment partager le contexte sans tout recopier ?

Le bon réflexe n’est pas de recopier des résumés entre terminaux. Il faut créer un emplacement de contexte partagé, versionné avec Git, et lisible par tous les agents Claude Code. Git sert ici d’historique commun : chaque agent peut lire, modifier et retrouver qui a changé quoi.

Dans le dépôt, je crée généralement un dossier simple, par exemple ai-command-center. Il contient peu de fichiers, mais chacun a un rôle clair.

• kanban.md : Suit les statuts des tâches, par exemple à faire, en cours, bloqué, en review ou terminé.
• decisions.md : Garde les arbitrages importants, avec la raison et la date.
• context.md : Centralise les règles stables du projet : conventions, architecture, commandes, contraintes métier.
• handoffs.md : Documente les passages de relais entre agents.
• artifacts : Stocke les sorties utiles, comme des rapports de test, exports, plans techniques ou captures textuelles.

Un handoff robuste doit permettre à un autre agent de reprendre sans poser de question. Il doit rester factuel et court. Les points indispensables sont toujours les mêmes : ce qui a été fait, ce qui reste à faire, les fichiers modifiés, les hypothèses prises, les tests lancés, les erreurs rencontrées et la prochaine action recommandée.

Agent	Agent API
Statut	Bloqué
Fait	Ajout du client HTTP et des types de réponse pour /users.
Reste	Brancher le client sur UserService et traiter les erreurs 401.
Fichiers	src/api/users.ts, src/types/user.ts
Hypothèse	Le token JWT est déjà disponible dans authStore.
Tests	npm test — users : OK. npm run lint : erreur sur import inutilisé.
Erreur	Réponse 401 non documentée dans la spec OpenAPI.
Prochaine action	Vérifier le contrat API puis implémenter le cas 401.

Le contexte partagé ne doit pas devenir une décharge. Si tout y entre, plus rien n’est lisible. Je privilégie les informations stables, vérifiables et utiles à la décision. Une intuition non testée, une piste abandonnée ou un log brut de 500 lignes n’ont rien à faire dans context.md. Ils peuvent aller dans artifacts si une trace est vraiment nécessaire.

La visibilité doit être immédiate. Dans kanban.md, chaque tâche doit afficher un statut court : Actif, Bloqué, Review ou Terminé. Un agent actif indique son objectif courant. Un agent bloqué indique la cause et la décision attendue. Un agent en review indique les fichiers à relire. Un agent terminé pointe vers son handoff.

• Checklist : Le statut de la tâche est à jour.
• Checklist : Les fichiers modifiés sont listés.
• Checklist : Les décisions prises sont dans decisions.md.
• Checklist : Les règles durables sont dans context.md.
• Checklist : Les tests lancés et leurs résultats sont indiqués.
• Checklist : Les erreurs ou blocages sont explicites.
• Checklist : La prochaine action est assez claire pour être exécutée directement.

Quels outils choisir pour démarrer simplement ?

Un fichier Markdown bien tenu suffit pour démarrer. Quand le nombre d’agents Claude Code, de cartes ou de dépendances augmente, un outil visuel comme Notion, Airtable, Linear, Trello ou GitHub Projects devient utile pour garder une vue claire du travail.

Les prérequis restent simples, mais ils doivent être solides. Claude Code doit être installé localement, le dépôt doit être structuré, les conventions de nommage doivent être explicites, et un dossier de contexte partagé doit exister. Les prompts doivent être structurés, avec un objectif, des contraintes, les fichiers concernés et des critères de complétion clairs. Un critère de complétion, c’est la condition qui permet de dire qu’une tâche est réellement terminée, pas seulement “à peu près faite”.

Deux approches fonctionnent bien au départ.

• Markdown dans le repo. Cette option garde les cartes proches du code. Git versionne chaque changement, donc l’historique reste traçable. C’est excellent en solo ou sur un petit projet. La limite arrive vite côté visibilité équipe, filtrage, priorisation et suivi des blocages.
• Outil kanban externe. Un kanban est un tableau de suivi avec des colonnes comme À faire, En cours, Bloqué, En revue et Done. Notion, Trello, Linear, Airtable ou GitHub Projects donnent une meilleure vue d’ensemble, surtout avec plusieurs agents. Le filtrage, les assignations et les automatisations deviennent plus simples. La limite, c’est le risque de séparer la vérité du code si le repo et le tableau racontent deux histoires différentes.

Le démarrage peut tenir en cinq étapes.

• Créer le dossier de contexte. Par exemple context/, avec project.md, architecture.md, conventions.md et decisions.md.
• Définir les colonnes. À faire, En cours, Bloqué, En revue, Done suffisent au départ.
• Écrire les premières cartes business. Chaque carte doit décrire une valeur utilisateur, pas seulement une tâche technique.
• Lancer un agent par carte. Chaque agent reçoit une mission courte, bornée et vérifiable.
• Imposer un handoff avant Done. Le handoff est le passage de relais écrit : ce qui a été fait, ce qui reste fragile, ce qui doit être relu.

Quelques règles évitent beaucoup de désordre. Pas plus d’un agent sur la même zone critique sans coordination. Pas de carte Done sans test, revue ou validation explicite. Pas de nouvelle décision importante sans entrée dans decisions.md.

L’automatisation aide, mais elle ne remplace pas la discipline. Les notifications de blocage, la création automatique de cartes ou la synchronisation entre GitHub Issues et le kanban sont utiles si une seule source de vérité reste claire.

Contexte	Choix simple
Solo	Markdown dans le repo
Petite équipe	GitHub Projects ou Trello
Équipe produit	Linear, Notion ou Airtable
Besoin de reporting	Airtable, Linear ou Notion
Besoin d’automatisation	GitHub Projects, Linear ou Airtable

Et si le vrai gain venait surtout de la coordination ?

Les agents Claude Code peuvent accélérer fortement le développement, mais seulement si leur travail reste lisible et coordonné. Le point clé n’est pas de lancer plus de sessions en parallèle. C’est de créer un AI command center simple, avec des objectifs business clairs, un statut partagé, un contexte commun et des passages de relais propres. Je commencerais petit : un kanban, quelques modèles de cartes, un fichier de décisions et une règle stricte sur les handoffs. Vous gardez ainsi la vitesse des agents sans subir le chaos opérationnel, avec un bénéfice direct : moins de doublons, moins de blocages, plus de livrables réellement exploitables.

FAQ

• Qu’est-ce qu’un AI command center pour agents Claude Code ?
  C’est un espace de pilotage partagé qui centralise les objectifs, les statuts, le contexte, les décisions et les passages de relais entre plusieurs agents Claude Code. Il peut être très simple : un fichier Markdown dans le dépôt, un tableau kanban ou un outil comme Notion, Airtable, Trello, Linear ou GitHub Projects.
• Pourquoi plusieurs agents Claude Code peuvent-ils créer du chaos ?
  Chaque session travaille avec son propre contexte. Sans source de vérité partagée, les agents peuvent répéter le même travail, modifier des zones incompatibles, prendre des décisions différentes ou démarrer une tâche sans connaître le résultat d’une tâche précédente.
• Faut-il un outil complexe pour coordonner plusieurs agents ?
  Pas au départ. Un kanban Markdown bien structuré dans le dépôt suffit souvent. L’important est d’avoir des colonnes claires, des cartes orientées objectif business, des critères de complétion et un protocole de handoff. Les outils visuels deviennent utiles quand l’équipe, les dépendances ou le reporting se complexifient.
• Comment éviter la dérive d’objectif avec Claude Code ?
  Il faut formuler chaque carte comme un résultat attendu, pas comme une instruction vague. Un bon objectif précise l’utilisateur concerné, le problème à résoudre, les contraintes, les critères d’acceptation, les fichiers sensibles et le livrable final. Plus l’objectif est vérifiable, moins l’agent interprète de travers.
• Que doit contenir un bon handoff entre agents ?
  Un bon handoff indique ce qui a été fait, ce qui reste à faire, les fichiers modifiés, les décisions prises, les hypothèses, les tests lancés, les erreurs rencontrées et la prochaine action recommandée. L’objectif est qu’un autre agent, ou un humain, puisse reprendre sans reconstituer tout le contexte.

 

 

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 clients 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, vous pouvez me contacter.