SDD et OpenSpec : Le guide complet pour passer du « Vibe Coding » au développement piloté par les spécifications
Pourquoi le « Vibe Coding » atteint ses limites
Ces derniers mois, la génération de code par intelligence artificielle a connu un engouement massif. Des milliers de développeurs se sont habitués à saisir des prompts informels dans des outils comme Claude Code, Cursor ou GitHub Copilot pour générer des fonctionnalités complètes en quelques secondes. Cependant, cette pratique informelle — souvent qualifiée de « vibe coding » — montre rapidement ses faiblesses dès qu’un projet gagne en complexité.
Parmi les problèmes les plus fréquents, on observe l’apparition d’hallucinations d’API, l’oubli du contexte au fil des conversations longues, et l’accumulation d’une dette technique incontrôlée. Lorsque l’assistant IA modifie un fichier à trois niveaux de profondeur sans comprendre l’architecture globale, les développeurs passent plus de temps à déboguer qu’à concevoir. C’est pour répondre à cette problématique majeure qu’émerge le Spec-Driven Development (SDD), une méthodologie consistant à formaliser l’intention et le comportement attendu dans une spécification structurée avant d’écrire la moindre ligne de code.
Qu’est-ce qu’OpenSpec et la philosophie SDD ?
Le concept de développement piloté par les spécifications n’est pas totalement nouveau, mais son adaptation aux assistants IA transforme la manière de concevoir le logiciel. Comme l’a souligné le célèbre informaticien Martin Fowler dans ses analyses de l’ingénierie logicielle assistée par IA, la spécification devient le document de référence durable, tandis que le code généré devient un produit d’exécution dérivé.
Créé par Tabish Bidiwale (fondateur de Fission AI), OpenSpec est un framework CLI open source léger conçu spécialement pour structurer la collaboration entre les développeurs et leurs agents de codage. Contrairement à des cadres plus rigides ou à cycle lourd, OpenSpec repose sur une philosophie pragmatique :
- Fluide et itératif : Pas de découpage strict en cascade ; les spécifications évoluent au fur et à mesure des découvertes techniques.
- Axé sur les deltas : OpenSpec ne demande pas de tout redocumenter à chaque changement. Il utilise des deltas (modifications ciblées via des balises comme
ADDED,MODIFIEDouREMOVED). - Conçu pour les projets existants (brownfield) : Il s’intègre directement au sein des dépôts existants sans imposer de réécriture globale.
L’expert en ingénierie logicielle Hari Krishnan, auteur de travaux de référence sur le sujet, rappelle d’ailleurs que le SDD permet de réduire la dérive de contexte en transformant l’agent d’un simple générateur de texte en un exécutant contraint par des critères d’acceptation précis.
Guide de mise en place : Installer et initialiser OpenSpec
L’installation d’OpenSpec s’effectue en quelques secondes via votre gestionnaire de paquets Node.js. L’outil fonctionne directement en ligne de commande (CLI) et communique avec les agents IA via des commandes dédiées (slash commands).
1. Installation globale de la CLI
Ouvrez votre terminal et exécutez la commande suivante :
npm install -g @fission-ai/openspec@latest
2. Initialisation dans votre projet
Placez-vous à la racine de votre dépôt de code et lancez l’initialisation :
openspec init
Cette commande crée l’arborescence nécessaire sur votre disque :
openspec/specs/: Le répertoire contenant la « source de vérité » de votre système, organisée par domaines (ex.auth/,payments/,ui/).openspec/changes/: Le dossier temporaire où sont isolées les propositions de modifications en cours.
De plus, openspec init génère automatiquement les configurations nécessaires pour que vos assistants IA (Claude Code, Cursor, Copilot) reconnaissent les compétences OpenSpec.
Guide d’utilisation : Le workflow quotidien en 4 étapes
Au quotidien, le cycle de vie d’une évolution de code avec OpenSpec s’articule autour de quatre phases claires.
Étape 1 : L’exploration (/opsx:explore)
Avant d’écrire une spécification ferme, il est souvent utile de réfléchir avec l’IA. En lançant la commande d’exploration, l’agent pose des questions pour clarifier le besoin fonctionnel, identifier les cas limites et explorer les choix d’architecture. Des formateurs reconnus comme Matt Pocock recommandent cette étape de dialogue préalable pour challenger les hypothèses avant la rédaction des documents sur disque.
Étape 2 : La proposition de changement (/opsx:propose)
Une fois l’idée claire, lancez la proposition :
/opsx:propose ajout-authentification-oauth
L’agent crée un dossier dédié dans openspec/changes/ajout-authentification-oauth/ contenant quatre artefacts en Markdown :
- proposal.md : Explique le pourquoi et le quoi en langage naturel (objectifs, périmètre, critères de succès).
- specs/ : Définit les exigences fonctionnelles et les scénarios de test sous forme de deltas (ex.
ADDED Requirement: The system SHALL support Google OAuth2 login). - design.md : (Optionnel) Décrit l’approche technique, les patterns d’architecture ou les choix de bibliothèques.
- tasks.md : Liste de tâches atomiques et séquentielles à exécuter par l’IA.
Étape 3 : L’exécution et la mise en œuvre (/opsx:apply)
Le développeur repasse sur les fichiers Markdown, ajuste les critères ou valide le plan. Une fois l’accord donné, la commande d’application est lancée :
/opsx:apply
L’assistant IA lit le fichier tasks.md et exécute chaque tâche une à une, en écrivant le code et les tests unitaires associés conformément aux exigences formulées dans la spec.
Étape 4 : L’archivage (/opsx:archive)
Une fois le code validé et les tests réussis, la modification est archivée :
/opsx:archive
OpenSpec intègre automatiquement les deltas de spécification dans la source de vérité globale (openspec/specs/) et déplace le dossier de changement vers les archives. La documentation du projet reste ainsi constamment à jour sans effort manuel supplémentaire, un avantage souligné par des praticiens comme le consultant Dan Clarke.
Conséquences concrètes pour les développeurs et l’industrie
L’adoption du Spec-Driven Development via des outils comme OpenSpec modifie profondément la dynamique des équipes de développement :
- Évolution du rôle de développeur : Le développeur passe du statut de simple rédacteur de syntaxes à celui d’architecte et de contrôleur d’intentions. Sa valeur ajoutée réside dans la clarté du besoin et l’arbitrage des choix techniques.
- Revue de code simplifiée : La revue de code commence par la relecture des spécifications (proposal et design). Si la spécification est validée, la vérification du code produit devient nettement plus rapide et prévisible.
- Réduction drastique du gaspillage : En identifiant les ambiguïtés et les incompatibilités techniques au niveau de la spec, les équipes évitent de générer des centaines de lignes de code inutiles qui finiraient par être jetées.
- Gouvernance et traçabilité : Pour les entreprises, chaque évolution conserve un historique complet des décisions d’architecture et des exigences métier associées.
Avez-vous déjà franchi le pas du Spec-Driven Development avec vos assistants IA, ou pratiquez-vous encore le « vibe coding » au quotidien ? Quels sont les principaux obstacles que vous rencontrez dans la formalisation de vos besoins ? N’hésitez pas à partager vos retours d’expérience dans les commentaires ci-dessous !
Photo : cottonbro studio sur Pexels.
Pour aller plus loin
Liens affiliés Amazon : en tant que Partenaire Amazon, ce site perçoit une commission sur les achats éligibles réalisés via ces liens, sans coût supplémentaire pour vous.
Un ouvrage de référence sur la méthodologie SDD qui explique comment transformer l’intention en spécifications exploitables par des agents IA.
Refactoring: Improving the Design of Existing Code, Martin Fowler
Un classique indispensable pour comprendre comment faire évoluer proprement une base de code existante tout en maintenant son comportement, un principe central des deltas dans OpenSpec.
