Gouvernance de l’IA : construire une politique et un registre utiles, pas une bureaucratie de plus

Les entreprises répondent souvent à l’arrivée de l’IA par une charte de quelques pages : ne pas partager de données confidentielles, vérifier les résultats et respecter le droit. Ces règles sont nécessaires, mais elles ne permettent pas de savoir quels systèmes sont utilisés, qui décide, quelles versions sont en production ni si les risques sont réellement surveillés.

À l’inverse, un programme trop lourd pousse les équipes à contourner le processus. La gouvernance doit donc être proportionnée : légère pour un assistant de rédaction sans donnée sensible, exigeante pour un agent connecté au système d’information ou une décision concernant des personnes.

La gouvernance doit être adaptée au contexte de l’organisation et rapprochée de ses obligations juridiques, contractuelles, sectorielles et de sécurité.

La gouvernance n’est pas un comité

Un comité peut arbitrer, mais il ne constitue pas à lui seul un système de management. Une gouvernance opérationnelle répond en permanence à six questions :

1. quels systèmes existent ;
2. qui en est responsable ;
3. quels usages sont autorisés ;
4. quelles preuves soutiennent la décision ;
5. quels changements ont eu lieu ;
6. quand faut-il réévaluer ou arrêter.

Elle s’intègre aux processus déjà présents : achat, sécurité, protection des données, architecture, développement, contrôle interne, ressources humaines et gestion des incidents.

Définir un périmètre clair

Le terme « système d’IA » doit être traduit dans le langage de l’entreprise. Le registre peut inclure :

• modèles développés en interne ;
• API externes ;
• fonctions IA d’un SaaS ;
• RAG documentaires ;
• agents et automatisations ;
• outils de génération de contenus ;
• assistants de développement ;
• modèles embarqués ;
• expérimentations utilisant des données réelles.

Un simple moteur de règles n’a pas nécessairement besoin du même circuit. L’objectif n’est pas de gonfler artificiellement le registre, mais de couvrir les systèmes dont le comportement, les données ou l’autonomie créent un risque particulier.

Écrire une politique qui aide à décider

Une politique utile tient sur quelques principes compréhensibles, complétés par des procédures. Elle précise :

• les usages librement autorisés ;
• les outils approuvés ;
• les données interdites ou conditionnelles ;
• les usages nécessitant une revue ;
• les décisions qui restent humaines ;
• les règles de transparence ;
• la propriété des contenus et du code ;
• les exigences de sécurité ;
• le signalement des erreurs et incidents ;
• les sanctions ou mesures en cas de contournement volontaire.

Les exemples concrets sont plus utiles qu’une formule générale. « Ne pas envoyer de données personnelles » est souvent impraticable. Mieux vaut distinguer données publiques, internes, confidentielles, secrets, données personnelles courantes et données sensibles, puis associer à chaque niveau les environnements autorisés.

Le registre minimal viable

Le registre commence avec un nombre limité de champs obligatoires :

• identifiant et nom ;
• description de la finalité ;
• propriétaire métier ;
• propriétaire technique ;
• statut du cycle de vie ;
• utilisateurs et personnes affectées ;
• fournisseur, modèle et version ;
• données utilisées ;
• systèmes connectés ;
• niveau d’autonomie ;
• risques principaux ;
• évaluations disponibles ;
• décision et conditions ;
• date de prochaine revue.

Il doit accepter l’incertitude. Une valeur « version inconnue » est préférable à un champ vide, car elle déclenche une action. La qualité du registre se mesure à sa capacité à révéler les inconnues et non à son apparence parfaite.

Classer les usages par niveau de contrôle

Une classification interne simple facilite la proportionnalité.

Niveau 1 : assistance sans donnée sensible

Rédaction, traduction ou idéation à partir de contenu public, sans décision significative. Contrôles : outil approuvé, formation, revue humaine et règles de propriété.

Niveau 2 : données internes ou recommandation métier

Résumé de documents internes, aide à l’analyse ou recherche augmentée. Contrôles supplémentaires : contrat, accès, rétention, évaluation, sources et suivi des erreurs.

Niveau 3 : action ou impact important

Agent connecté, automatisation d’un processus, recommandation influençant une personne ou utilisation de données sensibles. Contrôles renforcés : analyse d’impact, sécurité, approbation, supervision, logs, recours, tests adverses et plan d’incident.

Niveau 4 : usage interdit, réglementé ou critique

Le projet est bloqué jusqu’à qualification par les rôles compétents et mise en place des exigences spécifiques.

Cette échelle interne ne remplace pas les classifications légales. Elle sert à orienter le processus.

Mettre en place des portes de décision

Le cycle de vie comprend au minimum quatre passages.

Idée vers expérimentation

Vérifier finalité, propriétaire, outil, données autorisées et environnement isolé. Un POC ne doit pas recevoir automatiquement les accès de production.

Expérimentation vers pilote

Exiger un jeu d’évaluation, des résultats, une analyse des erreurs, la cartographie des données, les coûts et une première revue sécurité/RGPD.

Pilote vers production

Valider seuils, monitoring, responsabilité, support, contrat, reprise, documentation utilisateur, supervision humaine et plan de retrait.

Production vers changement majeur

Une nouvelle version de modèle, un nouvel outil, une autre population ou un droit d’écriture supplémentaire déclenche une réévaluation ciblée.

Chaque porte produit une décision datée : approuvé, approuvé sous conditions, refusé ou informations complémentaires.

Répartir les responsabilités

Le propriétaire métier répond de la finalité, de l’usage et des résultats attendus. Le propriétaire technique répond de l’architecture, des versions, des intégrations et de l’exploitation. Le DPO, la sécurité, le juridique et le contrôle interne interviennent selon le risque.

Le comité IA ne doit pas examiner chaque prompt. Il arbitre les cas complexes, définit les niveaux, suit les incidents et tranche les exceptions. Les cas standards suivent un parcours automatisé ou délégué.

Un RACI type précise qui :

• propose ;
• évalue ;
• approuve ;
• déploie ;
• surveille ;
• informe les personnes ;
• gère les incidents ;
• décide du retrait.

Organiser les preuves

Chaque entrée du registre pointe vers les documents, pas vers une simple case « conforme ». Les preuves comprennent :

• fiche du fournisseur ;
• contrat et sous-traitants ;
• architecture et flux ;
• analyses AI Act/RGPD/sécurité ;
• jeu d’évaluation ;
• rapport de résultats ;
• modèle de supervision ;
• notices et parcours ;
• décisions ;
• incidents ;
• historique de version.

L’organisation peut s’inspirer d’ISO/IEC 42001 pour structurer leadership, risques, cycle de vie, mesure et amélioration continue, sans prétendre être certifiée si elle ne l’est pas.

Gouverner les changements

Un système d’IA évolue parfois sans déploiement de code : le fournisseur remplace un modèle, modifie un filtre, augmente une fenêtre de contexte ou ajoute une mémoire. Le contrat et la supervision doivent permettre de détecter ces changements.

Définir les événements qui déclenchent une revue :

• nouvelle version ;
• nouvelle donnée ;
• nouvelle population ;
• nouvelle action ;
• baisse de qualité ;
• incident ;
• évolution réglementaire ;
• fin de support ;
• changement de sous-traitant.

Un journal relie l’événement à la décision et aux tests effectués.

Mesurer la gouvernance

Les indicateurs utiles ne sont pas le nombre de réunions ou de pages produites. Suivre plutôt :

• pourcentage de systèmes avec propriétaire ;
• proportion de versions connues ;
• couverture des évaluations ;
• délais de traitement des demandes ;
• nombre d’exceptions expirées ;
• incidents par niveau ;
• systèmes sans revue récente ;
• actions de remédiation en retard ;
• usages détectés hors registre ;
• temps de retrait ou de rollback.

Ces métriques révèlent la capacité réelle à contrôler le portefeuille.

Gérer les exceptions sans créer une porte dérobée

Une exception contient une justification, un périmètre, un propriétaire, des mesures compensatoires et une date d’expiration. Elle ne se renouvelle pas automatiquement.

Par exemple, un test limité peut utiliser un fournisseur non standard avec des données synthétiques, un environnement séparé et une suppression vérifiée. L’exception n’autorise pas le passage silencieux en production.

Relier gouvernance et expérience utilisateur

La gouvernance se matérialise dans le produit : messages de transparence, sources, possibilité de corriger, consentements si nécessaires, contrôle humain, historique et recours. Elle n’est pas seulement un travail de back-office.

Les retours utilisateurs alimentent le registre : erreurs récurrentes, incompréhensions, biais, abandon ou contournements. Un système « conforme sur le papier » mais inutilisable crée ses propres risques.

Démarrer petit, mais avec un modèle extensible

Une entreprise peut commencer en six semaines :

1. nommer un responsable ;
2. inventorier les vingt usages les plus visibles ;
3. adopter trois ou quatre niveaux de contrôle ;
4. définir les portes de décision ;
5. créer une fiche registre versionnée ;
6. traiter les cinq risques prioritaires ;
7. intégrer l’achat et la sécurité ;
8. publier une politique simple ;
9. former les équipes ;
10. mesurer et ajuster.

Partitech peut concevoir le registre, automatiser les workflows, connecter les preuves et intégrer les contrôles au cycle de développement. Une bonne gouvernance n’empêche pas l’expérimentation : elle permet de savoir où l’on expérimente, avec quelles limites et qui est responsable de la suite.

Parlons de votre projet

Concevoir un système de gouvernance IA proportionné et intégré à vos processus avec Partitech. Contactez Partitech.