Le prompt-to-code a rendu une chose visible : il est désormais possible de produire du logiciel beaucoup plus vite qu’avant.
Mais il a aussi exposé sa limite.
Demander à une IA de “coder une application” peut suffire pour explorer une idée, générer un prototype ou débloquer une tâche locale. Ce n’est pas suffisant pour construire un produit fiable, maintenable, sécurisé et exploitable en production.
La prochaine étape ne consiste pas à écrire plus de prompts. Elle consiste à construire des systèmes capables d’orchestrer le travail des agents IA dans un cadre maîtrisé.
C'est typiquement ce qu'est un Agentic Delivery System.
Un Agentic Delivery System est un système de production logicielle dans lequel les agents IA ne sont pas utilisés comme de simples assistants de code, mais comme des unités d’exécution spécialisées, gouvernées par des specs, des contextes, des pratiques de craftsmanship, des harnais qualité, des gates humains, des règles de sécurité et des métriques de ROI.
L’enjeu n’est donc pas d’ajouter de l’IA dans le SDLC. L’enjeu est de redessiner le SDLC pour qu’il devienne pilotable par des agents sans perdre le contrôle humain.
Et pour cela, un principe doit rester non négociable : l’état de l’art n’est pas agent-first. Il est craft-first, agent-accelerated.
Le malentendu du prompt-to-code
Le “vibe coding” a eu une vertu : il a montré la vitesse possible. Il a permis à des fondateurs, développeurs, designers et product builders de matérialiser une idée en quelques heures.
Mais il a aussi montré son angle mort : sans spec, sans architecture, sans tests, sans sécurité, sans feature flags et sans gouvernance, la vitesse devient une dette.
Le problème n’est pas que les agents IA codent mal. Le problème est qu’on leur demande trop souvent de coder avant d’avoir clarifié ce qui doit être construit, comment cela doit se comporter, comment cela sera testé, comment cela sera livré, comment cela sera désactivé, et qui assume le risque.
Une idée floue produit un logiciel flou. Un besoin ambigu produit des arbitrages implicites. Une architecture non formulée devient une architecture inventée par l’agent. Une absence de tests transforme chaque itération en pari. Un flag oublié transforme une livraison en bascule risquée.
Le prompt-to-code est utile pour explorer. Il est insuffisant pour industrialiser.
Du copilote à l’agent logiciel
La première génération d’outils IA pour développeurs était centrée sur l’assistance : autocomplétion, génération de snippets, explication de code, aide ponctuelle.
La génération actuelle est différente.
Des outils comme OpenAI Codex, Claude Code, GitHub Copilot coding agent, Cursor Background Agents, Google Jules, Devin, Kiro ou Hermes déplacent le sujet.
Ils ne se contentent plus de suggérer du code. Ils peuvent lire un dépôt, comprendre une base existante, modifier plusieurs fichiers, lancer des commandes, exécuter des tests, diagnostiquer une CI, produire une branche, ouvrir une PR ou travailler en arrière-plan dans un environnement isolé.
À partir de ce moment, l’agent n’est plus seulement un outil développeur. Il devient une unité d’exécution dans l’organisation logicielle.
Et une unité d’exécution doit avoir un rôle, un périmètre, des permissions, des livrables, des contrôles et une traçabilité.
Le vrai sujet est organisationnel
L’IA agentique n’est pas un sujet réservé aux développeurs. C’est un sujet d’organisation du travail logiciel.
Elle déplace la frontière entre conception, exécution et contrôle.
Le product manager ne peut plus écrire des tickets approximatifs en espérant que l’équipe interprète correctement. Le tech lead ne peut plus garder l’architecture uniquement dans sa tête. Le développeur ne peut plus compter seulement sur sa compréhension locale. Le QA ne peut plus arriver à la fin. La sécurité ne peut plus être une revue tardive. Le management ne peut plus mesurer la productivité en volume de code.
Les agents obligent l’organisation à rendre explicite ce qui était souvent implicite :
- la stratégie produit ;
- les hypothèses métier ;
- les bounded contexts ;
- les décisions d’architecture ;
- les exemples métier ;
- les tests attendus avant implémentation ;
- les règles de sécurité ;
- les critères d’acceptation ;
- la Definition of Done ;
- les chemins de validation ;
- les responsabilités humaines ;
- les métriques de qualité et de ROI.
Une équipe mature avec des agents bien cadrés peut accélérer fortement.
Une équipe immature avec des agents puissants produit seulement de la dette plus vite.
Les sept couches d’un Agentic Delivery System
Un Agentic Delivery System sérieux repose sur sept couches. Elles ne sont pas décoratives. Elles empêchent l’agent de devenir un générateur de dette rapide.
1. Intent Layer
La première couche clarifie l’intention.
Quel problème veut-on résoudre ? Pour qui ? Pourquoi maintenant ? Quelle valeur attendue ? Quelles contraintes ? Quels risques ? Qu’est-ce qui ne doit pas être construit ?
Cette couche produit une note d’opportunité, des personas, des hypothèses, des contraintes business et une première définition du succès.
L’agent peut aider à rechercher, comparer, synthétiser et challenger. Mais la décision reste humaine.
2. Spec & BDD Layer
La deuxième couche transforme l’intention en spécification vérifiable.
BDD ne doit pas être compris comme une simple technique de test. C’est une pratique de clarification. Elle force les conversations entre produit, engineering, QA, sécurité et métier avant que le code ne soit écrit.
Cette couche formalise :
- les user stories ;
- les exemples concrets ;
- les scénarios Gherkin ;
- les critères d’acceptation ;
- les règles métier ;
- les cas limites ;
- les états d’erreur ;
- les exigences non fonctionnelles.
La spec devient l’unité de travail.
Dans un système agentique mature, le prompt n’est pas le contrat. La spec est le contrat.
3. Architecture Layer
La troisième couche définit la structure.
Bounded contexts, modèle de domaine, choix techniques, intégrations, flux de données, dépendances, ADR, contraintes de sécurité, scalabilité, observabilité.
Cette couche est critique. Laisser un agent choisir seul l’architecture revient à déléguer des décisions irréversibles à un acteur qui optimise souvent pour l’achèvement immédiat de la tâche.
L’agent peut proposer. L’humain arbitre.
4. Craftsmanship Layer
La quatrième couche transforme la génération de code en travail d’ingénierie.
C’est la couche qui manquait souvent aux premières approches agentiques. On ne demande pas à l’agent de coder puis de tester. On lui impose de travailler dans une discipline de craftsmanship.
Concrètement, cela signifie :
- BDD en amont pour clarifier le comportement ;
- TDD pendant l’implémentation ;
- cycle red-green-refactor ;
- tests rouges avant le code ;
- code minimal pour passer au vert ;
- refactoring explicite ;
- simplicité de design ;
- petits incréments ;
- trunk-based development quand l’organisation le permet ;
- revue de code stricte ;
- suppression de dette, pas seulement ajout de fonctionnalités.
Le rôle du craftsmanship est simple : empêcher que l’agent confonde “ça marche” avec “c’est bien conçu”.
Sans craftsmanship, les agents automatisent surtout la production de dette. Avec BDD, TDD, refactoring, flags et gates, ils peuvent accélérer un vrai processus d’ingénierie.
5. Agent Layer
La cinquième couche distribue le travail aux bons agents.
Il ne faut pas chercher un agent omnipotent. Il faut créer une organisation logicielle miniature :
- agent de recherche ;
- agent produit ;
- agent UX/UI ;
- agent domaine ;
- agent architecture ;
- agent BDD ;
- agent TDD ;
- agent implémentation ;
- agent test ;
- agent sécurité ;
- agent DevOps ;
- agent reviewer ;
- agent ROI.
Chaque agent doit avoir un rôle clair, un périmètre limité, des entrées explicites et des sorties vérifiables.
6. Harness & Governance Layer
La sixième couche encadre l’exécution.
Tests, CI, lint, typecheck, SAST, dependency audit, secrets scanning, sandbox, permissions minimales, logs, checkpoints, rollback, feature flags, revue humaine.
C’est cette couche qui rend l’autonomie acceptable.
Un agent autonome sans harnais est un risque. Un agent autonome avec harnais devient un accélérateur contrôlé.
7. Learning & ROI Layer
La septième couche mesure et améliore.
Combien de temps gagné ? Combien de défauts évités ? Combien de PR acceptées sans reprise majeure ? Combien de dette créée ? Quel coût agent ? Quel temps humain de revue ? Quel impact sur le cycle time ? Quels incidents post-release ?
Sans mesure, l’IA devient une impression de productivité. Avec mesure, elle devient un système pilotable.
BDD, TDD et flags : la qualité avant le code
Le point de bascule est là.
Un Agentic Delivery System sérieux ne demande pas aux agents de coder puis de tester. Il leur impose de transformer le besoin en exemples exécutables, tests rouges, contrats, flags et gates avant toute implémentation.
Le flux cible n’est pas :
Prompt → Code → Tests si on a le temps.
Le flux cible est :
Intent → Exemples BDD → Architecture → Red tests → Code minimal → Green → Refactor → Feature flag → CI → Review → Release contrôlée.
Cette séquence change la nature du travail agentique. L’agent n’est plus récompensé parce qu’il produit beaucoup de code. Il est évalué sur sa capacité à faire passer un comportement clairement défini dans un système contrôlé.
Les feature flags doivent eux aussi arriver tôt. Pas comme un bricolage de fin de projet, mais comme une décision de livraison.
Avant le développement, l’équipe doit décider :
- le type de flag : release, expérimentation, opérationnel, permission ;
- son propriétaire ;
- son comportement par défaut ;
- sa durée de vie ;
- sa stratégie de retrait ;
- les métriques à observer ;
- le scénario de rollback.
Un flag sans propriétaire devient une dette. Un test sans comportement métier devient fragile. Un agent sans red test devient un pari.
Lire le marché par rôle, pas par hype
La question n’est pas : “Quel est le meilleur outil ?”
La bonne question est : “Quel outil prend en charge quelle partie du cycle, avec quel niveau d’autonomie, de risque et de vérifiabilité ?”
| Famille | Exemples | Usage dominant | Point de vigilance |
|---|---|---|---|
| Agents locaux | Codex, Claude Code | Comprendre, modifier, tester, revoir un repo sous supervision | Qualité du contexte local et discipline de validation |
| Agents IDE | Cursor, assistants IDE | Accélérer le flux développeur quotidien | Confusion entre prototype rapide et code de production |
| Agents cloud asynchrones | Jules, Devin, Cursor Background Agents | Déléguer des tâches longues dans un environnement isolé | Permissions, secrets, coûts, branches, traçabilité |
| Spec-driven tools | Kiro | Transformer l’intention en exigences, design, tâches et tests | La spec doit être solide, sinon l’outil formalise l’ambiguïté |
| Agents persistants | Hermes | Mémoire, skills, orchestration, automatisation | Gouvernance des capacités et des outils connectés |
| Couche d’intégration | MCP | Connecter agents, outils, données, APIs et systèmes internes | Prompt injection, exfiltration, permissions excessives |
La maturité ne consiste pas à choisir un camp. Elle consiste à composer une chaîne d’outils selon le niveau de risque, d’autonomie et de contrôle attendu.
Sécurité : traiter l’agent comme une surface de risque
Plus l’agent devient autonome, plus il faut traiter son périmètre comme une surface de risque.
Un agent peut avoir accès au code, au terminal, au réseau, à GitHub, Jira, Slack, aux secrets, à la CI/CD ou aux environnements cloud.
Ce n’est pas neutre.
Il faut donc appliquer des principes simples :
- moindre privilège ;
- séparation lecture/écriture ;
- sandbox ;
- validation humaine avant action sensible ;
- secrets jamais exposés inutilement ;
- restriction réseau ;
- contrôle des outils MCP ;
- logs d’actions ;
- branches dédiées ;
- revue obligatoire ;
- rollback ;
- surveillance des dépendances ;
- détection des injections de prompt.
Les agents ne réduisent pas le besoin de sécurité. Ils l’augmentent.
Parce qu’ils accélèrent l’exécution, ils accélèrent aussi les erreurs quand les garde-fous sont faibles.
Cas concret : ReleasePilot
Prenons un cas fil rouge : ReleasePilot.
ReleasePilot est une plateforme agentique qui transforme les feedbacks clients, tickets support, signaux produit et incidents de production en décisions priorisées, specs vérifiables, tickets engineering, PR assistées et notes de release.
Dans une approche naïve, on demanderait à un agent :
Code-moi une app SaaS de gestion de feedback produit.
L’agent produirait probablement quelque chose de visible. Peut-être même impressionnant. Mais il devrait inventer seul le modèle métier, l’architecture, l’UX, la sécurité, les intégrations, les tests et la stratégie de release.
Dans une approche Agentic Delivery System, on procède autrement.
L’Intent Layer clarifie le problème : les feedbacks sont dispersés, la priorisation est opaque, le lien entre support, produit et engineering est fragile, et les release notes arrivent trop tard.
Le Spec & BDD Layer formalise les scénarios : ingestion d’un feedback, regroupement de signaux similaires, priorisation, génération d’une spec, validation humaine, création d’un ticket, suivi de livraison, publication d’une note de release.
L’Architecture Layer définit les bounded contexts :
- Feedback Intake ;
- Signal Clustering ;
- Product Decisioning ;
- Spec Generation ;
- Delivery Orchestration ;
- Release Communication ;
- Engineering Analytics ;
- Governance & Audit.
Le Craftsmanship Layer impose les premiers tests rouges, les contrats d’intégration, les règles de refactoring et les flags nécessaires avant la première tranche verticale.
L’Agent Layer affecte les rôles. Un agent recherche les outils existants. Un agent produit formalise les personas. Un agent domaine structure les concepts. Un agent architecture propose les ADR. Un agent BDD écrit les scénarios. Un agent TDD prépare les tests rouges. Un agent implémente le minimum. Un agent sécurité vérifie les intégrations GitHub et les tokens. Un agent reviewer relit le diff.
Le Harness & Governance Layer impose les contrôles : tests, CI, lint, secrets scanning, revue humaine, feature flags, logs.
Le Learning & ROI Layer mesure le résultat : temps de cadrage gagné, qualité des specs, taux de PR acceptées, défauts détectés avant merge, coût agent, temps humain économisé, incidents évités.
Ce n’est plus du prompt-to-code. C’est un système de delivery.
Ce que cela change pour les dirigeants
Pour un CTO, un founder ou un product leader, le sujet n’est pas seulement de donner de meilleurs outils aux développeurs.
Le sujet est de repenser le modèle opérationnel.
Quels travaux peuvent être délégués à des agents ? Quels travaux doivent être supervisés ? Quels travaux restent non délégables ? Qui valide les specs ? Qui valide l’architecture ? Qui valide la sécurité ? Qui mesure la dette ? Qui décide du passage en production ?
La Definition of Done doit évoluer.
Une tâche terminée ne signifie plus seulement : “le code fonctionne”. Elle doit signifier :
- intention claire ;
- exemples BDD validés ;
- tests rouges écrits ;
- architecture cohérente ;
- feature flag défini quand nécessaire ;
- tests passés ;
- sécurité contrôlée ;
- CI verte ;
- revue humaine effectuée ;
- impact produit clair ;
- observabilité prévue ;
- rollback possible ;
- coût et ROI mesurables.
L’IA agentique ne supprime pas le management technique. Elle le rend plus exigeant.
Une matérialisation possible : AI SDLC Skills
C’est dans cette logique que j’ai formalisé, à titre d’exemple, une suite ouverte de skills IA dédiés au cycle complet de développement logiciel : AI SDLC Skills.
L’objectif n’est pas d’ajouter une collection de prompts. L’objectif est de rendre explicites les rôles, les livrables, les gates et les harnais nécessaires pour faire travailler des agents sur un projet réel.
Ce type de suite n’a de valeur que si elle s’intègre dans une méthode plus large : specs, architecture, craftsmanship, tests, sécurité, production et apprentissage continu.
Le modèle de maturité
On peut lire la maturité agentique en six niveaux.
- Niveau 0 : prompts isolés. L’IA est utilisée ponctuellement, sans cadre.
- Niveau 1 : assistant IDE. Les développeurs gagnent du temps localement.
- Niveau 2 : agents locaux supervisés. Les agents modifient du code, lancent des tests et expliquent leurs changements.
- Niveau 3 : agents spécialisés avec BDD/TDD. Produit, architecture, UX, BDD, TDD, sécurité, test et review commencent à être séparés.
- Niveau 4 : agents intégrés au delivery. GitHub, CI/CD, tickets, PR, documentation et environnements sont connectés.
- Niveau 5 : Agentic Delivery System gouverné. Les agents ont des rôles, permissions, harnais, métriques, gates et pratiques de craftsmanship.
- Niveau 6 : delivery semi-autonome. Le système peut transformer une idée cadrée en trajectoire produit, specs, red tests, code, PR, validation, release et boucle d’apprentissage.
Peu d’organisations sont réellement au niveau 5 ou 6. L’important n’est pas d’aller vite vers l’autonomie maximale. L’important est de construire les fondations qui rendent l’autonomie acceptable.
Les erreurs à éviter
- Commencer par le code.
- Croire qu’un agent peut compenser une absence de vision produit.
- Traiter BDD comme une documentation après coup.
- Faire du TDD un luxe réservé aux équipes matures.
- Laisser l’architecture dans l’implicite.
- Donner trop de permissions trop tôt.
- Traiter les tests comme une option.
- Ajouter des feature flags sans stratégie de retrait.
- Confondre vitesse de génération et vitesse de livraison.
- Empiler les outils sans modèle opérationnel.
- Ne pas mesurer les coûts : tokens, temps humain, dette, bugs, reprises, incidents.
- Croire que les agents remplacent le jugement senior. Ils l’exécutent quand ce jugement a été rendu explicite.
Conclusion
La prochaine différence de performance entre les équipes ne viendra pas seulement du modèle qu’elles utilisent.
Elle viendra de leur capacité à rendre leur propre exigence exécutable : intention, specs, exemples BDD, tests rouges, architecture, flags, sécurité, contexte, gates et apprentissage.
Les agents ne remplacent pas l’ingénierie. Ils révèlent brutalement la qualité ou la faiblesse de son système.
L’agentic engineering n’est pas une automatisation du développement logiciel. C’est une mise à l’épreuve de la maturité logicielle.
Et cette maturité commence par un choix simple : ne pas demander aux agents d’aller plus vite que notre capacité à penser correctement le produit, le code, l’organisation et le risque.
Références
- OpenAI Codex
- Claude Code
- GitHub Copilot coding agent
- Cursor Background Agents
- Google Jules
- Devin
- Kiro
- Hermes
- Model Context Protocol
- Cucumber BDD
- Feature Toggles, Martin Fowler
- Manifesto for Software Craftsmanship
Business