Votre déploiement IA semble probablement sain dans le rapport du conseil d’administration.
Quelques copilotes approuvés. Une poignée d’assistants internes. Peut-être un bot orienté client. Peut-être un agent de workflow intégré dans une équipe opérationnelle. Tout semble sous contrôle.
Ce n’est généralement pas le cas.
Ce qui se passe réellement dans la plupart des entreprises est plus chaotique : les équipes déploient des agents plus vite que l’IT ne peut les inventorier, la sécurité doit valider des comportements qu’elle ne peut pas entièrement observer, et la gouvernance est encore gérée comme un workflow documentaire de l’ère pré-agent.
C’est le vrai risque IA en entreprise à la mi-2026.
Pas parce qu’un employé a demandé à ChatGPT de résumer un PDF.
Le vrai risque est que votre entreprise construit silencieusement une couche distribuée de systèmes semi-autonomes, chacun avec ses propres prompts, outils, chemins d’accès, mémoire et modes de défaillance, tandis que votre modèle de contrôle suppose toujours qu’un humain est en boucle.
Le fossé de contrôle est désormais mesurable
IBM a chiffré ce que beaucoup d’équipes de sécurité et de gouvernance ressentent déjà au quotidien.
Dans son étude de juin 2026 auprès de 2 000 cadres technologiques, deux tiers ont déclaré être tenus responsables des systèmes IA qu’ils ne contrôlent pas entièrement. Soixante-dix pour cent ont indiqué que l’entreprise déploie la technologie plus vite que l’IT ne peut la suivre. Seulement 11 % se disent pleinement préparés à l’échelle de déploiement des agents IA attendue dans l’année à venir.
Ce n’est pas un simple retard de maturité. C’est un fossé de contrôle.
La même étude a révélé que les organisations ont connu en moyenne 54 incidents liés aux agents IA l’an dernier nécessitant une correction humaine. Dix-sept pour cent de ces incidents étaient de haute gravité et ont demandé plus de quatre heures pour être contenus. Parmi ces incidents graves, 37 % impliquaient une exposition de données ou des violations de sécurité et 33 % ont causé des défaillances en cascade des systèmes.
Cela devrait changer la manière dont les conseils d’administration et les dirigeants abordent le risque IA.
Nous avons dépassé l’étape où la question principale était « Devons-nous autoriser l’IA ? »
La meilleure question est « Combien de systèmes agissent déjà avec assez d’autonomie pour créer des conséquences opérationnelles, de sécurité ou de conformité avant même que nous ne les remarquions ? »
Pourquoi la gouvernance basée sur la politique échoue
Beaucoup de gouvernance IA en entreprise suit encore un schéma familier :
- approuver un outil
- publier une politique
- définir des règles d’usage acceptables
- demander aux équipes métier de se conformer
- examiner les incidents après coup
Cette approche était déjà faible pour l’IA fantôme. Elle est encore plus faible pour les agents.
Les agents ne se contentent pas de générer du texte. Ils appellent des outils. Ils interagissent avec des systèmes. Ils récupèrent du contexte. Ils enchaînent des décisions. Ils déclenchent des actions sur d’autres plateformes. Dès que vous autorisez cela, la gouvernance cesse d’être un problème de politique et devient un problème de contrôle en temps réel.
C’est précisément pourquoi l’ancien modèle de gouvernance donne aux dirigeants une confiance trompeuse. Une équipe peut être totalement conforme sur le papier et créer un système à haut risque en production simplement en connectant un agent à une mauvaise source de données, en lui donnant trop de liberté d’action, ou en ne surveillant pas son comportement lorsque les prompts et les cas limites réels s’accumulent.
Le plus dangereux est que beaucoup de ces échecs ne paraissent pas dramatiques au début.
Ils ressemblent à une recommandation confiante mais erronée. Ils ressemblent à une action inutile prise à la vitesse machine. Ils ressemblent à une étape de récupération qui a extrait le mauvais document. Ils ressemblent à un workflow qui a touché des données sensibles parce que personne n’a correctement cartographié la dépendance.
Au moment où l’incident devient visible, la cause racine se situe généralement à plusieurs niveaux : comportement du modèle, conception du prompt, permissions des outils, logique métier et exposition des données.
C’est pourquoi les politiques IA génériques semblent de plus en plus déconnectées du risque réel en entreprise.
Le NIST vient de rendre le problème plus difficile à ignorer
En juin, le NIST a publié un argument mathématique pour abandonner un modèle de sécurité IA ponctuel.
La version brute : il n’existe pas d’ensemble fini de garde-fous universellement robustes contre des prompts adversariaux adaptatifs.
Cela importe car beaucoup d’entreprises traitent encore la sécurité IA comme un exercice ponctuel de durcissement. Tester les règles de prompt. Ajouter des filtres. Documenter les contrôles. Passer à autre chose.
Le NIST dit en fait que cette mentalité est structurellement erronée.
Si aucune règle fixe ne tient éternellement, alors la gouvernance IA ne peut pas se limiter à une revue statique et une approbation périodique. Elle doit devenir une surveillance continue, des tests continus et une correction continue.
Cela est particulièrement vrai pour les agents, car ils fonctionnent dans la durée. Ils ne se limitent pas à une seule fenêtre de prompt. Ils évoluent grâce au contexte, à l'utilisation d'outils, aux intégrations et aux décisions cumulées. Un contrôle qui semblait correct lors de la revue peut échouer une fois que le système commence à interagir avec la réalité complexe de la production.
C’est là que beaucoup d’entreprises sont exposées aujourd’hui. Elles tentent de gouverner des systèmes dynamiques avec des processus statiques.
Ce que font différemment les équipes matures
L’aspect intéressant des données IBM n’est pas seulement l’avertissement. C’est le contraste.
Les organisations qui intègrent le contrôle directement dans leurs systèmes d’IA rapportent 25 % d’incidents en moins. IBM a également constaté que les organisations avec un contrôle intégré déploient 16 fois plus d’agents IA que celles qui s’appuient sur une gouvernance manuelle.
C’est ce que beaucoup de dirigeants ne saisissent pas.
La gouvernance n’est pas une taxe pour ralentir l’IA. Une bonne gouvernance permet de monter en charge sans perdre le contrôle.
En pratique, les équipes matures adoptent un modèle opérationnel différent :
1. Elles inventorient les comportements, pas seulement les fournisseurs
Savoir qu’un outil IA a été acheté ne suffit pas. Il faut une visibilité sur les agents existants, les systèmes auxquels ils se connectent, les données qu’ils manipulent, les actions qu’ils peuvent effectuer et leurs responsables.
2. Elles traitent les permissions des agents comme une surface de sécurité dynamique
Un agent avec un large accès aux outils n’est pas seulement un atout productif. C’est un opérateur non humain dans votre environnement. Cela signifie que le principe du moindre privilège, les actions limitées, les frontières d’approbation et l’auditabilité sont aussi importants que pour les administrateurs humains.
3. Elles surveillent l’exécution, pas seulement la configuration
La vraie question n’est pas de savoir si l’agent a passé la revue la première semaine. C’est ce qu’il fait à la douzième semaine, après dérive des prompts, changements d’intégration, nouvelles sources de données et demandes métier urgentes qui ont remodelé le système.
4. Elles unifient gouvernance et sécurité
Cette séparation est l’un des plus gros problèmes structurels que nous observons. Les équipes de gouvernance gèrent souvent les politiques, les risques et la conformité. Les équipes de sécurité gèrent les contrôles techniques et la réponse aux incidents. Les agents traversent ces deux domaines. Si ces fonctions restent cloisonnées, vos angles morts se multiplient rapidement.
Le prochain incident IA en entreprise ne ressemblera probablement pas à « de l’IA »
C’est une autre raison pour laquelle les dirigeants sous-estiment le problème.
Le prochain incident sérieux peut être enregistré comme une fuite de données, un manquement à la conformité, une panne de workflow, un problème de qualité de modèle ou une erreur d’intégration tierce. L’IA n’apparaîtra peut-être qu’en post-mortem comme un facteur contributif.
Mais si un agent a fait une mauvaise récupération, exécuté une mauvaise étape, exposé un mauvais enregistrement ou accéléré un mauvais workflow, alors l’IA n’était pas accessoire. Elle était impliquée opérationnellement.
C’est pourquoi la visibilité est si importante.
Vous ne pouvez pas gouverner ce que vous ne voyez pas, et vous ne pouvez pas sécuriser ce dont vous ne savez pas qu’il agit dans votre environnement.
La démarche pratique maintenant
Si je conseillais un DSI, RSSI ou responsable des risques aujourd’hui, je ne commencerais pas par une nouvelle réécriture de politique.
Je commencerais par trois questions inconfortables :
- Combien d’agents IA, assistants et workflows IA intégrés fonctionnent déjà dans l’entreprise ?
- Lesquels ont accès à des données sensibles ou peuvent déclencher des actions en aval ?
- Lesquels sont surveillés en continu pour leur comportement, pas seulement approuvés sur papier ?
La plupart des organisations n’aiment pas les réponses.
C’est l’ouverture.
Les gagnants dans l’IA d’entreprise ne seront pas ceux qui déploient simplement le plus d’agents. Ce seront ceux qui construisent une vraie couche de contrôle avant que la montée en charge ne tourne au chaos.
Aona existe précisément pour ce problème : découvrir quelles IA fonctionnent réellement dans votre environnement, voir où se situent les risques, et mettre en place des contrôles de gouvernance et de sécurité autour de l’usage réel au lieu d’espérer que la politique seule suffira.
Car à ce stade, la question IA n’est plus de savoir si votre entreprise a adopté des agents.
C’est de savoir si vos contrôles ont suivi.
