Les cycles de travail

4.1 Un chantier n'est pas un incrément

Il y a deux tailles de travail, et les confondre cause l'essentiel du désordre. Un incrément est un petit changement autonome. Un chantier est un effort plus large, avec sa propre intention, son périmètre et sa spec. On ouvre un chantier délibérément. On ne laisse pas un « petit changement rapide » devenir en silence une refonte de trois semaines sans avoir jamais écrit ce qu'on est en train de faire.

4.2 La spec d'intention, écrite avant la moindre ligne de code

Avant de construire, écrivez le document de conception : l'objectif, l'état actuel du code, les décisions déjà prises, le modèle de données (nouvelles tables et colonnes), les tranches, la liste des tests, et ce qui est explicitement reporté. C'est la source de vérité, et elle permet à n'importe qui (une autre session, ou une IA) de reprendre le fil. L'écrire n'est pas du temps perdu. C'est l'endroit le moins cher où se tromper.

4.3 La chaîne de livraison, dans l'ordre

Brainstormer, puis trancher les vrais arbitrages un par un, puis spécifier, puis ancrer (lire le code existant pour construire au bon endroit), puis prompter l'exécutant, puis construire, puis vérifier (build, type-check, relecture, test dans un vrai navigateur), puis commiter, pousser, déployer, puis tester la tranche. Sauter un maillon ne fait pas gagner de temps. Ça déplace le coût en aval, là où il est plus gros.

4.4 Classez le travail par réversibilité

La question de tri la plus utile qui soit : si ça tourne mal, combien coûte le retour en arrière ? Trois verdicts. Réversible à peu de frais, comme un ajustement visuel : allez vite, corrigez en avançant. Réversible avec effort, comme un changement de forme des données : vérifiez davantage, gardez un chemin de retour. Difficile à défaire, comme déplacer de l'argent, une migration destructrice, ou tout ce que les utilisateurs ne peuvent pas « dé-voir » : ralentissez, prouvez, testez pour de vrai. On n'applique pas la même prudence partout. On la dépense là où le retour arrière coûte cher.

4.5 Le débogage comme méthode, pas comme intuition

Quand quelque chose casse, ne tapotez pas au hasard. Travaillez par phases : reproduire de façon fiable, isoler l'endroit, formuler une hypothèse, tester cette hypothèse-là, corriger, puis prouver la correction avec le signal exact que le bug afficherait s'il revenait (Loi 4). Tapoter au hasard marche parfois et ne vous apprend rien. Une méthode marche et se capitalise.

4.6 Refactorer par vagues

Ne réécrivez pas tout d'un coup. Changez par petites vagues prouvables. Après un changement de masse, prouvez-le par un invariant (Loi 6), pas par une relecture. Et ne lancez jamais deux vagues en parallèle sur la même zone : elles modifient les mêmes gros fichiers et se marchent dessus.