Logiciel GRC : ce que l’IA change

L’essentiel

• Un logiciel GRC est un référentiel unique qui réunit les politiques, les risques, les contrôles, les obligations et les preuves qui les relient. Sa valeur tient au modèle de données, pas au tableau de bord.
• Ce que l’IA a changé, c’est le périmètre de ce modèle : les systèmes d’IA déployés par une organisation constituent désormais une catégorie d’actifs régulés à part entière.
• L’article 17 du règlement européen sur l’IA énumère douze éléments que le système de gestion de la qualité d’un fournisseur doit documenter. Lu comme une grille d’achat, cet article décrit ce qu’un outil GRC doit contenir.
• L’Omnibus numérique a reporté l’échéance des systèmes à haut risque de l’annexe III au 2 décembre 2027. L’échéance a bougé, pas le temps nécessaire pour constituer une piste de preuves crédible.
• Le critère de choix n’est pas le nombre de modules, mais la capacité des livrables à résister à l’examen d’un organisme notifié ou d’une autorité de surveillance du marché.

Ce que fait réellement un logiciel GRC

Un logiciel GRC constitue le référentiel unique où figurent les politiques d’une organisation, les risques qu’elle a acceptés ou refusés, les contrôles qui traitent ces risques, les obligations auxquelles ces contrôles répondent et les preuves que chaque contrôle a effectivement fonctionné. Les trois lettres désignent trois disciplines nées dans des directions différentes. L’outil est précisément ce qui les contraint à partager une même structure. Cette structure constitue le produit. Une gouvernance dépourvue de données de risque se réduit à des documents que personne ne lit. Un risque sans rattachement aux contrôles produit un registre qui ne change jamais rien. Une conformité sans preuve reste une affirmation. Lorsque ces trois dimensions vivent dans des tableurs séparés, chaque audit devient un exercice de rapprochement et chaque question du régulateur se transforme en projet. Lorsqu’elles partagent un modèle de données commun, une question du type « quels contrôles traitent ce risque, qui en est responsable, quand ont-ils été testés et où se trouve la preuve » trouve sa réponse en quelques minutes plutôt qu’en quelques semaines. C’est aussi la raison pour laquelle la catégorie résiste aux définitions simples. Deux produits peuvent l’un et l’autre revendiquer l’étiquette de plateforme GRC sans partager grand-chose, l’un étant construit autour de la diffusion des politiques et de leur acceptation, l’autre autour du test des contrôles et du déroulement des audits. La question utile n’est jamais de savoir s’il s’agit d’un outil GRC, mais de déterminer ce que son modèle de données rend économique et ce qu’il rend coûteux.

Pourquoi le modèle de données prime sur le tableau de bord

Les démonstrations commerciales mettent en avant des tableaux de bord, parce qu’ils se démontrent bien. Ils se situent pourtant en aval. Une cartographie des risques se produit sans difficulté dès lors que risques, contrôles et résultats de tests sont correctement reliés, et devient impossible à produire honnêtement lorsqu’ils ne le sont pas. Les questions qui méritent d’être posées en phase d’évaluation portent sur la structure. Un même contrôle peut-il satisfaire plusieurs référentiels simultanément, ou l’outil impose-t-il un contrôle dupliqué par référentiel ? Une obligation peut-elle être reliée à l’artefact précis qui la satisfait ? Un risque peut-il être rattaché à un actif et non uniquement à un processus métier ? Ces réponses déterminent si l’outil réduit la charge de travail ou se contente de la déplacer. Notre guide de la gouvernance de l’IA détaille le modèle opérationnel que cette structure doit soutenir.

Le modèle de capacités OCEG, et la place réelle de l’outil

La plupart des présentations de cette catégorie finissent par citer le GRC Capability Model de l’OCEG, publié sous le nom de Red Book. Il organise la discipline en quatre composantes : Learn, Align, Perform et Review, sous la bannière de la Principled Performance. Learn consiste à comprendre le contexte, la culture et les parties prenantes. Align relie objectifs, stratégie et appétence au risque. Perform recouvre l’exécution des contrôles. Review mesure ce qui a effectivement fonctionné. Le modèle est disponible auprès de l’OCEG. La lecture honnête, celle que la plupart des présentations évitent, tient en une phrase : un logiciel instrumente correctement Perform et Review, et ne peut en aucun cas fabriquer Align. Un outil sait enregistrer une déclaration d’appétence au risque. Il ne dira pas si l’organisation adhère réellement à cette appétence, ni si sa direction générale l’écarterait sous pression commerciale. Acquérir un outil avant d’avoir tranché ce que l’organisation accepte réellement produit une version remarquablement bien documentée d’un désaccord non résolu. Cette distinction pèse davantage avec l’IA qu’elle ne pesait avec les contrôles financiers, car les décisions relatives à l’IA se prennent beaucoup plus bas dans la hiérarchie. Un responsable produit peut insérer un modèle dans un parcours client en une après-midi. Si la phase Align n’a pas eu lieu, l’outil enregistre les conséquences au lieu d’orienter les choix. Cela explique également le flou des frontières de la catégorie. Un logiciel GRC n’est qu’une brique d’une chaîne de contrôle plus large, qui comprend la gestion des identités, la journalisation, les registres de modèles et la supervision de sécurité, une répartition que nous détaillons dans notre analyse de la plateforme de conformité face au reste de la chaîne.

Ce que l’IA change : le système devient l’actif régulé

Jusqu’à récemment, le périmètre d’un programme GRC couvrait des processus, des fournisseurs, des contrôles et l’information financière. L’IA y ajoute un objet pour lequel le modèle n’avait pas été conçu : un actif probabiliste plutôt que déterministe, qui se dégrade silencieusement à mesure que le monde s’éloigne de ses données d’entraînement, et qui se trouve régulé système par système plutôt que processus par processus. Trois conséquences en découlent. La première tient à l’inventaire, qui devient la contrainte déterminante. On ne classe pas, on ne contrôle pas et on ne prouve pas ce dont on ignore l’existence, et l’adoption non déclarée constitue la norme plutôt que l’exception. Tout ce que l’on ne voit pas échappe à l’ensemble des contrôles rédigés, ce qui constitue le problème concret que recouvre le shadow AI. La deuxième conséquence transforme la classification en acte juridique et non plus en commodité interne. Selon le règlement européen, le fait qu’un système relève des pratiques interdites, du haut risque, des seules obligations de transparence ou d’aucun régime particulier détermine les obligations qui s’y attachent. Cette classification doit être consignée, justifiée et réexaminée à chaque évolution du système. La troisième conséquence met fin au caractère périodique du registre des risques. Un contrôle testé une fois par an constitue une réponse raisonnable pour un processus d’achat. Elle devient insuffisante pour un modèle dont le comportement peut se déplacer après une mise à jour fournisseur dont personne n’a été prévenu. Notre guide de la gestion des risques liés à l’IA précise ce que recouvre concrètement le mot « continu ».

Du GRC augmenté par l’IA au GRC sur l’IA

Presque tous les produits du marché affichent désormais des fonctions d’IA : résumé de politiques, rédaction de descriptions de contrôles, suggestion de cotations, tri des questionnaires. Une partie de ces fonctions supprime réellement du travail. Il s’agit cependant d’un sujet entièrement distinct de celui sur lequel les régulateurs interrogent les organisations. Le GRC augmenté par l’IA signifie que l’éditeur utilise un modèle pour accélérer son propre logiciel. Le GRC sur l’IA signifie que votre organisation sait démontrer la maîtrise des systèmes d’IA qu’elle exploite. Un outil peut exceller dans le premier registre et se révéler inutile dans le second. Toute la distinction tient à la préposition, et il vaut la peine d’être direct avec les éditeurs sur ce qui est réellement démontré. Un point de second ordre mérite d’être signalé. Si un modèle contribue à produire vos preuves de contrôle, ce modèle entre lui-même dans le périmètre. Une preuve issue d’un système non validé ne vaut pas plus que le système qui l’a produite.

Le règlement européen rédige le cahier des charges

L’aspect le plus utile du règlement européen sur l’IA, pour qui évalue un outillage, tient à sa précision inhabituelle sur ce qui doit exister par écrit. Les articles 8 à 15 fixent les exigences applicables aux systèmes à haut risque : système de gestion des risques (article 9), données et gouvernance des données (article 10), documentation technique (article 11), enregistrement des événements (article 12), transparence et information des utilisateurs (article 13), supervision humaine (article 14), exactitude, robustesse et cybersécurité (article 15). L’article 16 énumère ensuite les obligations du fournisseur : respecter ces exigences, s’identifier sur le système, disposer d’un système de gestion de la qualité, conserver la documentation, conserver les journaux générés automatiquement, se soumettre à l’évaluation de la conformité, établir une déclaration UE de conformité, apposer le marquage CE, enregistrer le système, prendre les mesures correctives nécessaires, coopérer avec les autorités nationales compétentes et respecter les exigences d’accessibilité. L’article 17 fait apparaître une grille d’achat presque à la lettre. Le système de gestion de la qualité du fournisseur doit être documenté et comprendre au minimum : une stratégie de conformité réglementaire incluant les procédures d’évaluation de la conformité ; les techniques de conception, de développement et de contrôle de la qualité ; les procédures d’examen et d’essai ; les spécifications techniques ; les systèmes de gestion des données ; un système de gestion des risques ; un système de surveillance après commercialisation au titre de l’article 72 ; les procédures de signalement des incidents graves au titre de l’article 73 ; un processus de communication avec les autorités ; un système d’archivage ; la gestion des ressources ; et un cadre de responsabilité définissant les responsabilités de la direction et du personnel. Douze éléments, dont chacun doit se trouver quelque part et pouvoir être produit sur demande. Il s’agit d’un cahier des charges de référentiel, que quiconque lui donne ce nom ou non. L’article 9 précise la forme du travail sur le risque. La gestion des risques constitue un processus itératif continu sur l’ensemble du cycle de vie : identifier et analyser les risques pour la santé, la sécurité et les droits fondamentaux, évaluer les risques survenant en utilisation, évaluer les risques révélés par les données de surveillance après commercialisation, puis adopter les mesures appropriées. Les finalités sont également fixées : éliminer ou réduire le risque dans la mesure techniquement possible, atténuer ce qui ne peut être éliminé, fournir l’information de transparence et former les déployeurs le cas échéant. Le risque lui-même se définit comme la combinaison de la probabilité d’un dommage et de sa gravité. Une nuance désamorce l’objection habituelle selon laquelle tout cela ne concernerait que les grandes structures. L’article 17, paragraphe 2, impose que la mise en oeuvre du système de gestion de la qualité soit proportionnée à la taille de l’organisation du fournisseur, et le considérant 146 envisage explicitement une version simplifiée pour les microentreprises. La proportionnalité porte sur le volume de processus, non sur l’existence des obligations. Nos ressources sur le règlement européen sur l’IA reprennent les questions de classification en détail.

L’échéance a bougé, pas le temps de construction

Le calendrier s’est déplacé en 2026. L’Omnibus numérique sur l’IA a reporté les obligations applicables aux systèmes à haut risque autonomes de l’annexe III au 2 décembre 2027, et celles applicables à l’IA intégrée dans des produits déjà couverts par la législation européenne de sécurité des produits au 2 août 2028. Plusieurs dates n’ont pas bougé : les obligations de transparence et de marquage des contenus de l’article 50 s’appliquent depuis le 2 août 2026, les obligations relatives aux modèles d’IA à usage général depuis le 2 août 2025, et les pratiques interdites de l’article 5 depuis le 2 février 2025. Les analyses de la Cloud Security Alliance et du cabinet Gibson Dunn concordent sur ces dates. Lire ce report comme un répit constitue une erreur, pour une raison très concrète. La surveillance après commercialisation et l’archivage sont des obligations rétrospectives. Lorsqu’une autorité demandera en 2028 comment un système s’est comporté, la réponse se construira à partir de journaux qu’il fallait capter pendant que le système fonctionnait. Une organisation qui commence à collecter fin 2027 disposera d’un système de gestion conforme et d’aucun historique à y verser. L’échéance correspond au moment où il faut pouvoir montrer la piste, ce qui place la décision de collecte nettement plus tôt.

ISO 42001 et NIST AI RMF : la couche de contrôles

Le règlement dit ce qui doit être vrai. Il ne fournit pas de jeu de contrôles. Deux références comblent cet écart, et tout logiciel GRC sérieux doit porter les deux sans dupliquer le travail. La norme ISO/IEC 42001 spécifie un système de management de l’IA, construit comme les autres normes de systèmes de management, et elle est certifiable. Ce point compte autant commercialement qu’en interne, car un certificat constitue une preuve transportable dans une discussion d’achat. Elle se superpose correctement aux éléments de l’article 17, ce qui explique que tant de fournisseurs en fassent l’ossature de leur système qualité. Nous traitons la norme dans notre article ISO 42001 expliquée. Le NIST AI Risk Management Framework relève du volontariat et adopte une autre forme : quatre fonctions, Govern, Map, Measure et Manage, qui donnent aux équipes un vocabulaire commun pour parler du risque lié à l’IA sans commencer par un débat terminologique. Sa force réside dans la structuration de l’analyse, sa faiblesse dans sa valeur probante lors d’un audit, exactement l’inverse d’une norme certifiable. Notre guide du NIST AI RMF parcourt les quatre fonctions. La conséquence pour l’outillage est concrète. La plupart des organisations répondent simultanément à un règlement, à une norme certifiable et à un cadre volontaire, souvent en plus de certifications de sécurité existantes. Un outil qui rattache un contrôle à un seul référentiel impose de collecter plusieurs fois la même preuve. Un outil qui modélise le contrôle une fois et le relie à plusieurs obligations transforme une multiplication en addition. Cette seule question sépare les outils qui passent à l’échelle de ceux qui triplent discrètement la charge.

Une grille de capacités pour l’outillage à l’ère de l’IA

Voici ce qu’il convient de tester lors de l’évaluation d’un logiciel GRC, avec l’obligation à laquelle chaque capacité répond. La grille raisonne délibérément en capacités et non en modules, les noms de modules variant d’un produit à l’autre là où les obligations, elles, ne varient pas.

Deux lignes concentrent l’essentiel de la difficulté. La journalisation automatique constitue le point de rupture des outils conçus pour la conformité de processus, bâtis pour des validations humaines périodiques et non pour des flux d’événements machine. La traçabilité de la chaîne d’approvisionnement est l’endroit où la plupart des organisations découvrent qu’elles ne savent pas répondre à des questions élémentaires sur un modèle qu’elles n’ont pas entraîné, exactement l’écart traité dans nos travaux sur l’auditabilité.

Des preuves qui résistent à un audit

La plupart des problèmes de preuve ne sont pas des absences. Ce sont des artefacts qui existent mais ne tiennent pas à l’examen, selon quatre modes de défaillance récurrents. Notre guide de l’audit des systèmes d’IA détaille ce que recherchent réellement les évaluateurs. La temporalité vient en premier. Une capture d’écran prouve qu’un état existait au moment où quelqu’un l’a prise, pas qu’un contrôle a fonctionné sur toute une période. L’attribution vient ensuite : un export sans auteur, sans version de système et sans horodatage ne se rattache à rien. La mutabilité constitue le troisième mode, un tableur modifiable après coup prouvant sensiblement moins que son contenu ne le laisse croire. La traçabilité forme le quatrième et le plus fréquent : un artefact qu’on ne peut relier à l’obligation précise qu’il satisfait laisse l’évaluateur deviner, et les évaluateurs ne devinent pas en votre faveur. Les travaux du COSO sur le contrôle interne appliqué à l’IA générative apportent ici une distinction utile à reprendre. Lorsque la direction s’appuie sur une sortie de modèle comme élément de preuve d’un contrôle, le niveau d’exigence applicable à cette preuve s’élève. Refaire soi-même une vérification n’équivaut pas à accepter la conclusion d’un modèle, et la charge documentaire diffère en conséquence : l’invite, la configuration et la version du modèle entrent alors dans le dossier. La même publication formule une remarque connexe qui surprend souvent les équipes : les modèles, les configurations, les artefacts d’affinage, les plongements et les index de recherche devraient être traités comme des éléments de configuration soumis au contrôle d’accès et à la gestion des changements, et non comme du contenu. Le test pratique applicable à n’importe quel outil se mène en quelques secondes. Prenez un contrôle, remontez à l’obligation à laquelle il répond, puis descendez à l’artefact qui prouve son fonctionnement au trimestre précédent. Si ce chemin demande plus de deux clics, ou si l’une des étapes repose sur la mémoire de quelqu’un, l’outil relève de l’armoire à dossiers et non du référentiel.

Acheter, étendre, ou les deux

Trois options honnêtes se présentent pour se doter d’un logiciel GRC couvrant l’IA, et le choix dépend de l’existant. Étendre une plateforme déjà en place se justifie lorsqu’un programme mature fonctionne, que l’éditeur propose un véritable module IA plutôt qu’un registre de risques rebaptisé, et que la bibliothèque de contrôles existante est réellement réutilisable. L’avantage tient à l’unicité du système et des habitudes. Le risque réside dans un module qui modélise les systèmes d’IA comme des actifs ordinaires, et qui échoue donc sur la classification, la journalisation et la provenance des modèles. Un système dédié à la gouvernance de l’IA se justifie lorsque l’IA occupe une place centrale dans le produit, lorsque les obligations sont assez spécifiques pour que des structures de contrôle génériques ne conviennent pas, ou lorsqu’il n’existe rien de mature à étendre. L’avantage réside dans un modèle de données conçu pour le problème. Le coût tient au second système et au travail d’intégration que personne n’apprécie. L’approche hybride constitue l’issue la plus fréquente et la moins discutée. La plateforme historique demeure le référentiel de l’entreprise, tandis qu’un système spécialisé traite les obligations propres à l’IA et remonte un état consolidé. Elle fonctionne lorsque la frontière est tranchée délibérément, et produit deux registres concurrents lorsqu’elle ne l’est pas. Quelle que soit la voie retenue, fixez cette frontière avant la discussion commerciale plutôt que pendant. Notre page logiciel de conformité IA expose notre approche du volet spécialisé.

Questions fréquentes

Quel est un exemple de logiciel GRC ? La catégorie recouvre plusieurs formes de produits. Les plateformes GRC d’entreprise centralisent les registres de risques, le test des contrôles et le déroulement des audits pour de grandes organisations régulées. Les outils d’automatisation de la conformité se concentrent sur la collecte continue de preuves adossées à des certifications de sécurité. Les systèmes de gestion des politiques traitent la rédaction, la diffusion et l’acceptation. Les systèmes dédiés à la gouvernance de l’IA modélisent les systèmes d’IA, leur classification et leurs obligations. La plupart des organisations en exploitent plusieurs, si bien que la vraie comparaison porte sur celui qui tient le référentiel et ceux qui l’alimentent. GRC et audit informatique désignent-ils la même chose ? Non, même si la confusion est fréquente parce que les deux examinent les mêmes contrôles. Le GRC est la discipline opérationnelle continue : définir la politique, tenir le registre des risques, exécuter les contrôles et collecter les preuves. L’audit informatique est une évaluation indépendante et périodique du bon fonctionnement de cette discipline. Un programme GRC bien tenu rend les audits moins coûteux, puisque les preuves existent déjà sous forme structurée. Les constats d’audit alimentent ensuite le registre des risques. La relation est cyclique, mais les rôles restent délibérément séparés, et l’indépendance en est la raison. Jira est-il un outil GRC ? Pas à lui seul. Jira suit des tâches, et une grande partie du travail GRC en comporte : actions de remédiation, tests de contrôles, demandes de preuves. Beaucoup d’équipes commencent par y faire transiter leur activité de conformité. Ce qui manque, c’est le modèle de données sous-jacent, c’est-à-dire des objets de premier rang pour les risques, les contrôles, les obligations et les preuves, avec les relations entre eux. Des tickets étiquetés en donnent une approximation jusqu’au jour où un évaluateur demande quels contrôles traitent un risque donné et où se trouve la preuve. Jira fonctionne bien à côté d’un référentiel, et mal en tant que référentiel. Le GRC demande-t-il de savoir programmer ? Généralement pas pour le travail quotidien. Les outils actuels se paramètrent par interface, et les parties exigeantes du métier relèvent de l’analyse plutôt que de la technique : classer correctement les systèmes, rédiger des contrôles réellement testables, décider de ce qui constitue une preuve suffisante. La programmation devient utile aux extrémités, principalement pour les intégrations qui récupèrent automatiquement des preuves depuis les plateformes cloud, les registres de modèles ou les systèmes de journalisation. Cette automatisation rend la surveillance continue praticable à grande échelle, si bien qu’une capacité technique dans l’équipe reste un atout concret même là où elle n’est pas exigée. Vaut-il mieux un SOC ou un GRC ? Les deux répondent à des questions différentes et ne s’opposent pas. Un centre opérationnel de sécurité détecte et traite les menaces en temps quasi réel. Le GRC établit ce qui doit être maîtrisé, pourquoi, et si les contrôles ont fonctionné sur une période. Un SOC produit des preuves et des incidents qu’un programme GRC consomme, et un programme GRC fixe les politiques et l’appétence au risque dans lesquelles le SOC opère. Les organisations qui les traitent comme des lignes budgétaires concurrentes finissent avec une détection que personne n’a reliée à une obligation, ou des obligations que rien ne surveille. Les outils GRC couvrent-ils le règlement européen sur l’IA ? Ils le revendiquent de plus en plus, et ces affirmations méritent d’être testées. Demandez à voir un inventaire des systèmes d’IA avec classification par système et raisonnement consigné, des preuves reliées à des articles précis plutôt qu’à une famille de contrôles générique, des journaux machine conservés plutôt que des attestations humaines, et un traitement des incidents graves cadencé sur les délais réglementaires. Beaucoup de produits satisfont le premier point et achoppent sur les suivants. Un éditeur qui revendique cette couverture doit pouvoir dérouler un système depuis son enregistrement jusqu’à un dossier lisible par un évaluateur.

Conclusion

La catégorie n’a pas changé de nom. Elle a changé de périmètre. Un logiciel GRC se jugeait à sa manière de traiter des processus, des fournisseurs et des contrôles financiers ; il se juge désormais à sa capacité à traiter aussi un système d’IA comme un objet gouverné de premier rang, doté d’une classification, d’un jeu de contrôles, d’une piste de journaux et d’un responsable. Le règlement a rendu les exigences inhabituellement lisibles. L’article 17 énumère ce qui doit être documenté, l’article 12 impose l’existence des journaux, l’article 72 prolonge la surveillance après le déploiement, et le report des échéances signifie que la piste de preuves doit démarrer bien avant la date sur laquelle on sera mesuré. Évaluez en conséquence : non pas au nombre de modules, mais à la solidité du chemin qui relie l’obligation au contrôle puis à l’artefact daté, lorsque quelqu’un doté d’autorité le parcourt. Si vous menez cette évaluation pour des systèmes d’IA en particulier, notre plateforme de conformité IA est construite autour des obligations article par article décrites ci-dessus.