Deux ingénieurs et Codex ont mené un système jusqu’au pilote en deux mois, au lieu d’une équipe de cinq personnes

Le projet d’un client était attendu pour la veille, aucune ressource n’était disponible et il aurait été dommage de refuser. Deux ingénieurs ont donc décidé de vérifier s’ils pouvaient mener cette mission à bien à deux, en faisant écrire tout le code par des agents et en conservant la définition des tâches, le contrôle et les tests. Deux mois plus tard, ils disposaient d’un pilote opérationnel. Voici ce qui a fonctionné dans ce processus et les points faibles que les auteurs reconnaissent eux-mêmes.

Ce qu’ils ont construit et comment ils ont organisé le travail

L’objectif : un système d’automatisation des processus métier doté d’un LLM local, d’intégrations via MCP, d’une logique arborescente et d’un modèle de rôles. Le développer entièrement de zéro aurait été trop ambitieux. Ils sont donc partis d’un projet open source comprenant un éditeur de scénarios et un moteur d’exécution de base. Celui-ci dépendait toutefois du cloud de ses développeurs : il a fallu en dissocier le système et revoir la prise en charge du modèle local.

La technique principale consiste à économiser le contexte. Si l’on demande simplement à l’agent de « construire l’intégration », il sature sa fenêtre de contexte, commence à compresser l’historique, perd des détails et relit les mêmes fichiers en boucle jusqu’à épuiser les jetons. Ils demandent donc d’abord à l’agent de décomposer la tâche en petites étapes, puis un humain élimine le superflu : l’agent a tendance à multiplier les précautions et les contrôles inutiles. Le plan final devient la spécification.

Ensuite, tout réside dans des fichiers. AGENTS.md est chargé à chaque session et ne contient donc que des liens vers de petits documents consacrés à l’architecture, au serveur et à l’API. Un fichier de progression distinct indique à quelle étape du plan le travail s’est arrêté. L’agent prend l’étape suivante, ne lit que les documents nécessaires, effectue un commit et met à jour l’avancement. Autre avantage : lorsque l’un des ingénieurs épuise son quota de jetons, son collègue indique le même dossier à son propre agent, qui reprend le travail au bon endroit.

Le degré de supervision dépend des délais. Il est possible de vérifier le résultat après chaque sous-étape ou de laisser l’agent travailler toute la nuit, jusqu’au déploiement sur l’environnement de développement. Dans le pire des cas, les modifications sont annulées.

Là où ça fait mal

Les auteurs ne délèguent pas les tests. Playwright via MCP consomme des jetons, mais le principal problème est que l’agent vérifie uniquement les fonctionnalités. Un bouton peut fonctionner sans produire de réaction visuelle, ou un élément peut avoir bougé sans qu’il le remarque. Un humain le voit immédiatement.

Le coût du développement agentique :

• Vous perdez la connaissance du projet. Les grands blocs du système restent compréhensibles, mais le contenu précis d’un module ne l’est plus, ce qui conduit à formuler les tâches avec moins de précision.
• La qualité du code n’est pas encore confirmée. La revue de code et l’audit de sécurité ont été reportés pour préserver le rythme, et les tests à grande échelle restent à venir.
• Les délais sont imprévisibles. L’agent a décidé de reconstruire l’image Docker après chaque modification afin de disposer d’un point de restauration : un petit correctif a ainsi pris trois heures au lieu d’une demi-heure.
• L’agent comble les blancs. Au lieu de « créer un utilisateur administrateur », il a mis en place une invitation par e-mail.
• Le travail s’étale sur toute la journée : de brèves clarifications sont nécessaires le matin, le soir et avant de se coucher.

Pourquoi cela reste rentable

La vitesse globale est supérieure à celle de deux personnes travaillant selon une méthode classique, ce qui réduit le coût de validation d’une hypothèse au stade du pilote. La barrière à l’entrée dans des technologies inconnues diminue : le socle du produit est écrit en JS, qui n’est pas la spécialité de l’équipe. L’agent prend également facilement en charge l’intégration graphique : on lui fournit des liens vers les ressources de l’entreprise, il constitue un guide de marque et met l’interface en conformité presque dès la première tentative.

Sur le plan économique, les auteurs estiment qu’en l’absence d’agents, il aurait fallu un développeur frontend, deux développeurs backend, un testeur et un ingénieur DevOps. À la place : deux abonnements Pro à $200.

Ce qu’il faut retenir

• N’attendez pas de solution magique : commencez par définir le processus, le plan et la documentation.
• N’utilisez pas de modèles faibles sans garde-fous. Lors des tests, l’un d’eux a supprimé la base de données, puis a expliqué qu’il n’existait aucune sauvegarde, mais que les données étaient de toute façon peu nombreuses. Les commandes dangereuses doivent rester soumises à une confirmation manuelle.
• Prévoyez une marge dans le budget des abonnements : les itérations et les longues exécutions consomment des jetons.

Les limites sont exposées honnêtement. L’expérience n’est pas terminée : il n’y a encore eu ni mise en production ni test en charge. Pour les phases de conception et de pilote, l’approche se justifie. En revanche, il faudra élargir l’équipe pour passer en production : quelqu’un devra valider ce que l’agent a écrit. Dans le secteur public et dans les environnements où chaque ligne doit être justifiée, cette méthode aura peu de chances de s’imposer.