Comment gérer plusieurs agents Claude Code sans chaos ?

Avec un command center, plusieurs agents Claude Code peuvent travailler en parallèle sans se marcher dessus. L’enjeu n’est pas d’ajouter plus d’IA, mais de centraliser les objectifs, le contexte, les statuts et les transferts pour garder une exécution lisible.

Pourquoi les agents se désorganisent-ils ?

Les agents se désorganisent parce qu’ils travaillent souvent dans des sessions séparées, sans contexte partagé, sans statut commun et avec des objectifs parfois trop flous.

Claude Code est un outil d’assistance au développement piloté par prompts, c’est-à-dire par instructions écrites en langage naturel. Selon la documentation officielle d’Anthropic, Claude Code fonctionne dans le terminal, peut comprendre une base de code, modifier des fichiers et exécuter certaines commandes selon les permissions accordées. Une session peut donc avancer très vite sur une tâche précise. Le problème commence quand plusieurs sessions avancent vite sur des zones liées du même projet.

Quatre ruptures reviennent souvent quand plusieurs agents travaillent en parallèle :

• Fragmentation du contexte. L’information utile n’est pas disponible partout. Un agent connaît une contrainte métier, un autre ne l’a jamais vue. Résultat : chacun produit une solution localement logique, mais globalement fragile.
• Dérive d’objectif. Un agent interprète mal une demande trop vague. Par exemple, “améliore le module orders” peut vouloir dire sécuriser les requêtes, refactorer le code, accélérer les performances ou simplifier les tests.
• Absence de visibilité sur la file de travail. Personne ne voit clairement ce qui est en cours, bloqué, terminé ou à relire. Deux agents peuvent donc prendre la même tâche, ou pire, modifier deux dépendances incompatibles.
• Échecs de handoff. Le handoff correspond au passage de relais entre deux agents. Si le premier ne laisse pas d’état clair, le second doit deviner les décisions prises, les fichiers modifiés et les risques ouverts.

Prenons un module orders. Un agent sécurise les requêtes SQL pour éviter les injections, c’est-à-dire l’exécution de code SQL malveillant via une entrée utilisateur. En parallèle, un autre agent réorganise le même fichier pour séparer la logique métier et l’accès aux données. Les deux intentions sont bonnes. Mais sans coordination, le second peut écraser les protections du premier, créer un conflit Git difficile à résoudre ou produire deux abstractions incompatibles.

Le problème n’est donc pas Claude Code. Le problème, c’est l’absence de système de pilotage partagé. Sans command center, plusieurs agents rapides deviennent simplement plusieurs sources de désordre rapide.

À quoi sert un command center ?

Un command center sert à rendre visible, partagé et contrôlable le travail de plusieurs agents Claude Code.

Concrètement, c’est un document persistant ou une application légère qui centralise l’état du travail. Vous pouvez le voir comme un tableau kanban simple : chaque carte avance de colonne en colonne selon son statut. L’objectif n’est pas de faire du management visuel sophistiqué, mais d’éviter que deux agents modifient les mêmes fichiers, se contredisent ou oublient de transmettre une décision importante.

Les colonnes utiles restent volontairement simples :

• Backlog : Les sujets à traiter, pas encore assignés ou pas encore prêts.
• In Progress : Les travaux en cours, avec un agent clairement responsable.
• Blocked : Les tâches bloquées par une dépendance, une décision produit ou une incertitude technique.
• Review : Les changements terminés côté agent, mais à relire avant intégration.
• Done : Les objectifs validés, avec les critères de réussite atteints.

Le point le plus important : chaque carte doit représenter un objectif business, pas seulement une micro-tâche technique. “Corriger la fonction validateUser” donne peu de contexte. “Empêcher les inscriptions avec des emails invalides pour réduire les comptes inutilisables” aide beaucoup plus. Quand Claude Code rencontre une ambiguïté dans le code, le “pourquoi” lui permet de choisir une solution cohérente avec l’intention métier, au lieu d’optimiser localement une ligne ou une fonction.

Une carte peut rester très simple, tant qu’elle contient les informations nécessaires au passage de relais :

<ul>
  <li><strong>Objectif business :</strong> Réduire les erreurs de paiement côté utilisateur.</li>
  <li><strong>Contexte utile :</strong> Les erreurs API Stripe ne sont pas affichées clairement.</li>
  <li><strong>Fichiers concernés :</strong> checkout.ts, payment-form.tsx, stripe-client.ts</li>
  <li><strong>Critères de réussite :</strong> Message lisible, test ajouté, aucun changement non lié.</li>
  <li><strong>Agent assigné :</strong> Claude Agent 2</li>
  <li><strong>Statut :</strong> In Progress</li>
  <li><strong>Dépendances :</strong> Validation du wording par l’équipe produit.</li>
  <li><strong>Notes de handoff :</strong> Attention, checkout.ts est aussi utilisé dans le tunnel mobile.</li>
</ul>

Backlog	Liste les objectifs à traiter sans les lancer trop tôt.
In Progress	Montre qui travaille sur quoi à un instant donné.
Blocked	Rend visibles les blocages avant qu’ils ne deviennent du temps perdu.
Review	Force une étape de contrôle avant de considérer le travail terminé.
Done	Garde une trace des objectifs réellement livrés.
Notes de handoff	Transmettent le contexte entre agents sans repartir de zéro.

Comment formuler les bons objectifs ?

Il faut formuler des objectifs business mesurables, avec des critères de réussite, plutôt que des instructions techniques isolées.

Une consigne tactique décrit une action précise à exécuter. Elle peut être utile, mais elle enferme l’agent dans une solution locale. Par exemple : « Réécris cette requête dans orders.ts ». Le problème, c’est que l’agent peut modifier une seule requête, ignorer les autres accès à la base, casser un test, ou traiter le symptôme sans résoudre le risque.

Une consigne orientée résultat décrit l’état attendu du système. Par exemple : « Éliminer les risques d’injection SQL dans le module orders ». L’injection SQL est une faille où une entrée utilisateur peut modifier une requête envoyée à la base de données. Les requêtes paramétrées, aussi appelées prepared statements, sont une pratique de sécurité courante pour réduire ce risque. L’OWASP, référence reconnue en sécurité applicative, les recommande dans son SQL Injection Prevention Cheat Sheet.

Une bonne carte d’objectif donne assez de contexte pour que plusieurs agents travaillent sans se marcher dessus :

Résultat attendu	Le module orders ne doit plus exposer de risque d’injection SQL connu.
Périmètre	Fichiers liés aux commandes, notamment orders.ts, tests associés et accès base de données utilisés par ce module.
Contraintes	Ne pas changer le comportement fonctionnel existant. Préserver les signatures publiques sauf nécessité justifiée.
Critères de complétion	Toutes les requêtes sont paramétrées. Les tests existants passent. Un commentaire de revue de sécurité est ajouté à la pull request.

Ces critères réduisent l’ambiguïté. Un agent ne part pas seulement corriger une ligne pendant qu’un autre réorganise tout le module. Chacun comprend le résultat final, le périmètre autorisé et la définition de « terminé ». C’est aussi ce qui évite les annulations de travail : si deux agents touchent orders.ts, leurs décisions restent alignées sur les mêmes critères.

Plus les agents sont nombreux, plus l’objectif doit être explicite.

Comment partager le contexte utile ?

Le contexte utile doit être stocké dans un emplacement partagé, stable et facile à relire par les agents comme par les humains. Sans cela, chaque agent Claude Code risque de repartir de zéro, de contredire une décision précédente ou de modifier une zone sensible sans comprendre pourquoi elle l’est.

Avant de chercher un outil sophistiqué, quelques prérequis pratiques suffisent. Claude Code doit être installé et fonctionnel, le dépôt du projet doit être assez bien structuré, et un espace de contexte doit exister dans le repository ou dans un outil équivalent. Il faut aussi savoir écrire des prompts structurés, c’est-à-dire des consignes avec un objectif, des contraintes, des fichiers concernés et un résultat attendu. Notion, Airtable ou un fichier Markdown organisé peuvent aider, mais ils ne remplacent pas une bonne discipline d’écriture.

Un simple dossier dans le repository suffit souvent pour démarrer. Il est versionné avec Git, donc chaque changement est traçable. Il reste proche du code, donc les agents peuvent le consulter dans le même environnement. Il est aussi lisible par l’équipe, ce qui évite de créer une mémoire parallèle invisible.

docs/ai-context/
  objectifs-actifs.md
  decisions.md
  contraintes-techniques.md
  conventions.md
  zones-sensibles.md
  handoffs/
    2026-01-15-agent-api.md

Cette arborescence n’est pas une norme. Un dossier .ai/context peut très bien convenir si votre équipe préfère séparer les documents destinés aux agents. L’important reste la stabilité du chemin et la clarté du contenu.

Le contexte partagé doit contenir les informations qui évitent les erreurs coûteuses :

• Objectifs actifs : Ce que l’agent doit aider à livrer maintenant, pas toute l’histoire du produit.
• Décisions prises : Les choix déjà arbitrés, avec la raison quand elle est utile.
• Contraintes techniques : Versions, dépendances, limites de performance, règles de sécurité.
• Conventions du projet : Nommage, structure des fichiers, style de tests, règles de commit.
• Zones sensibles : Fichiers critiques, dette connue, comportements à ne pas casser.
• Notes de handoff : Une note de passage de relais indiquant ce qui est terminé, ce qui reste à faire, les fichiers touchés et les points de vigilance.

<p><strong>Handoff :</strong> Migration du module de paiement</p>

<p><strong>Terminé :</strong> Refactorisation du service PaymentService et ajout des tests unitaires principaux.</p>

<p><strong>Reste à faire :</strong> Vérifier les cas d’échec côté webhook Stripe et compléter les tests d’intégration.</p>

<p><strong>Fichiers touchés :</strong> src/payments/PaymentService.ts, tests/payments/PaymentService.test.ts</p>

<p><strong>Points de vigilance :</strong> Ne pas modifier la signature publique de createPayment sans vérifier l’impact sur l’API mobile.</p>

La valeur vient d’abord de cette discipline de coordination. L’outil choisi compte, mais il arrive seulement après : un mauvais contexte dans Notion reste un mauvais contexte, alors qu’un bon fichier partagé peut déjà éviter beaucoup de chaos.

Quels outils choisir pour démarrer ?

Le meilleur outil pour démarrer est celui que l’équipe consultera réellement, même s’il s’agit d’un simple fichier markdown dans le dépôt.

Un command center pour agents Claude Code n’a pas besoin d’être élégant. Il doit surtout rendre visibles cinq choses : les objectifs, les statuts, les blocages, les dépendances et les handoffs. Un handoff désigne le passage de relais entre deux agents, ou entre un agent et un humain, avec assez de contexte pour reprendre sans deviner.

Trois options sobres suffisent dans la majorité des cas :

• Fichier markdown dans le dépôt. C’est le choix le plus simple. Il est versionné avec Git, donc chaque modification laisse une trace. Il reste proche du code, ce qui convient bien à une équipe technique. Sa limite : la lecture devient moins agréable dès que les cartes se multiplient, et les vues par statut ou par priorité restent manuelles.
• Notion. C’est souvent plus lisible pour une équipe mixte, avec des profils produit, design, data ou métier. Les cartes, commentaires et pages liées facilitent le suivi. Sa limite : le lien avec le dépôt est moins naturel, et il faut éviter d’y créer trop de pages, sinon le command center devient un deuxième projet.
• Airtable. C’est utile quand les statuts, les responsables, les dépendances et les filtres deviennent importants. Les vues structurées aident à suivre plusieurs agents Claude Code en parallèle. Sa limite : l’outil ajoute une couche de gestion, donc il faut rester strict sur les champs utilisés.

Situation de l’équipe	Outil conseillé	Raison
Petite équipe technique, travail très proche du code	Fichier markdown	Simple, rapide, versionné dans Git, sans outil supplémentaire
Équipe mixte avec produit, métier ou design	Notion	Plus lisible pour les non-développeurs et pratique pour contextualiser les décisions
Plusieurs agents, beaucoup de statuts et dépendances	Airtable	Meilleure gestion des vues, filtres, champs structurés et priorités

Pour démarrer, il suffit de créer cinq colonnes : objectif, statut, agent assigné, blocages, handoff. Ensuite, rédigez les objectifs business en langage clair. Par exemple : “Réduire le temps de génération du rapport mensuel de 30 %”, plutôt que “Optimiser le script”. Assignez un agent par carte, exigez une note de handoff à chaque changement majeur, puis déplacez les cartes au fil de l’avancement.

Un command center efficace reste léger. S’il devient plus long à maintenir que le travail qu’il coordonne, il faut le simplifier.

Et si le vrai sujet était la coordination ?

Gérer plusieurs agents Claude Code en parallèle demande moins un outil spectaculaire qu’un système de coordination clair. Le command center sert à centraliser les objectifs business, les statuts, le contexte partagé et les passages de relais. Avec cinq colonnes simples, des cartes orientées résultat et des critères de réussite explicites, vous réduisez les conflits, la duplication d’efforts et les décisions contradictoires. Vous pouvez démarrer avec un fichier markdown, puis évoluer vers Notion ou Airtable si l’équipe en a besoin. Le bénéfice est direct : faire travailler plusieurs agents plus vite, sans perdre le contrôle du projet.

FAQ

• Qu’est-ce qu’un command center pour Claude Code ?
  C’est un espace centralisé qui permet de suivre le travail de plusieurs agents Claude Code. Il regroupe les objectifs, les statuts, le contexte utile, les blocages et les notes de passage de relais. Il peut prendre la forme d’un tableau kanban, d’un fichier markdown, d’une base Notion ou d’un Airtable.
• Pourquoi plusieurs agents Claude Code peuvent-ils créer du chaos ?
  Parce que chaque session peut avancer avec son propre contexte. Sans espace partagé, deux agents peuvent modifier les mêmes fichiers, prendre des décisions contradictoires, refaire le même travail ou ignorer qu’une étape précédente est déjà terminée.
• Quelles colonnes utiliser dans un command center ?
  Une structure simple suffit souvent : Backlog pour les objectifs à traiter, In Progress pour le travail actif, Blocked pour les blocages, Review pour les éléments à vérifier et Done pour ce qui est terminé. L’important est que chaque statut soit compris par toute l’équipe.
• Faut-il donner des tâches techniques ou des objectifs business aux agents ?
  Il vaut mieux donner des objectifs business avec des critères de réussite. Une tâche technique décrit seulement quoi faire. Un objectif explique le résultat attendu, le périmètre, les contraintes et les conditions de validation. Cela aide l’agent à prendre de meilleures décisions quand le code présente des ambiguïtés.
• Quel outil choisir pour commencer simplement ?
  Un fichier markdown dans le dépôt peut suffire pour démarrer, surtout si l’équipe technique travaille déjà dans Git. Notion peut être plus confortable pour une équipe mixte, et Airtable plus adapté si vous voulez filtrer, trier ou structurer beaucoup de cartes. Le bon choix reste celui qui sera réellement maintenu.

 

 

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, le SEO et le 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 workflows IA, automatiser vos process ou fiabiliser vos données, je peux vous aider : contactez-moi.