OpenSpec : le spec-driven taillé pour le code que vous avez déjà

OpenSpec est un cadre spec-driven conçu pour le code existant : chaque changement y est décrit comme un delta de spécification, et non comme une refonte de la spec entière. Il s'adresse aux équipes qui font du 1-vers-n, c'est-à-dire qui modifient un système déjà en production et veulent de la prévisibilité sans cérémonie.

Le dépôt a été ouvert en août 2025 par Fission AI, sous licence MIT¹. Le 19 septembre 2026, son README affiche 69 500 étoiles et 4 800 forks¹. Cet article est l'un des neuf satellites du comparatif des méthodes de développement avec agents, qui lit chaque méthode sur la grille du SDLC augmenté par l'IA de SFEIR.

D'où vient OpenSpec

Fission AI a stabilisé une version 1.0 après une refonte orientée actions (état des lieux de Ry Walker, 11 juin 2026)³. En septembre 2026, le cadre annonce plus de trente outils de codage pris en charge, dont Claude Code, Cursor, Kiro, Codex, Amazon Q et Copilot, sans dépendance à un serveur MCP ni clé d'API¹. La documentation recommande des modèles à fort raisonnement et cite Codex 5.5 et Opus 4.7¹. Le document de concepts résume la philosophie : « fluid not rigid, no phase gates, work on what makes sense » et « brownfield-first »².

Le cycle en cinq commandes

L'installation passe par le terminal : npm install -g @fission-ai/openspec@latest, puis openspec init (étape 1, Init, portée par le développeur) pose une fois le guidage du projet¹. Les commandes de travail se tapent ensuite dans le chat de l'assistant.

• /opsx:explore (étape 2, Explore, agent et humain) : l'agent lit le code et esquisse une piste, sans engagement.
• /opsx:propose (étape 3, Propose, humain et agent) : la commande canonique. L'agent rédige proposal.md, un dossier specs/, design.md et tasks.md ; l'humain relit¹.
• /opsx:apply (étape 4, Apply, agent) : l'agent implémente les tâches.
• /opsx:archive (étape 5, Archive, l'humain vérifie) : les deltas sont fusionnés dans la spec de référence, qui reste la source de vérité².

Un profil étendu ajoute /opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:bulk-archive et /opsx:onboard¹. Un refactor pur peut déclarer skip_specs: true et passer de la validation à l'archivage sans écrire de delta².

Lecture dans la grille SFEIR

Les cinq étapes d'OpenSpec se projettent ainsi sur le cycle SFEIR à onze phases, ses trois gates humains (Define, Plan, Ship) et ses deux capitalisations (Compound-1, Compound-2).

Étape OpenSpec	Étape(s) de la grille SFEIR
Init (openspec init)	0 Setup
Explore	1 Define (amorce)
Propose	1 Define, 2 Plan
Apply	3 Build, 4 Verify
Archive	5 Review, 6 Compound-1 (hors cycle)

OpenSpec couvre l'amont et la construction. Ship, Ops et Deprecation restent hors champ. La capitalisation vit hors cycle : l'archivage produit une spec système qui grossit avec le code. OpenSpec est le seul cadre de la série sans gate formel, ce que sa documentation revendique² : l'humain corrige n'importe quel artefact au fil de la conversation.

Le delta comme unité de travail

Chaque changement décrit seulement ce qu'il ajoute, modifie ou retire par rapport à une spec de référence, sous trois rubriques : ADDED, MODIFIED, REMOVED². Deux changements en cours peuvent toucher le même spec.md sans conflit tant qu'ils visent des exigences différentes². La revue devient une revue d'intention : le relecteur lit le delta, pas le diff brut. Les marqueurs existent pour qu'un agent travaillant dans un code mûr n'invente pas de nouvelles exigences sur le comportement existant⁵.

Forces, limites et angles morts

La sortie est légère : Hashrocket, en octobre 2025, situe un changement OpenSpec autour de 250 lignes contre environ 800 pour un toolkit plus lourd⁷, opposition que reprennent les comparatifs de juin 2026 avec Spec Kit⁴⁶. La portabilité tient à l'absence de dépendance MCP, et l'adoption coûte deux commandes.

La limite documentée principale est la dérive des specs. Les scénarios Given/When/Then figurent dans les exemples, mais rien dans l'outil ne force leur présence, et les specs ne se mettent pas à jour toutes seules pendant l'implémentation. Sur un système peu documenté inline, le modèle peut halluciner le contexte qu'il ne modifie pas. Ran Isenberg a relevé, en février 2026, des cas où l'agent documentait correctement des classes existantes puis en régénérait des doublons⁸.

Quand choisir OpenSpec

Pour la modernisation de legacy, l'ajout de fonctionnalités dans un système existant, et les équipes qui veulent du spec-driven sans pipeline lourd. Spec Kit vise le greenfield structuré et Kiro l'IDE outillé. Quand le projet grossit, OpenSpec peut nourrir un cadre plus complet comme BMAD.

Ce que le SDLC SFEIR en retient

SFEIR retient la revue d'intention et le delta comme unité de travail. L'absence de gate formel demande en retour une discipline de preuve d'autant plus stricte. Ship et Ops restent à couvrir par ailleurs.

Sources

1. Fission AI, dépôt OpenSpec (README : licence, outils pris en charge, commandes, modèles recommandés, badges), GitHub, consulté le 19 septembre 2026. github.com
2. Fission AI, « Concepts » (philosophie « fluid not rigid », delta specs, brownfield-first), documentation du dépôt. github.com
3. Ry Walker, « OpenSpec », Ry Walker Research, 11 juin 2026. rywalker.com
4. CodeMySpec, « OpenSpec vs Spec Kit: Lightweight vs Full Toolkit (2026) », 3 juin 2026. codemyspec.com
5. CodeMySpec, « OpenSpec Explained (2026): Delta Tracking + Brownfield », 3 juin 2026. codemyspec.com
6. Y. Pyl, « OpenSpec vs GitHub Spec-Kit, a Hands-On Comparison for Spec-Driven Development », Work Notes, 3 juin 2026. ypyl.github.io
7. Hashrocket, « OpenSpec vs Spec Kit: Choosing the Right AI-Driven Development Workflow for Your Team » (origine de la mesure 250 lignes contre 800), 13 octobre 2025. hashrocket.com
8. Ran Isenberg, « I Tested Three Spec-Driven AI Tools. Here's My Honest Take. », ranthebuilder.cloud, évaluation de février 2026 publiée le 13 avril 2026. ranthebuilder.cloud