La Règle #82 : Ce qui garde doit être exécutable et exécuté

Une consigne écrite n'a jamais protégé personne. Qu'il s'agisse de charte informatique, de procédure qualité ou de guide de conformité, la plupart des organisations accumulent des montagnes de règles théoriques. Pourtant, lorsqu'un dysfonctionnement survient, le constat est toujours le même : la règle existait bel et bien sur le papier, mais personne ne vérifiait son application réelle.

Voici le récit d'une prise de conscience majeure et de la règle désormais célèbre qui en a découle : ce qui garde doit être exécutable et exécuté.

LE VACCIN-DOCUMENT : POURQUOI ÉCRIRE UNE RÈGLE NE VACCINE RIEN DU TOUT

Dans beaucoup d'entreprises, la gestion des risques repose sur un réflexe pavlovien : face à une erreur ou un incident, on rédige un nouveau document. Une nouvelle note de service est diffusée, une procédure de trois pages est ajoutée au manuel interne, puis classée dans un dossier partagé.

C'est ce que l'on appelle l'illusion du vaccin-document.

Penser qu'écrire une règle suffit à garantir son respect équivaut à croire qu'afficher un panneau de limitation de vitesse sur un mur empêche techniquement un véhicule de rouler trop vite. Sans contrôle automatisé, la règle reste un voeu pieux.

LE GRAND RÉVEIL : DES COMPÉTENCES "VERTES" SANS UN SEUL TEST EXÉCUTÉ

L'élément déclencheur est survenu lors d'un audit de gouvernance de nos systèmes opérationnels. Tout semblait parfait au premier abord : les tableaux de bord affichaient des indicateurs au vert, certifiant que l'ensemble des modules et des compétences nécessaires au fonctionnement étaient déclarés conformes.

Cependant, une analyse approfondie des journaux d'exécution a révélé une réalité bien différente.

Il y avait un décalage flagrant entre la conformité déclarative (ce qui est écrit) et la conformité vérifiée (ce qui est exécuté). Tout le système reposait sur la foi aveugle en des fichiers passifs.

LA RÈGLE EN ACTE : UN MOTEUR D'ÉVALUATION QUI NE MENT PLUS

Face à ce constat, une décision radicale s'imposait : bannir la déclaration passive et instaurer la preuve par l'exécution. C'est ainsi qu'a été gravée la Règle #82 : ce qui garde doit être exécutable et exécuté.

Concrètement, qu'est-ce que cela change dans la pratique ?

1. La règle devient un programme : Chaque exigence est traduite sous forme de test automatisé (un linter, un script d'audit ou un jeu de données de contrôle).
2. L'exécution est obligatoire et continue : Une règle n'est considérée comme active que si son évaluation s'exécute à chaque étape critique du flux de travail.
3. L'échec est bloquant : Si l'évaluation échoue ou si le test n'a pas été lancé, le processus s'arrête immédiatement.

"UNE COMPÉTENCE EXIGÉE SANS ÉVALUATION EST EN DETTE" : LA DETTE DE GOUVERNANCE MESURABLE

De cette transformation est né un concept fondamental pour toute organisation moderne : la dette de gouvernance.

De la même manière que la dette technique désigne le coût futur des raccourcis pris dans le code, la dette de gouvernance mesure le fossé entre les règles qu'une organisation prétend appliquer et celles qu'elle vérifie réellement.

Mesurer cette dette permet d'éviter l'accumulation de règles mortes qui alourdissent l'organisation sans apporter la moindre sécurité.

TRANSFERT PRATIQUE : AUDITER VOS PROPRES RÈGLES ET NE GARDER QUE CELLES QUI S'EXÉCUTENT

Comment appliquer cette leçon de gouvernance dans votre propre organisation, qu'il s'agisse d'une PME, d'une équipe technique ou d'un service administratif ?

Voici une méthode en quatre étapes pour transformer vos règles papier en garde-fous réels :

1. Lister l'existant : Recensez toutes les règles, chartes et consignes actuellement en vigueur dans votre service.
2. Identifier le mode de contrôle : Pour chaque règle, posez-vous la question : Comment savons-nous, de manière irréfutable, que cette règle est appliquée aujourd'hui ?
3. Automatiser ou supprimer :

• Si la règle peut être convertie en contrôle automatisé (linter, validation de formulaire, script d'alerte), faites-le.
• Si la règle ne peut être ni contrôlée ni exécutée, supprimez-la. Elle ne sert qu'à créer un faux sentiment de sécurité.

1. Instaurer le blocage à la source : Faites en sorte qu'un manquement à la règle bloque physiquement la suite du processus au lieu d'émettre un simple rapport que personne ne lira.

En appliquant la Règle #82, vous réduisez la bureaucratie inutile tout en renforçant considérablement la fiabilité réelle de vos opérations. Car au final, seule la preuve par l'exécution fait foi.

🔁 REGARD CROISÉ — TROIS ÉTAPES POUR ASSAINIR VOS RÈGLES

Notre jumeau du 30/09 terminait par un mode d'emploi opérationnel, que nous reprenons :

1. « Brûlez » la documentation décorative : prenez vos dix règles les plus importantes et demandez, pour chacune, quel script la vérifie au moment du commit ? Sans script, la règle n'existe pas.
2. Écrivez le test avant le guide : un linter d'abord, la documentation ensuite — elle n'est que le mode d'emploi du test.
3. Refusez les victoires par défaut : un pipeline vert qui n'a pas exécuté vos tests métier est plus dangereux qu'un pipeline rouge.

Concrètement, chaque règle devient un script CLI déterministe (ex. scanner les chemins /home/… et sortir exit(1)), l'intégrité est scellée par empreinte SHA256, et l'imposition est progressive : un contrôle nouveau rapporte d'abord, puis bloque une fois prouvé vert.