Headless GRC : pourquoi la conformité perd son interface et y gagne

Pourquoi la GRC a besoin d’une nouvelle approche

Les logiciels GRC deviennent headless : données, logique et workflows migrent vers un cœur API-first, et l’interface devient interchangeable. Le marché du CRM a déjà franchi exactement cette étape.

Les outils GRC classiques sont des monolithes. Registre des risques, contrôles, preuves, audits et politiques résident dans une seule application à l’interface figée. Qui veut y travailler doit se connecter, apprendre les menus et saisir les données à la main.

Tout RSSI connaît le résultat : la conformité se déroule à côté de l’activité réelle au lieu d’en faire partie. Les métiers ouvrent l’outil une fois par trimestre, les preuves arrivent par e-mail, et le tableau de bord montre ce que l’éditeur juge important. Ce que la direction veut savoir, il ne le montre pas.

L’analogie : le CRM headless

Le CRM headless sépare les données clients de l’écran sur lequel elles s’affichent. La GRC headless fait de même avec les risques, les contrôles et les preuves.

Dans le CRM classique, les commerciaux travaillaient dans l’interface de l’éditeur. Le CRM headless inverse la logique : le CRM est une base de données dotée de logique métier, accessible par des API. Les commerciaux voient les données clients dans Slack, dans leur messagerie, dans leur propre cockpit commercial ou dans la boutique en ligne. Presque plus personne ne voit le CRM lui-même : c’est le System of Record en arrière-plan.

Transposé à la GRC, cela signifie que le registre des risques ne vit plus seulement dans un formulaire, mais là où les décisions se prennent. Un développeur voit le contrôle pertinent dans la pull request, les achats voient l’évaluation du fournisseur dans le processus de commande, et la direction voit sa cartographie des risques dans son reporting.

Caractéristiques clés de la GRC headless

Six caractéristiques distinguent la GRC headless d’un outil classique auquel une API a été greffée après coup.

1. Couche de présentation découplée. Les données et la logique sont entièrement séparées de l’interface. Une interface livrée avec le produit est une vue possible parmi d’autres, pas la seule.
2. API-first plutôt qu’API en complément. Chaque fonction qu’utilise l’interface de l’éditeur est aussi disponible via l’API. Aucune action ne passe uniquement par un clic.
3. Modèle de données structuré. Risques, actifs, contrôles, exigences et preuves sont des objets proprement modélisés et reliés entre eux. Seule cette structure rend les données exploitables par d’autres systèmes et par l’IA.
4. Logique des référentiels dans le cœur. Les correspondances entre ISO 27001, NIS2, DORA ou le BSI IT-Grundschutz se trouvent dans le backend. Chaque interface en hérite au lieu de les reconstruire.
5. Événements et intégrations. Les modifications déclenchent des événements, et les preuves arrivent automatiquement du cloud, du fournisseur d’identité ou de l’outil de tickets. La conformité devient un flux de données plutôt qu’un exercice à date fixe.
6. Droits granulaires et traçabilité. Lorsque de nombreuses interfaces et de nombreux agents accèdent aux mêmes données, les droits, les versions et la piste d’audit doivent résider dans le cœur. La valeur probante des enregistrements ne doit pas dépendre de l’interface utilisée.

L’avenir : des tableaux de bord sur mesure plutôt que des vues standard

Le tableau de bord standard de l’éditeur perd de son importance. Chaque organisation construit les vues adaptées à ses propres questions.

La direction veut savoir si l’entreprise est prête pour NIS2 et où se situe le risque résiduel le plus élevé. Un auditeur veut les preuves par exigence. Un chef d’équipe ne veut voir que les trois contrôles dont son équipe est responsable. Un tableau de bord unique ne sert correctement aucune de ces personnes.

Avec un cœur headless, ces vues se construisent rapidement et sans projet chez l’éditeur : sous forme de rapport BI, de page sur l’intranet, de widget dans l’outil de tickets ou de présentation pour la direction qui se met à jour toute seule. Les données restent une source unique ; la présentation est construite pour chaque public.

Generative UI : des interfaces créées à la demande

L’étape suivante après les tableaux de bord sur mesure est la Generative UI : l’interface n’est plus construite, elle est générée par une IA au moment où la question est posée.

Au lieu de naviguer dans des menus, la dirigeante demande : « Quels fournisseurs critiques n’ont pas d’évaluation à jour, et quels risques en dépendent ? » Un agent IA récupère les données via l’API et génère une vue adaptée : un tableau, un graphique ou une carte des dépendances. Demain, la même question aura peut-être une autre allure, parce que les données auront changé.

Cela déplace ce qu’un éditeur GRC livre réellement. L’interface devient un instantané. Ce qui reste et a de la valeur :

• un modèle de données fiable et structuré,
• une logique de référentiels et d’évaluation correcte,
• des droits rigoureux, pour que l’IA ne montre que ce que la personne qui pose la question a le droit de voir,
• une piste d’audit complète, même lorsqu’un agent écrit à la place d’un humain.

Des protocoles comme le Model Context Protocol (MCP) rendent exactement cela possible dès aujourd’hui : les assistants IA accèdent de manière structurée aux données GRC, lisent les risques et créent des mesures, sans que personne n’ouvre l’interface classique.

L’API-first est la seule véritable condition préalable

Lorsque les interfaces sont générées, un système GRC n’a plus besoin que d’une chose en son cœur : une API complète et bien documentée.

Cela ressemble à une simplification, mais l’exigence est élevée. Une API greffée après coup sur un outil ne couvre généralement que la lecture ou quelques objets isolés. L’API-first signifie au contraire que l’interface de l’éditeur n’est elle-même qu’un client de cette API parmi d’autres. Ce qui fonctionne là fonctionne aussi pour chaque tableau de bord, chaque intégration et chaque agent IA.

Pour les acheteurs de logiciels GRC, il en découle des questions de contrôle claires. Elles complètent nos sept questions pour choisir un logiciel GRC :

• Chaque fonction de l’interface est-elle aussi disponible via l’API, y compris en écriture ?
• Le modèle de données est-il documenté publiquement et versionné de façon stable ?
• Les rôles et les droits s’appliquent-ils aux accès API exactement comme dans l’interface ?
• Les modifications effectuées via l’API sont-elles journalisées avec valeur probante ?
• Existe-t-il une connexion pour les assistants IA, par exemple via MCP ?

Qui peut répondre oui à ces questions est prêt pour les tableaux de bord sur mesure et la Generative UI. Qui ne le peut pas achète un outil dont personne ne voudra plus ouvrir l’interface d’ici quelques années.

Conclusion

La GRC suit le chemin tracé par le CRM : du poste de travail au System of Record. L’interface devient d’abord individuelle, puis générée, et à la fin seul le cœur compte.

Pour les éditeurs, cela signifie investir dans le modèle de données, la logique et l’API plutôt que dans toujours plus de formulaires. Pour les utilisateurs, cela signifie amener la conformité là où l’on travaille, et choisir les outils GRC selon leur capacité à se rendre invisibles.

Nous décrivons comment cette évolution s’inscrit dans le modèle générationnel de Michael Rasmussen dans GRC 7.0 : ce que GRC Orchestrate de Michael Rasmussen signifie pour les organisations. Notre pronostic GRC 9.0 : Embedded GRC montre où elle peut mener à long terme.