IBM vient d’interroger 2 000 DSI et directeurs techniques. Le chiffre principal devrait arrêter net tout dirigeant.
67 % déclarent ne pas pouvoir contrôler entièrement ce que font leurs agents IA.
Pas « ne disposent pas d’un système parfait ». Pas « y travaillent ». Ne peuvent pas le contrôler. Aujourd’hui. Avec des agents déjà en production.
La même enquête montre que seules 11 % des organisations ont mis en place une gouvernance complète de l’IA. Les autres comptent sur la chance : que leurs agents restent dans les limites prévues, qu’ils ne prennent pas de mesures pour lesquelles ils n’ont reçu aucune autorisation, que quelqu’un remarque quand quelque chose tourne mal.
Ce n’est pas un problème technologique. C’est un problème d’architecture. Et il a une solution, à condition de l’intégrer dès le départ.
L’écart dont personne ne parle
Les chiffres de 67 % et de 11 % racontent une histoire précise. Les organisations ont déployé des agents rapidement. Elles ont fait vite pour saisir les gains de productivité, les succès de l’automatisation et l’avantage concurrentiel d’une IA qui travaille à grande échelle.
Ce qu’elles n’ont pas fait, c’est construire la couche de gouvernance avant le déploiement.
Résultat : une flotte d’agents qui opèrent sans autorité définie. Ils peuvent agir. Ils peuvent communiquer avec l’extérieur. Ils peuvent accéder aux systèmes. Mais les limites de cette autorité n’ont jamais été formellement définies, jamais appliquées techniquement et jamais rendues auditables.
Quand quelque chose tourne mal, et c’est déjà arrivé dans 88 % des organisations, la question « qui a autorisé cela ? » reste sans réponse. Parce que personne ne l’a fait explicitement. L’agent, tout simplement… le pouvait.
Ce que les 25 % ont fait autrement
Les organisations qui ont comblé l’écart partagent un même schéma d’architecture. Elles n’ont pas ajouté la gouvernance après le déploiement. Elles l’ont intégrée à la couche de déploiement.
Concrètement, elles ont fait trois choses :
1. Elles ont traité les agents comme des entités gouvernées, pas comme des outils.
Chaque agent IA possède une identité, un périmètre d’autorité défini et un modèle d’autorisations appliqué à l’exécution. L’agent ne peut effectuer que les actions explicitement autorisées pour son rôle. Pas « ne dépassera probablement pas son périmètre ». Ne peut pas dépasser son périmètre, car le système l’impose au moment de l’exécution.
2. Elles ont intégré l’observabilité en temps réel à la couche des agents.
Chaque action, chaque décision, chaque communication externe est journalisée au moment de l’exécution, et non reconstituée après coup à partir des journaux des systèmes en aval. Quand vous devez répondre à la question « qu’a fait cet agent, et pourquoi ? », la réponse est déjà là.
3. Elles ont défini les responsabilités au déploiement, pas lors d’un incident.
Avant qu’un agent soit mis en service, quatre questions ont une réponse explicite :
- Qui a approuvé son périmètre ?
- Qui examine ses actions ?
- Qui est averti quand il sort des limites prévues ?
- Qui a le pouvoir de le suspendre ?
Ce ne sont pas des questions auxquelles vous voulez répondre pour la première fois en plein incident.
Le résultat n’est pas un déploiement plus lent. Il est plus rapide, car la couche de gouvernance supprime les allers-retours qui surviennent quand des agents non gouvernés créent des problèmes nécessitant une intervention humaine.
L’argument de l’architecture
L’écart entre 77 % et 11 % révèle une erreur précise dans la façon dont le secteur a présenté la gouvernance de l’IA.
La gouvernance a été vendue comme une exigence de conformité : quelque chose que l’on fait parce que les régulateurs ou les auditeurs l’imposent. Cette approche produit le résultat des 11 % : des organisations qui ne mettent en place la gouvernance que là où elles y sont obligées, a minima et le plus tard possible.
Les 25 % qui ont comblé l’écart traitent la gouvernance comme une exigence d’architecture. De la même façon que vous ne déploieriez pas une base de données de production sans contrôle d’accès, vous ne déployez pas un agent IA en production sans modèle d’autorisations défini, sans piste d’audit et sans mécanisme de suspension.
L’approche par la conformité demande : « De quelle gouvernance devons-nous disposer ? »
L’approche par l’architecture demande : « De quelle gouvernance avons-nous besoin pour faire confiance à ce système en production ? »
Ce sont deux questions différentes, aux réponses très différentes.
Ce que cela signifie pour votre organisation
Si vous faites partie des 67 %, la voie à suivre n’est ni un audit de gouvernance ni un document de politique interne. C’est un changement d’architecture dans la façon de déployer les agents.
Cela signifie :
- L’identité avant le déploiement. Chaque agent doit disposer d’une identité définie et d’un périmètre d’autorité délimité avant de toucher aux systèmes de production.
- L’observabilité au niveau des agents. Journaliser les effets sur les systèmes en aval ne suffit pas. Vous devez capter les décisions des agents au moment où elles sont prises.
- Des responsabilités définies dès le départ. La personne responsable des actions de chaque agent doit être nommée avant la mise en service de l’agent, et non identifiée après un incident.
Les organisations qui y parviennent n’avancent pas plus lentement. Elles avancent plus vite, avec davantage de confiance, car elles ont éliminé les défaillances qui imposent une intervention humaine.
L’enquête d’IBM est un instantané de l’état du secteur. Les 25 % qui ont comblé l’écart donnent un aperçu de la direction qu’il prend.
La question est de savoir de quel côté de cet écart se trouve votre organisation.
Outermind conçoit des agents IA dont la gouvernance est intégrée à l’architecture, et non ajoutée après le déploiement. Chaque agent dispose d’une identité définie, d’un modèle d’autorisations délimité et d’une piste d’audit en temps réel dès le premier jour. Rejoignez la liste d’attente pour voir à quoi ressemble concrètement une IA qui place la gouvernance en premier.