Les lois du build

Ce sont les principes qui survivent même si l'on retire de l'histoire tout projet particulier. Ils sont la colonne vertébrale de tout ce qui suit. Chacun a été appris à la dure.

Loi 1. Une règle s'écrit avec son incident

Une règle sans histoire se fait contourner. Une règle qui porte la date, le coût et l'échec qui l'a créée, non, parce que le lecteur voit exactement ce qu'il achète en l'ignorant.

Alors quand vous écrivez une règle, écrivez l'échec à côté. Et le test : si vous ne trouvez aucun échec derrière votre règle, c'est probablement une préférence, pas une règle. Les préférences, c'est très bien. Ne les défendez simplement pas comme des lois.

Loi 2. Une exception se documente comme une règle

Le réflexe normal est de tolérer une exception en silence, ce qui est exactement la façon dont les exceptions se multiplient. Faites l'inverse. Une exception s'écrit avec quatre choses : la règle générale, redite et explicitement protégée ; les critères cumulatifs qui autorisent l'exception ; la liste nommée de tous les cas qui l'utilisent aujourd'hui ; et la condition de retour à la règle générale.

« Si un seul critère tombe, ceci repasse sous la règle générale. » Cette ligne-là empêche une exception de devenir discrètement la nouvelle norme.

Loi 3. Une décision rejetée vaut autant qu'une décision retenue

Gardez une « alternative rejetée » à côté de chaque vraie décision. C'est ce qui empêche quelqu'un, six mois plus tard, de reproposer une option que vous aviez déjà écartée, avec les mêmes arguments, parce qu'il n'était pas dans la pièce la première fois.

Corollaire : un plan obsolète ne se supprime pas. Il se barre et se date, avec un renvoi vers la décision vivante. Le supprimer signifie simplement que vous le reconstruirez de zéro et redécouvrirez pourquoi il était mauvais.

Loi 4. Une vérification que vous n'avez pas lancée est pire que rien

C'est l'anti-pattern le plus coûteux qui soit. Imaginez une note qui dit « vérifié : renvoie le bon résultat », présentée comme une preuve, alors que la vérification n'a jamais été exécutée. Non seulement elle ne vous protège pas, mais elle clôt le sujet, et donc plus personne ne regarde. Sur un projet, une « vérification » écrite mais jamais lancée a laissé un lot de fichiers internes exposés en public pendant des mois.

Donc la forme correcte d'un correctif n'est jamais « vérifier que ça marche ». C'est la commande exacte à lancer, et le critère de régression : le signal précis qui vous dirait que le bug est revenu.

Loi 5. Un feu vert ne vaut rien tant que vous ne l'avez pas vu passer au rouge

Avant de faire confiance à un contrôle automatique sur un terrain neuf, faites-le échouer exprès. S'il ne passe pas au rouge quand vous cassez la chose, il ne vous protégera jamais, il vous rassurera seulement.

Un contrôle automatique a de nombreuses façons de mentir en silence : il n'analyse pas la zone qui vous intéresse ; il ne voit que les fichiers déjà enregistrés dans le versionnage, et déclare donc « tout va bien » sur du code tout neuf ; son motif de recherche rate la vraie forme du code ; la cible se trouve hors de son périmètre ; l'exécuteur compte « rien à faire » comme un succès. Exemple réel du dernier piège : une suite de tests existait, plus de cent assertions, et elle était branchée pour ne tourner nulle part. Elle passait en ne s'exécutant jamais.

La discipline : calibrez chaque verrou sur un cas connu-bon et un cas connu-mauvais, figés en tests. Sans ça, rien ne distingue « fonctionne » de « inerte ». Et n'oubliez pas le versant humain : un verrou qui crie au loup finit désactivé.

Loi 6. Un changement de masse se prouve par un invariant, jamais par une relecture

Quand vous changez mille choses d'un coup, vous ne pouvez pas vérifier à l'œil. Vous le prouvez par un invariant, un fait qui doit tenir. Trois qui fonctionnent en pratique.

L'égalité d'ensembles : après avoir remplacé quelque chose sur N pages, vérifiez que le nombre de pages portant la nouvelle version égale le nombre qui portait l'ancienne, et qu'il ne reste aucune ancienne. Une montée de version à moitié faite désynchronise tout tout en ayant l'air normale.

L'empreinte des lignes qui ne doivent pas bouger : avant et après une grosse migration, prouvez que les lignes précises auxquelles vous ne deviez pas toucher sont identiques octet pour octet. Vous n'évitez pas seulement d'y toucher, vous prouvez que vous n'y avez pas touché.

Le delta chiffré en production : pas « le test est vert », mais « ces nombres précis sont passés de X à Y sur les vraies données, et zéro élément s'est retrouvé mal classé ». Un delta vaut mieux qu'une coche verte.

Loi 7. Le nom ment, la preuve est l'usage

Les noms dérivent de leur sens. Sur une app, un objet appelé « Société » désignait en réalité un groupe parent, pas un site unique. Une relation construite sur la ressemblance des noms, plutôt que sur la réalité des données, rejetait près de huit lignes sur dix. Les noms étaient d'accord. Les données, non.

L'extension la plus difficile et la plus utile : cela vaut aussi pour vos propres documents. Un document que vous avez écrit vous-même n'est pas une source de vérité, c'est une hypothèse datée. Confrontez-le au réel avant de lui faire confiance. Deux corollaires : le code désactivé est souvent plus riche que le code vivant (il dit ce qui a été tenté), et un composant nommé dans un commentaire est un composant qui mérite d'être ouvert.

Loi 8. Ce qui n'est pas branché sur un contrôle mécanique n'existe pas

Et son jumeau : ce qui n'est pas écrit dans un fichier n'existe pas. Une conversation n'est pas un système de mémoire.

La preuve est banale et universelle : sur cinq points soulevés à l'oral pendant une revue, quatre ont été écrits quelque part, un non. Celui qui s'est évaporé était une mention légale affichée aux utilisateurs au moment exact de leur consentement, et elle était devenue fausse en silence. Les accords verbaux s'évaporent. Si ça compte, ça vit dans un fichier ou dans un contrôle automatique, ou ça n'existe pas vraiment.

Loi 9. Le vrai correctif, c'est de supprimer l'espace partagé

Quand deux personnes (ou deux sessions d'IA) travaillant en parallèle se percutent sans arrêt sur la même ressource partagée, l'instinct est d'ajouter un meilleur contrôle. Souvent, le meilleur geste est de supprimer entièrement la chose partagée.

Le cas classique : des travaux en parallèle attrapaient chacun « le numéro suivant » pour un changement, sans se voir, et se percutaient encore et encore. Aucune vérification préalable ne pouvait marcher, parce que regarder « le dernier numéro utilisé » revient à regarder un monde où le changement voisin n'existe pas encore. Le correctif n'était pas un contrôle plus malin. C'était de passer à un horodatage, pour qu'il n'y ait plus de compteur partagé à consulter. Deux horodatages n'entrent pas en collision. Quand un verrou n'arrive pas à tenir une ressource partagée, demandez-vous si cette ressource doit être partagée du tout.

Loi 10. La mémoire a un budget, et elle tend vers le vide

La mémoire de votre projet (le fichier qui conserve le contexte dont une IA ou un coéquipier a besoin) a un budget. Au-delà, on n'ajoute plus, on distille. Un bon fichier de mémoire est conçu pour rétrécir avec le temps, pas pour grossir : chaque entrée est distillée ou supprimée quand son chapitre se referme.

La version plus profonde : une leçon écrite six fois, à chaque fois comme si elle était neuve, ce n'est pas six leçons. C'est une loi qui n'a jamais eu de maison. Quand vous vous surprenez à réapprendre la même chose, n'ajoutez pas une septième note. Donnez une maison à la loi, et chaque occurrence future n'aura plus qu'à pointer dessus.