Compétence Développement Piloté par les Spécifications (SDD)

Guidez les utilisateurs à travers Spec-Kit de GitHub pour le Développement Piloté par les Spécifications - une méthodologie qui renverse le développement logiciel traditionnel en rendant les spécifications exécutables et en générant directement des implémentations fonctionnelles.

Philosophie Fondamentale

Le Développement Piloté par les Spécifications met l'accent sur :

Développement piloté par l'intention : Définir le "quoi" avant le "comment"
Création de spécifications riches : Utiliser des garde-fous et des principes d'organisation
Raffinement en plusieurs étapes : Pas de génération de code en un seul coup
Natif IA : Forte dépendance aux capacités avancées de l'IA

Souvenez-vous : C'est du développement natif IA. Les spécifications ne sont pas simplement de la documentation - ce sont des artefacts exécutables qui conduisent directement l'implémentation. L'agent IA les utilise pour générer du code fonctionnel correspondant à l'intention définie dans les spécifications.

Critères d'Acceptation : Format Gherkin (Requis)

Chaque histoire utilisateur dans chaque spec.md (ou specify.md) DOIT comporter des critères d'acceptation de style Gherkin, en plus de sa description en prose. Cela s'applique aussi bien aux projets greenfield que brownfield, pour chaque histoire utilisateur, que l'artefact ait été produit par /speckit.specify ou rédigé à la main pour un dépôt qui n'utilise pas le modèle généré par CLI. La prose décrit le sujet de l'histoire ; les scénarios Gherkin disent exactement comment la vérifier — c'est ce qui rend une spécification exécutable plutôt que descriptive.

Format — un bloc gherkin délimité directement sous chaque histoire utilisateur, 1 à 4 scénarios : le chemin heureux en premier, puis les cas limites/négatifs qui comptent pour cette histoire (pas tous les cas limites de la spécification — ceux-ci appartiennent à la section Cas Limites de la spécification ; seulement ceux spécifiques à cette histoire).

Scénario : <nom court et spécifique — pas "chemin heureux">
  Étant donné <la précondition / l'état de départ>
  Quand <l'action unique de l'acteur>
  Alors <le résultat observable et testable>
  Et <résultat supplémentaire, si nécessaire>

Scénario : <le cas limite/négatif pour cette histoire>
  Étant donné <précondition>
  Quand <action>
  Alors <résultat — ce qui ne devrait PAS se produire est un Alors valide>

Règles d'écriture :

Un Quand par scénario. Plusieurs actions signifient plusieurs scénarios — cela permet à chaque scénario de correspondre à un test.
Alors doit être observable, pas interne : "l'utilisateur voit un toast de confirmation", pas "l'état se met à jour correctement." Si vous ne pouvez pas dire comment quelqu'un le vérifierait, ce n'est pas prêt.
Réutilisez le vocabulaire de la spécification. Les étapes Étant donné/Quand/Alors doivent utiliser les mêmes noms que l'histoire utilisateur et les exigences fonctionnelles (noms d'actifs, types de transactions, noms de champs) — pas de paraphrase.
Ne reformulez pas les exigences fonctionnelles en Gherkin. Les critères d'acceptation vérifient l'histoire ; les EF sont tracées séparément. Un chevauchement est acceptable, mais la duplication de chaque EF en tant que scénario ne l'est pas.
Numérotez les scénarios pour la traçabilité lorsqu'une histoire en a plus d'un : Scénario : CA-1 — ..., Scénario : CA-2 — ... (facultatif pour les histoires à un seul scénario).

Lors du résumé (le modèle à 10 points, "Ce qui a été généré"), signalez le nombre de scénarios en plus des nombres d'histoires utilisateur/critères de succès, par exemple "5 histoires utilisateur (11 scénarios Gherkin), 8 critères de succès." Si une histoire utilisateur manque de critères d'acceptation, signalez-le sous "🔍 Éléments Importants à Réviser" avant de passer à /speckit.plan — les plans construits sur des histoires sans critères d'acceptation ont tendance à sous-spécifier les tests.

CA Comportementaux : uniquement pour les histoires avec IA dans la boucle

Gherkin suppose qu'une seule exécution décide du succès/échec. Cela ne fonctionne plus lorsque la sortie d'un modèle décide du résultat : une exécution réussie d'une histoire non déterministe ne prouve presque rien. Pour ces histoires, ajoutez un bloc CA Comportementaux sous le bloc Gherkin.

Générez-le uniquement lorsque le résultat observable de l'histoire dépend de la sortie d'un modèle. Exemples : un prompt, un prompt système, une mission, un fichier de compétence ou une description d'outil change ; un modèle choisit l'action, juge ou tranche quelque chose, ou rédige le texte destiné à l'utilisateur ; le modèle ou ses paramètres changent. Ne le générez pas pour du code déterministe, le rendu UI de données stockées, la tuyauterie, ou une histoire où un appel de modèle est présent mais sa sortie n'est pas vérifiée. En cas de doute, posez une question ; n'ajoutez pas le bloc de manière spéculative. Une spécification sans histoires avec IA dans la boucle n'a pas de CA Comportementaux du tout, et pas de placeholder vide non plus.

Format : un bloc par histoire qualifiée, directement après son Gherkin.

**CA Comportementaux** (IA dans la boucle : <ce que le modèle décide>)
- **Cas :** <N> cas dans `<chemin vers l'ensemble de cas>`, à partir de <échecs réels / traces / transcriptions> ; entrées synthétiques uniquement pour combler les lacunes, jamais de sorties attendues synthétiques
- **Exécutions :** k = <k> par cas (≈ 3 / taux d'échec attendu ; 20–30 si inconnu)
- **Seuil de réussite :** <métrique> ≥ <seuil> sur k, bat le baseline de plus que le bruit (comparaison par paires contre la version actuelle)
- **Correcteur :** vérification de code | juge LLM (binaire, un par mode d'échec) | humain ; un juge nomme également sa validation : TPR/TNR ≥ 0,9 (seuil 0,8) sur des étiquettes humaines retenues, ou "NON VALIDÉ" dit clairement
- **Commande :** `<une commande qui l'exécute et affiche le taux de réussite, le coût et la latence>`

Règles :

Seule une véritable exécution du modèle compte. Un mock, une simulation par mot-clé ou un score prédit n'est pas un résultat. Si elle ne peut pas être exécutée (coût, clés), dites que l'histoire est NON ÉVALUÉE. Ne falsifiez pas un nombre.
Préférez un correcteur de code. Utilisez un juge uniquement pour ce que le code ne peut pas vérifier.
Gherkin s'applique toujours. Les scénarios Gherkin couvrent la coque déterministe (artefacts écrits, gardes tenus). Les CA Comportementaux couvrent le comportement du modèle.
plan.md porte l'évaluation : l'emplacement de l'ensemble de cas, la commande d'exécution, le coût par exécution, et quand elle s'exécute (par PR, ou avant fusion uniquement si c'est coûteux).

Lors du résumé, comptez-les séparément, par exemple "5 histoires utilisateur (11 scénarios Gherkin, 2 avec CA Comportementaux)". Signalez sous "Éléments Importants à Réviser" toute histoire avec IA dans la boucle qui manque du bloc, et tout juge marqué NON VALIDÉ.

Arbre de Décision Rapide

S'agit-il d'un nouveau projet (greenfield) ?

→ Voir Workflow Greenfield pour le processus complet en 6 étapes

S'agit-il d'une base de code existante (brownfield) ?

→ Voir Workflow Brownfield pour des conseils de rétro-ingénierie et d'intégration

Besoin d'aide à l'installation ?

→ Voir Guide d'Installation pour la configuration et le dépannage

Démarrage Rapide de l'Installation

Recommandé (Persistant) :

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Utilisation Unique :

uvx --from git+https://github.com/github/spec-kit.git specify init <NOM_DU_PROJET>

Vérification :

specify check

Pour des options d'installation détaillées, le dépannage et les variables d'environnement, voir Guide d'Installation.

Agents IA Supportés

Fonctionne avec :

✅ Claude Code
✅ GitHub Copilot
✅ Gemini CLI
✅ Cursor
✅ Qwen Code
✅ opencode
✅ Windsurf
✅ Kilo Code
✅ Auggie CLI
✅ CodeBuddy CLI
✅ Roo Code
✅ Codex CLI
✅ Amp
⚠️ Amazon Q Developer CLI (ne supporte pas les arguments personnalisés pour les commandes slash)

Résumé d'Artefacts et Boucle de Rétroaction

WORKFLOW CRITIQUE : Après que toute commande SDD génère ou modifie des artefacts, suivez automatiquement cette boucle de rétroaction pour maintenir l'engagement de l'utilisateur :

Après Chaque Commande Terminée

Détecter les Changements d'Artefacts
- Identifiez quels artefacts ont été créés ou modifiés :
  - constitution.md (principes du projet)
  - spec.md (spécification des exigences)
  - plan.md (plan d'implémentation technique)
  - tasks.md (répartition des tâches actionnables)
  - Rapports d'analyse des workflows brownfield
Lire et Résumer
- Lisez le(s) artefact(s) concerné(s)
- Extrayez les informations clés :
  - Pour constitution.md : Principes fondamentaux, normes de codage, contraintes
  - Pour spec.md : Exigences principales, histoires utilisateur (avec leurs critères d'acceptation Gherkin), critères de succès
  - Pour plan.md : Choix de stack technique, décisions d'architecture, jalons
  - Pour tasks.md : Nombre de tâches, catégories de tâches principales, dépendances
  - Pour les rapports d'analyse : Patterns actuels, dette technique, points d'intégration
Présenter un Résumé Structuré (Utilisez le Modèle à 10 Points Ci-Dessous)
- Montrez ce qui a été généré et pourquoi
- Mettez en évidence les décisions les plus importantes avec leur justification
- Incluez des indicateurs de qualité et des points d'attention
- Gardez le résumé ciblé et actionnable
- Utilisez des titres clairs pour chaque section
Inclure l'État des Fonctionnalités (Approche Hybride)
- Ligne d'état brève dans chaque résumé
- État détaillé sur demande avec /speckit.status
- Voir la section "Suivi de l'État des Fonctionnalités" ci-dessous
Offrir des Options de Rétroaction
- Option A : "Ça a l'air bien, passer à l'étape suivante"
- Option B : "Je voudrais modifier [section spécifique]"
- Option C : "Régénérer avec ces modifications : [saisie utilisateur]"
- Option D : "Expliquer pourquoi [décision spécifique] a été prise"

Modèle de Résumé à 10 Points

Utilisez ce format structuré APRÈS toute commande SDD terminée :

## ✅ [Nom de la Commande] Terminée - Voici Ce Qui Vient de se Passer

### 🎯 Décisions Clés Prises (Top 3)
1. [Décision] - **Justification :** [Pourquoi cela a été choisi]
2. [Décision] - **Justification :** [Pourquoi cela a été choisi]
3. [Décision] - **Justification :** [Pourquoi cela a été choisi]

### 📋 Ce Qui a Été Généré
- [Artefact 1] : [Brève description du contenu]
- [Artefact 2] : [Brève description du contenu]

### 🔍 Éléments Importants à Réviser (Top 3)
1. [Élément critique à vérifier et pourquoi c'est important]
2. [Détail important à vérifier et impact potentiel]
3. [Cas limite à considérer et comment il affecte la conception]

### ⚠️ Attention (Top 2)
- [Problème potentiel ou piège] - **Comment l'éviter :** [Conseil]
- [Erreur courante] - **Comment l'éviter :** [Conseil]

### 🔄 Ce Que Cela Permet Ensuite (2 Options)
- **Option 1 :** [Prochaine étape] - Idéal si : [Condition]
- **Option 2 :** [Étape alternative] - Idéal si : [Condition]

📊 **État de la Fonctionnalité :** [Nom de la Fonctionnalité Actuelle] ([Étape]) → Suivante : [Prochaine Fonctionnalité]
   Progression : [●●●○○] [X]% | Terminées : [N] sur [Total] fonctionnalités | Dépendances : [Statut]

**Vos options :** [A] Continuer [B] Modifier [C] Expliquer plus [D] Afficher l'état complet

Exemple : Résumé Amélioré Après `/speckit.specify`

```

✅ Specify Terminée - Voici Ce Qui Vient de se Passer

🎯 Décisions Clés Prises

Authentification : jetons JWT - Justification : Architecture sans état, évolutivité horizontale, standard de l'industrie
Exigences de mot de passe : 12+ caractères avec complexité - Justification : Équilibre entre sécurité (recommandations NIST) et convivialité
Délai d'expiration de session : 24 heures - Justification : Standard pour les applications web, équilibre entre sécurité et commodité utilisateur

📋 Ce Qui a Été Généré

`.speckit/features/user-auth/specify.md` : Exigences complètes avec 5 histoires utilisateur (12 scénarios de critères d'acceptation Gherkin), 8 critères de succès, 3 cas limites

🔍 Éléments Importants à Réviser

Flux de réinitialisation de mot de passe - Vérifiez que les exigences de messagerie correspondent à votre infrastructure (serveur SMTP, modèles)
Authentification multifacteur - Actuellement marquée comme "amélioration future" ; peut être nécessaire pour le MVP
Limitation de débit - Fixée à 5 tentatives de connexion par 15 min ; vérifiez si cela correspond à votre politique de sécurité

⚠️ Attention

Dépendance au service de messagerie non spécifiée - Comment l'éviter : Ajoutez le service de messagerie aux dépendances de plan.md
Conformité RGPD pour les données utilisateur - Comment l'éviter : Révisez les exigences de conservation des données et de suppression des utilisateurs

🔄 Ce Que Cela Permet Ensuite

Option 1 : Exécuter `/speckit.plan` pour concevoir l'implémentation technique - Idéal si : Les exigences semblent bonnes
Option 2 : Modifier specify.md - Idéal si : Vous devez ajuster les exigences ou ajouter des fonctionnalités

📊 État de la Fonctionnalité : user-authentication (Spécifiée) → Suivante : profile-management Progression : [●●○○○] 40% | Terminées : 1 sur 5 fonctionnalités | Dépendances : database-setup ✅

Vos options : [A] Continuer vers la planification [B] Modifier les exigences [C] Expliquer le choix JWT [D] Afficher l'état complet ```

Quand Sauter le Résumé

Ne sautez l'étape de résumé que lorsque :

L'utilisateur demande explicitement "ignorer les résumés" ou "exécuter toutes les étapes automatiquement"
Réexécution d'une commande sans changement d'artefacts
La commande échoue ou produit des erreurs (dépanner à la place)

Avantages de Ce Workflow

Élimine le sentiment de "boîte noire" : Explications claires de ce qui a été généré et pourquoi
Permet une rétroaction précoce : Repérez les malentendus avant l'implémentation
Maintient l'agilité : Révision rapide avec un format structuré, pas de longs processus d'approbation
Instaure la confiance : L'utilisateur voit le raisonnement et les décisions de l'IA avec leur justification
Fournit du contexte : L'état des fonctionnalités maintient l'utilisateur orienté dans l'ensemble du projet

Suivi de l'État des Fonctionnalités

Approche Hybride

Après chaque commande SDD, incluez une ligne d'état brève de la fonctionnalité dans le résumé. Fournissez un état détaillé sur demande avec /speckit.status.

Format de Ligne d'État Brève

Incluez ceci à la fin de chaque résumé :

📊 **État de la Fonctionnalité :** [Nom de la Fonctionnalité Actuelle] ([Étape]) → Suivante : [Nom de la Prochaine Fonctionnalité]
   Progression : [●●●○○] [X]% | Terminées : [N] sur [Total] fonctionnalités | Dépendances : [Dep] ✅/⏸️

Valeurs d'étape :

Spécification (20% terminée)
Planification (40% terminée)
Tâches (60% terminée)
En Cours (80% terminée)
Terminée (100% terminée)

Indicateur de progression :

Utilisez des cercles pleins (●) pour les étapes terminées
Utilisez des cercles vides (○) pour les étapes en attente
Calculez le pourcentage en fonction de l'étape

Tableau de Bord d'État Détaillé

Lorsque l'utilisateur demande l'état complet (option D) ou exécute /speckit.status, affichez :

📊 Tableau de Bord de l'État des Fonctionnalités du Projet

🎯 FONCTIONNALITÉ ACTUELLE
├─ [nom-fonctionnalité] ([Étape] - [X]% terminée)
│  ├─ ✅ Exigences spécifiées
│  ├─ 🔄 Plan d'implémentation en cours
│  ├─ ⏸️  Tâches non démarrées
│  └─ ⏸️  Implémentation non démarrée
│  Bloqueurs : [Aucun | Description]
│  Dépendances : [nom-fonctionnalité] ✅

✅ FONCTIONNALITÉS TERMINÉES ([N])
├─ [fonctionnalité-1] (100% terminée)
└─ [fonctionnalité-2] (100% terminée)

📋 FONCTIONNALITÉS À VENIR ([N])
├─ [fonctionnalité-3] (dépend de : [fonctionnalité-actuelle])
└─ [fonctionnalité-4] (dépend de : [fonctionnalité-3])

⚠️  FONCTIONNALITÉS BLOQUÉES

...

GalRogozinski/sdd

Qu'est-ce que sdd ?

Demander à votre IA préférée

Documentation