Par Mathieu GRENIER — 15 août 2026
Jusqu'à cette semaine, mon réseau agentique avait une limite claire : il était cantonné à un seul projet à la fois. Chaque orchestrateur, avec ses sous-agents, résolvait les problèmes de développement d'un périmètre fermé. Le passage à plusieurs projets en parallèle semblait simple sur le papier — mais il manquait un chaînon essentiel : la capacité pour les orchestrateurs de se parler, entre eux et avec leurs sous-agents.
Cette semaine, j'ai pu tester ce fonctionnement multi-projets, grâce à une feature de communication bidirectionnelle. Des orchestrateurs (frontend Svelte 5, backend php symfony, devops docker) dialoguent désormais directement, tout en gardant le lien avec leurs propres agents. Et un agent central .pi peut interviewer chacun d'eux pour recueillir leurs doléances et améliorer les outils de délégation et de communication. C'est un vrai cap, et je veux vous en parler de manière factuelle, avec les exemples concrets qui m'ont convaincu — et les limites que j'ai rencontrées.
Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
D'un réseau mono-projet à un réseau multi-projets
Le point de départ, c'est un réseau agentique mono-projet : un orchestrateur par projet, qui délègue à ses sous-agents (coder, runner, scout, memory-curator…), et veille sur leur travail. Cela fonctionnait, mais sans communication entre orchestrateurs. Trois projets distincts, trois orchestrateurs, trois univers parallèles qui ne se croisaient jamais.
Or, dans le développement réel, les projets ne sont pas des îles. Un fix d'infrastructure sur un serveur débloque une chaîne de traitement backend, qui lui-même sert les décisions du frontend (svelte5). Sans canal inter-projets, chaque équipe d'agents résolvait ses problèmes en silo, et les corrections devaient transiter par moi.
Le passage au multi-projets a exigé deux choses : un transport de messages fiable entre orchestrateurs, et une philosophie d'orchestration que je ne savais pas nommer avant — celle où l'orchestrateur n'est pas seulement un distributeur de tâches, mais un chef qui observe et corrige le cap en continu.
La communication bidirectionnelle, le chaînon manquant
Tout repose sur un transport par sockets unix (dans ~/.pi/coms/sockets/), des registres par projet et des enveloppes JSON (prompt, response, ping, nudge) avec accusé de réception et une limite de cinq hops. Concrètement, cela signifie que les orchestrateurs peuvent utiliser coms_send, coms_get, coms_await, coms_reply et coms_check entre eux, comme je le fais moi-même avec mes agents.
La nouveauté qui a tout déclenché, c'est le caractère bidirectionnel. Ce n'est pas une simple messagerie descendant (l'orchestrateur qui donne des ordres), ni une simple remontée (le sous-agent qui rend des comptes). C'est un dialogue. Un sous-agent peut solliciter son orchestrateur — et dans le sens inverse, l'orchestrateur peut orienter son sous-agent en pleine exécution.
Un exemple parlant vient du frontend svelte5. Son memory-curator, qui n'a pas le droit d'écrire arbitrairement, a demandé via coms de barrer un lot de tâches dans le plan d'orchestration après avoir écrit trois éléments. Le workflow « single-writer » a imposé que la demande passe par l'orchestrateur, qui a barré le lot. Résultat : aucun doublon, aucun conflit d'écriture. C'est le chaînon manquant du mono-projet : un agent n'est plus un exécutant aveugle, il est un acteur qui converse.
L'orchestrateur, chef d'orchestre et garde-fou
Le deuxième pilier, c'est le rôle actif de l'orchestrateur. Il ne délègue pas et s'efface : il suit le travail de ses agents et peut les rediriger quand il les voit dériver. La redirection en cours d'exécution est devenue un outil de premier ordre, et non une intervention chirurgicale exceptionnelle.
Sur le backend php, un runner est resté bloqué près de 12 minutes à écrire son script sans jamais l'exécuter. Constaté, il a été déclaré défaillant et relancé proprement — sans débat, sans boucle d'attente. Dans un autre cas, un runner a émis un +$now+ littéral dans du JSON, à cause d'une substitution shell cassée ; le script a été réécrit en python3 + ARGV. Leçon importante apprise ce jour-là : on ne steer pas un runner qui progresse. Un de mes premiers steers, pourtant bien intentionné, avait fait boucler un runner environ 10 minutes à répondre aux messages au lieu d'avancer.
Sur l'infra, un runner de kill a remonté un échec intermédiaire : sa boucle grep s'était auto-tuée. La redirection a tenu en cinq lignes : « PIDs fixes, pas de boucle ». Exécuté, vérifié, relancé. Un runner cache:clear avait dérivé 22 secondes dans une découverte de dossier inutile — re-dispatch avec un workdir absolu : 18 secondes, exit 0.
Sur le frontend, un runner qui croisait un inventaire utilisait des boucles for cassées par le wrapper shell ; il s'est adapté seul vers find -o, sous la contrainte d'un prompt initial ferme et d'une surveillance du status-file à plus de 30 secondes. L'orchestrateur agit donc comme un chef d'orchestre et un garde-fou : il suit sans bloquer, il redirige quand c'est pertinent, et il n'intervient pas quand le travail progresse.
Un méta-orchestrateur qui améliore ses propres outils
La pièce la plus originale de l'architecture, c'est l'agent central .pi. Insistons sur ce qu'il fait et ne fait pas : il ne pilote pas. C'est une distinction importante. Chaque orchestrateur de projet lui envoie ses doléances via coms_send — un canal fiable, car les coms_reply montraient des pertes inter-projets. Le central trie ces doléances en quatre catégories, Ambiguity, False info, Struggle, Suggestion, fait valider le tri par l'utilisateur, délègue l'implémentation, puis vérifie directement par lecture — jamais sur parole.
Les orchestrateurs ont effectivement nourri cette boucle. le backend a remonté des coms_reply non routés (contenu perdu à trois reprises), des coms_await répondant « unknown msg_id », des noms d'orchestrateurs qui rotent par session, un batch curator tué en plein write. L'infra a signalé des pertes de coms_reply, des runners morts à max_steps, et le fait que docker exec -d n'attache pas stdout. Le frontend Svelte5 a noté les dead-letters silencieux vers un sous-agent terminé et les boucles for transformées par le wrapper shell.
Ce mécanisme alimente des corrections réelles dans ~/.pi/extensions/ : coms.ts ré-résout le sender au moment du coms_reply, conserve les messages en attente au timeout, porte le TTL entrant de 5 à 30 minutes, met en cache les réponses déjà livrées, et détecte rapidement un récepteur mort ou roté. Un mécanisme de nudge automatique à 5 minutes a été ajouté. pi-delegate.ts maintient un fichier de statut JSON par délégué (aperçu de sortie, étapes, code de sortie) pour suivre sans bloquer.
Voilà ce qui rend ce pattern intéressant : le central n'améliore pas un produit, il améliore la couche de délégation et de communication elle-même. C'est une boucle de feedback qui se referme sur l'outillage.
Ce qui existe déjà, et ce qui est vraiment nouveau
Forcément, je me suis demandé si d'autres avaient fait ça avant. La recherche montre un paysage contrasté. Dans les bâtiments publics, l'orchestration est hiérarchique (LangGraph, CrewAI, AutoGen), avec les protocoles A2A/MCP — le Microsoft Agent Framework est nativement compatible A2A depuis avril 2026. L'idée d'un « orchestrateur-d'orchestrateurs » existe, mais limitée à une seule application : c'est le cas de metaswarm, « swarm of swarms » de février 2026, ou des équipes hiérarchiques de LangGraph de janvier 2024.
Le point notable : le multi-projet / multi-repo comme unité d'orchestration de premier ordre n'apparaît nulle part dans la littérature comme traitement à part entière. Et surtout, le méta-orchestrateur central qui interviewe ses sous-orchestrateurs pour améliorer l'outillage lui-même, c'est réellement nouveau comme pattern nommé de bout en bout. L'analogie la plus proche est la boucle self-reflect de metaswarm — mais elle améliore le produit, pas la couche délégation/communication. La couverture francophone, elle, reste muette sur ce pattern précis.
Je le dis prudemment : ce n'est pas une preuve d'unicité absolue, c'est un état de la recherche au moment où j'écris. Mais sur la question spécifique du dialogue inter-orchestrateurs multi-projets, je n'ai trouvé nulle part ce pattern décrit de bout en bout.
La prochaine étape : parallélisme et coordinateurs
Je serai honnête sur l'état actuel. Cinq à six projets tournent déjà en « live » avec cette architecture. La journée d'aujourd'hui a été un test réussi du fonctionnement multi-projets. Mais ce n'est pas encore du parallélisme au sens plein : nous échangeons, nous coordonnons, chaque projet avance — mais je n'ai pas encore déployé le réseau sur de multiples projets en parallèle avec des agents coordinateurs.
C'est l'objectif suivant, et il a un nom. En plus des orchestrateurs par projet, je veux des coordinateurs par domaine : des agents qui ne portent pas un projet, mais un ensemble de projets, capables de trancher les arbitrages transverses (un problème d'infrastructure qui bloque trois projets, une décision de sécurité partagée, une bascule de service auditable). La communication bidirectionnelle que je teste depuis aujourd'hui pose exactement la fondation dont ces coordinateurs auront besoin.
Conclusion
Passer d'un réseau agentique mono-projet à un réseau multi-projets n'est pas qu'un changement d'échelle, c'est un changement de nature. Ce n'est plus une hiérarchie où un chef distribue des tâches, mais un système qui converse : des orchestrateurs qui se parlent, des sous-agents qui dialoguent avec leurs chefs, un agent central .pi qui les interroge pour rendre les outils de délégation et de communication plus fiables.
Ce que j'ai appris cette semaine mérite d'être dit franchement. La communication bidirectionnelle est le chaînon manquant — sans elle, le multi-projets restait un vœu. La redirection en cours d'exécution fonctionne, à condition de respecter une règle simple : on steer un agent qui dévie, jamais un agent qui progresse. Et le méta-orchestrateur qui améliore ses propres outils est, au moment où j'écris, un pattern encore neuf — documenté ici de bout en bout, mais sans équivalent identifié dans la littérature courante.
Le réseau agentique n'est plus un objet mono-projet. Il devient un système multi-projets qui apprend de ses propres orchestrateurs. La prochaine étape — le parallélisme et les agents coordinateurs — en est la suite logique, et la fondation posée aujourd'hui est exactement celle dont elles auront besoin.
Qui suis je ?
Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.
J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.
Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.
L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.
La technologie, les méthodes, le management sont le cœur de mes compétences.
Vous pouvez me faire confiance sur ces points là.
Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr
Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.
Sources
- Dsifry, « metaswarm » (swarm of swarms, fév. 2026) — https://github.com/dsifry/metaswarm
- LangChain, « LangGraph multi-agent workflows » — https://blog.langchain.dev/langgraph-multi-agent-workflows
- Microsoft, « AutoGen group chat » — https://microsoft.github.io/autogen/group-chat
- Microsoft Agent Framework, « A2A integration » — https://learn.microsoft.com/agent-framework/integrations/a2a
- Flowt, « Systèmes multi-agents : l'orchestration » — https://flowt.fr/systemes-multi-agents-orchestration
- IBM, « AI agents orchestration » — https://ibm.com/fr-fr/ai-agent-orchestration
- Swiss AI, « Orchestration guide » — https://swiss.ai/fr/ai-orchestration-guide
- Retour d'expérience interne (tests multi-projets 2026-08-15, extensions coms/pi-delegate, doléances des orchestrateurs dev2/docker-prod/svelte5)
Mon réseau agentique passe au multi-projet : des orchestrateurs qui se parlent