Chez Automathing, nous opérons plusieurs produits en parallèle — Towerz, StyleAfro, TransformZ, et d'autres. Chaque membre de l'équipe a un projet principal, et avec lui une connaissance approfondie de la stack, des conventions internes, et de l'historique des décisions techniques accumulées au fil des mois.
Dans une petite équipe qui gère plusieurs produits, on ne choisit pas toujours sur quel projet on travaille le lendemain. Une urgence client, un signal marché, une priorité qui bascule, et du jour au lendemain, il faut poser un projet et en reprendre un autre. Et ce basculement a un coût concret. La prise en main prend du temps — et personne n'a forcément eu l'espace pour tout documenter entre deux urgences. Une fois qu'on retrouve ses marques, chaque développeur garde sa signature : un style légèrement différent, des choix d'implémentation qui ne s'alignent pas tout à fait avec ceux de la personne qui a porté ce projet depuis le début.
Le résultat : une productivité inégale d'un projet à l'autre, et un coût de switching qui finit par grignoter la vélocité de toute l'équipe.
D'où l'idée initiale : monter des agents IA spécifiques à chaque projet, capables de porter la mémoire vivante des conventions, des patterns et des décisions techniques. Un développeur qui arrive sur un projet inconnu peut alors s'appuyer sur l'agent du projet pour rester aligné dès la première heure, plutôt qu'au bout de deux jours de relecture.
C'est en construisant cette première couche, un agent par projet, que la vraie complexité est apparue. Un agent unique, même bien doté en contexte, ne suffisait pas à couvrir toutes les dimensions d'un projet : code, infrastructure, données, UX, sécurité. D'où une seconde couche d'architecture : un orchestrateur par projet, qui délègue à des agents spécialisés par domaine.
Voici ce que cette démarche a appris à l'équipe.
L'architecture : un orchestrateur, des spécialistes
Le schéma de base est simple. Un orchestrateur central reçoit la demande, la décompose, puis la route vers les agents spécialisés les mieux placés pour l'exécuter.
Chaque agent possède son périmètre, ses outils et son skill propre :
- Code : développement de fonctionnalités, refactoring, tests
- Infra : Docker, CI/CD
- Data : schémas de base de données, migrations, requêtes complexes
- AI : intégrations LLM, embeddings, design de prompts
- User : UX, copy, formulaires, parcours utilisateur
- Audit : revue de code, sécurité, cohérence avec l'existant
Pourquoi ne pas utiliser un seul agent généraliste avec un méga-prompt ? Parce qu'au-delà d'une certaine complexité, un agent qui essaie de tout faire ne fait plus rien correctement. C'est exactement le problème d'un développeur full-stack à qui l'on demanderait de pousser une migration de base de données, configurer le reverse proxy et faire l'audit sécurité dans la même journée. Le résultat est rarement bon.
C'est en mettant en place cette architecture qu'on a compris ce qui compte vraiment
Leçon 1 : Un agent qui sait tout ne fait plus rien bien
L'erreur classique consiste à partager un contexte unique entre tous les agents. La logique semble évidente : plus ils en savent, mieux ils collaborent.
Faux.
En pratique, voici ce qui se passe : l'agent Code commence à toucher à l'infra parce qu'il a vu la configuration Docker dans son contexte. L'agent Data se met à proposer des changements d'interface parce qu'il a accès aux fichiers React. La précision chute. Les hallucinations augmentent. Les responsabilités se diluent.
Pire encore : la fenêtre de contexte se sature avec des informations dont l'agent n'a pas besoin, ce qui dégrade les performances sur sa vraie tâche.
La solution est simple : séparer explicitement les espaces d'exécution. La façon de le faire dépend du provider :
- Claude : utiliser le système de subagents (
subagent_type) pour isoler les contextes - Gemini : configurer les rôles (
generalist,codebase_investigator, etc.) - Tous les providers : le préciser noir sur blanc dans le skill de l'agent "Utilise l'outil xxx pour assigner une tâche à un agent."
Aucun framework d'orchestration complexe n'est nécessaire. Il suffit que chaque agent sache ce qu'il n'a pas le droit de toucher. Cette contrainte est précisément ce qui le rend bon.
Leçon 2 : Les specs ne se conçoivent pas. Elles s'observent.
Celle-ci est la plus contre-intuitive.
L'approche d'ingénieur consiste naturellement à vouloir écrire LE document de spécifications parfait avant de lancer les agents. Architecture, conventions, règles métier, patterns de code — tout doit être anticipé.
Le résultat habituel : un document de 40 pages que les agents ignorent à moitié, et qui ne couvre pas les 20 vrais problèmes apparus dès la première semaine.
Le bon processus fonctionne à l'inverse :
- Commencer avec un skill minimal (50 lignes maximum)
- Lancer l'agent sur une vraie tâche
- Observer ce qu'il fait mal
- Transformer chaque erreur en règle
- Recommencer
Quelques exemples concrets, tirés de notre setup sur TowerZ :
- L'agent contourne une vérification d'authentification → règle ajoutée : "Toute query sur une table privée doit passer par
auth.uid()dans la RLS." - L'agent ignore une convention d'arborescence du monorepo → règle ajoutée : "Les composants partagés vont dans
/components/ui, jamais dans/src/lib/." - L'agent produit du code correct mais incohérent avec le reste de la codebase → règle ajoutée : "Toujours utiliser le pattern Server Action existant dans
/lib/actions, ne pas créer de nouvelle API route."
Chaque règle est une cicatrice. Et au bout de quatre à six semaines d'itération, on obtient un set de specs qui couvre 90 % des cas réels — ce qu'aucun document théorique n'aurait pu prévoir.
L'effet de bord rarement mentionné : la clarté s'impose à l'humain
C'est le bénéfice que peu d'équipes anticipent.
Pour écrire une bonne règle, il faut articuler par écrit ce qui se faisait jusque-là de manière implicite. Pourquoi structurer le code de telle façon ? Pourquoi tel pattern et pas un autre ? Pourquoi cette convention de nommage ?
La plupart des décisions qu'un développeur expérimenté prend sont tacites. Elles vivent dans sa tête. Pour les transmettre à un agent, il faut les rendre explicites.
Le résultat : la codebase devient mieux documentée, l'architecture devient plus cohérente, et la pensée d'architecte de l'équipe s'affûte. Les agents agissent comme une fonction de forçage pour la clarté humaine.
C'est probablement le bénéfice le plus sous-estimé de ce setup.
Quand ce pattern n'est PAS adapté
Soyons honnêtes — ce n'est pas une solution universelle.
- Projet solo, moins de 5 000 lignes de code : un seul agent généraliste fait largement le travail. L'orchestration multi-agents est de l'over-engineering.
- Stack ultra-standard (par exemple Next.js + Supabase basique) : les agents généralistes connaissent déjà ces conventions par cœur.
- Budget tokens serré : six agents qui s'échangent du contexte, ça consomme. Il faut compter trois à cinq fois plus de tokens qu'un setup mono-agent. Le gain de qualité doit justifier le coût.
Le pattern orchestrateur + spécialistes brille sur les projets de complexité moyenne à élevée, en particulier dans des petites équipes, où chaque projet et chaque domaine technique demande un contexte distinct.
Ce qu'il faut retenir
Pour qui souhaite se lancer, voici les principes à garder en tête dès le jour 1 :
- Commencer petit. Un orchestrateur et deux agents. Pas six. Les autres s'ajoutent au fur et à mesure que des domaines récurrents polluent le contexte.
- Écrire les règles APRÈS les erreurs, pas avant. Les specs sont un journal de bord, pas un cahier des charges.
- Séparer les contextes dès le départ. C'est plus difficile à corriger après coup qu'à mettre en place tout de suite.
- Garder les skills courts. Au-delà de 200 lignes, l'agent commence à ignorer la moitié du contenu. Mieux vaut cinq règles bien suivies que cinquante noyées dans la masse.
- L'expertise du projet reste humaine. L'agent n'est pas un consultant qui va enseigner l'architecture. C'est un exécutant à qui il faut transmettre l'expertise existante.
Ce dernier point résume tout : plus l'équipe humaine connaît son projet, plus les agents deviennent précis. L'IA n'a pas remplacé le travail d'ingénierie — elle l'a déplacé. Avant, on codait. Maintenant, on enseigne à des entités qui codent.
Et c'est précisément ce qui résout le problème de départ : un développeur qui bascule d'un projet à l'autre n'a plus à reconstituer mentalement les conventions de la maison. L'agent du projet les porte déjà.
Cet article s'appuie sur l'expérience d'Automathing dans la construction de TowerZ et de plusieurs autres produits développés avec une architecture multi-agents. Pour échanger sur ces sujets ou explorer comment ces approches peuvent s'appliquer à vos propres projets, contactez-nous.