Contexte et objectifs de l’étude

Le rapport Breaking Analysis No. 333, réalisé avec le cabinet Qualitate, interroge 25 responsables de la sécurité et de la résilience cyber. L’objectif était de mesurer comment les organisations gèrent deux pressions simultanées : la protection contre des adversaires qui utilisent l’intelligence artificielle et la mise en place de garde‑fous pour leurs propres projets d’IA en production. L’accent a été mis sur les scénarios où un agent IA, autorisé, commet une erreur et déclenche des actions non prévues.

Méthodologie et principaux résultats

Les chercheurs ont mené des entretiens approfondis avec les 25 participants, couvrant les pratiques de gestion d’identité d’agent, de permissions, de surveillance et de réponse aux incidents. Trois questions clés ont structuré l’enquête : la capacité à reconstruire l’action de l’agent, à identifier les effets en cascade sur les systèmes et à récupérer les processus métier affectés. Parmi les répondants, seulement quatre organisations ont déjà réalisé un exercice – complet ou partiel – de scénario d’incident IA. Deux d’entre elles ont testé la détection d’un comportement anormal, et trois ont évalué la surveillance et la reconstruction d’activités d’agent. Aucun cas ne montre une validation d’une récupération d’entreprise de bout en bout.

Analyse des écarts de confiance

Le rapport révèle un « trust gap » : la confiance affichée dans la capacité de récupération dépasse largement les preuves concrètes. Un cadre de santé a déclaré ne jamais avoir mené d’exercice de table‑top dédié à l’IA, tout en se disant « hautement confiant » parce que les scénarios ressemblent à des incidents non‑IA déjà gérés. Cette confiance repose souvent sur des playbooks de ransomware ou d’incident traditionnel, qui ne couvrent pas les spécificités d’un agent capable d’agir sur plusieurs systèmes simultanément. La vitesse, l’échelle et l’interconnexion des actions d’un agent augmentent la difficulté de reconstituer la chaîne d’événements, ce qui rend les tests de récupération plus complexes que les simulations classiques.

Implications et recommandations

Les données indiquent que les outils existants – systèmes d’identité, journaux d’applications, solutions de protection des données – sont rarement validés pour suivre un flux complet d’activité d’agent. Sans une visibilité unifiée, la reconstruction d’un incident IA reste fragmentaire. Les organisations doivent donc :

1. Étendre les exercices de table‑top aux scénarios d’erreur d’agent, en incluant la reconstruction d’actions à travers plusieurs couches d’infrastructure.

2. Déployer des capacités de détection large, au moins deux des 25 répondants disposaient d’une telle visibilité, ce qui montre un besoin urgent d’élargir la couverture.

3. Normaliser la surveillance et la reconstruction en intégrant les logs d’applications, les traces d’API et les métadonnées d’exécution d’IA dans une plateforme centralisée.

En l’absence de ces mesures, les entreprises risquent de sous‑estimer les impacts d’une mauvaise décision d’agent, ce qui pourrait entraîner des interruptions de service prolongées et des pertes de données sensibles. Le passage d’une confiance intuitive à une confiance basée sur des preuves mesurées constitue le principal levier pour combler le fossé de confiance identifié.