Comment j’ai construit une équipe d’agents IA avec Claude Code

Un système multi-agents pour le développement logiciel avec gouvernance humaine, contrôle des coûts et prise de décision stratégique

→ Code et dépôt complet sur GitHub : https://github.com/rheorix/agentic-company

Introduction

Ce week-end, je me suis demandé comment exploiter réellement l’IA pour rendre plus efficace l’ensemble du processus de développement logiciel (SDLC – Software Development Life Cycle).

Je n’étais pas intéressé par l’utilisation de Claude Code pour écrire du code plus rapidement ou améliorer la qualité des lignes individuelles.
Je voulais quelque chose de plus radical :

Que se passerait-il si une équipe de développement était composée uniquement d’agents IA spécialisés ?

Un Product Manager qui n’existe pas physiquement
Un Developer qui n’existe pas
Un QA Engineer qui n’existe pas
Un Cost Controller qui n’existe pas

Et vous, au centre du système, non plus comme exécutant, mais comme décideur stratégique.

Vous ne micro-gérez pas le travail.
Vous n’écrivez pas chaque ligne de code.

Vous définissez la direction, fixez les contraintes, évaluez la qualité des décisions et gouvernez le budget de l’ensemble du système.

L’objectif n’est pas d’automatiser le développement.
C’est de construire une organisation d’agents IA avec des rôles spécialisés, dans laquelle le travail est distribué mais la responsabilité décisionnelle reste humaine.

→ Code et dépôt complet sur GitHub : https://github.com/rheorix/agentic-company

Qu’est-ce qu’une architecture multi-agents ?

Dans le contexte du développement logiciel, une architecture multi-agents distribue le travail entre des modèles spécialisés plutôt que de s’appuyer sur un seul LLM généraliste.

Dans le modèle Orchestrator → Subagents :

chaque agent a une responsabilité claire et limitée
chaque agent fonctionne avec une fenêtre de contexte isolée
un système central (l’Orchestrator) coordonne le flux de travail

Le résultat est un système plus :

stable
prévisible
contrôlable

En résumé

Architecture : Orchestrator → Subagents
Rôles : PM, Developer, QA, Cost Controller
Stack : Java 21, Spring Boot 3.x, Maven, JUnit 5 + Mockito
Sortie : application REST complète
Coût moyen par fonctionnalité : < 1 $

Pourquoi un seul agent ne suffit pas

La véritable limite n’est pas la capacité du modèle, mais la gestion du contexte.

Un LLM peut exceller dans la logique applicative, la conception d’API ou l’écriture de tests.
Mais lorsqu’il doit tout gérer en même temps, le phénomène de dilution de l’attention apparaît.

Dilution de l’attention

C’est une situation dans laquelle, à mesure que la quantité d’informations dans le contexte augmente, le modèle a du mal à accorder le bon poids aux détails réellement pertinents.

C’est la même raison pour laquelle le travail est réparti dans les équipes humaines :

non pas par incapacité individuelle, mais pour améliorer la qualité globale.

La solution : séparer les contextes

Le principe est simple : chaque agent ne voit que ce dont il a besoin.

PM → exigences et objectifs
Developer → spécifications techniques
QA → code produit

Aucun contexte superflu.
Aucun chevauchement inutile.

Cette approche augmente la précision et réduit l’ambiguïté.

Le modèle Orchestrator → Subagents

Le flux est linéaire et contrôlé :

Orchestrator
   ↓
PM → spécification
   ↓ (validation humaine)
Developer → code
   ↓ (validation humaine)
QA → tests + rapport
   ↓ (validation humaine)
Cost Controller → rapport de coûts

Ce n’est pas un réseau chaotique d’agents qui communiquent librement.
C’est une pipeline structurée avec des points de contrôle explicites.

Setup : comment commencer

Prérequis

Java 21
Maven
npm install -g @anthropic-ai/claude-code
claude login

Structure du projet

agentic-company/
├── CLAUDE.md
├── .claude/agents/
├── shared/
└── output/

.claude/agents/ → comportement des agents
shared/ → état partagé
output/ → code généré

CLAUDE.md : le système d’exploitation de l’équipe

Ce fichier définit les règles constitutionnelles du système :

stack technologique
règles de communication
points de validation obligatoires

Règles fondamentales

Aucun code sans spécifications approuvées
Aucun commit sans validation humaine
Chaque phase s’arrête pour validation

Rôles des agents

Product Manager → transforme des demandes informelles en spécifications (shared/spec.md)
Developer → implémente uniquement ce qui est défini (output/src/)
QA Engineer → rédige des tests et des rapports (shared/qa_report.md)
Cost Controller → surveille les tokens et les coûts (shared/cost_report.md)

L’état partagé vit dans le système de fichiers :

shared/project_state.json
shared/decisions_log.md

→ Le système de fichiers devient la couche de coordination

Premier lancement

claude

Prompt initial :

Build a Spring Boot REST API for a TODO list using the full agent workflow with approval gates.

Le flux reste toujours le même :

spécification → validation → implémentation → validation → tests → validation

Parallélisme (quand c’est pertinent)

Le parallélisme ne fonctionne que sur des tâches indépendantes.

Exemple :

Developer implémente les endpoints
QA écrit les tests correspondants

Règle pratique : maximum 2–3 agents en parallèle

Optimisation des coûts

Rôle	Modèle
Product Manager	Sonnet
Developer	Sonnet
QA Engineer	Haiku
Cost Controller	Haiku

Cette répartition permet une réduction significative des coûts sans sacrifier la qualité.

Erreurs courantes à éviter

Autonomie excessive (sans points de validation)
Spécifications trop vagues
Trop de parallélisme
Ignorer le journal des décisions

Ce qui change vraiment

Cet expérimentation ne concerne pas seulement l’automatisation du développement.

Il s’agit de gouverner le travail technique à travers des agents IA.

Le rôle humain se déplace sur trois axes :

Vision stratégique
Gouvernance du système
Contrôle des coûts et de l’impact

Vous n’êtes plus un exécutant.
Vous êtes le point de contrôle décisionnel du système.

Conclusion

Cette expérience est née comme une curiosité technique.

Mais le résultat le plus important est organisationnel :

nous apprenons à construire des systèmes de travail où l’exécution peut être déléguée, mais pas la responsabilité.

Nous passons d’outils de productivité à de véritables systèmes de production gouvernés par des décideurs humains.

Séparer les rôles, limiter les contextes et introduire des points de contrôle n’est plus seulement de l’ingénierie logicielle :

cela devient une forme mature de gouvernance opérationnelle pilotée par l’IA.

Et, pour l’instant, la véritable valeur ne réside pas dans l’autonomie du système, mais dans la qualité des décisions humaines.