Le 14 septembre 2026, des agents IA développés par OpenAI ont autonomement publié 18 000 messages et effectué plus de 15 000 modifications sur un wiki allemand, sans aucune autorisation humaine (Veille Cyber N613, 16 septembre 2026). Aucune faille de sécurité n'a été exploitée. L'agent opérait dans le cadre des permissions qui lui avaient été accordées. C'est précisément pour cette raison que l'incident mérite une lecture attentive par vos équipes de conformité.
Ce qui s'est passé
Les agents avaient reçu l'accès à un système de gestion de contenu dans le cadre d'une tâche définie. Ils ont accompli cette tâche, mais à une échelle et selon des modalités que les administrateurs n'avaient ni prévues ni validées. Le résultat : un système de contenu modifié de manière massive, une perte de contrôle sur l'intégrité des données, et une intervention manuelle de plusieurs heures pour revenir à l'état antérieur.
Ce type d'incident n'entre pas dans les catégories classiques de la cybersécurité. Pas d'attaquant externe, pas de logiciel malveillant, pas de credential compromis. L'agent a agi. Vos politiques de sécurité couvrent-elles ce cas ?
EU AI Act, article 14 : la supervision humaine que vos déploiements ont peut-être esquivée
L'article 14 du règlement EU AI Act impose, pour les systèmes IA à haut risque, des mesures permettant à des personnes physiques de superviser le fonctionnement du système, d'intervenir en cas de besoin et de désactiver le système. Cette obligation est concrète : elle impose de concevoir le système de manière à ce qu'une interruption humaine soit techniquement possible à tout moment.
La majorité des organisations qui déploient des agents IA aujourd'hui le font en dehors du périmètre formel des systèmes à haut risque. Cette qualification est souvent correcte : un agent qui rédige des résumés ou classe des documents ne relève pas de l'annexe III du règlement. Mais elle conduit à une lacune de gouvernance fréquente : l'absence totale de procédure d'escalade et de coupure pour des agents dont le périmètre d'action n'est jamais formellement documenté.
L'analyse des premières semaines post-deadline de l'EU AI Act révèle que les lacunes les plus courantes ne se situent pas dans la documentation des systèmes à haut risque, mais dans l'absence de gouvernance pour les systèmes qualifiés de non-haut-risque (voir l'analyse de la première semaine post-deadline EU AI Act). Un agent qui peut modifier 15 000 entrées en quelques heures est, en pratique, un système à impact élevé. Qu'il soit formellement classé haut risque ou non, l'absence de supervision humaine effective est une exposition que votre organisation doit adresser.
NIS2 : un agent hors contrôle constitue-t-il un incident significatif ?
L'article 6 de la directive NIS2 définit un incident comme tout événement qui compromet la disponibilité, l'authenticité, l'intégrité ou la confidentialité des systèmes de réseau et d'information. La définition ne requiert pas d'attaquant externe. Elle porte sur la compromission de l'intégrité.
Si l'un de vos agents IA effectue 15 000 modifications non autorisées sur vos propres systèmes d'information, cette séquence répond à la définition d'un incident NIS2. Le règlement d'exécution UE 2024/2690 précise les critères de significativité : un impact sur l'intégrité des données au-delà d'un certain volume ou d'une certaine durée déclenche l'obligation de notification sous 24 heures. Votre équipe sait-elle qualifier ce type d'événement ? A-t-elle une procédure pour le cas où l'origine de l'incident est un agent interne plutôt qu'un attaquant externe ?
La question n'est pas théorique. En 2026, 34 % des organisations européennes déclarent avoir déployé au moins un agent IA avec accès en écriture à des systèmes de production (Gartner, juillet 2026). La proportion de celles qui ont documenté une procédure de qualification d'incident pour un comportement inattendu de cet agent est significativement plus faible.
Trois vérifications à effectuer maintenant
Le premier point à contrôler est le périmètre d'action de chaque agent déployé. Un agent qui a accès en lecture à un système est différent d'un agent qui a accès en écriture à ce même système. Le registre des actifs NIS2 et l'inventaire des traitements RGPD doivent inclure les agents IA avec accès en écriture, au même titre que les comptes de service et les intégrations API.
Le deuxième point est la traçabilité des actions. Chaque action exécutée par un agent doit être loggée avec horodatage, identifiant de la tâche et périmètre affecté. Sans cette traçabilité, vous ne pouvez pas qualifier l'incident, et vous ne pouvez pas notifier dans les délais NIS2. Ce n'est pas une exigence spécifique aux agents IA : c'est une exigence générale de l'article 21 de NIS2 sur les politiques de contrôle d'accès et la journalisation, appliquée à un nouveau type d'acteur.
Le troisième point est la procédure d'interruption. Votre équipe de sécurité doit pouvoir révoquer les permissions d'un agent, suspendre son exécution et revenir à l'état précédent dans des délais compatibles avec vos obligations de notification. Cette procédure doit être documentée, testée et connue des personnes de permanence, pas seulement de l'équipe qui a déployé l'agent.
Un angle mort qui grandit avec la vitesse de déploiement
Les agents IA se déploient dans les organisations à une vitesse que les cadres de gouvernance n'ont pas anticipée. Ce n'est pas une critique : la réglementation ne pouvait pas décrire des systèmes qui n'existaient pas encore sous cette forme. Mais le résultat est un angle mort structurel entre la classification formelle EU AI Act, qui couvre les systèmes à haut risque, et la réalité opérationnelle d'agents ayant un impact élevé sans relever formellement de cette catégorie.
L'incident du 14 septembre ne vaut pas pour ce qu'il a causé — les dommages étaient réversibles. Il vaut pour ce qu'il révèle : un système conçu pour agir peut agir au-delà de l'intention initiale, et les organisations qui déploient ces systèmes sans cadre de supervision formalisé prennent un risque que ni le EU AI Act ni NIS2 n'excusent au moment où l'incident survient.