Une règle écrite n'arrête rien.
Chaque règle importante du CRM est doublée d'un test qui échoue le jour où elle n'est plus respectée.
Dix règles qui se défendent seules
Pour chacune, un test échoue le jour où elle n'est plus respectée. Ce qu'il empêche tient en une ou deux phrases.
Pas d'écran sans droit d'accès
Un écran oublié dans le registre des droits fait échouer les contrôles avant la mise en ligne.
Chaque écran garde sa navigation
Un écran qui s'afficherait sans son menu fait échouer les contrôles. Le défaut est passé une fois, signalé par un utilisateur ; un test le détecte désormais avant la mise en ligne.
Aucune donnée client dans le code
Les données client sont repérées par leur forme, jamais par une liste de noms : une liste de clients dans le code serait la fuite elle-même.
Aucun secret dans ce qui part au navigateur
Un secret glissé dans les fichiers envoyés au navigateur fait échouer la mise en ligne.
Messages d'erreur sans fuite
Quand une opération échoue, le message affiché dit ce qui s'est passé sans rien révéler du fonctionnement interne de l'outil.
Une seule liste de collaborateurs
Tous les écrans lisent la même liste de référence. Un nouveau venu apparaît partout, sans attendre d'avoir un dossier.
Pas de mots collés à l'écran
Deux mots qui s'afficheraient collés sont repérés avant la mise en ligne : 260 relevés au premier passage du contrôle. Le contrôle vérifie aussi qu'il a bien lu des fichiers, pour ne jamais être vert à vide.
Avatars lisibles
Les initiales posées sur un avatar sans photo atteignent un contraste de 3:1 au minimum. Le plancher, 3,25:1, est atteint sur Finance.
Les faits réfutés ne survivent pas
Une affirmation reconnue fausse ne peut pas revenir dans la documentation : le contrôle la repère et bloque.
Un chiffre affiché est daté et recalculé
Un chiffre de référence porte sa date de relevé et se recalcule depuis sa source. Recopié à la main à deux endroits, il finirait par diverger.
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.
Dix étapes, toujours dans le même ordre
De l'idée à l'écran, une modification suit le même chemin. La base passe avant le code, la relecture avant la fusion.
-
Isoler le travail
Une branche par chantier, et un espace de travail jetable, retiré après la fusion. Deux chantiers ne se mélangent pas.
-
La base d'abord
Toute évolution de la base est un fichier daté et versionné, qui ajoute sans casser et se rejoue sans effet de bord. Elle est jouée avant le code qui en dépend.
-
Les cinq contrôles, sur le poste
Les cinq contrôles passent d'abord sur le poste, dans l'ordre. Un seul échec, et on s'arrête là.
-
Les relectures
Une relecture contradictoire du code, une revue de conformité pour tout sujet sensible, et une vérification à l'œil dans un navigateur, parce que les tests ne voient pas un écran cassé.
-
Enregistrer fichier par fichier
Jamais tout d'un coup : chaque fichier est ajouté par son nom, puis l'ensemble préparé est relu en entier avant d'être enregistré.
-
Demande de fusion
Tout est rejoué automatiquement sur une installation propre.
-
Préversion
Les écrans sont vérifiés dans un navigateur, sur une version d'essai, avant la fusion.
-
Fusion par une personne
Jamais par programme. Trois actes restent soumis au visa de la Direction : les honoraires, les documents de mission et la communication externe.
-
Mise en production
On attend le feu vert de la mise en ligne, puis on recharge la page pour travailler sur la nouvelle version.
-
Consigner
Le récit du lot rejoint le journal mensuel. Un piège nouveau s'écrit en une ligne, avec son mécanisme ; le détail va dans la fiche du module.
Les cinq contrôles
Ils tournent dans cet ordre, d'abord sur le poste, puis automatiquement à chaque demande de fusion. Un seul échec suffit à tout arrêter.
-
Vérification des types
Une donnée du mauvais genre, comme un texte là où un nombre est attendu.
-
Mots collés dans le code
Deux mots qui s'afficheraient collés à l'écran, alors que le code paraît juste.
-
Suite de tests
Une règle qui n'est plus respectée, dont chacun des garde-fous ci-dessus. 13 427 tests lors de la dernière exécution complète, le 19 octobre 2026.
-
Construction complète
Un site qui ne se construit plus. Le site entier est construit, puis on cherche tout secret dans ce qui part au navigateur.
-
Mots collés dans le résultat construit
Le même défaut, cherché cette fois dans ce qui part réellement au navigateur.
Les cinq sont nécessaires. Un type vérifié ne présage rien de la construction, et une construction réussie ne dit rien de deux mots collés à l'écran. Chaque contrôle voit ce que les autres laissent passer.
Méthode : durée médiane de 54 passages complets des cinq contrôles, mesurés du 13 au 23 octobre 2026. Les tests sont ceux de la dernière exécution complète, le 19 octobre 2026, sur 489 fichiers.
133 jours, mois par mois
Les modifications enregistrées et les lots intégrés depuis la première version, le 13 juin 2026.
| Mois | Modifications | Lots intégrés |
|---|---|---|
| Juin 2026, à partir du 13 | 246 | 4 |
| Juillet 2026 | 691 | 151 |
| Août 2026 | 275 | 54 |
| Septembre 2026 | 666 | 200 |
| Octobre 2026, au 23 | 262 | 53 |
| Total | 2 140 | 462 |
Méthode : relevé de l'historique du dépôt au 23 octobre 2026. Une modification est rattachée au mois de son arrivée dans la branche principale ; octobre est arrêté au 23. Les modifications sont recomptées par trois chemins. Les 462 lots intégrés réunissent 456 fusions retrouvées dans l'historique et 6 lots intégrés par écrasement. Les lignes de code sont comptées par deux chemins, à 4 lignes d'écart.
L'histoire derrière la règle
Comment une règle écrite est devenue un contrôle qui la fait respecter à chaque passage.
Lire l'article