10 agents IA, 4 heures, $30 : retour d’expérience sur OpenClaw

Comment nous avons fait produire une application de facturation par une équipe de 10 agents IA autonomes, et ce que cela change pour l’avenir du développement logiciel.

Le constat de départ

Le « vibe coding », cette pratique qui consiste à coder en dialogue libre avec un LLM, a des limites évidentes. Ça fonctionne pour un script, un composant isolé, un prototype rapide. Mais dès qu’un projet dépasse le stade du POC, l’absence de structure se paie : perte de contexte, incohérences d’architecture, bugs récurrents, zéro traçabilité.

Et si, au lieu de dialoguer avec un seul modèle, on faisait collaborer une équipe complète d’agents spécialisés, chacun avec son rôle, sa mémoire et ses responsabilités ?

C’est cette hypothèse que nous avons testée chez Castelis, en combinant deux briques open source : OpenClaw pour l’orchestration multi-agent, et les prompts de la méthode BMAD pour définir les rôles de nos agents.

 

Les outils : OpenClaw et BMAD en deux mots

Qu’est-ce que OpenClaw ?

Openclaw est un runtime d’agent IA auto-hébergé et open source. Concrètement, c’est un service Node.js persistant qui tourne sur votre serveur et rend vos agents accessibles via Telegram, WhatsApp, Discord ou webchat.

Chaque agent dispose de son propre workspace (fichiers de personnalité, mémoire, outils), de sessions persistantes, et peut communiquer avec les autres agents via un mécanisme de messagerie inter-agent (sessions_send).

 

BMAD (Breakthrough Method of Agile AI-Driven Development)

Il s’agit d’un framework qui définit des rôles d’agents calqués sur une équipe agile réelle : analyste, product manager, architecte, UX designer, développeur, QA, scrum master, ops. Chaque rôle est décrit dans un fichier Markdown qui sert à la fois de persona et d’instructions opérationnelles.

 

Notre approche hybride

Nous n’avons pas utilisé BMAD directement comme framework, mais nous avons extrait les prompts de ses agents pour les injecter dans les fichiers SOUL.md de nos agents OpenClaw. Par exemple, le prompt de l’agent Analyst de BMAD est devenu la base du SOUL.md de notre agent Mary (analyst) dans OpenClaw. Cela nous a permis de bénéficier de la rigueur méthodologique de BMAD tout en exploitant la persistance et la communication inter-agent d’OpenClaw.

 

L’architecture : 10 agents, un pilote, zéro vibe coding

Nous avons déployé 10 agents sur un serveur Debian minimal (2 vCPU, 2 Go de RAM) avec Nginx en reverse proxy et Let’s Encrypt pour le SSL. Coût d’infrastructure : quasi nul.

Chaque agent a une identité, un rôle précis et une mémoire persistante :

• Le Pilote (orchestrateur) assigne les tâches, suit l’avancement et maintient le contexte global du projet. Il ne code pas, ne designe pas : il coordonne.
• Mary (analyste) produit les briefs business.
• John (PM) rédige les PRD, epics et stories.
• Winston (architecte) définit l’architecture technique et les ADR.
• Sally (UX) et Lena (UI) couvrent respectivement les specs d’expérience utilisateur et l’identité visuelle.
• Bob (scrum master) gère le sprint planning.
• Amelia (dev) implémente le code et pousse sur GitHub via une clé SSH configurée.
• Quinn (QA) teste et valide.
• Oscar (ops) gère le déploiement et la sécurité serveur.

Le tout suit le pipeline BMAD en quatre phases : Analysis, Planning, Solutioning, Implementation.

Chaque agent reçoit ses tâches avec un bloc de contexte standardisé (projet, slug, chemin, phase en cours), et les artefacts produits sont stockés dans une structure de fichiers partagée via un fichier project-context.md.

 

Ce qui a fonctionné

Le modèle hub-and-spoke tient la route

Le pilote orchestre, les agents exécutent, et le contexte se transmet correctement d’un agent à l’autre via les fichiers partagés. Les agents restent dans leur rôle et produisent des artefacts au bon endroit.

La communication latérale est naturelle

Autoriser les agents à se parler directement, par exemple Amelia qui signale à Quinn qu’une release est prête, Quinn qui remonte un bug directement à Amelia, reproduit les interactions d’une équipe réelle. Le garde-fou « pas de redélégation » (un agent ne peut pas déléguer à un tiers) évite les chaînes incontrôlées.

Le workflow QA a prouvé sa valeur dès le premier jour

Règle simple : aucun déploiement sans validation de Quinn. Dès que cette règle a été instaurée, les bugs en production sont tombés à zéro. L’agent QA a détecté des problèmes que l’agent dev avait ratés, exactement comme dans une équipe humaine.

La mémoire persistante change la donne

Chaque agent dispose de son MEMORY.md et accède aux fichiers de contexte partagés. Entre deux sessions, un agent retrouve où il en était. C’est ce qui différencie ce setup d’un simple prompt engineering : on passe d’un dialogue éphémère à une collaboration continue.

 

Les pièges : ce que la documentation ne dit pas

Le timeout de 30 secondes est un tueur silencieux

C’est le problème le plus insidieux que nous avons rencontré. Le timeout par défaut de sessions_send dans OpenClaw est de 30 secondes. Or, nos agents mettent régulièrement plus de 30 secondes pour produire un document (brief, PRD, implémentation).

Quand le timeout expire, le résultat n’est jamais enregistré dans l’historique de session. OpenClaw injecte un résultat synthétique d’erreur, et l’agent perd tout le travail qu’il vient de faire. Aucune erreur visible côté utilisateur.

La solution : spécifier timeoutSeconds explicitement, minimum 180s pour les tâches standard, 300s pour les documents longs.

 

La documentation multi-agent est incomplète

Il a fallu lire le code source d’OpenClaw pour comprendre que tools.agentToAgent doit être explicitement activé (désactivé par défaut), que les deux agents (source et cible) doivent figurer dans une liste d’autorisation, et que la distinction entre sessions_send (messagerie A2A avec persona et mémoire) et sessions_spawn (sous-agent éphémère sans contexte) est critique. Nous utilisons exclusivement sessions_send.

 

La fenêtre de contexte reste le nerf de la guerre

La limite de taille des fichiers workspace injectés dans le contexte provoque des troncatures silencieuses. Le MEMORY.md du pilote, avec ses 9 000 caractères, dépasse la limite et se retrouve amputé.

Plus fondamentalement, les agents finissent par « oublier » des décisions prises lors de sprints précédents, ce qui provoque des bugs récurrents, typiquement des erreurs de déploiement ou des régressions sur des choix d’architecture déjà tranchés.

C’est le point d’optimisation le plus critique pour garantir la cohérence sur la durée d’un projet.

 

Le bilan en chiffres

Le premier projet, une application de facturation pour TPE/indépendants (backend Express.js + PostgreSQL, frontend React + Vite), a été développé en environ 4 heures de consommation LLM pour un coût de 30 dollars.

Le modèle par défaut était Claude Haiku 4.5 pour l’efficacité/coût, avec des appels ponctuels à Claude Opus 4.5 pour les tâches complexes. Neuf stories ont été implémentées sur le premier sprint : CRUD clients, CRUD factures, génération PDF, gestion des statuts.

Soyons clairs : le résultat est un POC fonctionnel qui démontre la faisabilité de l’approche, pas un produit prêt pour la mise en production. Mais le ratio coût/résultat est remarquable et ouvre des perspectives concrètes pour des projets réels.

 

Nos recommandations pour la suite

Adapter le nombre d’agents au contexte

Dix agents, c’est probablement trop pour la plupart des projets. Fusionner UX et UI, PM et Scrum Master, voire certains rôles selon la phase du projet, réduirait la complexité de coordination sans perte de qualité. Le setup idéal n’est pas fixe : il doit évoluer avec les phases du projet (dev initial, debug, ajout de fonctionnalités).

Prévoir des workflows différents par phase

Le pipeline linéaire Analysis → Planning → Solutioning → Implementation fonctionne bien pour le dev initial. Mais pour le debug ou l’ajout de features, un workflow allégé avec moins d’agents et des boucles de feedback plus courtes serait plus efficace.

Traiter la documentation des agents comme du code

Chaque modification d’un AGENTS.md, TOOLS.md ou SOUL.md change le comportement de l’agent. Ça se versionne dans Git, ça se révise, ça se déploie avec la même rigueur que du code applicatif.

Investir dans la gestion de la mémoire

Fragmenter les fichiers de mémoire, implémenter des mécanismes de synthèse périodique, et surtout monitorer activement les troncatures de contexte. C’est la clé pour passer du POC à un usage projet réel.

 

Prochaines étapes : observabilité et montée en puissance

Deux axes d’amélioration se dessinent clairement pour passer du POC à un usage industrialisable.

Intégrer une couche d’observabilité LLM

Aujourd’hui, notre visibilité sur le comportement des agents se limite aux logs gateway d’OpenClaw (14 Mo par jour d’activité) et à l’inspection manuelle des artefacts produits. C’est insuffisant pour garder le contrôle à l’échelle.

Chez Castelis, nous utilisons déjà Langfuse en production sur nos projets IA basés sur LangChain. C’est une plateforme open source d’observabilité LLM, auto-hébergeable, qui permet de tracer chaque appel LLM (prompts envoyés, réponses reçues, tokens consommés, latence), de suivre les coûts en temps réel et de détecter les anomalies.

L’étape suivante naturelle est d’étendre cette instrumentation à notre setup multi-agent OpenClaw : tracer les échanges inter-agents, mesurer la consommation par agent et par phase de projet, identifier un agent qui tourne en boucle ou une dégradation de qualité.

Dans un système à 10 agents autonomes, cette visibilité n’est pas un luxe : c’est une condition de viabilité. Sans elle, on pilote à l’aveugle. Le sujet est d’ailleurs pris en compte par les deux communautés, qui portent précisément sur l’intégration OpenClaw/Langfuse via OpenTelemetry, et un maintainer Langfuse est prêt à publier une intégration officielle.

Le rapprochement entre orchestration multi-agent et observabilité LLM n’est plus une question de « si », mais de « quand ».

 

Tester des modèles plus robustes que Haiku

Notre POC reposait principalement sur Claude Haiku 4.5, choisi pour son rapport coût/performance. C’est un choix pertinent pour les tâches répétitives et bien cadrées (CRUD, formatage, déploiement).

Mais pour les tâches à forte complexité, analyse d’architecture, résolution de bugs subtils, décisions de conception, les limites apparaissent. Les erreurs de déploiement récurrentes que nous avons observées sont en partie imputables à la capacité de raisonnement du modèle sur des problèmes multi-étapes.

L’étape suivante consiste à tester une stratégie de routage plus fine : des modèles légers pour les tâches d’exécution, des modèles plus puissants (Claude Sonnet 4.5 ou Opus 4.6) pour les tâches de raisonnement. Le surcoût API serait compensé par la réduction du temps passé à corriger des erreurs évitables.

 

Ce que cela préfigure pour le cycle de développement logiciel

Cette expérimentation dépasse le simple exercice technique. Elle illustre une évolution profonde du SDLC : le passage d’un modèle où l’IA est un outil d’assistance ponctuel (copilot, compléteur de code) à un modèle où une équipe d’agents autonomes exécute un pipeline d’ingénierie complet sous supervision humaine.

Le multi-agent IA n’est pas du prompt engineering, c’est de l’ingénierie système. La configuration, les timeouts, la gestion de mémoire, la coordination entre agents : ce sont des problèmes d’infrastructure, pas de prompts. Et c’est précisément ce qui rend l’approche viable pour des organisations qui ont besoin de rigueur, de traçabilité et de reproductibilité.

Pour les entreprises, la question n’est plus « est-ce que l’IA peut coder ? » mais « comment structurer une équipe d’agents IA pour qu’elle produise des résultats fiables et maintenables ? ». Chez Castelis, nous continuons à explorer cette question, et les premiers résultats sont prometteurs.