Construire & corriger

La boucle construire-tester-corriger

Tu as envoyé ton mini-PRD, l'IA a généré la base de ton app. Commence maintenant la phase la plus longue — et la plus formatrice — du projet : la construction itérative. Le rythme est toujours le même : tu demandes une chose, l'IA la fait, tu testes immédiatement, et selon le résultat tu valides ou tu corriges. Puis tu recommences avec la chose suivante.

Ce rythme peut sembler lent comparé à la tentation de tout demander d'un coup. Il est en réalité beaucoup plus rapide sur la durée, pour une raison simple : quand un bug apparaît, tu sais exactement quelle demande l'a introduit — la dernière. Sans cette discipline, un bug peut venir de n'importe laquelle de tes cinq dernières demandes, et tu passeras plus de temps à chercher le coupable qu'à le corriger.

flowchart LR
  D["Demande UNE chose"] --> G["L'IA génère"]
  G --> T["Teste immédiatement"]
  T -->|"Ça marche"| V["Valide et passe à la suite"]
  T -->|"Ça casse"| E["Copie l'erreur exacte"]
  E --> C["Demande la correction"]
  C --> T
  V --> D

Tester chaque étape : ta checklist

Après chaque génération, ouvre l'app et essaie réellement la fonctionnalité. Ne te contente pas de regarder l'écran : utilise l'app comme le ferait un utilisateur. Pour la fonction « ajouter une habitude » de Tom, ça veut dire : taper un nom, cliquer sur le bouton, vérifier que l'habitude apparaît, en ajouter une deuxième, puis recharger la page pour vérifier que tout est encore là.

Prends aussi l'habitude de tester les cas limites — c'est là que se cachent les bugs : que se passe-t-il si tu ajoutes une habitude au nom vide ? Si tu en ajoutes vingt ? Si tu cliques deux fois très vite ? Tu n'as pas besoin d'être exhaustif, mais deux ou trois essais « hors des clous » par fonctionnalité révèlent les fragilités avant tes utilisateurs.

• Tester le cas normal : l'action principale fonctionne-t-elle ?
• Recharger la page : les données sont-elles toujours là ?
• Tester un cas limite : champ vide, valeur bizarre, double clic.
• Vérifier sur mobile (ou en rétrécissant la fenêtre) si ton app est mobile-first.

La console du navigateur : ton meilleur allié

Quand quelque chose casse sans explication visible, la réponse se trouve presque toujours dans la console du navigateur. Appuie sur F12 (ou clic droit → « Inspecter »), puis ouvre l'onglet « Console ». C'est là que le navigateur écrit les erreurs : des lignes rouges, souvent en anglais, qui indiquent ce qui a échoué et où.

Tu n'as pas besoin de comprendre ces messages — tu as juste besoin de les copier. Voici à quoi ressemble une erreur typique :

Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
    at app.js:24:18

Traduction libre : « à la ligne 24 du fichier app.js, le code essaie d'utiliser quelque chose qui n'existe pas ». C'est exactement le genre d'indice dont l'IA a besoin pour corriger en un message au lieu de cinq. Erreurs fréquentes que tu croiseras : TypeError (le code manipule une valeur du mauvais type), ReferenceError (il utilise un nom qui n'existe pas), SyntaxError (le code lui-même est mal formé), et 404 Not Found (un fichier est introuvable).

Le prompt de débogage parfait

Quand ça casse, ne dis pas « ça marche pas ». L'IA n'a aucun moyen de deviner ce que tu vois à l'écran. Un bon rapport de bug contient quatre éléments : ce que tu faisais, ce que tu attendais, ce qui s'est passé à la place, et le message d'erreur exact de la console. Avec ces quatre informations, le diagnostic est presque toujours immédiat.

Bug à corriger.
Ce que je faisais : je clique sur « ajouter une habitude » après avoir tapé « Lecture » dans le champ.
Ce que j'attendais : l'habitude apparaît dans la liste.
Ce qui se passe : rien ne s'affiche, le champ se vide.
Erreur dans la console : Uncaught TypeError: Cannot read properties of null (reading 'addEventListener') at app.js:24:18
Diagnostique la cause et corrige, en m'expliquant simplement ce qui n'allait pas.

Remarque la dernière phrase : « en m'expliquant simplement ce qui n'allait pas ». C'est elle qui transforme chaque bug en leçon. Au bout de dix corrections, tu reconnaîtras toi-même les erreurs courantes — et tu écriras des demandes qui les évitent d'emblée.

Quand l’IA tourne en rond

Cela arrive : tu signales un bug, l'IA « corrige », le bug est toujours là, elle « corrige » encore, et rien ne change — ou pire, autre chose casse. Au bout de deux ou trois tentatives infructueuses, arrête d'insister sur la même voie. Trois stratégies efficaces : demande à l'IA de repartir de zéro sur cette fonctionnalité (« supprime tout le code du calendrier et refais-le plus simplement »), demande-lui d'ajouter des messages de diagnostic (« ajoute des console.log pour qu'on voie où ça bloque »), ou reformule complètement ta demande initiale, qui était peut-être ambiguë.

Garde aussi en tête l'option nucléaire : revenir à la dernière version qui marchait et reprendre depuis là. C'est exactement à ça que sert Git, dont on parle tout de suite — un filet de sécurité qui rend les expérimentations sans risque.

Sauvegarder avec Git : ton filet de sécurité

Git est l'outil que tous les développeurs utilisent pour sauvegarder l'historique d'un projet. L'idée tient en une image : à chaque étape qui marche, tu prends une « photo » (un commit) de ton projet. Si une expérimentation tourne mal, tu reviens à la dernière photo en un instant. Plus besoin d'avoir peur de casser : tout est réversible.

Si tu es sur un outil navigateur (Lovable, v0, Bolt), bonne nouvelle : la plupart gèrent l'historique des versions pour toi — cherche un menu « History » ou « Versions » et repère comment restaurer un état précédent. Si tu es sur Cursor ou Claude Code, demande simplement à l'IA de faire les commits pour toi, ou apprends les trois commandes essentielles :

# À chaque étape qui marche, prends une photo du projet :
git add .
git commit -m "Ajout d'habitude fonctionne"

# Pour voir l'historique de tes photos :
git log --oneline

Le bon rythme : un commit après chaque fonctionnalité testée et validée. Le message du commit décrit ce qui marche (« cochage quotidien OK », « calendrier affiché »). Tom prend cette habitude dès la première soirée — et le jour où une expérimentation de design casse toute sa mise en page, il revient en arrière en trente secondes au lieu de tout reconstruire.

Avancer par petits pas sûrs

Une fonctionnalité testée et qui marche = un point d'appui solide. Tu construis sur du stable, pas sur du sable. C'est ce qui évite l'effet « tout est cassé et je ne sais pas pourquoi » qui décourage tant de débutants. La séquence complète de Tom pour chaque fonctionnalité : demander → tester → corriger si besoin → committer → passer à la suivante.

Cette méthode a un effet secondaire précieux : la confiance. Chaque petit pas validé est une victoire concrète, et la motivation se nourrit de victoires. À la fin du chapitre, l'app de Tom fait tout ce que prévoyait sa v1 — ajout, suppression, cochage quotidien, streak — et chaque brique a été vérifiée. Il est prêt pour la mise en ligne.