L’adoption de l’IA progresse plus vite que les règles qui doivent l’encadrer. En 2025, 88 % des entreprises utilisaient déjà l’IA dans au moins une fonction, mais seules 39 % déclaraient un impact mesurable sur leur résultat opérationnel, selon les données relayées par McKinsey et le Stanford HAI. L’écart entre expérimentation et valeur industrielle ne tient donc pas uniquement à la technologie.
Un autre obstacle s’installe au cœur des organisations : personne ne sait toujours clairement qui répond des systèmes d’IA lorsqu’ils accèdent aux données, prennent une décision ou déclenchent une action. Une analyse de PwC publiée le 1er octobre 2026 pointe cette zone grise, où les responsabilités se répartissent entre CIO, CTO, CISO et équipes spécialisées en IA. Tant que cette question reste ouverte, chaque nouveau déploiement ajoute une couche de risque, de validation et de prudence.
PwC identifie une responsabilité éclatée entre CIO, CTO et CISO
Le problème central n’est pas l’absence de compétences, mais l’absence d’un propriétaire clairement désigné pour l’IA. PwC relève qu’aucun poste n’assume systématiquement la gestion et la sécurité des systèmes d’IA dans les entreprises. Les responsabilités varient selon les structures et se partagent principalement entre les directions informatiques, technologiques, de la sécurité et les fonctions IA dédiées.
Cette organisation peut fonctionner pour un projet limité, avec un périmètre défini et peu d’accès sensibles. Elle devient plus difficile à maintenir lorsque des assistants et des agents sont intégrés à plusieurs services, utilisent des données internes ou peuvent agir dans des applications métier.
Le CIO supervise généralement les systèmes d’information et leur intégration dans l’entreprise. Le CTO porte davantage les choix technologiques et l’architecture. Le CISO se concentre sur la sécurité, la gestion des menaces et la protection des accès. Une direction IA peut, de son côté, piloter les modèles, les cas d’usage et la transformation des métiers.
Le chevauchement de ces périmètres crée une difficulté concrète : plusieurs responsables peuvent participer à une décision sans qu’un seul soit désigné pour en assumer les conséquences. Cette distinction devient essentielle lorsqu’un système produit une erreur, expose une donnée ou exécute une action non prévue.
À retenir : répartir les tâches n’équivaut pas à attribuer la responsabilité. Une entreprise peut disposer de plusieurs experts tout en laissant sans réponse la question de savoir qui doit arrêter, corriger ou déclarer un système d’IA.
Les agents d’IA transforment un sujet informatique en problème de responsabilité
Les agents d’IA, des systèmes capables d’utiliser des outils et d’exécuter des tâches avec un degré d’autonomie, rendent le sujet plus sensible que celui des simples assistants conversationnels. Un agent peut consulter une base documentaire, appeler une API, modifier un enregistrement ou lancer un processus selon les autorisations qui lui sont accordées.
Cette capacité d’action élargit la chaîne de responsabilité. Le modèle peut être fourni par un éditeur, configuré par une équipe interne, connecté à un outil métier par un intégrateur et utilisé par un salarié. En cas d’incident, l’entreprise doit pouvoir reconstituer cette chaîne et identifier la décision qui a permis l’action.
Deloitte indique que 80 % des responsables de l’automatisation prévoient d’accélérer leurs investissements dans les agents d’IA. Dans le même temps, seuls 21 % des organisations interrogées déclarent disposer de capacités de gouvernance agentique suffisamment matures. Cette différence mesure le décalage entre la vitesse de déploiement et la préparation des contrôles.
Le risque ne se limite pas à une réponse incorrecte. Un agent mal configuré peut recevoir trop de privilèges, utiliser une information dans un mauvais contexte ou poursuivre une tâche au-delà de ce qui était prévu. Plus son périmètre d’action est large, plus l’entreprise doit savoir qui a approuvé ses accès et qui surveille ses décisions.
Le passage du copilote à l’action autonome
Un copilote propose généralement une réponse ou une recommandation que l’utilisateur peut vérifier. Un agent peut enchaîner plusieurs opérations et agir directement dans le système d’information. Cette différence modifie les exigences de contrôle, car l’humain n’examine plus nécessairement chaque étape.
Les entreprises doivent alors définir des limites opérationnelles : actions autorisées, données accessibles, durée des sessions, seuils de validation humaine et conditions d’arrêt. Ces règles ne peuvent pas être confiées à un seul service si l’agent touche à la fois à la technologie, à la sécurité et aux processus métier.
L’absence de responsable unique ralentit chaque déploiement
Lorsqu’un projet d’IA arrive dans une entreprise, plusieurs questions doivent recevoir une réponse avant la mise en production. Qui valide les données utilisées ? Qui évalue le fournisseur ? Qui définit les droits d’accès ? Qui surveille les erreurs ? Qui décide de suspendre le système ?
Si ces décisions sont réparties sans circuit clair, les équipes ajoutent des étapes de validation pour réduire leur exposition. Les services juridiques, informatiques, de sécurité et de conformité examinent successivement le même projet. Le délai augmente, tandis que la responsabilité finale reste difficile à établir.
Ce mécanisme peut freiner l’adoption de deux façons. Les équipes renoncent d’abord à certains cas d’usage jugés trop risqués. Elles peuvent ensuite déployer des outils sans validation centrale, ce qui crée une shadow AI, c’est-à-dire l’utilisation de services d’IA en dehors des processus officiels de l’entreprise.
Les deux scénarios sont coûteux. Le premier bloque des gains potentiels de productivité. Le second réduit la visibilité sur les données envoyées aux fournisseurs, les comptes utilisés et les décisions prises par les outils.
Une enquête OneTrust et Sapio Research menée auprès de 1 200 décideurs dans huit marchés illustre cette difficulté : 74 % des organisations interrogées déclarent avoir atteint un niveau d’adoption départemental ou une mise à l’échelle, tandis que 52 % utilisent l’IA dans plusieurs fonctions ou l’ont intégrée à leurs opérations. Pourtant, seules 5 % indiquent que la coordination et la responsabilité sont claires sur l’ensemble du cycle de vie de l’IA.
| Situation de gouvernance | Conséquence opérationnelle | Risque associé |
|---|---|---|
| Responsabilités réparties entre plusieurs directions | Validation plus lente | Décisions difficiles à attribuer |
| Agent relié à plusieurs applications | Contrôle plus complexe | Action excessive ou non autorisée |
| Adoption départementale sans coordination transverse | Règles différentes selon les équipes | Données et accès moins visibles |
| Gouvernance mature et contrôle centralisé | Déploiement plus prévisible | Meilleure traçabilité des décisions |
Ces chiffres montrent que l’adoption ne garantit pas la maîtrise. Une organisation peut généraliser l’usage de l’IA tout en conservant une gouvernance fragmentée.
Traiter un agent comme un utilisateur humain devient une règle de sécurité
Des experts recommandent d’appliquer aux agents d’IA les mêmes contrôles d’identité que pour les utilisateurs humains. Cette approche part d’un principe simple : un agent qui accède à des ressources sensibles doit être identifiable, autorisé et traçable.
L’agent ne devrait pas fonctionner derrière les identifiants permanents d’un salarié ou d’un compte partagé. Son identité doit permettre de savoir quel système a réalisé une action, avec quelles autorisations, dans quel contexte et pendant combien de temps.
Okta recommande une architecture centrée sur l’identité, avec des identifiants à durée limitée, une autorisation en deux niveaux et une désactivation automatisée. IBM préconise également d’enregistrer chaque agent dans le système d’identité de l’entreprise et de lui accorder uniquement les privilèges nécessaires à la tâche en cours.
Cette logique reprend le principe du moindre privilège, qui consiste à ne donner à un utilisateur ou à un système que les accès indispensables à son activité. Appliqué aux agents, il réduit la portée d’une erreur de configuration ou d’une compromission.
Les contrôles à appliquer aux agents
Un dispositif de base peut s’appuyer sur plusieurs contrôles complémentaires :
- une identité propre à chaque agent ;
- des autorisations limitées à des ressources et à des actions définies ;
- des accès temporaires, renouvelés uniquement lorsque la tâche le justifie ;
- une journalisation des requêtes, décisions et actions exécutées ;
- une procédure de révocation immédiate en cas d’anomalie ;
- une validation humaine pour les opérations sensibles ou irréversibles.
Ces contrôles ne désignent pas à eux seuls le responsable de l’agent. Ils rendent toutefois les décisions auditables et permettent de relier une action technique à une configuration, une équipe et une approbation.
Le contrôle d’identité ne remplace pas l’évaluation du modèle. Il complète les tests de qualité, les protections contre la fuite de données et les règles de supervision. Un agent correctement authentifié peut toujours prendre une mauvaise décision ; l’entreprise doit donc contrôler à la fois son identité, ses permissions et ses résultats.
Le risque juridique et réglementaire renforce la prudence des entreprises
La gouvernance de l’IA ne relève pas uniquement de la cybersécurité. Les systèmes peuvent traiter des données personnelles, influencer une décision RH, produire un contenu trompeur ou générer une recommandation dont les critères sont difficiles à expliquer.
Dans chacun de ces cas, l’entreprise doit documenter le fonctionnement du système, ses limites et les contrôles appliqués. Une responsabilité mal attribuée complique la conservation des preuves et la réponse à un incident.
Le sujet devient encore plus sensible lorsque l’IA est fournie par un prestataire. Le fournisseur contrôle souvent le modèle général, tandis que l’entreprise choisit les données, les instructions, les connecteurs et les utilisateurs. Cette séparation technique ne supprime pas la nécessité d’une décision interne sur l’usage autorisé.
La direction de la sécurité peut réduire le risque d’intrusion, mais elle ne décide pas seule si une application métier doit confier une tâche à un agent. La direction juridique peut encadrer les contrats, mais elle ne possède pas nécessairement la visibilité sur les journaux techniques. La direction informatique peut administrer la plateforme, sans être propriétaire du processus métier affecté.
C’est précisément cette interdépendance qui rend indispensable une gouvernance transverse avec une responsabilité finale clairement attribuée. Sans cette clarification, les équipes cherchent surtout à éviter de devenir le dernier maillon responsable d’un système qu’elles ne contrôlent pas entièrement.
Les entreprises doivent passer d’une gouvernance de projet à une gouvernance du cycle de vie
Un comité qui approuve un outil au moment de son lancement ne suffit pas à encadrer une IA déployée pendant plusieurs années. Les modèles changent, les données évoluent, les fournisseurs modifient leurs conditions et les agents reçoivent de nouveaux accès.
La gouvernance doit donc suivre tout le cycle de vie du système : conception, évaluation, déploiement, supervision, modification et retrait. Chaque étape nécessite un responsable, des critères d’acceptation et des traces consultables.
Un registre central des systèmes d’IA constitue une première brique. Il peut recenser le propriétaire métier, l’équipe technique, le fournisseur, les données utilisées, les applications connectées, le niveau de risque et la date de la dernière revue.
La revue ne doit pas être identique pour tous les outils. Un assistant limité à la reformulation de textes ne présente pas le même périmètre qu’un agent capable de modifier des dossiers clients ou de déclencher un paiement. La profondeur des contrôles doit correspondre aux accès et aux conséquences possibles.
Une répartition lisible des rôles
La structure la plus efficace ne consiste pas nécessairement à créer un nouveau poste pour chaque risque. Elle doit surtout distinguer trois niveaux de responsabilité :
- le propriétaire métier, qui décide de la finalité et accepte les conséquences opérationnelles ;
- le responsable technique, qui garantit l’intégration, la disponibilité et la configuration ;
- le responsable du risque, qui contrôle la sécurité, la conformité et les conditions d’arrêt.
Une même personne peut cumuler plusieurs fonctions dans une petite entreprise. L’essentiel est que les responsabilités soient écrites, connues des équipes et révisées lorsque le périmètre de l’IA change.
Le CIO, le CTO, le CISO ou un responsable IA peuvent coordonner cette organisation. Mais la coordination ne doit pas masquer la décision finale. Pour chaque système, il faut savoir qui peut autoriser le déploiement, qui peut suspendre l’accès et qui répond de l’impact sur le métier.
À retenir : la gouvernance devient opérationnelle lorsqu’elle indique une personne ou une fonction responsable pour chaque agent, chaque accès sensible et chaque décision d’arrêt.
L’écart entre adoption et valeur rend la clarification urgente
L’utilisation de l’IA augmente, mais les résultats économiques restent inégaux. Les données relayées par McKinsey et le Stanford HAI indiquent que 88 % des organisations utilisaient l’IA en 2025, alors que 39 % seulement déclaraient un impact mesurable sur leur résultat opérationnel. Cette différence signifie que l’expérimentation ne se transforme pas automatiquement en valeur durable.
Une gouvernance confuse peut accentuer cet écart. Les équipes consacrent du temps à vérifier les responsabilités après l’apparition d’un problème, plutôt qu’à définir les contrôles avant le déploiement. Les dirigeants financent alors des pilotes supplémentaires sans disposer d’un cadre commun pour comparer leurs résultats et leurs risques.
La situation est particulièrement critique pour les agents. Leur capacité à exécuter des tâches promet un gain supérieur à celui d’un outil limité à la génération de texte, mais elle augmente aussi le coût d’une erreur. Une entreprise qui veut industrialiser ces systèmes doit donc associer chaque gain attendu à une limite opérationnelle et à un responsable identifiable.
Les plateformes intégrant une architecture commune et un plan de contrôle centralisé peuvent faciliter cette industrialisation. Le BCG indique que plus des deux tiers des entreprises considérées comme les plus avancées s’engagent vers une plateforme IA d’entreprise reposant sur une architecture commune et un plan de contrôle partagé.
Ce choix ne règle pas automatiquement la responsabilité. Il donne cependant aux équipes un même environnement pour gérer les identités, les droits, les journaux, les évaluations et les changements de configuration.
Notre avis : l’adoption décollera quand l’IA aura un propriétaire clairement nommé
Le flou sur la responsabilité est déjà un frein concret à l’industrialisation de l’IA. Les entreprises ne manquent pas seulement de règles : elles manquent d’un point de décision capable d’arbitrer entre vitesse, sécurité et valeur métier.
La priorité n’est pas de multiplier les comités ni de créer un titre supplémentaire dans l’organigramme. Elle consiste à attribuer à chaque système un propriétaire métier, un responsable technique et un responsable du risque, puis à appliquer aux agents une identité distincte, des accès temporaires et une traçabilité complète.
Dans les six prochains mois, les organisations qui progresseront le plus vite seront probablement celles qui traiteront la gouvernance comme une infrastructure de déploiement, et non comme une validation administrative ajoutée à la fin d’un projet. La question décisive ne sera plus seulement de savoir ce qu’un agent peut faire, mais qui peut l’autoriser, le surveiller et l’arrêter.