Agents IA : pourquoi personne ne peut les arrêter
Un agent IA mal configuré continue d'agir tant que personne ne le débranche. C'est ce constat simple que révèle une étude menée en 2026 auprès de 225 responsables sécurité, IT et risque : 6 entreprises sur 10 ne disposent d'aucun moyen réel d'arrêter un agent IA qui se comporte mal une fois qu'il est en production. La gouvernance de l'intelligence artificielle existe sur le papier dans la plupart des grandes entreprises. Le bouton d'arrêt, lui, manque souvent à l'appel. Pour les comités de sécurité, les DSI et les directions juridiques, cet écart entre la règle affichée et le contrôle réel devient le vrai sujet de 2026.
Ce n'est pas un problème théorique réservé aux géants de la tech. Un agent qui répond aux clients, qui alimente un CRM ou qui déclenche des actions dans un ERP tourne aujourd'hui dans des entreprises de taille moyenne, souvent avec des droits plus larges que ce que son usage réel justifie. La question n'est plus de savoir si une entreprise utilise des agents IA, mais si elle sait, concrètement, comment reprendre la main le jour où l'un d'eux dérape.
Photo : Vitaly Gariev / UnsplashÀ retenir
Selon une étude 2026 menée auprès de 225 responsables sécurité, IT et risque, 60 % des entreprises ne peuvent pas arrêter un agent IA défaillant, 63 % ne peuvent pas limiter son usage et seules 45 % isolent correctement leurs systèmes IA du reste du réseau. La gouvernance IA ne protège rien tant qu'elle n'est pas doublée de moyens techniques réels et d'une documentation des décisions prises en comité.
Le chiffre qui dérange les comités de sécurité
Le Kiteworks 2026 Data Security and Compliance Risk Forecast Report a interrogé 225 décideurs sécurité, IT et risque dans dix secteurs et huit régions du monde. Les résultats mettent en évidence un décalage structurel entre les politiques de gouvernance IA, souvent rédigées et validées en comité, et les capacités techniques réellement déployées pour les faire respecter.
Trois chiffres résument le problème. Soixante pour cent des organisations interrogées ne peuvent pas arrêter un agent IA qui dérape, la capacité de coupure d'urgence (ce qu'on appelle un kill switch) ne concernant qu'environ quatre entreprises sur dix. Soixante-trois pour cent ne parviennent pas à limiter l'usage d'un agent à sa finalité d'origine, autrement dit à l'empêcher d'accéder à des données ou des systèmes hors de son périmètre prévu. Et seulement 45 % disposent d'une isolation réseau suffisante pour contenir un agent compromis sans affecter le reste du système d'information.
Ces trois capacités (couper, limiter, isoler) forment le socle minimal d'une gouvernance IA opérationnelle. Sans elles, une politique de gouvernance reste un document. Elle ne protège rien tant qu'un incident ne survient pas.
Pourquoi l'écart se creuse en 2026
Des agents partout, une surface d'attaque qui suit
Le déploiement d'agents IA autonomes s'est généralisé en 2026 dans les grandes entreprises : agents de support client, copilotes commerciaux, assistants qui préparent des documents ou déclenchent des actions dans un CRM ou un ERP sans validation humaine systématique. Chaque agent ajouté est un point d'accès supplémentaire, souvent doté de droits plus larges que nécessaire pour simplifier son déploiement.
Le 2026 Global Threat Report de CrowdStrike documente la conséquence directe de cette extension : l'activité des adversaires qui exploitent eux-mêmes l'intelligence artificielle a augmenté de 89 % en un an. Le temps de propagation moyen d'une intrusion, c'est-à-dire le délai entre l'accès initial et le mouvement latéral dans le système, est tombé à 29 minutes en 2025, soit une baisse de 65 % par rapport à 2024. Des cas documentés montrent des prompts malveillants injectés directement dans des outils d'IA générative chez plus de 90 organisations, dans le but de voler des identifiants et des actifs numériques. Quand l'attaquant progresse en quelques minutes, un comité de sécurité qui découvre l'incident le lendemain matin arrive déjà trop tard.
Le cas des identités non humaines
Un agent IA agit avec des identifiants, des jetons d'accès, des permissions. Ce sont des identités non humaines, au même titre qu'un compte de service ou une clé API, sauf qu'elles se multiplient à un rythme que les équipes sécurité peinent à suivre. Nous avons détaillé ailleurs pourquoi ces identités non surveillées constituent aujourd'hui le premier risque de sécurité lié à l'IA en entreprise. Le problème de confinement décrit ici en est le prolongement direct : une identité qu'on ne surveille pas est aussi une identité qu'on ne sait pas désactiver rapidement.
Le World Economic Forum confirme la tendance dans son Global Cybersecurity Outlook 2026 : 94 % des dirigeants et responsables cyber interrogés considèrent l'intelligence artificielle comme le principal moteur de changement en cybersécurité pour l'année à venir, et 87 % identifient les vulnérabilités liées à l'IA comme le risque qui progresse le plus vite. Signe que le sujet commence à être pris au sérieux : 64 % des organisations évaluent désormais la sécurité de leurs outils IA, contre 37 % seulement un an plus tôt. L'intention progresse. L'outillage réel, lui, reste en retard sur cette prise de conscience.
Gouverner sur le papier ne suffit plus
Beaucoup d'entreprises confondent avoir une charte d'usage de l'IA et avoir une gouvernance opérationnelle. La première fixe des règles. La seconde donne les moyens de les faire respecter, de les vérifier, et de réagir en quelques minutes si un agent sort de son périmètre.
Quand l'activité des adversaires qui exploitent eux-mêmes l'IA progresse de 89 % en un an et que le temps de propagation moyen d'une intrusion tombe à 29 minutes, un comité de sécurité qui met plusieurs heures à réagir a déjà perdu la partie.
Ce que doit vérifier un comité de gouvernance IA
Un comité de sécurité ou un comité de direction qui veut sortir de la gouvernance de façade doit pouvoir répondre, sans hésitation, à une série de questions concrètes. Combien d'agents IA sont en production aujourd'hui, avec quels accès précis à quelles données. Qui, dans l'organisation, a techniquement la capacité de désactiver un agent en moins de quelques minutes, et cette capacité a-t-elle déjà été testée en conditions réelles plutôt que supposée sur un schéma d'architecture. Les agents sont-ils isolés du reste du réseau de façon à ce qu'une compromission reste circonscrite. Enfin, existe-t-il une trace exploitable de chaque décision qui a conduit à déployer tel agent avec tel niveau d'accès, trace qui servira en cas d'audit, de contrôle réglementaire ou de litige.
Cette dernière question est souvent la plus négligée, alors qu'elle conditionne la capacité même de l'entreprise à démontrer sa diligence le jour où un incident survient.
Un exemple concret suffit à mesurer l'écart. Une direction commerciale déploie un agent IA pour qualifier des leads et rédiger des premiers emails de relance. Six mois plus tard, personne ne sait précisément à quelles bases de contacts il accède, ni qui a le pouvoir de le couper si une campagne part dans le mauvais sens. Le comité qui a validé le projet au départ n'a laissé aucune trace exploitable de ses conditions d'approbation. Le jour où un client se plaint d'un message inapproprié, l'entreprise découvre en même temps le problème et l'absence de réponse organisée.
Par où commencer : un chantier en 90 jours
Face à ce constat, mieux vaut un plan d'action concret qu'une nouvelle charte. Quatre chantiers peuvent être engagés en parallèle sur un trimestre. D'abord, un inventaire exhaustif des agents IA en production, avec leurs accès précis, mené conjointement par la sécurité et les équipes métiers qui les ont déployés. Ensuite, un test réel de la capacité de coupure d'urgence sur un échantillon d'agents, pas seulement une vérification documentaire du schéma d'architecture. Puis une revue des droits accordés à chaque agent, pour ramener son périmètre à ce qui est strictement nécessaire à sa mission. Enfin, la mise en place d'un rythme régulier de comités de gouvernance IA dont chaque décision est documentée et conservée, pas seulement discutée puis oubliée.
La traçabilité, brique oubliée de la gouvernance IA
Le confinement technique (couper, limiter, isoler) relève des équipes infrastructure et sécurité. Mais une gouvernance IA solide repose aussi sur un second pilier, moins visible : la capacité à prouver que les décisions de déploiement, de validation et de révision des agents IA ont bien eu lieu, avec qui, sur quels arguments, et avec quel suivi des actions décidées.
C'est précisément le terrain sur lequel l'adoption des agents IA bute déjà dans la plupart des grandes entreprises : seulement 10 % des agents IA autonomes passent du pilote à la production, le frein principal n'étant pas technique mais l'absence d'une mémoire d'entreprise fiable sur laquelle ces agents peuvent s'appuyer et que les comités de gouvernance peuvent auditer. Un comité de sécurité qui se réunit pour statuer sur le déploiement d'un nouvel agent IA, sans compte rendu structuré de cette réunion, de ses conditions et de ses décisions, prive l'entreprise d'une pièce de preuve qui lui sera réclamée tôt ou tard, que ce soit par un auditeur, un régulateur ou, en cas d'incident, par un tribunal.
C'est là que la mémoire d'entreprise rejoint directement la gouvernance IA. Seedext transforme chaque réunion de comité de sécurité, chaque revue d'architecture, chaque arbitrage sur le périmètre d'un agent IA en document structuré et consultable : qui a décidé quoi, sur la base de quels arguments, avec quel suivi des actions. Cette documentation ne remplace pas un kill switch technique. Elle en est le complément indispensable : la preuve que la gouvernance a réellement fonctionné, au-delà de la politique rédigée une fois par an.
Ce que ça change concrètement pour la banque, l'assurance et le BTP
Dans la banque et l'assurance, le règlement DORA impose déjà aux établissements financiers de cartographier précisément leurs prestataires de technologies de l'information, agents IA compris, et de documenter les décisions associées. Un comité des risques qui approuve le déploiement d'un agent IA sans laisser de trace exploitable de cette approbation s'expose directement lors du contrôle du registre réglementaire.
Dans le BTP et l'industrie, les comités de chantier et les comités de sécurité produisent déjà des décisions qui engagent la responsabilité de l'entreprise en cas d'incident : procès-verbaux, rapports d'audit, comptes rendus de revue de risques. Un agent IA déployé sur un chantier pour automatiser des tâches de reporting ou de suivi n'échappe pas à cette exigence de traçabilité, bien au contraire : plus l'agent agit de façon autonome, plus la documentation des décisions qui ont encadré son déploiement devient la pièce qui protège l'entreprise.
Dans les deux cas, le constat reste le même. La gouvernance des agents IA ne se joue pas uniquement dans l'infrastructure technique. Elle se joue aussi dans la salle de réunion où ces décisions se prennent, et dans la qualité de ce qui en reste ensuite.
Comment Seedext s'inscrit dans cette réponse
Seedext n'est pas un outil de confinement réseau ni un kill switch pour agents IA : ce n'est pas sa vocation. Sa place dans cette chaîne de gouvernance se situe en amont et en aval des décisions techniques. En amont, en capturant avec une précision de l'ordre de 96 % chaque réunion où un comité de sécurité, un CISO ou une direction des risques discute du périmètre, des accès et des conditions de déploiement d'un agent IA. En aval, en structurant ces échanges en comptes rendus exploitables, horodatés, retrouvables par mot-clé, qui constituent une base de preuve en cas d'audit, de contrôle réglementaire ou d'incident.
Cette mémoire d'entreprise est hébergée en France, chiffrée en AES-256, avec une option d'instance privée ou de déploiement On-Premise pour les secteurs les plus exigeants comme la banque, l'assurance ou la défense. Les entreprises qui ont déjà adopté cette approche pour sécuriser leurs échanges, comme AXA ou SNCF, y trouvent un socle commun : transformer la parole des comités en documentation d'entreprise exploitable plutôt qu'en souvenirs épars. Pour un comité de gouvernance IA, c'est la différence entre pouvoir affirmer qu'une décision a été prise et pouvoir la prouver.
FAQ
Qu'est-ce qu'un kill switch pour un agent IA ?
Un kill switch est la capacité technique à désactiver immédiatement un agent IA dès qu'il se comporte de façon anormale, sans attendre une intervention manuelle complexe. Selon l'étude Kiteworks 2026, seules 40 % des entreprises interrogées disposent réellement de cette capacité en production.
Combien d'entreprises peuvent vraiment arrêter un agent IA défaillant ?
Environ 4 entreprises sur 10, selon le Kiteworks 2026 Data Security and Compliance Risk Forecast Report mené auprès de 225 responsables sécurité, IT et risque dans dix secteurs. Les 60 % restants n'ont pas de moyen technique fiable pour couper un agent qui sort de son périmètre prévu.
La gouvernance IA suffit-elle sans moyens techniques de confinement ?
Non. Une charte ou une politique de gouvernance IA fixe des règles, mais ne protège rien tant qu'elle ne s'accompagne pas de moyens réels de limiter, isoler et désactiver un agent défaillant, ainsi que d'une documentation exploitable des décisions prises à son sujet.
Quel est le lien entre traçabilité des réunions et gouvernance des agents IA ?
Chaque décision de déploiement ou de révision d'un agent IA se prend d'abord en comité. Documenter ces réunions de façon structurée, avec les arguments et les actions décidées, fournit la preuve que la gouvernance a réellement fonctionné, utile en cas d'audit, de contrôle réglementaire ou d'incident.
Par où commencer pour auditer ses agents IA en entreprise ?
Par un inventaire complet des agents en production, de leurs accès précis et de leur capacité réelle de désactivation, suivi d'une vérification concrète de l'isolation réseau et de la limitation d'usage, puis d'une documentation systématique des décisions de gouvernance associées.
