Chaque contrôle est une hypothèse

J'étais étudiante en physique avant d'être spécialiste compliance, et la transition m'a pris près de dix ans à digérer.

Vues de loin, les deux disciplines n'ont rien à voir. La physique, c'est des blouses blanches, des équations, des mesures à sept décimales. La compliance, c'est des mémos de politique, des workflows d'approbation et des disputes occasionnelles avec un VP des ventes.

Mais en dessous, le travail est le même. On mène toutes les deux des expériences contre le monde pour voir si notre modèle de comportement attendu colle au comportement réel. On appelle juste nos instruments autrement.

En physique, un modèle qui n'a pas été testé n'est pas de la science. C'est de la spéculation.

En compliance, un contrôle qui n'a pas été testé n'est pas de l'assurance. C'est aussi de la spéculation. On ne l'appelle juste pas comme ça, parce que le mot « contrôle » sonne rassurant et définitif.

Je veux soutenir, dans cet essai, que la plus grande amélioration que la plupart des équipes GRC pourraient apporter à leur métier, c'est d'arrêter de traiter les contrôles comme des faits et de commencer à les traiter comme des hypothèses. Le shift est conceptuel, pas technique, et une fois fait, presque toutes les pratiques en aval changent de forme.

Ce qu'on se trompe sur les contrôles

Un contrôle, sur le papier, ressemble à une affirmation de fait.

« La ségrégation de fonctions est appliquée entre le demandeur et l'approbateur des modifications de la fiche fournisseur. »

Lis cette phrase et remarque comme elle sonne confiante. Le verbe est au présent. La voix est active. La structure invite à la croyance. Au moment où l'auditeur arrive, le contrôle a l'air d'une description du monde, pas d'une affirmation à son sujet.

Mais chaque mot est une hypothèse. Est-ce que la ségrégation est appliquée ? Entre qui, précisément ? Sur quel sous-ensemble de modifications ? Par quel mécanisme — système, politique, ou espoir ? Et le mécanisme se comporte-t-il pareil la troisième semaine de décembre, quand la moitié de l'équipe est en PTO et que quelqu'un essaie de passer une modif de fin d'année ?

Un contrôle est une assertion porteuse sur le comportement d'un process sous stress. Il vaut exactement ce que vaut la preuve qui le soutient. La plupart des contrôles ont une preuve assez bonne pour soutenir « ça se passe les mardis de mars ». Peu en ont une assez bonne pour soutenir « ça se passe toujours ».

C'est dans cet écart que vivent les findings.

La méthode scientifique appliquée à un contrôle de fiche fournisseur

Concrètement. Disons que je veux tester le contrôle ci-dessus. L'approche naïve consiste à tirer un échantillon de modifs de fiches fournisseur, regarder qui demande et qui approuve, vérifier que ce sont deux humains différents. Si 25/25 sont différents, le contrôle passe.

L'approche scientifique est différente. Elle part d'une question qui a le potentiel de falsifier le contrôle.

« Sous quelles conditions ce contrôle échouerait-il ? »

Je m'assois avec cette question dix minutes avant de toucher un système. Les conditions qui me viennent, à peu près par ordre d'inquiétude :

1. 1Un utilisateur ayant à la fois le rôle demandeur et approbateur dans l'application
2. 2Un compte de service partagé qu'une seule personne utilise sous plusieurs identités
3. 3Un bypass de workflow ouvert aux administrateurs système
4. 4Une procédure de change d'urgence qui saute explicitement la ségrégation
5. 5Une route de modification de fiche fournisseur passant par un autre système (l'intégration avec la plateforme procurement, par exemple) où la ségrégation n'est pas appliquée
6. 6Un ticket help desk qui autorise des édits manuels de la fiche fournisseur

Le test naïf n'attrape rien de tout ça. Le test naïf attrape un mardi normal de mars.

Ce que je veux, c'est un design de test qui cherche les modes de défaillance. La sélection des échantillons n'est pas aléatoire — elle est adverse. Trois de mes 25 viennent de la période où le contrôleur était en vacances. Deux de la fin d'année. Deux de modifs initiées par ticket. Un d'un override administrateur, s'il en existe.

Si rien de tout ça ne fait surface, le contrôle survit à l'expérience. Maintenant je peux l'écrire comme un fait.

Pourquoi ça compte à l'échelle

Voici la partie qui devrait inquiéter tout CAE.

Si tu admets que les contrôles sont des hypothèses, tu dois aussi admettre qu'une bibliothèque de contrôles est une liste de revendications non falsifiées, pas une liste de garde-fous. Certaines sont bien testées. Beaucoup ne l'ont été que contre le cas ennuyeux. Quelques-unes n'ont jamais été sérieusement testées.

Dans la plupart des organisations, le ratio bien-testé / mal-testé est entre 20:80 et 30:70, en faveur du mal-testé.

Ça ne veut pas dire que ces contrôles sont faux. Ça veut dire qu'on ne sait pas. On opère sur une confiance qu'on n'a pas gagnée.

L'implication pour le testing assisté par IA est significative. Quand un LLM lit la description d'un contrôle et propose des cas de test adverses — des modes de défaillance qu'un humain mettrait des heures à brainstormer — la structure de coût des tests rigoureux change. On peut enfin, pour la première fois dans l'histoire du métier, traiter chaque contrôle comme une vraie hypothèse, pas juste les high-risk.

C'est ce que fait l'agent EvidenceHunter dans les plateformes GRC modernes. L'agent lit le contrôle, génère les modes de défaillance, conçoit des échantillons qui ciblent chaque mode, et fait remonter la preuve qui confirme ou casse le contrôle. Le job de l'auditeur monte d'un cran : de « le contrôle a-t-il passé ? » à « avons-nous testé la bonne hypothèse ? »

Le reframe

Essaie ça une semaine. Chaque fois que tu lis l'énoncé d'un contrôle, insère mentalement « nous faisons l'hypothèse que » au début.

« Nous faisons l'hypothèse que la ségrégation de fonctions est appliquée entre le demandeur et l'approbateur des modifications de la fiche fournisseur. »

D'un coup, c'est une phrase qui demande à être testée. Elle est nue. Elle invite au désaccord. Tu te mets à demander, presque automatiquement, « sous quelles conditions ça échouerait ? » Et la réponse à cette question, c'est ton plan de test.

Le point

Voilà le shift. Du fait à l'hypothèse. De la défense de l'existence du contrôle à l'interrogation de son comportement. De la confirmation à la falsification.

La physique a pris ce virage quelque part au XVIIᵉ siècle. La compliance est en plein dedans, maintenant. Les équipes qui penchent dans le bon sens sont celles dont les findings font vraiment bouger les organisations. Les autres continueront à écrire « contrôle effectivement opérant » — jusqu'au jour où il ne le sera plus.