5. Milestones, tests et versions

Travailler étape par étape, définir des tests simples et mettre en place un retour arrière concret.

Avancé Étape 5 sur 9

Le cycle d'une étape

Une étape (ou "milestone"), c'est un morceau de projet avec un début et une fin clairs. On ne traite qu'une étape à la fois. Le cycle :

  Comprendre        Documenter         Implémenter        Tester
     │                  │                  │                  │
     ▼                  ▼                  ▼                  ▼
  ┌──────┐         ┌──────┐         ┌──────┐         ┌──────┐
  │ Lire  │───────▶│Écrire│────────▶│ Faire│────────▶│Vérif.│
  │le bes.|        │le plan|        │ le tra│         │ le rés│
  └──────┘         └──────┘         └──────┘         └──────┘
                                                          │
                    ┌──────┐         ┌──────┐               │
                    │Maj doc|◀──────▶│Point  |◀──────────────┘
                    │+ Git  │        │retour |
                    └──────┘         └──────┘

  Corriger (si le test échoue) ← ──────┘

Chaque étape passe par ce cycle. On ne saute pas d'étape. On ne fait pas deux étapes en même temps.

Pourquoi traiter les étapes une par une

  • Limiter les changements simultanés — si tout casse, tu sais d'où ça vient
  • Identifier l'origine d'une erreur — l'erreur vient de l'étape en cours, pas d'avant
  • Éviter de construire sur une base instable — chaque étape validée est solide
  • Garder un historique vérifiable — chaque étape a son point de retour

Les tests : ce que ça veut dire

Un test, ce n'est pas un truc de programmeur. C'est juste "vérifier que le résultat de l'étape fonctionne sur les cas prévus".

Jean-Paul : tester une macro

  1. Prend 10 lignes représentatives de ton tableau
  2. Calcule le résultat attendu à la main pour 3 d'entre elles
  3. Lance la macro
  4. Compare : est-ce que le résultat correspond à ce que tu attendais ?
  5. Teste un cas vide (ligne sans donnée) et un cas inhabituel (montant négatif, date manquante)

Kevin : tester une fonction

  1. Lance la fonction avec une entrée normale → résultat attendu ?
  2. Lance avec une entrée vide → gestion correcte ?
  3. Lance avec une valeur incorrecte → pas de crash ?
  4. Vérifie que les fonctions précédentes marchent toujours (non-régression)
Le test n'a pas besoin d'être automatisé pour être utile. Un test manuel sur 10 lignes vaut mieux que pas de test du tout. L'automatisation viendra plus tard.

Git vulgarisé (pour les non-dev)

Si tu fais du code, Git est le standard pour le retour arrière. Si tu ne fais pas de code, tu peux sauter cette section et garder tes copies datées.

Terme Git En clair
Commit Une photo de l'état actuel du projet. Tu en fais une avant chaque modification importante.
Branch Une copie parallèle pour tester quelque chose sans risquer de casser la version principale.
Revert Revenir à une photo précédente. "Annule tout, reviens à la version d'avant."
Diff Voir ce qui a changé entre deux versions. "Montre-moi ce que l'IA a modifié."
Pour Jean-Paul : Git c'est pour les codeurs. Toi, ta version de Git c'est une copie datée du fichier. "factures_2026-01-15.xlsx" avant la modification, "factures_2026-01-15-apres.xlsx" après. Simple, efficace.

Le template d'étape

Pour chaque étape, écris ces infos avant de commencer. Ça prend 2 minutes et ça t'évite de partir dans la mauvaise direction :

## Étape : [nom court de l'étape]

Contexte : [pourquoi cette étape est nécessaire]
Objectif : [ce que cette étape doit accomplir]
Périmètre : [ce qui est dans l'étape]
Hors périmètre : [ce qui n'y est pas]
Fichiers concernés : [quels fichiers seront modifiés]
Tests : [comment vérifier que l'étape est terminée]
Critères d'acceptation : [ce qui doit être vrai pour valider]
Retour arrière : [comment revenir en arrière si ça casse]

Tu peux demander à l'IA de remplir ce template pour toi :

Je veux faire cette étape : [décris l'objectif].
Remplis ce template pour moi :
- Contexte
- Objectif
- Périmètre
- Hors périmètre
- Fichiers concernés
- Tests à réaliser
- Critères d'acceptation
- Comment revenir en arrière si ça casse
Pose-moi des questions si tu as besoin de plus d'info.

Planifier sans figer

Tu peux écrire une feuille de route avec plusieurs étapes, mais ne détaille que les 2-3 prochaines. Les étapes lointaines seront plus claires quand tu seras plus près. C'est normal de réajuster en cours de route.

Règle : détaille fortement les 2 prochaines étapes. Écris le nom et l'objectif des suivantes. Réévalue après chaque étape validée.

Exemple Jean-Paul : le processus de factures

Jean-Paul a cadré son projet (page 4) : extraire le montant et le fournisseur de 50 factures PDF par mois dans un tableau Excel. Il découpe en étapes :

  1. Étape 1 : importer un PDF dans Excel et extraire le texte (test : 1 PDF, vérifier le texte extrait) → copie du fichier avant
  2. Étape 2 : identifier le montant et le fournisseur dans le texte (test : 3 PDF différents, comparer avec les montants connus) → copie avant
  3. Étape 3 : générer le tableau récapitulatif (test : 10 PDF, comparer avec un mois précédent) → copie avant
  4. Étape 4 : ajouter le statut de validation manuel (test : valider 3 lignes, vérifier le statut) → copie avant

Exemple Kevin : le portfolio

Kevin découpe son portfolio :

  1. Étape 1 : structure HTML de la page d'accueil (test : la page s'affiche) → Git commit
  2. Étape 2 : style CSS responsive (test : s'affiche sur mobile) → Git commit
  3. Étape 3 : page projets (test : 3 projets affichés) → Git commit
  4. Étape 4 : page contact avec formulaire (test : le formulaire envoie) → Git commit

Mon expérience sandbox

La sandbox — les milestones : Quand j'ai découvert les milestones, j'ai arrêté de tout demander d'un coup à l'IA. Chaque milestone avait un objectif, des tests et un point de retour. Mon projet ne cassait plus parce que je construisais sur du stable. Si une milestone échouait, je revenais au commit d'avant et je repartais. C'est devenu mon mode de travail par défaut.
C'est déjà un excellent niveau. Les pages suivantes demandent d'installer des outils ou de travailler avec des agents. C'est optionnel. Si tu utilises ChatGPT sur le web avec cette méthode (cadrer, découper, tester, retour arrière), tu fais déjà mieux que 90% des utilisateurs d'IA.
← Étape 4 : cadrer un projet Étape 6 : agir sur les fichiers →