Comment notre "entreprise virtuelle" à 6 agents s'est transformée en architecture Lean CEO — et pourquoi la spécialisation des LLM est un piège.
Quand on commence à travailler avec des agents IA autonomes, il y a une tentation irrésistible : reproduire ce qu'on connaît. Et ce qu'on connaît, c'est l'organigramme d'entreprise.
C'est exactement ce qu'on a fait.
On a monté une organisation multi-agents calquée sur une PME classique. Un CEO orchestrateur au sommet, et cinq agents spécialisés en dessous : un CTO pour le code et l'architecture, un Sales pour la prospection et le closing, un Marketing pour le contenu et le branding, un RH pour le recrutement et la culture, et un DAF pour le budget et la trésorerie.
Chaque agent avait sa propre session persistante, son propre fichier de personnalité (SOUL.md), son propre contexte système. Le CTO "pensait" comme un directeur technique. Le Sales avait le vocabulaire d'un commercial aguerri. Le DAF raisonnait en marges et en cash-flow.
Sur le papier, c'était élégant. On avait notre petite entreprise virtuelle, avec des rôles clairs, une hiérarchie définie, et un CEO qui orchestrait le tout en dispatchant les tâches aux bonnes personnes.
On était fiers. On avait tort.
Les problèmes ne sont pas apparus d'un coup. Ils se sont accumulés, insidieusement, comme une dette technique qu'on refuse de voir.
Le premier signal, c'est la facture. Chaque agent embarquait son propre contexte système — son SOUL.md, ses instructions, ses outils, son historique de conversation. Multipliez ça par six agents actifs, et vous obtenez une duplication massive.
On ne parle pas de quelques tokens en plus. On parle d'un facteur x6 sur le contexte système. Six fois les mêmes instructions de base. Six fois les mêmes descriptions d'outils. Six fois le même overhead incompressible, avant même qu'un seul mot utile ne soit généré.
Pour une architecture censée être plus efficace qu'un humain, payer six fois le prix d'entrée pour chaque interaction, ça pique.
Deuxième problème : on pensait gagner en parallélisme. Après tout, c'est l'argument massue du multi-agents — pendant que le CTO code, le Marketing rédige, et le Sales prospecte, non ?
Sauf que non. Notre mécanisme de communication inter-agents (sessions_send) était séquentiel. Le CEO envoyait un message au CTO, attendait la réponse, puis envoyait au Marketing, attendait la réponse, et ainsi de suite.
En pratique, on avait un pipeline série déguisé en organisation parallèle. Tout le monde faisait la queue derrière le CEO, comme des employés devant la machine à café un lundi matin.