OpenSpec

Un cadre spec-driven pour le code déjà en production

OpenSpec est un cadre de spec-driven development édité par Fission AI sous licence MIT. Le dépôt GitHub a été créé en août 2025 et affichait, à la mi-2026, environ 68 000 étoiles (badge officiel openspec.dev) et de l'ordre de 4 500 à 4 700 forks, après une version 1.0 stable issue d'une refonte orientée actions. Il cible les équipes qui modifient un système déjà en production (le brownfield) et qui veulent de la prévisibilité sans cérémonie.

En septembre 2026, OpenSpec supporte plus de trente outils de codage, dont Claude Code, Cursor, Kiro, Codex, Amazon Q et Copilot, sans dépendance MCP ni clé d'API. Sa documentation recommande les modèles à fort raisonnement et cite Codex 5.5 et Opus 4.7.

Le cycle propose, apply, archive

« npm install -g @fission-ai/openspec@latest » puis « openspec init » posent le guidage projet une fois. Les commandes de travail se tapent ensuite dans le chat de l'assistant. « /opsx:explore » sert de partenaire de réflexion sans engagement : l'agent lit le code et esquisse une piste. « /opsx:propose », la commande canonique, fait rédiger par l'IA une proposition (proposal.md, specs/, design.md, tasks.md) que l'humain relit. « /opsx:apply » implémente les tâches, et « /opsx:archive » fusionne les deltas dans la spec source de vérité, après vérification humaine. Un profil étendu ajoute six commandes, dont « /opsx:verify » et « /opsx:bulk-archive », et les refactors purs peuvent déclarer « skip_specs: true » pour aller droit à la validation puis à l'archivage.

Le delta comme unité de travail

Chaque changement décrit seulement ce qu'il ajoute, modifie ou retire (ADDED, MODIFIED, REMOVED) par rapport à une spec de référence. Deux changements en cours peuvent donc toucher le même spec.md sans conflit tant qu'ils visent des exigences différentes, et la revue porte sur l'intention : on lit le delta, pas le diff brut. Ces marqueurs existent pour qu'un agent travaillant dans un code mûr n'hallucine pas de nouvelles exigences sur le comportement existant. La documentation résume la philosophie par « fluid not rigid » : aucune gate de phase, l'humain corrige n'importe quel artefact au fil de la conversation.

Limites et place dans le SDLC augmenté par l'IA

Sa sortie reste légère : Hashrocket situe, en octobre 2025, un changement OpenSpec autour de 250 lignes contre environ 800 pour un toolkit plus lourd. La limite documentée principale tient à la dérive des specs : les scénarios Given/When/Then sont optionnels, et les specs ne se mettent pas à jour toutes seules pendant l'implémentation. Sur un système peu documenté, le modèle peut halluciner le contexte non modifié ; Ran Isenberg a relevé en février 2026 des cas où l'agent documentait des classes existantes puis en régénérait des doublons.

Dans la grille du SDLC augmenté par l'IA, Init correspond à Setup, Explore amorce Define, Propose couvre Define et Plan, Apply couvre Build et Verify, et Archive nourrit Review puis Compound-1. Ship, Ops et Deprecation restent hors champ, et la capitalisation vit hors cycle, dans une spec système qui grossit avec le code. SFEIR retient la revue d'intention et le delta comme unité, avec une réserve : sans gate formel, la discipline de preuve doit être d'autant plus stricte. Analyse détaillée dans l'article OpenSpec, le spec-driven taillé pour le code que vous avez déjà et le comparatif des neuf méthodes.

• Modernisation de legacy et ajout de fonctionnalités dans un système existant.
• Équipes qui veulent du spec-driven sans pipeline lourd.
• Se combine avec Spec Kit pour le greenfield structuré, Kiro pour l'IDE outillé, et peut nourrir BMAD quand le projet grossit.