Playbook Dev × IA
Sommaire
03Chapitre 3·60 min·Intermédiaire

Méthodologie

Spec-Driven & Explore → Plan → Code → Verify

Le cœur opérationnel : Spec-Driven Development + le cycle Explore → Plan → Code → Verify d'Anthropic.

Ce que vous saurez faire
  • 01Pratiquer le Spec-Driven Development (spec → plan → tasks → code)
  • 02Appliquer le cycle Explore → Plan → Code → Verify
  • 03Refuser tout code avant validation explicite du plan
  • 04Donner à l'IA un moyen de vérifier son propre travail

1. Pourquoi une méthodologie ?

Sans méthode, utiliser l'IA pour coder ressemble à ça :

Sans méthode
  1. Prompt vague
  2. Code généré
  3. Ça ne marche pas
  4. Nouveau prompt
  5. Code différent
  6. Ça marche en apparence
  7. On merge
  8. 3 semaines plus tard : bug en prod

Avec une méthode, ça ressemble à ça :

Avec méthode
  1. Spec validée
  2. Exploration de l'existant
  3. Plan approuvé
  4. Implémentation atomique
  5. Vérification automatique
  6. Revue humaine
  7. Merge confiant

La différence : tu ne codes jamais sur des ambiguïtés.

2. Le cycle Explore → Plan → Code → Verify

Ce cycle est issu des meilleures pratiques documentées par Anthropic pour Claude Code, adapté à n'importe quel outil IA.

Phase 1 : EXPLORE (Plan Mode)

Objectif : comprendre l'existant avant de toucher quoi que ce soit.

Règle absolue : en mode Explore, l'IA lit uniquement, n'écrit pas.

Prompt
[MODE ANALYSE — PAS DE CODE] Explore le répertoire src/auth/. Comprends comment les sessions sont gérées et comment le login fonctionne. Identifie également la gestion des variables d'environnement pour les secrets. Livre un rapport avec : 1. Fichiers clés et leur rôle 2. Dépendances entre composants 3. Points d'entrée et de sortie 4. Risques si on modifie l'auth flow

Quand utiliser Explore :

  • Tu modifies du code que tu ne connais pas bien
  • La modification touche plusieurs fichiers
  • Le risque de régression est élevé

Quand skipper Explore :

  • Fix d'une typo
  • Ajout d'un log
  • Renommage d'une variable

Phase 2 : PLAN

Objectif : obtenir un plan d'implémentation détaillé, validé par un humain, avant d'écrire une seule ligne.

Prompt
Je veux ajouter l'authentification Google OAuth. Sur la base de ton analyse précédente : 1. Quels fichiers doivent changer ? 2. Quel est le flow session OAuth complet ? 3. Quels sont les edge cases (token expiré, compte existant, etc.) ? Génère un plan d'implémentation détaillé en étapes numérotées. Format : Étape | Fichier(s) concerné(s) | Action | Critère de validation Ne génère pas de code encore.

La validation humaine est obligatoire ici. Tu ouvres le plan, tu le lis, tu valides ou tu corriges. Utilise Ctrl+G dans Claude Code pour éditer le plan directement.

Questions à te poser avant de valider :

  • Le choix des librairies est-il cohérent avec notre stack ?
  • L'approche architecturale respecte-t-elle nos patterns existants ?
  • Y a-t-il des étapes qui semblent trop grosses (à découper) ?
  • Tous les edge cases sont-ils couverts ?

Phase 3 : CODE

Objectif : implémentation atomique, étape par étape, en suivant le plan validé.

Prompt
Implémente maintenant l'étape 1 du plan : [description étape]. Vérifie ta progression contre le plan. Une fois cette étape terminée, arrête-toi et attends ma validation.

Règles d'implémentation :

  • Une étape du plan = une demande
  • Ne demande jamais "implémente tout le plan" en une fois
  • Valide chaque bloc avant de passer au suivant
  • Si l'IA s'écarte du plan, stoppe et redirige

Phase 4 : VERIFY

Objectif : fournir à l'IA les moyens de vérifier son propre travail. C'est la différence entre du code "qui a l'air bien" et du code qui fonctionne.

Prompt
L'implémentation est terminée. Maintenant, agis en QA Engineer. 1. Lance les tests unitaires : npm run test -- --testPathPattern=auth 2. Lance le linter : npm run lint src/auth/ 3. Génère des tests pour les edge cases non couverts : - Token OAuth expiré - Email déjà associé à un compte local - Provider indisponible (timeout) 4. Prends un screenshot du flow si c'est une feature UI [optionnel] Rapport final : Tests passés | Avertissements | Échecs

La vérification sans les outils ne vaut rien. Donne à l'IA accès aux commandes de test, au linter, au build. C'est là que la qualité se construit.

3. Spec-Driven Development (SDD)

Le SDD est complémentaire au cycle EPCV. Il s'applique en amont, pour les nouvelles features et projets.

Principe

Les specifications sont la source de vérité. Tout le reste est généré depuis elles.

Structure de fichiers SDD

/specs
  ├── feature-auth-oauth.md    → Requirements + User Stories
  ├── plan.md                  → Étapes d'implémentation
  ├── tasks.md                 → Tâches atomiques avec statuts
  └── outcome.md               → Résultats, décisions prises, leçons

Ces fichiers vivent dans le repo Git, versionnés comme du code.

Étape 1 : Générer la spec avec l'IA Interview

Prompt
Je veux construire [description de la feature]. Interviewe-moi en détail en utilisant l'outil AskUserQuestion. Pose des questions sur : - L'implémentation technique (stack, patterns, contraintes) - L'UX/UI si pertinent - Les edge cases - Les tradeoffs entre approches - Les risques Ne pose pas de questions triviales. Creuse les parties difficiles. Continue jusqu'à avoir tout ce qu'il faut. Puis génère une spec complète dans specs/feature-[nom].md.

Structure d'une spec.md

# Feature : [Nom]
**Date** : [date]  
**Auteur** : [nom]  
**Status** : Draft / Validated / Implemented

## Résumé
[2-3 phrases : quoi, pourquoi, pour qui]

## Requirements
### Must Have
- [ ] [Requirement 1]
- [ ] [Requirement 2]

### Should Have
- [ ] [Requirement 3]

### Won't Have (this version)
- [Exclusion explicite]

## Architecture
[Description de l'approche technique choisie]

## Entités & Modèles
[Structures de données, schémas DB]

## API / Interface
[Endpoints, signatures de méthodes, contrats]

## Edge Cases & Gestion d'erreurs
[Liste des cas limites et comportements attendus]

## Critères d'acceptance
- [ ] Test 1 : [comportement attendu]
- [ ] Test 2 : ...

## Décisions techniques
[Pourquoi cette approche vs alternatives considérées]

Étape 2 : Générer le plan depuis la spec

Prompt
Voici la spec validée : @specs/feature-auth-oauth.md Génère maintenant un plan d'implémentation dans specs/plan.md. Format : - Étapes numérotées et séquentielles - Chaque étape : description + fichiers concernés + estimation - Dépendances entre étapes (ce qui doit être fait avant) - Critère de validation de chaque étape

Étape 3 : Décomposer en tâches atomiques

Prompt
Sur la base du plan @specs/plan.md, génère specs/tasks.md. Format pour chaque tâche : - [ ] [ID] [Description courte] | Dépendances: [IDs] | Validation: [commande/critère] Règle : chaque tâche doit être faisable en < 30 minutes. Si une tâche est plus grande, décompose-la.

Étape 4 : Implémenter tâche par tâche

Prompt
Implémente la tâche T-03 de @specs/tasks.md. Contexte : @specs/feature-auth-oauth.md Plan global : @specs/plan.md Une fois T-03 terminée : 1. Marque-la comme [x] dans tasks.md 2. Exécute le critère de validation 3. Arrête-toi et rapporte

4. Cas pratique complet : Ajout d'un soft delete

Voici l'application du cycle EPCV sur un cas concret — migrer un delete physique en soft delete.

Explore

Prompt
[ANALYSE UNIQUEMENT] Analyse UserRepository.ts. Identifie : - La méthode deleteUser actuelle (signature, SQL) - Toutes les requêtes SELECT qui devront être modifiées - La contrainte UNIQUE sur email et ses implications - Les tests existants qui couvrent deleteUser

Plan

Prompt
Sur la base de l'analyse : Propose le plan de migration vers le soft delete. Inclus : 1. Le SQL exact du nouveau delete (UPDATE + suffixage email pour UNIQUE) 2. Les SELECT à modifier (ajout WHERE deleted_at IS NULL) 3. Les tests à mettre à jour Format : plan en markdown, pas de code d'implémentation encore. Attends ma validation.

Code (après validation du plan)

Prompt
Implémente maintenant la méthode deleteUser selon le plan validé. Stack : TypeORM + PostgreSQL. Gère : - Le suffixage email : email + '_deleted_' + timestamp - La transaction si plusieurs tables sont touchées - La gestion d'erreur (user inexistant) Arrête après cette méthode uniquement.

Verify

Prompt
Agis en QA Engineer. Génère un test d'intégration (Jest + testcontainers PostgreSQL) pour deleteUser. Scénarios : 1. Delete d'un user existant → deleted_at renseigné, email suffixé 2. findByEmail après delete → retourne null 3. Réinscription avec le même email → fonctionne (contrainte UNIQUE respectée) 4. Delete d'un user inexistant → erreur appropriée

5. Les règles d'or de la méthodologie

Règle 1 : Pas de code sans plan validé par un humain.

Règle 2 : Une tâche = une session. Ne mélange jamais deux features dans la même conversation.

Règle 3 : Donne toujours à l'IA un moyen de vérifier son travail (tests, linter, commande de build).

Règle 4 : Si tu as dû corriger l'IA plus de 2 fois sur la même chose → /clear + nouveau prompt enrichi.

Règle 5 : Les specs vivent dans le repo. Ce qui n'est pas versionné n'existe pas.