L’IA ne se contente plus de produire du texte ou de résumer des documents. Avec les agents capables d’appeler des outils, de modifier des données ou de déclencher des actions, elle commence à agir dans le système d’information. Cette évolution change la nature du risque : une erreur ne reste plus nécessairement confinée à une réponse incorrecte.
La gouvernance de l’IA devient donc une fonction opérationnelle, et non une simple charte éthique. Elle doit attribuer les responsabilités, encadrer les accès, documenter les décisions et fournir des preuves exploitables en cas d’incident ou de contrôle. Le calendrier européen renforce cette urgence : certaines obligations s’appliquent déjà, tandis que les exigences liées aux systèmes à haut risque de l’annexe III entreront en vigueur le 2 décembre 2027.
L’IA passe du logiciel qui répond au système qui agit
La gouvernance devient indispensable lorsque l’IA peut intervenir directement dans les processus de l’entreprise. Un chatbot qui reformule un texte ne présente pas le même profil qu’un agent autorisé à envoyer un message, supprimer un fichier, modifier une commande ou acheter un service.
Cette différence impose de traiter l’IA comme un composant du système d’information. Son périmètre d’action, ses données d’entrée, ses outils et ses conditions d’arrêt doivent être définis avant la mise en production.
Un agent opérationnel devrait notamment être soumis à plusieurs contrôles :
- des droits limités au strict nécessaire ;
- une séparation entre lecture et écriture lorsque le processus le permet ;
- une validation humaine pour les actions sensibles ;
- un journal des requêtes, outils appelés et résultats obtenus ;
- un mécanisme d’arrêt accessible et testé ;
- une procédure de retour arrière en cas d’erreur.
À retenir : une charte décrit des principes, mais elle ne suffit pas à contrôler un système qui peut agir. Les permissions, les journaux et l’arrêt d’urgence doivent être intégrés dans l’architecture.
La question centrale n’est donc plus seulement « l’IA produit-elle une réponse correcte ? ». Elle devient : « que peut-elle faire, avec quelles données, sous quelle responsabilité et avec quelle possibilité de contrôle ? »
Un responsable unique évite la gouvernance sans propriétaire
La gouvernance échoue lorsque les responsabilités sont dispersées entre la direction des systèmes d’information, la cybersécurité, les métiers, les achats et les fournisseurs. Chacun peut posséder une partie du sujet, mais l’entreprise doit désigner un responsable final capable d’arbitrer les usages et d’imposer des règles communes.
Ce rôle peut être rattaché à une direction existante ou organisé dans une structure transverse. L’essentiel est de définir clairement son mandat : validation des cas d’usage, classification des risques, contrôle des fournisseurs, suivi des incidents et pilotage des mesures correctives.
Une répartition efficace distingue au moins quatre responsabilités :
- la direction, qui fixe le niveau de risque acceptable et finance les contrôles ;
- la DSI, qui encadre l’architecture, les intégrations et les accès ;
- la cybersécurité, qui évalue les menaces, les fuites de données et les abus de privilèges ;
- les métiers, qui valident la finalité, les données utilisées et les conséquences opérationnelles.
Les fournisseurs doivent également être intégrés au dispositif. Un contrat d’IA ne devrait pas être évalué uniquement sur son prix ou ses performances commerciales. L’entreprise doit examiner les modalités de conservation des données, la localisation des traitements, les sous-traitants, les logs disponibles et les procédures de notification d’incident.
Une gouvernance utile commence par un inventaire
Le premier outil concret est un registre des systèmes d’IA. Il doit identifier les modèles, les applications, les équipes utilisatrices, les données traitées et les actions possibles. Sans cette cartographie, l’entreprise ne sait pas quelles applications sont déjà en service ni quelles informations circulent vers des services externes.
Le registre peut associer à chaque usage une fiche comprenant :
- le propriétaire métier ;
- le responsable technique ;
- la finalité ;
- les catégories de données traitées ;
- les utilisateurs autorisés ;
- les outils accessibles ;
- le niveau de risque ;
- les contrôles requis ;
- la date de dernière revue.
Cette documentation transforme un sujet abstrait en portefeuille pilotable. Elle permet aussi de prioriser les efforts : un outil de synthèse interne n’appelle pas les mêmes contrôles qu’un système qui influence une décision concernant un salarié, un candidat ou un client.
Le calendrier européen rend la conformité immédiate
L’AI Act ne se limite pas aux systèmes à haut risque. Depuis le 2 février 2025, les organisations qui utilisent l’IA doivent mettre en place une formation suffisante du personnel et interdire les pratiques prohibées prévues par le règlement.
Cette échéance concerne donc déjà les entreprises qui déploient des outils d’IA, y compris lorsque leurs usages ne relèvent pas encore des obligations les plus lourdes. La formation ne doit pas être réduite à une présentation générale des modèles : elle doit couvrir les limites, les erreurs possibles, la protection des données et les règles internes d’utilisation.
Les principales échéances à intégrer dans une feuille de route sont les suivantes :
| Échéance | Sujet | Conséquence pour l’entreprise |
|---|---|---|
| 2 février 2025 | Interdiction des pratiques prohibées et obligation de développer la maîtrise de l’IA | Former les personnes concernées et bloquer les usages interdits |
| 2 décembre 2027 | Obligations applicables aux systèmes à haut risque de l’annexe III | Organiser la gestion des risques, la surveillance, la documentation et la traçabilité |
| 2 août 2028 | Obligations pour les systèmes à haut risque liés à certains produits réglementés | Préparer les contrôles de conformité associés aux produits concernés |
Les systèmes de l’annexe III couvrent notamment la biométrie, les infrastructures critiques, l’éducation, l’emploi, les services essentiels, le maintien de l’ordre, la migration et la justice ou les processus démocratiques. Cette classification est particulièrement importante pour les ressources humaines : les systèmes utilisés pour le recrutement, la sélection ou certaines décisions liées à la relation de travail peuvent relever du haut risque.
Pour ces systèmes, les obligations comprennent notamment un système de gestion des risques sur tout le cycle de vie, des exigences concernant les données, une documentation technique et des mécanismes de surveillance. Les entreprises qui attendent 2027 pour commencer à structurer ces éléments risquent de devoir reconstruire dans l’urgence des historiques, des procédures et des contrôles difficiles à improviser.
Les agents autonomes imposent une gouvernance technique
Les agents d’IA ajoutent une difficulté absente des usages purement conversationnels : ils enchaînent des étapes et peuvent sélectionner eux-mêmes certains outils. Le risque ne vient donc pas seulement du modèle, mais aussi de la combinaison entre instructions, mémoire, connecteurs, données et permissions.
Un agent chargé de traiter des factures peut par exemple consulter une boîte mail, extraire des informations, interroger un progiciel et proposer un paiement. Chaque étape élargit la surface d’attaque et multiplie les possibilités d’erreur. Une instruction mal interprétée ou une donnée contaminée peut alors provoquer une action non prévue.
La gouvernance doit prévoir une politique de droits adaptée au niveau d’autonomie :
- lecture seule pour les premières phases de test ;
- accès limité à des environnements ou dossiers définis ;
- approbation humaine avant une action irréversible ;
- plafonds de montant ou de fréquence ;
- interdiction de transmettre des données vers des outils non autorisés ;
- suspension automatique après un comportement anormal.
La traçabilité devient une fonction de sécurité
Un journal utile ne se limite pas à enregistrer la réponse finale. Il doit permettre de reconstituer le déroulement de l’action : utilisateur ou processus à l’origine de la demande, version du modèle, données consultées, outils appelés, paramètres importants, résultat produit et validation éventuelle.
Ces informations servent à enquêter sur un incident, à améliorer un workflow et à démontrer que des contrôles existaient. Elles doivent toutefois être protégées à leur tour, car les logs peuvent contenir des données personnelles, des secrets commerciaux ou des informations de sécurité.
L’arrêt d’un agent mérite le même niveau d’attention que son lancement. Une entreprise doit savoir qui peut le désactiver, dans quel délai, avec quel impact sur les opérations et comment reprendre manuellement le processus. Sans procédure testée, un bouton d’arrêt théorique ne constitue pas une garantie opérationnelle.
La donnée reste le principal point de fragilité
La qualité d’un système d’IA dépend moins d’une promesse marketing que du contexte auquel il a accès. Un agent peut être performant dans une démonstration et peu fiable dans l’entreprise si ses sources sont incomplètes, contradictoires ou mal gouvernées.
La gouvernance doit donc relier les usages d’IA aux politiques de gestion des données. Les sources autorisées doivent être identifiées, les droits d’accès hérités ou attribués explicitement et les informations sensibles séparées lorsque cela est nécessaire.
Plusieurs contrôles sont essentiels :
- vérifier la fraîcheur et la provenance des documents ;
- supprimer les doublons et les versions obsolètes ;
- distinguer les données publiques, internes, confidentielles et réglementées ;
- limiter les réponses aux sources accessibles et validées ;
- empêcher la réutilisation non autorisée des données dans l’entraînement ;
- conserver les preuves de validation des jeux de données sensibles.
Les exigences européennes liées aux systèmes à haut risque portent notamment sur la qualité des jeux de données d’entraînement, de validation et de test. Ces données doivent être examinées pour détecter les biais et présenter des propriétés adaptées au contexte d’utilisation, notamment en matière de pertinence et de représentativité.
Le contrôle des accès doit suivre le principe du moindre privilège
Un agent ne devrait jamais disposer automatiquement des mêmes droits que la personne qui l’utilise. Le compte humain peut accéder à de nombreuses ressources, tandis que l’agent doit recevoir uniquement les permissions nécessaires à la tâche définie.
Cette distinction réduit le risque d’exfiltration et limite les conséquences d’une erreur de configuration. Elle permet également de mieux attribuer les actions : l’entreprise sait si une opération vient d’un collaborateur, d’un agent ou d’un automatisme déclenché par un autre système.
La donnée doit enfin rester compréhensible par les équipes chargées du contrôle. Une réponse générée à partir d’un corpus impossible à identifier ne permet ni audit sérieux ni correction rapide. La recherche de sources, la conservation des versions et l’explication du contexte deviennent donc des composants de la gouvernance.
Les référentiels structurent sans remplacer la conformité
Les entreprises peuvent s’appuyer sur des référentiels pour organiser leur démarche. Le NIST AI Risk Management Framework propose une logique fondée sur quatre fonctions : gouverner, cartographier, mesurer et gérer les risques. Ce cadre est volontaire et ne remplace pas les obligations légales applicables à une organisation.
La norme ISO 42001 fournit de son côté un système de management de l’IA. Elle aide à formaliser des politiques, des objectifs, des processus et des responsabilités liés au développement, à la fourniture ou à l’utilisation de systèmes d’IA. Une certification ISO 42001 ne suffit toutefois pas, à elle seule, à satisfaire les obligations de l’AI Act.
| Référentiel | Utilité principale | Limite à connaître |
|---|---|---|
| NIST AI RMF | Structurer l’identification, la mesure et la gestion des risques | Cadre volontaire |
| ISO 42001 | Formaliser un système de management de l’IA | Certification distincte des obligations de l’AI Act |
| AI Act | Fixer des exigences juridiques européennes selon les usages et les niveaux de risque | Application progressive selon les catégories de systèmes |
L’intérêt de ces référentiels est pratique : ils fournissent un vocabulaire commun entre directions, ingénieurs, juristes, auditeurs et métiers. Ils facilitent également la création de preuves, comme les politiques internes, les évaluations de risques, les comptes rendus de revue et les rapports d’incident.
Mais aucun référentiel ne dispense de regarder le fonctionnement réel des applications. Une entreprise peut avoir une politique bien écrite et conserver des agents surdimensionnés, des comptes partagés ou des données non contrôlées. La gouvernance doit donc combiner documentation, tests techniques et vérification sur le terrain.
Transformer la gouvernance en avantage opérationnel
Une gouvernance bien conçue ne sert pas uniquement à éviter une sanction ou un incident. Elle accélère aussi les projets en donnant aux équipes un cadre de lancement connu à l’avance. Les métiers savent quelles données peuvent être utilisées, quels outils sont approuvés et quelles validations sont nécessaires.
Sans cadre commun, chaque équipe recrée ses propres règles. Cette fragmentation augmente les coûts, complique les audits et rend les incidents plus difficiles à analyser. Elle favorise également le recours à des outils non validés lorsque les circuits internes sont trop lents ou trop imprécis.
Une démarche efficace peut être organisée autour de cinq chantiers :
- inventorier les systèmes et les expérimentations ;
- classer les cas d’usage selon leurs effets et leurs capacités d’action ;
- attribuer un responsable pour chaque système ;
- déployer des contrôles techniques proportionnés ;
- mesurer les incidents, les erreurs, les contournements et les délais de correction.
Les indicateurs doivent dépasser le nombre de formations suivies ou de chartes signées. Une direction peut suivre la part des systèmes inventoriés, la proportion d’agents disposant d’un propriétaire identifié, le délai de révocation d’un accès, le nombre d’actions à validation humaine et le temps nécessaire pour reconstituer un incident.
Ces mesures donnent une vision concrète de la maturité. Elles montrent si l’entreprise contrôle réellement ses systèmes ou si elle se contente de déclarer des intentions.
Notre avis : la gouvernance doit précéder le déploiement des agents
La gouvernance de l’IA est essentielle parce que l’entreprise ne déploie plus seulement des modèles, mais des systèmes capables d’influencer ou d’exécuter des décisions. Le risque principal ne réside pas dans une réponse imparfaite isolée : il apparaît lorsque des données sensibles, des permissions étendues et une automatisation rapide se combinent sans responsable clairement désigné.
La priorité pour 2026 est nette : nommer un propriétaire final, établir l’inventaire, verrouiller les accès des agents, rendre les actions traçables et former les utilisateurs. Les obligations européennes déjà applicables rendent cette base nécessaire, tandis que l’échéance du 2 décembre 2027 laisse un délai pour préparer sérieusement les systèmes à haut risque de l’annexe III.
Les entreprises qui traitent la gouvernance comme un frein retarderont surtout leurs propres projets. Celles qui l’intègrent dans l’architecture pourront tester plus vite, démontrer leur maîtrise et étendre les usages avec moins de risques. Dans six mois, la question décisive ne sera probablement plus de savoir si un agent peut agir, mais si l’organisation saura expliquer précisément ce qu’il a fait, pourquoi il l’a fait et qui pouvait l’arrêter.