24 agents, 161 fichiers générés, 5 EPICs livrés... et zéro intervention manuelle sur le code.
Voilà ce que j'ai obtenu en orchestrant des agents IA spécialisés avec Claude Code sur mon projet NFCGame.
Au départ, j'utilisais Claude comme n'importe qui : un prompt, une réponse, copier-coller. Ça fonctionne pour des scripts rapides. Mais dès qu'on attaque un vrai projet Android avec de l'architecture, des tests, du Git... ça devient ingérable.
Du coup, j'ai construit un système où chaque agent a un rôle précis. Un peu comme une vraie équipe de dev, mais en automatisé.
Dans cet article, je vous partage toute l'architecture : les patterns d'orchestration, la gestion des ressources, et les erreurs à éviter. Applicable dès aujourd'hui sur vos projets.
Avant de continuer de lire la suite de l'article, je vous invites à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
Pourquoi un seul agent IA ne suffit pas
J'ai commencé NFCGame avec un seul agent qui faisait tout. Coder, tester, documenter, gérer le Git. Résultat : au bout de 20 fichiers, il perdait le fil.
Le problème du contexte, c'est qu'il est limité. Un agent qui doit retenir l'architecture, les conventions de nommage, les tests existants ET ce qu'il vient de modifier... ça finit par buguer.
La limite du "one-shot prompting"
Ce qui marche pour un script de 50 lignes ne scale pas du tout. J'avais des erreurs récurrentes :
- Des imports oubliés parce que l'agent ne se souvenait plus de la structure
- Des tests qui cassaient des features précédentes
- Des commits en masse impossibles à debugger
C'est là que j'ai compris : un agent généraliste, c'est comme un développeur junior qu'on mettrait seul sur un projet complexe. Ça ne peut pas marcher.
L'analogie équipe humaine
Dans une vraie équipe, un dev senior ne fait pas la review de son propre code. Il y a un QA, un lead, parfois un DevOps. Chacun son rôle, chacun sa spécialité.
Du coup, j'ai appliqué le même principe aux agents IA. Et ça change tout.
L'architecture Orchestrateur + Agents Spécialisés
Le pattern central est simple : un orchestrateur qui coordonne des agents spécialisés. L'orchestrateur ne code pas. Il décide qui fait quoi, dans quel ordre, et vérifie que les ressources sont disponibles.
+------------------------------------------------------------------+ | ORCHESTRATOR | | +------------------------------------------------------------+ | | | Pre-Flight Checks | | | | [Environment Monitor] [Usage Monitor] | | | +------------------------------------------------------------+ | | | | | v | | +------------------------------------------------------------+ | | | Agent Queue (par priorité) | | | +------------------------------------------------------------+ | | | | | | | v v v | | [Verifier] [Generator] [Writer] | +------------------------------------------------------------------+
Mes 24 agents NFCGame
Sur le projet, j'ai créé 24 agents répartis en 5 catégories :
Monitors (2 agents)
- environment-monitor : Check CPU, RAM, Disk en temps réel
- usage-monitor : Surveille le quota Claude toutes les 15 min
Verifiers (7 agents)
- kotlin-epic-verifier : Vérifie les EPICs vs la spec
- kotlin-task-verifier : Vérifie les tâches vs les EPICs
- kotlin-algo-verifier : Vérifie le code vs le design
- kotlin-unit-test-verifier : Valide les tests unitaires
- kotlin-integration-test-verifier : Valide les tests d'intégration
- kotlin-algo-design-verifier : Valide les designs algo
- kotlin-unit-test-design-verifier : Valide les designs de tests
Generators (5 agents)
- kotlin-epic-generator : Génère les EPICs depuis la spec
- kotlin-task-generator : Génère les TASKs depuis les EPICs
- kotlin-algo-designer : Conçoit les algorithmes
- kotlin-unit-test-designer : Conçoit les tests unitaires
- kotlin-integration-test-designer : Conçoit les tests d'intégration
Implementers (4 agents)
- kotlin-code-writer : Écrit le code Kotlin
- kotlin-unit-test-coder : Implémente les tests unitaires
- kotlin-integration-test-coder : Implémente les tests d'intégration
- kotlin-ui-designer : Conçoit l'interface
Utilities (6 agents)
- kotlin-orchestrator : Coordonne tout le workflow
- kotlin-spec-updater : Met à jour la documentation
- git-workflow : Gère les worktrees et commits
- epic-pr-merger : Merge les PRs d'EPICs
- action-logger : Trace toutes les actions
La structure d'un fichier agent
Chaque agent est défini dans un fichier Markdown avec un front matter YAML :
--- name: kotlin-code-writer description: Écrit le code Kotlin selon le design algo model: inherit color: blue tools: ["Read", "Write", "Bash", "Glob", "Grep"] --- # Role Tu es un développeur Kotlin senior... # Core Responsibilities 1. Lire le design algorithmique 2. Implémenter le code selon les patterns définis 3. Respecter les conventions du projet ...
L'invocation se fait avec la syntaxe @agent-name "instruction". Simple et direct.
Le workflow complet : de la spec au code livré
Le pattern clé, c'est la vérification AVANT la génération. On ne code rien tant que la spec n'est pas validée.
specification.md
|
v
[Epic Verifier] ----[FAIL]----> [Epic Generator]
|
[PASS]
v
[Task Verifier] ----[FAIL]----> [Task Generator]
|
[PASS]
v
[Design Verifiers] --[FAIL]----> [Designers]
|
[PASS]
v
[IMPLEMENTATION]
Les phases du workflow
Step -3 à 0 : Pre-flight et vérification
Avant de lancer quoi que ce soit :
- Check du log d'activité (reprise ou fresh start ?)
- Environment monitor : CPU, RAM, Disk sont OK ?
- Usage monitor : quota Claude pas à 90% ?
- Chain de vérification : EPICs → Tasks → Designs
Phases 1-6 : Design et implémentation
Une fois les vérifications passées, on attaque le code. Chaque phase génère des artefacts que la suivante consomme.
Phase 10 : Documentation et finalisation
Le kotlin-spec-updater met à jour la spec avec ce qui a été réellement implémenté. C'est crucial pour la cohérence long terme.
Métriques réelles du projet
Sur NFCGame, ça donne :
- 5 EPICs documentés (NFC Infrastructure, Lecture, Persistance, UI, Intégration)
- 161 fichiers source générés
- 1 commit par task (format : feat(TASK-XXX-YYY): description)
- Référence spec dans chaque commit
Gérer les ressources : le throttling intelligent
C'est là que beaucoup se plantent. Lancer 4 agents en parallèle sur une machine qui rame, c'est le crash garanti.
Du coup, j'ai implémenté un dual pre-flight check obligatoire.
Les thresholds
| Condition | Max Agents | Délai | Mode |
|---|---|---|---|
| OK (CPU <50%, RAM >2GB) | 4 | 5s | Parallèle |
| MODERATE | 3 | 10s | Parallèle |
| HIGH | 2 | 15s | Séquentiel |
| CRITICAL | 1 | 30s | Pause |
L'auto-pause à 90%
Si l'usage monitor détecte qu'on est à 90% du quota Claude, l'orchestrateur fait un sleep automatique. Il calcule le temps restant avant reset et reprend tout seul.
Ça m'a sauvé plusieurs fois. Avant, je me retrouvais bloqué en plein milieu d'un EPIC sans possibilité de continuer.
Le choix du modèle
Petit conseil qui change tout en termes de coût et performance : utilisez haiku pour les monitors, opus pour les décisions critiques.
Un environment-monitor n'a pas besoin de la puissance d'opus. Par contre, un kotlin-algo-designer qui doit prendre des décisions architecturales, là oui.
Git intégration : un commit par task, un worktree par EPIC
La stratégie Git, c'est ce qui permet de paralléliser sans créer de conflits.
La structure des worktrees
NFCGame/ |-- .worktrees/ | |-- EPIC-001-nfc-infrastructure/ | |-- EPIC-002-lecture-nfc/ | |-- EPIC-003-persistance/ |-- app/ |-- agents/
Chaque EPIC a sa propre branche et son propre worktree. L'agent qui bosse sur EPIC-001 ne peut pas casser le travail de celui sur EPIC-002.
Le format de commit
Tous les commits suivent le même format :
feat(TASK-001-003): Implémenter le reader NFC de base [SPEC] Chapitre 3.2 - Lecture des tags NDEF Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Le Co-Authored-By permet de tracer l'apport IA. C'est important pour l'audit et la transparence.
Le merge propre
L'agent epic-pr-merger gère les merges une fois l'EPIC terminé. Il vérifie que tous les tests passent avant de fusionner dans main.
Resume et résilience : ne jamais perdre le travail
Un agent qui plante à 3h du matin, ça arrive. Du coup, tout est logué.
[QUEUED] --> [RUNNING] --> [COMPLETE]
|
+--> [PAUSED] --> [RESUMED]
|
+--> [FAILED] --> [RETRY]
Le mécanisme de reprise
Au démarrage, l'orchestrateur :
- Parse docs/logs/agent-activity.log
- Identifie la dernière action complétée
- Skip les phases terminées
- Resume depuis la prochaine étape
J'ai eu des sessions qui se sont étalées sur 3 jours à cause des pauses quota. Sans le resume automatique, j'aurais dû tout recommencer à chaque fois.
Le logging obligatoire
Conseil pratique : loguez AVANT et APRÈS chaque action. Ça sauve des heures de debug.
Un log typique ressemble à ça :
[2026-02-01 14:23:15] agent=kotlin-code-writer action=START task=TASK-001-003 [2026-02-01 14:25:42] agent=kotlin-code-writer action=COMPLETE task=TASK-001-003 files=3
Les erreurs à éviter
Après plusieurs projets avec cette architecture, voici ce qui fait mal :
1. Lancer en parallèle sans checker les ressources
Crash garanti. Toujours faire le dual pre-flight check.
2. Créer des agents trop génériques
Un agent "kotlin-developer" qui fait tout, ça redevient un one-shot prompt. Spécialisez.
3. Pas de logging
Impossible de debug ou resume. C'est non négociable.
4. Ignorer les verifiers
Du code généré sans vérification, c'est de la dette technique IA. Elle s'accumule vite.
5. Commit en masse
Un commit avec 50 fichiers, c'est impossible à review ou rollback. Un commit par task, pas plus.
Conclusion
L'orchestration multi-agents transforme le développement en pipeline semi-automatisé. L'humain définit la spec et valide les résultats. Les agents gèrent le reste.
Les patterns clés à retenir :
- Orchestrateur central : un agent qui coordonne, ne code pas
- Vérification avant génération : on ne produit rien sans valider
- Throttling intelligent : adapter le parallélisme aux ressources
- Un commit par task : granularité fine pour le debug
- Logging obligatoire : pour le resume et l'audit
Les chiffres parlent d'eux-mêmes : 24 agents, 161 fichiers, 5 EPICs. Et selon Gartner, 40% des applications enterprise auront des agents IA intégrés d'ici 2027. L'approche se démocratise.
Si vous voulez implémenter ce type d'architecture sur votre projet, commencez simple : un orchestrateur + 3-4 agents spécialisés. Le reste viendra naturellement au fil des besoins.
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 écris 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.
Orchestrer 24 agents IA pour développer une app Android : retour d'expérience