Confier la génération de code à un agent IA sans spécifications formelles, c’est lui demander de construire un pont en lui montrant une photo de rivière. Le code sort vite, il compile, il passe même les tests — et pourtant il ne correspond à aucune décision d’architecture que votre équipe aurait prise délibérément. Le Spec-Driven Development (SDD) renverse cette logique : la spécification devient l’artefact durable, le code n’est plus qu’un artefact jetable, régénérable à la demande. C’est la seule réponse structurée au chaos que le vibe coding produit à grande échelle.
Pourquoi l’IA générative sans spécifications est-elle un risque métier ?
Le vibe coding accélère la production mais désintègre la gouvernance. Sans spécification partagée, chaque développeur instruit l’agent différemment : l’un choisit JWT, l’autre des cookies de session. Les deux solutions compilent, les deux passent les tests unitaires, et personne ne peut justifier le choix six mois plus tard. En cas d’audit ou de conformité, c’est ingérable.
La donnée confirme l’intuition. D’après l’étude DORA de Google, après l’adoption généralisée d’outils IA par les équipes, la stabilité des livraisons a chuté de 7,2 %. La vitesse gagnée à la génération est mangée par l’instabilité produite en aval.
Le cas Amazon est encore plus concret. Lorsque l’entreprise a imposé une utilisation à 80 % de ses assistants IA sans cadrage suffisant, une panne de six heures a affecté 6,3 millions de commandes. La cause n’était pas l’IA. C’était l’absence de règles formelles sur ce qu’elle pouvait ou ne pouvait pas décider.
Pour les organisations soumises à l’AI Act ou au RGPD, la traçabilité des choix d’implémentation n’est pas une option. Un agent qui choisit seul entre deux patterns de sécurité ne laisse aucune trace auditable — et ça, les équipes juridiques et conformité le détectent, souvent après un incident.
En quoi le Spec-Driven Development change-t-il le travail des agents de code ?
Le SDD pose une règle simple : la spécification est le code source de l’IA. On ne patche jamais le code généré en cas de bug — on affine la spécification et on régénère. Exactement comme on modifie un schéma de données plutôt que la migration SQL qu’il a produite.
Wenvision décrit ce modèle comme une architecture en trois couches : spécifications structurées (Gherkin, Markdown technique, ADR), génération automatique par l’agent, itération sur l’intention plutôt que sur l’artefact. Ce qui change fondamentalement, c’est la direction du curseur : la valeur n’est plus dans la syntaxe, elle est dans la sémantique.
Les équipes qui appliquent ce modèle ont une règle opérationnelle claire :
- Un bug dans le code généré : on rouvre la spec, pas le fichier .py ou .ts
- La documentation reste automatiquement « iso-prod » car elle est la source, pas le reflet
- Les décisions d’architecture sont traçables : chaque ligne de code générée pointe vers un choix explicite
- En cas de refonte partielle, on régénère depuis la spec — pas besoin de comprendre l’historique du code
Sébastien Bourguignon, de Sopra Steria Next, le formule directement : des équipes plus compactes, composées de profils très expérimentés, orchestrent des outils capables de générer spécifications, architecture, design et code. La squad Scrum classique n’est plus l’unité pertinente — et aucun framework agile existant ne répond encore à cette réalité.
Quelle architecture pour faire cohabiter LLM et langages de modélisation formels ?
La séparation est nette : une couche spec (OpenAPI, Gherkin, JSONSchema, Architecture Decision Records), une couche génération (LLM orchestré), une couche validation (tests de conformité automatisés). Chaque couche a son rythme propre. La spec évolue à la vitesse des décisions métier ; le code, à la vitesse des agents — c’est-à-dire en permanence.
En pratique, les organisations qui industrialisent ce modèle s’appuient sur des formats bien établis : OpenAPI 3.x pour les contrats d’API, Gherkin pour les comportements attendus en langage quasi-naturel, les ADR pour tracer les choix structurants, et des fichiers de contexte projet — à la manière d’un CLAUDE.md ou de cursor rules — pour instruire l’agent sur les conventions du projet.
La nomenclature des niveaux proposée par Okoone est utile pour se situer : au niveau 0, chaque prompt est isolé et la décision se perd ; aux niveaux 1-2, on codifie les conventions de style ; aux niveaux 3-5, la spec intègre l’intention architecturale et les métadonnées de conformité. Le niveau 5 — le « SDD constitutionnel » — intègre directement les principes réglementaires dans la logique de génération : chaque principe correspond à un référentiel de vulnérabilités connu.
Sur l’orchestration des agents IA en entreprise, nous avons détaillé comment cette séparation des couches s’articule avec les patterns de gouvernance existants. La logique est identique : ce qui cadre l’agent, c’est son contexte structuré — pas ses prompts libres.
De la spec au commit validé : à quoi ressemble le cycle de vie réel ?
Un cycle SDD industrialisé tient en cinq étapes : rédiger la spec au format structuré, la faire valider par l’équipe (y compris les métiers), la transmettre à l’agent, exécuter la suite de tests de conformité, committer uniquement si les gates passent. L’intervention humaine se déplace de la relecture du code vers la validation de l’intention.
Ce déplacement est la vraie rupture organisationnelle. Un développeur senior passe moins de temps à corriger des bugs de génération et davantage à s’assurer que la spec capture correctement le besoin — un travail qui demande plus de jugement, pas moins.
La traçabilité est un bénéfice direct de cette mécanique : chaque commit pointe vers la spec qui l’a produit, chaque spec vers la décision métier ou réglementaire qui l’a motivée. C’est exactement ce que nous décrivons dans notre article sur le data lineage pour l’IA : la traçabilité des décisions automatisées n’est pas une contrainte administrative, c’est un actif stratégique en cas de contentieux ou d’audit.
Les gates de CI/CD jouent un rôle central dans ce cycle. Les tests de conformité automatisés — validation du contrat OpenAPI avec Spectral, scénarios Gherkin exécutés via Cucumber, vérifications architecturales avec Dependency Cruiser — bloquent le commit si le code généré diverge de la spec. Le juge n’est plus un humain qui relit en fin de sprint : c’est la spec elle-même, à chaque push.
FAQ
Comment tester automatiquement la conformité du code généré aux spécifications ?
Les outils sont matures : Spectral valide les specs OpenAPI, Cucumber et Behave exécutent les scénarios Gherkin contre le code réel, ArchUnit ou Dependency Cruiser vérifient les contraintes structurelles. Un pipeline CI qui combine ces trois couches rend la relecture manuelle systématique obsolète pour la grande majorité des cas de régression.
L’IA peut-elle rédiger ses propres spécifications techniques ?
Oui, avec des gardes-fous stricts. Un agent peut dériver une spec OpenAPI depuis une description en langage naturel, ou proposer un ADR depuis un historique de décisions. Mais la validation humaine reste indispensable : une spec erronée produit un code cohérent avec la spec — donc systématiquement faux, et difficile à détecter.
Quels frameworks utiliser pour structurer les inputs des agents de code ?
Les plus adoptés : OpenAPI 3.x pour les APIs, Gherkin/Cucumber pour les comportements, le format ADR de Michael Nygard pour les décisions d’architecture, et les fichiers de contexte projet (CLAUDE.md, cursor rules, Copilot Instructions). Aucun de ces formats n’est nouveau — ce qui change, c’est qu’ils deviennent des inputs machine plutôt que des documents de référence rarement lus.
Le SDD rend-il obsolètes les développeurs juniors ?
Non, mais il déplace leur point d’entrée. L’accès au code brut diminue ; la compréhension du domaine métier, la capacité à écrire des specs précises et à valider des comportements augmentent en importance. Les juniors formés à ces pratiques ont un avenir réel. Ceux dont la valeur ajoutée se résumait à « coder sur ticket » sans comprendre le pourquoi sont effectivement moins utiles.
Votre organisation déploie des agents de code mais n’a pas encore structuré le processus en amont ? Notre offre Industrialisation & Automatisation couvre ce chantier précisément — des formats de spécification à la mise en place des gates de validation en CI. Demander mon diagnostic pour faire le point sur votre maturité SDD.
