Construire un logiciel avec des agents : dix semaines, 436 tâches, 5 794 tests

La boucle est simple : un fichier de backlog, une tâche en tête, un agent qui démarre avec un contexte neuf, lit les règles du projet, fait la tâche, écrit ses tests, et un second passage qui juge le résultat avant qu'il entre dans le code. Si le juge refuse, la tâche revient. Pas de conversation de trois heures qui dérive : chaque run repart de zéro, avec les règles écrites.

Ce qui fait la différence, ce n'est pas l'agent, ce sont les règles écrites avant le code. Un fichier d'instructions qui dit ce qu'on ne fait jamais (aucun paramètre prix, écriture au brouillon, un conteneur par client), et des fichiers de garde-fous que l'agent n'a pas le droit de modifier. Quand un agent a voulu « simplifier » un test de sécurité pour le faire passer, c'est ce verrou qui l'a arrêté, pas sa bonne volonté.

Le chiffre qui compte n'est pas 320, c'est 116. Ce sont les tâches qu'aucun agent n'a faites, et qu'il ne fallait pas lui confier.

• Les vérifications en direct. Chaque capacité a été testée dans Telegram, sur le pilote en cours, et recoupée dans Odoo. Un chiffre d'affaires par vendeur exact au centime. Deux clients homonymes départagés par la ville. Un redéploiement qui attend la fin de la question en cours au lieu de couper l'utilisateur. Aucun test automatique ne remplace ça.
• Les décisions. Onze décisions d'architecture, chacune avec ses options rejetées et ses risques assumés. Des outils par intention plutôt que par objet Odoo. Un vérificateur de chiffres. Un index local. Un agent peut proposer, il ne tranche pas ce qui engage le produit pour deux ans.
• Les réglages de qualité. Quand le premier lot d'enrichissement du catalogue a donné des types approximatifs, c'est une relecture humaine qui a dit lesquels, et une itération qui a monté la justesse à environ 20 sur 22. L'agent ne sait pas qu'il s'est trompé tant que personne ne le lui dit.

Trois choses, pour être utile plutôt que flatteur. Des tests qui passaient au vert parce qu'ils ne testaient rien de réel : on a ajouté une règle qui échoue quand un test ne trouve pas assez de cibles. Un agent qui a modifié un fichier de configuration qu'il n'aurait pas dû toucher : la liste des fichiers protégés a été étendue. Et des tâches trop larges qui revenaient trois fois : la règle est devenue « une tâche tient dans un run, sinon on la découpe avant ».

Ce que ça coûte en argent n'est pas un chiffre public, mais l'ordre de grandeur se dit : une tâche livrée par un agent coûte quelques dollars de calcul, et le vrai coût est le temps humain des 116. C'est beaucoup moins qu'une équipe, et beaucoup plus que zéro.

Distinction qui compte pour votre budget : ce coût est celui de la construction. Une fois livré, le logiciel ne tourne pas sur les grands modèles qui l'ont écrit. Il tourne sur un modèle ouvert, sur une machine équipée d'une bonne carte graphique, administrée à distance, et chaque question de votre équipe coûte zéro. Pas de crédit, pas de siège. Le calcul détaillé.

Quatre questions à poser à qui vous propose un logiciel « fait avec l'IA ». Combien de tests, et tournent-ils à chaque livraison ? Où sont écrites les règles que l'agent n'a pas le droit de casser ? Qui a vérifié en direct, sur de vraies données, et comment ? Et quelles décisions ont été écrites avec les options rejetées ? Si les réponses sont des chiffres et des fichiers, continuez. Si ce sont des adjectifs, non.

Le logiciel dont il est question ici est notre serveur MCP pour Odoo. Ce que les garde-fous interdisent à l'agent, et pourquoi : l'agent qui ne peut pas toucher aux prix. Et pour prendre la main vous-même sur ces outils, en une demi-journée sur votre propre projet : l'atelier Claude Code pour dirigeant.