PILIER · GOUVERNANCE DE L'IA
Direct answer
La gouvernance de l'IA regroupe les rôles, politiques, contrôles et pratiques de preuve qu'une organisation utilise pour maintenir ses systèmes d'IA conformes, sûrs et responsables tout au long de leur cycle de vie. C'est une discipline opérationnelle continue, et non une loi ou un certificat ponctuel. Des normes comme l'ISO 42001 et le NIST AI RMF lui donnent une structure ; des réglementations comme l'AI Act fixent des obligations. L'intégrer dans votre programme de conformité existant, plutôt que dans un silo parallèle, permet de capitaliser sur le travail au lieu de le dupliquer.
La gouvernance de l'IA consiste à définir qui est responsable d'un système d'IA, ce qu'il est autorisé à faire, comment vous vérifiez qu'il continue de le faire, et quelles preuves vous pouvez produire lorsqu'on vous interroge. Elle couvre les modèles que vous entraînez, les outils que vous achetez, les fonctionnalités que vous activez dans des logiciels existants, et l'IA exécutée par vos prestataires pour votre compte. Elle s'applique sur tout le cycle de vie : décision de construire ou d'acquérir, données en entrée, tests avant mise en production, supervision humaine en exploitation, surveillance des dérives et des usages détournés, et traçabilité complète. Le terme gouvernance est essentiel. Il ne s'agit pas d'une évaluation ponctuelle ni d'un certificat affiché au mur. C'est la discipline permanente qui maintient les réponses à jour alors que les systèmes et les règles évoluent.
Trois évolutions se sont produites simultanément. Les régulateurs ont adopté des lois spécifiques à l'IA, notamment l'AI Act, en les superposant aux obligations existantes en matière de protection des données, de sécurité et de résilience opérationnelle. Les organismes de normalisation ont publié des cadres structurants, de sorte que la gouvernance de l'IA n'est plus une question d'opinion. Et l'IA a cessé d'être un projet de laboratoire : elle apparaît dans le recrutement, le scoring crédit, le support client et le code, souvent achetée et activée par des équipes qui n'ont pas informé la sécurité ou le juridique. Cette dernière dimension, parfois appelée shadow AI, explique pourquoi l'inventaire de ce que vous exploitez réellement est désormais la première question pertinente, et non la dernière. La pression ne vient pas d'une seule loi. Elle vient du fait que le risque IA atterrit sur des fonctions qui gèrent déjà la protection des données, la sécurité et le risque tiers, et qui ont besoin d'un point unique pour en répondre.
Il est utile de distinguer trois types d'instruments, car ils remplissent des fonctions différentes. L'AI Act est une loi : il classe les usages de l'IA par niveau de risque, interdit un petit nombre de pratiques, impose des obligations substantielles aux usages à haut risque comme le recrutement, le scoring crédit et l'accès aux services essentiels, et ajoute des devoirs de transparence, notamment l'obligation d'informer lorsqu'une personne interagit avec une IA. Son calendrier a été modifié en 2026 par le Digital Omnibus de l'UE, qui a reporté plusieurs échéances à haut risque : vérifiez toujours le texte en vigueur plutôt que de vous fier à la mémoire. L'ISO/IEC 42001 est une norme de système de management certifiable : elle fournit la structure, un système de management de l'IA, pour opérer la gouvernance de manière reproductible et la démontrer. Le NIST AI Risk Management Framework est un cadre volontaire, largement utilisé comme vocabulaire commun pour identifier et traiter les risques liés à l'IA. Des règles sectorielles s'ajoutent aux trois, de sorte que les opérateurs financiers et d'infrastructures critiques intègrent la supervision de l'IA dans les régimes de résilience et de sécurité qu'ils pilotent déjà. Pour approfondir la voie certifiable, consultez notre guide sur la mise en place d'un système de management de l'IA et, pour la perspective commerciale, la certification ISO 42001.
Au-delà du vocabulaire, un programme de gouvernance de l'IA opérationnel repose sur un nombre limité d'éléments. Un inventaire, pour connaître chaque système d'IA en usage, y compris ceux achetés par d'autres équipes et ceux exécutés chez vos prestataires. Une méthode pour classer chaque système selon le préjudice potentiel, car un filtre anti-spam et un outil de recrutement ne méritent pas le même niveau de contrôle. Des politiques qui définissent ce qui est autorisé et qui valide. Une supervision humaine, pour qu'une personne, et non le modèle, porte les décisions à fort impact. Des tests avant mise en production et une surveillance continue, car un modèle équitable en mars peut dériver en septembre. Et une documentation qui transforme tout cela en preuves exploitables pour un auditeur, un régulateur ou votre propre conseil d'administration, sans précipitation de dernière minute. Rien de cela n'est exotique. C'est la même logique qu'un programme de contrôles, appliquée à l'IA.
C'est la distinction qui crée la confusion lors des appels d'offres. Une vague d'outils natifs IA excelle sur une tranche précise, généralement l'évaluation technique des modèles ou la documentation spécialisée exigée par l'AI Act. Ce travail est réel et, pour les équipes dont le métier est de gouverner des modèles à grande échelle, parfois le bon choix. Mais la plupart des organisations ne gouvernent pas l'IA en vase clos. Elles pilotent une quinzaine de référentiels simultanément, et l'IA s'ajoute aux obligations en protection des données, sécurité, risque tiers et continuité d'activité. Pour elles, la question n'est pas de savoir quel outil IA est le meilleur, mais si la gouvernance de l'IA vit dans le même système que le reste de leurs obligations, afin qu'un contrôle cartographié une fois apparaisse partout où il s'applique et que la chaîne de preuve ne se rompe pas à la frontière IA. Nous détaillons cette distinction dans la réponse sur le lien entre gouvernance de l'IA et GRC.
La bonne nouvelle : vous ne partez pas de zéro. Un programme de sécurité de l'information mature fournit déjà l'essentiel d'un système de management de l'IA : inventaires d'actifs, contrôle d'accès, gestion des changements, réponse aux incidents, supervision des fournisseurs. Si vous pilotez l'ISO 27001, une large part de ce travail se transpose vers l'ISO 42001 : la couche IA prolonge votre système de management existant plutôt que de le dupliquer. Lorsque l'IA traite des données personnelles, vos obligations de protection des données s'appliquent intégralement : protection des données pour l'IA et gouvernance de l'IA relèvent du même dialogue, pas de deux silos. Lorsque l'IA est intégrée à des systèmes financiers ou critiques, elle hérite des obligations de résilience opérationnelle et de gestion des risques cyber que vous portez déjà. Cartographier un contrôle une fois et le réutiliser sur l'ensemble de ces référentiels, plutôt que de le redémontrer référentiel par référentiel, est précisément l'intérêt d'intégrer la gouvernance de l'IA dans un programme multi-référentiels. Acuna prend en charge plus de 50 référentiels sur un socle unique pour cette raison.
Il existe une symétrie utile. Le même principe qu'exige une bonne gouvernance de l'IA de vos systèmes, à savoir qu'une personne porte les décisions à fort impact, est celui que nous appliquons lorsque l'IA vous aide à piloter le programme. L'assistant Acuna propose : il suggère comment un système d'IA pourrait être classé, rédige la documentation demandée par les normes, et signale les contrôles que vous détenez déjà et qui pourraient satisfaire une obligation IA. Une personne confirme. L'assistant ne décide jamais de votre classification de risque ni ne signe vos preuves à votre place. La piste d'audit reste défendable, ce qui est précisément l'objet du programme.
Commencez par l'inventaire, car vous ne pouvez pas gouverner ce que vous ne voyez pas, et la première passe révèle presque toujours des usages d'IA dont vous n'aviez pas connaissance. Classez ce que vous trouvez selon le préjudice potentiel, pour concentrer l'effort là où il compte. Orientez vos politiques et contrôles existants vers les systèmes d'IA concernés avant d'en rédiger de nouveaux, car l'essentiel de la couverture est déjà en place. Désignez un responsable de la gouvernance de l'IA : dans de nombreuses organisations, c'est le RSSI ; parfois un responsable IA dédié ; mais ce doit être une personne identifiée, et non un comité qui se réunit trimestriellement. Puis rendez le dispositif continu. Les systèmes changent, les prestataires changent, et, comme 2026 l'a montré, les règles changent aussi. Un programme qui produit des preuves à la demande, plutôt qu'en urgence avant un audit, fait la différence entre gouverner l'IA et simplement la documenter une fois.
EXPLORE
Une définition opérationnelle, le périmètre du terme, et la différence avec le simple fait de disposer d'une politique IA ou de principes énoncés.
Comment la gouvernance de l'IA s'intègre dans un programme multi-référentiels plutôt qu'à côté, et pourquoi cette distinction compte opérationnellement.
Les niveaux de risque de l'Acte, les obligations par niveau, et le calendrier révisé suite à l'amendement Digital Omnibus de l'UE.
La norme de système de management et la loi contraignante remplissent des fonctions différentes. Voici comment utiliser les deux sans dupliquer le travail.
Quand un outil natif IA est le bon achat, et quand il est plus pertinent d'intégrer la gouvernance de l'IA dans le programme GRC que vous pilotez déjà.
Les organisations qui peinent avec la gouvernance de l'IA sont généralement celles qui la traitent comme une discipline entièrement nouvelle. En pratique, la plupart des contrôles existent déjà dans leurs programmes de sécurité et de protection des données. Le travail consiste à les orienter vers l'IA et à maintenir un humain sur les décisions qui comptent, plutôt que d'acheter un second système à faire tourner en parallèle.
Alexis Hirschhorn, Auditeur principal ISO 42001
DÉMARRER
La gouvernance de l'IA fonctionne mieux lorsqu'elle n'est pas un silo séparé. Voyez comment les contrôles IA se cartographient aux côtés des plus de 50 référentiels que vous pilotez déjà, pour qu'un contrôle démontré une fois compte partout où il s'applique.