Construire une équipe d'agents IA : ce qui compte vraiment

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

Peu importe la composition de l'équipe d'agents, une règle ne change pas : les actions critiques qu'ils préparent (publication, écriture en base, dépense) restent derrière des points de contrôle human-in-the-loop. La spécialisation décide qui fait le travail ; le point de contrôle décide ce qui part sans regard humain.

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 :

1. Commencer avec un skill minimal (50 lignes maximum)
2. Lancer l'agent sur une vraie tâche
3. Observer ce qu'il fait mal
4. Transformer chaque erreur en règle
5. Recommencer

L'étape 3 est celle où la plupart des setups échouent : impossible de transformer des erreurs en règles si on ne les voit pas. C'est tout l'argument pour tracer le raisonnement de vos agents en production : un agent échoue rarement bruyamment ; il dérive en retournant des outputs parfaitement valides.

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 secondaire 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 :

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.
2. Écrire les règles APRÈS les erreurs, pas avant. Les specs sont un journal de bord, pas un cahier des charges.
3. Séparer les contextes dès le départ. C'est plus difficile à corriger après coup qu'à mettre en place tout de suite.
4. 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.
5. 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à.

Foire aux questions

Pourquoi plusieurs agents IA spécialisés plutôt qu'un seul agent généraliste ?

Parce qu'au-delà d'un certain seuil de complexité, un agent qui essaie de tout faire ne fait plus rien correctement. Un contexte partagé pousse les agents à sortir de leur périmètre, augmente les hallucinations et sature la fenêtre de contexte d'informations sans rapport avec la tâche en cours. Des périmètres séparés gardent chaque agent précis.

Faut-il un framework d'orchestration pour construire une équipe d'agents IA ?

Non. Ce qui compte, c'est de séparer explicitement les espaces d'exécution : des subagents aux contextes isolés chez Claude, des rôles configurés chez Gemini, ou des instructions claires dans le skill de l'agent. Chaque agent doit savoir ce qu'il n'a pas le droit de toucher ; aucun framework lourd n'est nécessaire pour ça.

Avec combien d'agents IA une équipe devrait-elle commencer ?

Un orchestrateur et deux agents spécialisés. On n'en ajoute que lorsqu'un domaine récurrent commence à polluer le contexte des agents existants. Démarrer avec six agents multiplie les coûts en tokens et la coordination avant même d'avoir appris quelles spécialisations le projet exige réellement.

Quand l'architecture multi-agents est-elle de l'over-engineering ?

Pour les projets solo de moins d'environ 5 000 lignes de code, pour les stacks ultra-standards que les agents généralistes connaissent déjà par cœur, et quand le budget tokens est serré : un setup multi-agents consomme trois à cinq fois plus de tokens qu'un agent unique. Le pattern devient rentable sur les projets de complexité moyenne à élevée, surtout dans les petites équipes qui jonglent avec plusieurs produits.

Pour aller plus loin

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. Découvrez nos services de développement logiciel ou réservez un appel découverte gratuit et, même si vous ne nous choisissez pas, vous repartirez avec une vision plus claire de la manière d'intégrer des agents IA à vos propres projets.