Plus de cent écarts à une règle écrite
Le Pôle Technique s'était fixé une règle d'écriture interne : une certaine mention ne devait jamais figurer dans l'historique des modifications. La règle était écrite, claire, sans ambiguïté. Elle n'a vraiment été tenue que le jour où un contrôle automatique l'a fait respecter.
Une règle écrite repose sur l'attention de chacun, à chaque fois. Il suffit d'un oubli, et l'oubli se répète. Un contrôle automatique, lui, ne se fatigue pas : il vérifie à chaque fois et refuse ce qui ne passe pas. Depuis qu'il existe, la question ne se pose plus.
Les défauts qui ne font pas de bruit
Les pièges les plus coûteux ne font rien planter. Deux exemples.
Les mots collés. Le compilateur qui prépare les écrans rabote les espaces en fin de ligne. Dans le code, tout paraît juste ; à l'écran, deux mots se retrouvent collés. Le premier passage du contrôle en a relevé 260. Un contrôle les cherche désormais, et il vérifie au passage qu'il a bien lu des fichiers : un contrôle qui ne lit rien serait toujours vert.
L'écran sans navigation. Une page peut s'afficher sans son menu ni sa barre du haut, et fonctionner quand même. Le défaut est passé une fois, et c'est un utilisateur qui l'a signalé. Un écran qui perd sa navigation fait désormais échouer les contrôles.
Chercher une forme, jamais une liste
Aucune donnée client ne doit entrer dans le code. Le réflexe serait de tenir la liste des clients et de la chercher partout. Ce serait la pire des idées : une liste de clients dans le code serait la fuite elle-même.
Le contrôle cherche donc des formes, pas des noms. Il reconnaît ce qui ressemble à une donnée client sans jamais savoir qui sont les clients.
Un chiffre, un seul endroit
Un chiffre écrit à deux endroits finit toujours par diverger : l'un est mis à jour, l'autre est oublié. Un chiffre affiché est donc daté et recalculé, et l'on renvoie à sa source plutôt que de le recopier. Les chiffres du CRM présentés sur ce portail portent leur date et leur méthode.
Voir le test échouer
« Un contrôle qu'on n'a pas vu échouer n'est pas un contrôle. »
Après chaque correction, on casse volontairement le correctif pour vérifier que le test passe au rouge.
Un test peut passer pour une mauvaise raison : il vérifie la mauvaise chose, ou rien du tout. D'où un geste simple. On casse le correctif exprès, on regarde le test passer au rouge, puis on remet le correctif et le test repasse au vert. Seul un garde-fou qu'on a vu réagir protège vraiment quelque chose.
Avant chaque mise en ligne, cinq contrôles s'enchaînent. Lors de la dernière exécution complète mesurée, le 19 octobre 2026, la suite comptait 13 427 tests automatisés, répartis sur 489 fichiers. Une règle écrite dit ce qu'il faut faire. Un test vérifie qu'on le fait, à chaque fois, sans compter sur la mémoire de personne.