Plateforme de gouvernance de l’IA : capacités attendues et critères de choix

Le concept de gouvernance de l’intelligence artificielle est traité dans notre article sur gouverner données et IA dans un cadre unifié, et la démarche dans la méthode de mise en place en cinq étapes. Ici, on parle outil.

Le contexte a changé. Selon l’étude Cisco 2026 sur la confidentialité des données, menée auprès d’environ 5 200 professionnels dans le monde entier, la part d’organisations qui interdisent purement l’IA générative est passée de 28 % à 7 % en un an. L’interdiction freinait l’innovation sans supprimer l’usage, la gouvernance a pris le relais.

Une plateforme de gouvernance de l’IA tient le registre des systèmes d’IA au sein de l’entreprise, les relie aux données qu’ils consomment, applique les politiques internes et produit les preuves qu’un auditeur réclamera. Elle répond à quatre questions simples à poser, difficiles à documenter : quels systèmes d’IA tournent chez nous, sur quelles données, sous la responsabilité de qui, à quel niveau de risque.

• Une catégorie d’outil, pas une fonctionnalité : elle centralise l’inventaire des systèmes d’IA, leur classification par niveau de risque et les preuves associées, tout au long du cycle de vie.
• Huit capacités minimales : registre, portefeuille de cas d’usage, notation du risque, politiques et contrôles, documentation technique, journalisation, lignage des données, surveillance en production.
• Des frontières nettes : le catalogue de données, l’industrialisation des modèles, les suites de conformité et les passerelles d’IA alimentent la gouvernance, ils ne la remplacent pas. La plateforme les relie autour d’un inventaire unique.
• Une exigence de preuve : le règlement européen sur l’IA (AI Act), ISO/IEC 42001 et le NIST AI RMF demandent des artefacts documentés et datés. L’outil doit les produire par automatisation, pas à la main.
• Le shadow IA est le vrai test : un inventaire déclaratif ne voit que ce qu’on lui déclare. Les usages non déclarés se détectent par les traces techniques, pas par les formulaires.
• Un déploiement par vagues : périmètre restreint, cas d’usage à haute valeur, puis élargissement. La première vague se juge sur des gains rapides (quick wins), pas sur l’exhaustivité.

Ce qu’est une plateforme de gouvernance de l’intelligence artificielle

C’est le système d’enregistrement des activités d’IA d’une organisation. Chaque cas d’usage (use case) y possède une fiche : finalité, propriétaire métier, données consommées, modèles employés, niveau de risque, statut dans le cycle de vie, contrôles appliqués, décisions d’approbation. Cette fiche vit du besoin exprimé jusqu’au retrait du système.

Trois évolutions ont fait naître la catégorie. Le volume d’abord : les initiatives d’IA se multiplient à travers les directions métier, à grande échelle et sans point de convergence. La nature des modèles ensuite : un système génératif ne se surveille pas comme un modèle prédictif d’apprentissage automatique. La génération varie d’un appel à l’autre, ses données d’entraînement sont souvent opaques quand le modèle vient d’un tiers ou d’un dépôt open source, et un test unitaire n’en dit rien. La contrainte réglementaire enfin, qui fait passer la gouvernance de l’IA des bonnes pratiques aux obligations documentées, sujet que nous détaillons dans la mise en conformité avec l’AI Act.

Le sujet change donc de nature. La gouvernance ne porte plus seulement sur la donnée, mais sur les décisions automatisées prises à partir d’elle. Le tableur d’inventaire ne tient pas ce rôle : périmé dès sa publication, sans historique, il ne prouve rien. Construire un cadre de gouvernance reste indispensable, mais un cadre écrit ne produit aucune preuve par lui-même. C’est l’outillage qui transforme une politique en contrôle appliqué, et une ambition d’IA digne de confiance en dossier vérifiable.

Les capacités qu’une plateforme de gouvernance de l’IA doit couvrir

Une grille de comparaison utile tient en huit capacités. Un outil qui n’en couvre que trois ou quatre reste utile, mais laisse aux équipes la charge d’en garantir la maîtrise.

La supervision humaine se conçoit, elle ne se décrète pas

L’exigence de supervision humaine revient dans tous les cadres. Elle se traduit par trois éléments concrets : un point d’arrêt matérialisé dans le processus, une personne nommée qui peut valider ou bloquer, et la trace de ce qu’elle a vu au moment de trancher. Une case à cocher « revue humaine effectuée » ne satisfait aucun contrôle sérieux. La plateforme doit conserver l’élément soumis, la décision et son motif, de manière traçable.

Explicabilité, éthique et biais : ce que l’outil apporte vraiment

Une plateforme de gouvernance ne rend pas un modèle explicable à elle seule. Elle organise l’explicabilité selon un principe simple : elle exige un document de méthode, stocke les résultats des analyses d’équité, versionne les jeux de test et alerte quand une métrique sort de sa plage. La détection de biais reste l’affaire des experts data science ou d’un composant spécialisé. La gouvernance en garantit l’existence, la fraîcheur et la lisibilité par un lecteur non expert.

En quoi elle se distingue d’un catalogue de données, d’un MLOps, d’un GRC ou d’une passerelle IA

La catégorie est jeune, comme l’était celle de la plateforme de gouvernance de la valeur. Les offres qui s’en réclament viennent d’horizons différents : catalogues de données, plateformes d’industrialisation des modèles, suites de conformité, passerelles techniques. Elles ne couvrent pas le même périmètre. Une solution voisine achetée en pensant traiter la gouvernance de l’IA laisse le manque apparaître au premier audit.

La lecture utile est celle de l’orchestration des flux. La passerelle IA et le MLOps produisent les faits d’exécution. Le catalogue de données fournit le contexte des données et le glossaire métier. Le GRC porte le cadre de contrôle de l’entreprise. La plateforme de gouvernance consomme les trois, les rattache à un objet placé au centre, le système d’IA, et en tire une décision. Celle qui n’ingère rien et ne vit que de saisie manuelle reproduit le tableur, avec une interface plus agréable.

Exemples de cas d’usage courants, positionnés en valeur et en faisabilité

Toutes les briques ne se valent pas au démarrage. Ce tableau situe les cas d’usage les plus courants selon leur valeur pour l’entreprise et la difficulté réelle de mise en place, dans la logique décrite pour prioriser vos cas d’usage IA. Les niveaux sont des ordres de grandeur, à ajuster selon la maturité du système d’information.

Une stratégie s’en dégage. Commencer par l’inventaire et la classification, qui délivrent une valeur immédiate à faible coût. Installer ensuite la porte de validation, qui verrouille l’entrée de nouveaux systèmes non gouvernés. Le reste suit.

Ce que la réglementation exige de l’outil lui-même

Le règlement (UE) 2024/1689, dit AI Act, est entré en vigueur le 1er août 2024 et s’applique par étapes. Les interdictions visant les pratiques à risque inacceptable s’appliquent depuis février 2025, les obligations relatives aux modèles à usage général (GPAI, general-purpose AI) depuis août 2025. Les systèmes à haut risque relèvent d’un calendrier distinct : le règlement (UE) 2026/1744, entré en vigueur le 27 juillet 2026, a reporté leur application au 2 décembre 2027 pour les cas d’usage de l’annexe III, et au 2 août 2028 pour les systèmes intégrés à des produits déjà réglementés (annexe I). Les obligations de transparence, elles, ne sont pas reportées : elles s’appliquent depuis le 2 août 2026.

La réglementation ne prescrit nulle part l’achat d’une plateforme de gouvernance. Elle n’impose pas davantage un inventaire général des systèmes d’IA : ses obligations sont ciblées, documentation technique, enregistrement en base européenne, journaux conservés six mois par le déployeur. L’appui le plus explicite en faveur de l’inventaire est normatif. Le NIST AI RMF demande, en sous-catégorie GOVERN 1.6, que des mécanismes d’inventaire des systèmes d’IA soient en place et dotés de ressources proportionnées aux priorités de risque. Le règlement impose des résultats documentés, et ces résultats déterminent les fonctions attendues de l’outil. Santé, secteur public et ressources humaines sont les domaines les plus exposés.

Trois référentiels complètent le règlement. La norme ISO/IEC 42001 définit un système de management de l’IA : politique, rôles, objectifs, amélioration continue. C’est le cadre qui ouvre la voie à une certification. ISO/IEC 23894 donne des lignes directrices sur la gestion du risque appliquée à l’IA. Le NIST AI RMF, cadre volontaire publié aux États-Unis, propose quatre fonctions : gouverner, cartographier, mesurer, gérer. Leurs exigences se recoupent largement, ce qui rend une mise en œuvre conjointe réaliste. Une plateforme sérieuse rattache un même contrôle à plusieurs cadres sans dupliquer la saisie. Le critère d’achat est mesurable : demandez à voir la table de correspondance entre référentiels, pas une déclaration de compatibilité.

Deux précisions évitent un contresens fréquent en phase d’achat. La certification ISO/IEC 42001 porte sur le système de management de l’organisation, pas sur le produit : un éditeur certifié ne démontre pas que son logiciel vous met en conformité. Et cette norme n’est pas une norme harmonisée de l’AI Act. Le Centre commun de recherche de la Commission européenne la juge non alignée sur les objectifs et l’approche du règlement. La norme européenne dédiée, EN 18286, a été publiée le 31 juillet 2026, mais sa référence n’est pas encore citée au Journal officiel de l’Union européenne : à ce jour, aucune norme ne confère de présomption de conformité à l’AI Act.

Trois conséquences pèsent en matière de conception de l’outil : journalisation, export et transparence.

• Journaux horodatés et conservés : le règlement impose l’enregistrement automatique des événements sur la durée de vie des systèmes à haut risque. Les champs libres modifiables sans trace sont donc exclus.
• Documentation exportable : le dossier technique doit pouvoir être présenté aux autorités dans un format lisible hors de la plateforme. Un dossier réglementaire enfermé dans une base propriétaire est un risque contractuel, pas un actif.
• Transparence datée : l’information due aux personnes exposées au système, et leurs droits, supposent de conserver la formulation exacte employée, et sa date.

La confiance d’un auditeur se gagne sur des artefacts, jamais sur des déclarations d’intention.

Comment gérer le shadow IA, que l’inventaire ne voit pas

Le shadow IA (shadow AI, usages non déclarés) est l’angle mort structurel de la gouvernance. Un collaborateur qui colle un extrait de contrat dans un assistant grand public transfère des données hors du cadre, sans passer par aucun formulaire. Une équipe qui appelle une API de modèle depuis un compte cloud de projet crée un système d’IA qui n’apparaît nulle part. Un agent autonome y échappe aussi, et ces agents se multiplient.

Le phénomène est mesuré. Le rapport IBM Cost of a Data Breach 2026, mené auprès de 602 organisations, établit que 43 % des incidents de sécurité impliquent désormais le shadow IA, contre 20 % l’année précédente, et que 68 % des organisations concernées n’avaient aucun dispositif de gouvernance de l’IA pour le détecter.

Le déclaratif seul ne suffit pas. Il se complète par quatre sources techniques que la plateforme doit savoir ingérer.

• Le proxy web et le pare-feu : ils révèlent les domaines de services d’IA consultés depuis le réseau, avec les volumes d’utilisation.
• Le SSO et l’annuaire : les autorisations accordées aux applications tierces montrent quels outils et quelles technologies ont obtenu un accès aux données internes.
• Les dépenses cloud et SaaS : une ligne de facturation d’API de modèle signale une utilisation productive, souvent avant sa déclaration.
• Les dépôts de code et les plateformes d’intégration : les clés d’API et les appels aux fournisseurs de modèles y sont visibles.

Reste à ouvrir une voie de régularisation avant de mesurer. Un usage détecté puis sanctionné produit une seule chose : un shadow IA mieux caché. Un usage détecté puis instruit en quelques jours, avec une décision claire, aide les équipes à revenir au circuit officiel. La menace est autant organisationnelle que technologique. La confiance dans le dispositif conditionne sa complétude, davantage que la finesse de la détection.

Comment l’intégrer au système d’information existant

Une plateforme de gouvernance de l’IA n’a pas de valeur isolée. Sa qualité dépend de ce qu’elle sait lire dans son environnement. Six points d’intégration comptent.

• Le catalogue de données et le glossaire métier : ils fournissent la définition partagée des objets et la classification de sensibilité. Sans intégration, la fiche du système d’IA décrit ses données en texte libre, donc de manière inexploitable.
• Le lignage : c’est la brique essentielle pour garantir une réponse à « quelles données ont servi à entraîner ce modèle, et où ses sorties sont-elles réutilisées ». La finesse compte, et DataGalaxy documente notamment le lignage au niveau colonne, granularité nécessaire pour tracer un attribut sensible dans un jeu d’entraînement.
• Le MLOps et le registre de modèles : versions, métriques et dates de déploiement remontent automatiquement grâce aux connecteurs, plutôt que d’être ressaisies.
• La passerelle IA : elle applique les politiques décidées en gouvernance et renvoie les journaux d’appel. La politique se définit d’un côté, l’opération s’exécute de l’autre.
• L’IAM (identity and access management, gestion des identités et des accès) : les rôles existants évitent de recréer une gestion des accès parallèle, source d’écarts de sécurité.
• Les outils de travail : ticketing, messagerie d’équipe, suites bureautiques. Une approbation qui exige de se connecter à un portail dédié sera contournée.

Un test simple révèle la maturité d’une solution et de ses intégrations : demandez comment elle réagit quand une source amont change de schéma. Une plateforme robuste détecte l’écart, marque les fiches affectées, déclenche une revue et permet de suivre la correction. Une plateforme fragile continue d’afficher une information devenue fausse, ce qui est pire que l’absence d’information.

Quels critères d’évaluation utiliser avant de choisir

Les démonstrations d’outils de gouvernance se ressemblent toutes. L’analyse les départage sur huit critères, chacun avec une question à poser et un signal d’alerte à guetter.

Ce que le report du Digital Omnibus ne dispense pas de faire

Le report des obligations haut risque à décembre 2027 est souvent lu comme un répit. C’est un contresens coûteux. Les obligations décalées sont précisément celles qu’une plateforme instrumente : gestion des risques, gouvernance des données d’entraînement, documentation technique, journalisation, contrôle humain, obligations respectives du fournisseur et du déployeur. Aucune ne se met en place en quelques semaines, car chacune suppose un inventaire fiable à maintenir et un historique de preuves qui, par définition, se constitue dans la durée.

Deux tâches restent immédiates. Classer les systèmes existants, puisqu’on ne peut pas savoir ce qui relèvera du haut risque sans les avoir inventoriés. Et instrumenter les obligations déjà applicables, interdictions, littératie et transparence, qui ne bénéficient d’aucun report. L’enquête 2026 de Grant Thornton auprès de 950 dirigeants donne la mesure du retard : 78 % ne se disent pas confiants dans leur capacité à passer un audit indépendant de gouvernance de l’IA en 90 jours.

Un dernier critère, moins visible : la vitesse de mise en service. Un outil qui exige plusieurs trimestres de paramétrage avant son premier rapport aura consommé son crédit politique avant d’avoir démontré sa valeur. Demandez à voir un client comparable en production, ses meilleures pratiques, et ce qu’il obtenait au bout du premier trimestre.

Par quelles étapes déployer

La mise en œuvre échoue rarement pour des raisons techniques, le défi est ailleurs. Elle échoue quand la gouvernance arrive comme une contrainte administrative sans impact sur des équipes déjà engagées. Un programme d’action en quatre vagues limite ce risque.

La répartition des responsabilités se fixe dès le cadrage, avec les dirigeants. Le CDO (chief data officer, directeur des données) porte la stratégie et arbitre le portefeuille. Le DPO (délégué à la protection des données) traite l’articulation avec la protection des données personnelles. Le data steward (référent de la donnée) garantit la qualité et la définition des données consommées. Le RSSI couvre la sécurité des modèles et des accès. Le responsable métier reste propriétaire de son cas d’usage : lui seul connaît la finalité réelle du système, donc lui seul peut en donner une classification honnête.

Deux erreurs reviennent souvent. Lancer une preuve de concept (POC) technique sans décision de gouvernance derrière : l’outil fonctionne, personne ne l’utilise. Viser l’exhaustivité de l’inventaire avant d’installer le moindre contrôle : pendant ce temps, de nouveaux systèmes entrent en production hors cadre. Mieux vaut un périmètre partiel réellement gouverné qu’un inventaire complet sans conséquence. La gouvernance ne freine pas l’innovation, elle pose des garde-fous. Structurer très tôt un portefeuille de cas d’usage IA donne à la direction la vue d’arbitrage nécessaire dès le démarrage.

Vers une gouvernance Data et IA intégrée et transversale

La séparation entre gouvernance des données et gouvernance de l’IA ne tient pas à l’usage. Un modèle est un consommateur de données comme un autre, avec des exigences supplémentaires. Les mêmes objets reviennent des deux côtés : propriétaire, définition métier, classification de sensibilité, lignage, politique d’accès, qualité. Faute de gouvernance transversale, deux dispositifs distincts produisent deux inventaires qui divergent, deux glossaires contradictoires et deux réponses à la même question d’audit.

L’effet du dispositif se mesure. Selon une enquête Gartner menée auprès de 360 organisations au deuxième trimestre 2025, celles qui ont déployé une plateforme de gouvernance de l’IA sont 3,4 fois plus susceptibles d’atteindre un niveau élevé d’efficacité dans leur gouvernance de l’IA.

Le marché va vers une architecture unique, où le système d’IA devient un objet de plus dans un référentiel qui contient déjà les données, les traitements et les responsabilités. L’intérêt est opérationnel avant d’être conceptuel : la classification de sensibilité posée sur une table se propage au modèle qui la consomme, et l’incident sur une source sensible remonte jusqu’aux décisions qui en dépendent.

C’est la logique que suit DataGalaxy, en permettant de piloter politiques et responsabilités sur un référentiel commun, et de piloter votre portefeuille data et IA depuis la même vue. Le choix d’un outil se juge au-delà de la démonstration : sur sa capacité à faire tenir les données et l’IA dans un seul récit, compréhensible par un directeur métier comme par un auditeur.

Points clés à retenir

• La plateforme est un système d’enregistrement, pas un tableau de bord : elle tient l’inventaire des systèmes d’IA, leur classification et leurs preuves sur tout le cycle de vie.
• Huit capacités font la différence : registre, portefeuille de cas d’usage, notation du risque, politiques et contrôles, documentation technique, journalisation, lignage, surveillance de la dérive et des biais.
• Les outils voisins ne suffisent pas : le catalogue de données, le MLOps, le GRC et la passerelle IA alimentent la gouvernance, ils ne la remplacent pas.
• Le contrôle se joue sur les artefacts : journaux horodatés et conservés, documentation exportable, correspondance entre AI Act, ISO/IEC 42001, ISO/IEC 23894 et NIST AI RMF.
• Le shadow IA se traite par les traces : proxy, SSO, dépenses cloud et dépôts de code, avec une voie de régularisation rapide plutôt qu’une sanction.
• Un déploiement se juge sur sa première vague : périmètre restreint, inventaire fiable, porte de validation active, avant toute ambition d’exhaustivité.

La maturité d’un dispositif se mesure à une chose : le temps qu’il faut pour répondre, preuves à l’appui, à une question posée sur un système d’IA en production.

À propos de l'auteur: Max Faivre

Product Marketing Manager