Le contexte bat la donnée : pourquoi un finding sans Owner, sans Processus et sans Entité, c'est du bruit

La première fois que j'ai « livré » un finding à une CEO, elle me l'a rendu.

C'était un an après le début de mes missions de conseil. J'avais fait ce que je pensais être du bon travail — échantillonnage, walkthrough, identification d'un trou dans les contrôles entity-level d'une filiale régionale. J'avais rédigé propre. Deux paragraphes de finding, un paragraphe de recommandation. J'étais fière.

La CEO l'a lu deux fois. Puis elle l'a poussé en travers de la table.

« Aisha, je ne suis pas en désaccord avec ce que tu écris. Mais je ne sais pas ce que tu veux que j'en fasse. Quelle entité ? Le processus de qui ? Qui je dois appeler ? »

Je lui avais donné de la donnée. Je ne lui avais pas donné de contexte. Et sans le contexte, la donnée était inactionnable — donc du bruit.

Je repense souvent à cette réunion. C'est le moment où j'ai compris que tout ce qu'on fait en GRC, c'est de l'ancrage, et la donnée est la partie facile.

Ce que les cartographes ont compris 500 ans avant nous

Le problème de la longitude a failli briser la marine britannique.

Pendant l'essentiel des XVIIᵉ et XVIIIᵉ siècles, des navires coulaient régulièrement parce que les capitaines savaient mesurer leur latitude (avec un sextant et le soleil) mais n'avaient aucun moyen fiable de mesurer leur longitude. Ils savaient, en un sens réel, où ils étaient — mais sur un seul axe. L'autre axe, c'était une supposition. Des flottes entières se sont échouées parce qu'un « où » sans cadre de référence n'est pas une position. C'est un sentiment.

Le Parlement a fini par offrir un prix — le Longitude Act de 1714, 20 000 £ — à qui résoudrait le problème. John Harrison a passé quarante ans à construire des chronomètres marins. Une fois la solution trouvée, les navires ont arrêté de couler au rythme antérieur.

Ce qui a changé, ce n'est pas la donnée. Les capitaines avaient toujours eu de la donnée. Ce qui a changé, c'est l'ancrage. Une coordonnée est devenue une position.

La GRC est en plein dans sa phase longitude. On a la donnée. On n'a pas l'ancrage. Et nos navires continuent de s'échouer.

La forme du problème

Assieds-toi devant n'importe quel outil GRC aujourd'hui, tu verras des milliers de lignes.

• Des risques, notés 1 à 25.
• Des contrôles, marqués design-effective / operating-effective.
• Des findings, color-codés par sévérité.
• Des KRIs, en tendance haussière ou baissière.
• Des exigences réglementaires, mappées à des contrôles.

Chaque ligne est une coordonnée. Et chaque ligne dérive, parce qu'aucune équipe n'est d'accord sur ce à quoi la ligne se rattache. À qui est ce risque ? À l'entité légale ? À la BU ? Au processus ? Au système ? Au control owner ? Au directeur ? Quand tu fais défiler un registre de 1000 lignes dans un groupe global, tu ne peux pas dire — depuis la ligne seule — si le risque appartient à une personne responsable, ou à une catégorie commode.

Les catégories sont commodes. Les catégories ne t'appellent pas quand ça casse.

Dans les boards où j'ai siégé, à la seconde où une question devient précise — « qui possède ce risque, et quel processus le produit ? » — l'équipe passe en général quatre-vingt-dix secondes à fouiller dans des systèmes adjacents. Parfois elles ne trouvent jamais la réponse. Parfois elles trouvent trois réponses différentes dans trois sources différentes.

C'est l'équivalent audit de la latitude sans longitude. On sent où on est. On n'est pas, au sens opérationnel, localisé.

Ce que l'ancrage signifie vraiment

La solution est structurelle, pas analytique. On ne résout pas un problème de longitude en échantillonnant mieux — on le résout en adoptant un cadre de référence.

En GRC moderne, le cadre de référence, c'est le référentiel organisationnel. C'est la même idée, quel que soit le vendor :

• Une taxonomie d'Entités qui reflète la vraie structure légale et opérationnelle.
• Une taxonomie de Processus qui nomme chaque processus à une granularité assez grosse pour qu'on en débatte.
• Un modèle d'Owner qui nomme des humains réels, pas des rôles abstraits.
• Une couche de liaison qui ancre chaque risque, chaque contrôle, chaque finding, chaque KRI, chaque exigence réglementaire et chaque étape de remédiation à un tuple précis (Entité, Processus, Owner).

Une fois que ça existe, chaque ligne dans chaque outil porte une coordonnée qui veut dire quelque chose.

« Risque #4172 — latence de réconciliation des paiements — possédé par Marcus Yi au Treasury Singapour, Processus P-117 (settlement T+1). »

Maintenant je peux appeler Marcus. Je peux retrouver le runbook de P-117. Je peux comparer cette ligne aux sept autres lignes de P-117 et voir si on a un pattern.

Si tu ne peux pas faire ça depuis une ligne unique dans ton outil GRC, tu n'as pas de GRC. Tu as une base de données.

Ce que ça change en aval

L'ancrage a l'air bureaucratique jusqu'à ce que tu voies ce qui se passe quand tu le fais vraiment. Trois choses changent immédiatement.

1. Les findings cessent d'être orphelins. Chaque finding a une route par défaut vers un humain réel, un processus réel, et un control owner entity-level réel. Le CAE n'a plus à chorégraphier le handoff de chaque issue. Le système le fait.

2. L'agrégation marche enfin. Le roll-up par entité a du sens, parce que les entités sont réelles. Le roll-up par processus a du sens, parce que les processus sont nommés. Tu peux enfin dire, sans gêne, « Singapour Treasury a 14 findings ouverts, tous sur P-117 — on a un problème de processus, pas un problème de contrôle. » Avant l'ancrage, tu ne pouvais dire ni l'un ni l'autre.

3. Les agents IA deviennent utiles. C'est l'effet sous-estimé. Chaque agent d'une plateforme GRC moderne — RiskSentinel, EvidenceHunter, RegMapper — dépend du contexte pour opérer. Donne à un agent un finding sans Entité / Processus / Owner, et le mieux qu'il puisse faire, c'est de résumer. Donne-lui un finding pleinement ancré, et il peut proposer une refonte de contrôle, faire remonter des findings liés dans d'autres entités, drafter le mémo de remédiation, et router l'issue. Les agents n'inventent pas le contexte. Ils le consomment.

Si tu te demandes pourquoi tes fonctionnalités IA déçoivent, la réponse est presque toujours : ta donnée n'est pas ancrée.

À quoi ça ressemble lundi matin

Un reframe et un test.

Le reframe est simple. Chaque artefact de ton système GRC — chaque risque, chaque contrôle, chaque finding, chaque KRI — devrait être jugé sur une seule question :

« Si une personne qui n'a jamais vu cet artefact l'ouvre, peut-elle dire quoi faire et qui appeler ? »

Si oui, l'artefact est ancré. Si non, l'artefact est de la donnée sans contexte, donc du bruit.

Le test, c'est l'artefact qui est devant toi maintenant. Sors un finding au hasard de ton issue tracker. Pose la question. Regarde ce qui se passe.

La première fois que les équipes font ça, elles ratent. Six mois plus tard, après le travail d'ancrage, chaque artefact passe. L'opération GRC devient — pour la première fois — localisée. Les navires cessent de s'échouer.

Le point

C'est ça, le travail. C'est pour ça que chaque essai de cette série finit par revenir au contexte. Les huit morceaux de l'album reposent sur celui-ci. Sans le contexte, aucun des autres ne signifie ce qu'il est censé signifier.

Tu peux avoir le meilleur registre des risques du monde, la bibliothèque de contrôles la plus fine, la méthodologie de test la plus rigoureuse, les agents IA les plus malins — si les lignes ne sont pas ancrées à une Entité réelle, à un Processus réel, à un Owner réel, tu navigues toujours sans longitude.

Règle ça d'abord. Tout le reste devient plus facile.