L’essentiel
- La conformité et la gouvernance ne sont pas deux domaines parallèles : ce sont deux faces d’un même modèle opérationnel qui transforme l’intention stratégique en preuves auditables.
- La gouvernance fixe le cap et l’autorité ; la conformité prouve que l’organisation est restée à l’intérieur des lignes qu’elle a acceptées.
- L’OCEG GRC Capability Model 3.5, le NIST Cybersecurity Framework 2.0 et le NIST AI Risk Management Framework partagent la même architecture : gouverner d’abord, puis décliner jusqu’aux contrôles.
- L’ajout en 2024 de la fonction GOVERN au NIST CSF 2.0, ainsi que la publication parallèle d’
ISO/IEC 42001et duRèglement européen sur l'IA, marquent le moment où conformité et gouvernance ont fusionné en un workflow unique et responsable. - Un dispositif de conformité et de gouvernance qui fonctionne se mesure à un seul test : peut-il tracer une obligation externe, ligne par ligne, jusqu’à un contrôle, un responsable et une pièce justificative qu’un inspecteur pourrait auditer dès demain matin.
Ce que veulent vraiment dire conformité et gouvernance
La plupart des pages qui dominent Google ouvrent sur un diagramme de Venn rassurant et s’arrêtent là. Le vrai enseignement, enfoui sous le schéma, est plus utile : gouvernance et conformité sont des fonctions séquentielles du même modèle opérationnel, et non deux disciplines distinctes.
Gouvernance : fixer le cap
Le NIST regroupe gouvernance, risque et conformité dans une seule discipline parce qu’ils partagent une finalité commune : aligner ce que l’organisation fait avec ce que sa direction a décidé qu’elle devait faire. La gouvernance occupe la partie amont de ce travail. Elle décide qui peut prendre quelles décisions, sur quelles preuves, et dans quelles limites. Dans une entreprise typique, elle se matérialise par des chartes, des délégations de pouvoir, des comités, des politiques internes et le calendrier des décisions que ces instances doivent traiter chaque année. Le trait définitoire de la gouvernance est qu’elle fixe le cap. Elle ne vérifie pas que ce cap a été tenu. C’est le rôle de la seconde moitié du modèle.
Conformité : prouver que le cap a été tenu
La conformité occupe la partie aval. Elle accepte le cap fixé par la gouvernance, puis produit les preuves que l’organisation est restée à l’intérieur de ce cap. Ces preuves sont consommées par les auditeurs, les régulateurs et les contreparties. Dans un environnement régulé, la conformité s’adresse à deux publics. L’audit interne examine les preuves pour confirmer que les contrôles ont fonctionné comme prévu. Les régulateurs externes examinent les mêmes preuves pour confirmer que l’obligation légale a été respectée. Les deux inspectent souvent les mêmes artefacts ; seul l’auditoire change l’étiquetage.
Le diagramme de Venn où s’arrêtent les concurrents
La plupart des articles dessinent gouvernance et conformité en cercles qui se chevauchent, avec le risque en pont entre les deux. L’image n’est pas fausse, mais elle masque l’essentiel. Les deux fonctions ne sont pas seulement voisines : elles sont conçues pour s’alimenter mutuellement. La gouvernance produit des obligations et des règles ; la conformité produit les preuves que ces obligations ont été honorées ; ces preuves remontent à la gouvernance pour nourrir le cycle de décision suivant. Quand la boucle est rompue, on se retrouve avec des politiques jamais opérationnalisées et des contrôles jamais reliés à une politique. C’est précisément le mode d’échec que tous les référentiels modernes, du OCEG GRC 3.5 au NIST CSF 2.0 en passant par ISO/IEC 42001, cherchent à éviter.
Comment la fusion en GRC s’est faite : un arc de vingt ans
L’acronyme GRC a été forgé en 2002 par l’Open Compliance and Ethics Group (OCEG), et le premier OCEG Red Book décrivant le capability model est paru en 2004. Le moteur immédiat fut la loi américaine Sarbanes-Oxley de 2002, qui obligeait les sociétés cotées aux États-Unis à produire des preuves auditables que leurs contrôles internes sur le reporting financier fonctionnaient réellement. Les entreprises qui géraient déjà la gouvernance, la gestion des risques et la conformité ont découvert qu’en les opérant en silos, la chaîne de preuves SOX devenait quasiment impossible à assembler. L’apport de l’OCEG fut de nommer une capacité unifiée, puis de publier un modèle open source de ce à quoi elle devait ressembler. Le Red Book a posé la Principled Performance comme objectif : atteindre les objectifs de manière fiable, traiter l’incertitude et agir avec intégrité. Chacune des capacités décrites par l’OCEG est un instrument au service de ce résultat unique. Vingt ans plus tard, l’architecture est adoptée presque partout. L’inflexion suivante est arrivée en février 2024, lorsque le NIST a publié CSF 2.0. La mutation portait moins sur la cybersécurité que sur la gouvernance : le NIST a ajouté GOVERN comme sixième fonction centrale, aux côtés d’Identify, Protect, Detect, Respond et Recover. La même année, l’ISO publiait ISO/IEC 42001, le premier standard de management system international dédié à l’intelligence artificielle. Les deux événements ratifient la même idée sous des angles différents : gouverner d’abord, puis décliner jusqu’aux contrôles. La conformité est la trace d’audit de cette traduction.
Le modèle opérationnel intégré : une seule pile, trois référentiels
Les trois référentiels les plus souvent cousus ensemble par les équipes GRC d’entreprise paraissent différents en surface. Ils partagent le même squelette.
OCEG GRC Capability Model 3.5
Le modèle OCEG actuel regroupe ses capacités sous quatre composantes : LEARN (apprendre le contexte, la culture et les parties prenantes qui doivent orienter les objectifs) ; ALIGN (aligner la stratégie sur ces objectifs et les actions sur la stratégie) ; PERFORM (exécuter les actions qui favorisent les résultats souhaités et préviennent les indésirables) ; REVIEW (passer en revue pour détecter ce qui a fonctionné et alimenter le cycle suivant). Chaque composante se décompose en capacités, chaque capacité en pratiques, chaque pratique en artefacts qu’une organisation réelle peut produire. Le modèle est volontairement neutre en périmètre : il peut héberger n’importe quelle obligation, du reporting financier à la sécurité de l’information jusqu’à l’IA.
Les six fonctions de NIST CSF 2.0
Le NIST CSF 2.0 organise son travail autour de six fonctions : Govern, Identify, Protect, Detect, Respond et Recover. La fonction GOVERN, ajoutée en 2024, occupe le centre. C’est elle qui articule la stratégie, les attentes et la politique de l’organisation en matière de risque cyber, puis s’assure qu’elles apparaissent dans les cinq autres. Le choix est délibéré : sans couche de gouvernance, les contrôles cybersécurité produisent de l’activité, pas de l’assurance.
Les quatre fonctions du NIST AI Risk Management Framework
Le NIST AI Risk Management Framework embarque quatre fonctions : GOVERN, MAP, MEASURE et MANAGE. GOVERN vient en premier par construction. Elle cadre la responsabilité, définit le risque tolérable et alloue les ressources dont les trois autres fonctions ont besoin. MAP cartographie le contexte et l’impact. MEASURE quantifie. MANAGE applique les traitements retenus. La forme est volontairement familière à toute organisation qui pratique déjà CSF ou COBIT : gouverner d’abord, décliner ensuite.
Un squelette, trois périmètres
Ces trois modèles ne se concurrencent pas. Ils sont le même système d’exploitation appliqué à des périmètres différents : risque d’entreprise, risque cyber, risque IA. Le travail d’une équipe moderne de conformité et de gouvernance consiste à reconnaître cette architecture commune, puis à cesser d’entretenir trois bibliothèques de contrôles parallèles quand une seule bibliothèque bien structurée suffirait.
L’architecture des contrôles : de l’obligation à la preuve
La partie que presque aucun article du top 10 ne traite en profondeur sur ce mot clé est aussi celle qui décide si un dispositif de conformité et de gouvernance est réel ou décoratif : la chaîne à quatre maillons qui relie une obligation externe à une pièce justificative.
Obligation, contrôle, preuve, assurance
Une obligation est l’énoncé contraignant par lequel une autorité externe rend l’organisation responsable. Cela peut être une clause de règlement, un engagement contractuel, un standard que l’organisation a choisi de certifier ou une politique imposée par le conseil. La formulation est rarement opérationnelle. L’article 9(2)(a) du Règlement européen sur l'IA dispose que les fournisseurs de systèmes d’IA à haut risque établissent, mettent en œuvre, documentent et tiennent à jour un système de gestion des risques. Cette phrase est contraignante, pas implémentable. Un contrôle est la réécriture opérationnelle de l’obligation. Il nomme un comportement que l’organisation exécute, souvent selon une cadence récurrente, identifie son exécutant et précise l’artefact produit. Pour l’article 9, le contrôle pourrait être : le Comité Risques IA passe en revue le registre des risques modèles chaque trimestre, valide la classification du risque résiduel et met à jour le plan de traitement dans les cinq jours ouvrés. La preuve est l’artefact produit par le contrôle : le formulaire signé, le registre daté, le plan de traitement mis à jour, l’e-mail de validation du président de séance. La preuve a une provenance, un horodatage et un dépositaire. L’assurance est la vérification indépendante que les contrôles ont fonctionné comme prévu et que la preuve correspond bien à ce qu’elle prétend être. L’audit interne produit l’assurance destinée au conseil ; un certificateur externe produit l’assurance destinée à un marché.
Exemple traité : l’article 9 du Règlement européen sur l’IA de bout en bout
Reprenons la même obligation à travers la chaîne. L’obligation : l’article 9(2) du Règlement européen sur l'IA exige des fournisseurs de systèmes d’IA à haut risque qu’ils maintiennent un processus continu de gestion des risques tout au long du cycle de vie. Le contrôle : chaque modèle de l’inventaire à haut risque dispose d’un responsable nommé, d’une cadence de revue trimestrielle ancrée dans la charte du Comité Risques et d’un plan de traitement documenté qui référence la matrice impact-sévérité validée par la couche de gouvernance. La preuve : le procès-verbal du Comité Risques, l’entrée d’inventaire avec la date de dernière revue, le plan de traitement avec son historique de versions, l’e-mail de validation du responsable de risque. L’assurance : un échantillon d’audit interne de trois modèles par trimestre, plus l’évaluation annuelle par l’organisme notifié qui confirme que la clause QMS de l’article 17 fonctionne. Une fois la chaîne construite pour une obligation, la même forme se rejoue pour toutes les autres. Cette réutilisation est tout l’intérêt de l’exercice.
Là où s’arrêtent la plupart des outils GRC, et ce qu’apporte une plateforme dédiée à l’IA
La plupart des outils GRC généralistes traitent correctement les deux premiers maillons : ils permettent de stocker les obligations et de les rattacher à des contrôles. Les troisième et quatrième maillons, preuve et assurance, sont généralement renvoyés vers des outils de ticketing et des disques partagés. Ce montage tenait quand une obligation pointait vers un contrôle statique. Il casse dès que l’actif sous gouvernance est un modèle de machine learning dont le comportement évolue à chaque cycle de réentraînement. Une plateforme de gouvernance spécifiquement conçue pour l’IA referme la boucle en couplant la chaîne de preuves directement au cycle de vie du modèle, de sorte que le fait qu’un modèle ait été réentraîné un mardi déclenche automatiquement la revue trimestrielle du responsable de contrôle dès le mercredi. Ce couplage est exactement ce que la plateforme de gouvernance IA d’AI Sigil a été conçue pour offrir au-dessus d’une pile GRC existante.
Rôles, responsabilités et modèle des trois lignes
La plupart des grandes organisations opérationnalisent la gouvernance via le modèle des trois lignes : la première ligne possède et exploite les contrôles ; la deuxième ligne supervise les fonctions risque et conformité et challenge la première ; la troisième ligne, l’audit interne, apporte une assurance indépendante au conseil. Le modèle existe depuis assez longtemps pour ne plus prêter à débat. Ce qui change, c’est la distribution. Le Directeur de la Conformité reste responsable de l’inventaire réglementaire. Le Directeur des Risques détient toujours la déclaration d’appétence au risque. Le comité d’audit du conseil consomme toujours l’assurance. Deux rôles ont gagné en stature à l’ère IA : le RSSI s’approprie de plus en plus les contrôles qui protègent les données d’entraînement et les poids des modèles ; et un responsable de la gouvernance IA, rattaché souvent à la fois au Directeur de la Conformité et au Directeur Technique, devient le détenteur naturel de la bibliothèque de contrôles spécifique à l’IA. Là où ce rôle n’existe pas encore, le signe pratique est que personne ne sait répondre à la question : qui valide la dernière model card avant le déploiement. Le modèle s’adapte sans douleur quand l’actif sous gouvernance est un système d’IA. La première ligne inclut les responsables de modèles, les data scientists et les ingénieurs MLOps ; la deuxième ligne ajoute une fonction risque IA aux côtés du risque opérationnel ; la troisième ligne audite l’inventaire des risques modèles comme elle auditait jusque-là le registre des provisions pour pertes sur prêts.
L’inflexion de l’ère IA : pourquoi la GRC est recâblée autour des workloads d’IA
Depuis vingt ans, les programmes GRC absorbaient les nouvelles régulations en étendant la bibliothèque de contrôles existante. La vague IA impose une remise à plat structurelle, parce que les workloads d’IA cassent deux hypothèses sur lesquelles repose l’architecture GRC historique : l’actif est statique entre deux audits, et la chaîne fournisseur est bornée par la fonction achats.
Calendrier du Règlement européen sur l’IA
Le Règlement européen sur l’IA est entré en vigueur le 1er août 2024, avec des dates d’application échelonnées qui contraignent déjà les budgets opérationnels. Les interdictions sur les pratiques à risque inacceptable et les obligations de littératie IA s’appliquent depuis le 2 février 2025. Les règles sur les modèles d’IA à usage général, les organismes notifiés, la gouvernance, la confidentialité et les sanctions s’appliquent depuis le 2 août 2025. Les obligations Annexe III pour les systèmes à haut risque ont été reportées du 2 août 2026 au 2 décembre 2027 par le Digital Omnibus on AI conclu en mai 2026. Le report change l’échéance ; il ne change pas le travail à accomplir.
ISO/IEC 42001 comme couche opérationnelle
ISO/IEC 42001, publié en décembre 2023, est le premier standard de management system dédié à l’IA. Le standard répond à la question que le Règlement européen sur l’IA laisse en suspens : comment. Selon la cartographie publiée par l’ISACA en 2025, le standard se rattache directement à sept articles cœurs du règlement : gestion des risques (9), données et gouvernance des données (10), documentation technique (11), tenue de registres (12), transparence (13), supervision humaine (14) et systèmes de management de la qualité (17). Le chevauchement couvre une estimation de quarante à cinquante pour cent des exigences de haut niveau, ce qui signifie que les preuves produites pour un régime accélèrent le travail pour l’autre.
La fonction GOVERN du NIST AI RMF en détail
La fonction GOVERN du NIST AI RMF est le pont entre la culture de risque d’entreprise existante et la nouvelle bibliothèque de contrôles dédiée à l’IA. Elle définit les conditions culturelles, structurelles et procédurales qui permettent aux trois autres fonctions d’opérer. Elle reconnaît aussi explicitement que le risque IA est socio-technique : le framework demande aux organisations d’évaluer non seulement si un modèle fonctionne comme prévu, mais si son déploiement est compatible avec les valeurs et les obligations de son contexte d’usage.
Pourquoi l’IA expose les limites des outils GRC génériques
Trois propriétés des systèmes d’IA cassent les outils GRC génériques. Premièrement, l’actif change entre deux audits : un modèle réentraîné n’est plus le modèle que les preuves de contrôle précédentes décrivaient. Deuxièmement, les chaînes d’approvisionnement sont plus larges : un système déployé peut dépendre d’un modèle de fondation, d’un dataset de fine-tuning, d’une plateforme d’inférence, d’un feature store et d’une boucle de feedback, chacun détenu par une partie différente. Troisièmement, l’espace des conséquences est plus vaste : les défaillances vont des sorties biaisées aux actions autonomes qu’un humain n’a pas demandées. Un dispositif de conformité et de gouvernance bâti pour des services IT statiques a besoin d’une couche d’extension conçue pour ces propriétés.
Mettre en place la conformité et la gouvernance : un plan de démarrage à 90 jours
Les programmes matures se sont construits par incréments. Les premiers quatre-vingt-dix jours existent pour fixer l’architecture avant que l’inventaire ne grossisse.
Jours 0 à 30 : cartographier l’état actuel et inventorier les obligations
Construire d’abord l’inventaire des obligations. Lister les régulations, engagements contractuels, certifications et politiques de conseil qui contraignent l’organisation. Capturer le texte contraignant, le régulateur ou la contrepartie, la date d’entrée en vigueur et le dirigeant responsable. Lister ensuite les contrôles qui existent déjà, indépendamment de leur lieu de stockage actuel. La sortie est un registre à deux colonnes : obligations et contrôles existants, avec les manques et les orphelins visibles.
Jours 31 à 60 : instancier l’architecture des contrôles pour deux obligations pilotes
Choisir deux obligations qui comptent. L’une sur un terrain connu (une clause SOX, RGPD ou ISO 27001) ; l’autre spécifique à l’IA (un article du Règlement européen sur l'IA ou une clause d’ISO/IEC 42001). Construire la chaîne à quatre maillons complète pour chacune : obligation, contrôle, preuve, assurance. Chronométrer le travail. La première chaîne prend en général une semaine ; la deuxième prend deux jours. Ce ratio est la preuve de concept sur laquelle le reste du programme se construira.
Jours 61 à 90 : définir la cadence des preuves et la boucle d’assurance
Décider à quelle fréquence chaque contrôle produit ses preuves, qui les passe en revue, et ce qui déclenche une exception. Inscrire la cadence dans l’agenda de l’équipe responsable, et définir le chemin qu’une exception emprunte avant d’arriver à l’ordre du jour du Comité Risques. Lancer le premier échantillon d’audit interne sur les deux contrôles pilotes avant le jour 90. À la fin de l’échantillon, l’organisation aura vécu un cycle complet de conformité et de gouvernance pour deux obligations et disposera des preuves pour passer le modèle à l’échelle.
La conformité et la gouvernance en pratique : une PME et un grand groupe
Le modèle opérationnel passe à l’échelle vers le bas comme vers le haut.
PME avec une obligation ISO 27001 et une obligation Règlement européen sur l’IA
Une fintech de 200 personnes équipée d’un seul modèle d’IA de détection de fraude peut faire tourner un programme crédible avec une dizaine de contrôles. La liste d’obligations est courte : ISO 27001 pour la sécurité de l’information, les articles pertinents du Règlement européen sur l'IA pour le système IA, les règles du superviseur local sur l’externalisation. La bibliothèque de contrôles hérite des preuves SOC 2 que l’entreprise produit déjà et ajoute trois contrôles spécifiques à l’IA : registre des risques modèles, validation de réentraînement, revue du seuil de monitoring post-déploiement.
Multinationale cartographiant SOX, RGPD, Règlement européen sur l’IA et règles sectorielles
Une banque internationale opère sur une autre échelle. Les preuves SOX sous-tendent la publication trimestrielle des résultats. Les contrôles RGPD protègent les données clients sur trente juridictions. Les contrôles Règlement européen sur l'IA couvrent le modèle de credit-scoring à haut risque et le filtrage des pratiques interdites sur la stack marketing. Des règles sectorielles, comme les lignes directrices EBA sur le model risk, se superposent à tout cela. La bibliothèque de contrôles compte des milliers d’éléments. L’architecture est la même que celle de la fintech : obligation, contrôle, preuve, assurance. Seul le volume change.
Questions fréquentes
Que signifient conformité et gouvernance ? La gouvernance fixe la direction que l’organisation s’engage à suivre, à travers chartes, politiques et délégations de pouvoir. La conformité produit les preuves que l’organisation est restée dans cette direction. Ensemble, elles forment le modèle opérationnel qui transforme les obligations externes en contrôles auditables et en artefacts que ces contrôles produisent. Quels sont les 4 P de la gouvernance ? Les 4 P le plus souvent cités dans la littérature sur la gouvernance publique et d’entreprise sont People (qui détient l’autorité et la responsabilité), Purpose (la mission ou les objectifs auxquels l’organisation s’engage), Process (comment les décisions sont prises et revues) et Performance (comment les résultats sont mesurés et restitués). La liste exacte varie selon les sources ; le fond ne change pas. Les référentiels de gouvernance réussissent quand ils rendent les quatre explicites et leurs relations auditables. Quelles sont les 4 phases de la conformité ? Un cycle de conformité passe en général par quatre phases : Identifier l’obligation et son périmètre ; Mettre en œuvre les contrôles qui satisfont l’obligation ; Surveiller les contrôles pour détecter rapidement les écarts ; Restituer les preuves auprès des audiences internes et externes. Chaque phase produit des artefacts dont la suivante dépend. Les programmes qui sautent les phases de surveillance et de restitution produisent des politiques, pas de l’assurance. Quels sont les 3 C de la conformité ? Les 3 C le plus souvent cités sont Culture, Communication et Contrôles. La culture façonne les décisions du quotidien quand personne ne regarde. La communication maintient la visibilité des obligations auprès de ceux dont le travail les touche. Les contrôles sont les comportements et artefacts qui traduisent la politique en preuves. Les trois se renforcent mutuellement ; une organisation qui n’investit que dans les Contrôles, sans Culture ni Communication, reconstruira les mêmes manques à chaque audit. La GRC est-elle la même chose que conformité et gouvernance ? Presque. La GRC est un sur-ensemble qui ajoute la gestion des risques comme troisième pilier. La conformité et la gouvernance décrivent les moitiés direction-et-preuves du modèle ; la gestion des risques est la fonction qui décide quelles obligations et quels contrôles méritent le plus d’attention. La plupart des référentiels modernes les traitent comme inséparables, raison pour laquelle OCEG, NIST et ISO 42001 les câblent ensemble. ISO 42001 est-elle obligatoire au titre du Règlement européen sur l’IA ? Non. La certification ISO/IEC 42001 n’est pas exigée par la loi au titre du Règlement européen sur l'IA. Les deux sont conçues pour se compléter. Le règlement dit aux organisations régulées ce qu’elles doivent atteindre ; le standard décrit comment faire tourner, prouver et améliorer en continu un programme de gouvernance IA d’une manière qui satisfasse régulateurs, certificateurs et conseil. La certification 42001 ne prouve pas à elle seule la conformité au règlement, et la conformité au règlement n’exige pas la certification 42001. La plupart des organisations poursuivent les deux parce que le travail sous-jacent se recouvre à environ la moitié. AI Sigil remplace-t-il notre outil GRC existant ? Non. AI Sigil est conçu pour se placer au-dessus d’une pile GRC existante comme couche opérationnelle dédiée aux systèmes d’IA. Il utilise la même chaîne obligation, contrôle, preuve, assurance, puis connecte le côté preuve directement au cycle de vie des modèles IA, de sorte qu’un événement de réentraînement déclenche automatiquement les revues de contrôle concernées. L’outil GRC existant continue de porter la bibliothèque de contrôles d’entreprise ; AI Sigil détient l’extension spécifique à l’IA et alimente les preuves en retour.
Conclusion
La conformité et la gouvernance forment un seul modèle opérationnel, pas deux domaines. Les référentiels que les SERP répètent en juxtapositions de définitions rejouent en fait la même architecture : gouverner d’abord, puis décliner jusqu’aux contrôles, aux preuves et à l’assurance. La fonction GOVERN du NIST CSF 2.0, l’ISO/IEC 42001 et le Règlement européen sur l'IA n’ont pas inventé cette architecture ; ils l’ont ratifiée pour l’ère IA. Le travail des responsables de la gouvernance aujourd’hui consiste à reconnaître cette forme unifiée et à cesser d’entretenir des programmes parallèles qui produisent des preuves en doublon et des décisions contradictoires. Le chemin le plus court entre la situation actuelle de la plupart des organisations et l’attente actuelle des régulateurs et des conseils est de construire une seule chaîne à quatre maillons, de la prouver sur deux obligations, puis de passer l’architecture à l’échelle sur le reste de l’inventaire. Pour voir à quoi ressemble cette couche opérationnelle appliquée spécifiquement aux systèmes d’IA, la plateforme AI Sigil a été conçue pour s’imbriquer au-dessus de la pile GRC que vous opérez déjà.