Le rapport d’évaluation comparative de la résilience de CYGNVS révèle des lacunes dans la préparation aux incidents liés à l’IA

Le Rapport de référence CYGNVS sur la résilience, élaboré par CYGNVS en partenariat avec Marsh Risk, met en évidence un écart croissant entre le recours à l’IA par les organisations et leur capacité à gérer les incidents qui y sont liés. S’appuyant sur plus de 9 500 réponses à des enquêtes autodéclarées, le rapport indique que 89 % des organisations interrogées ont connu une forme d’incident lié à l’IA, tandis que 46 % improviseraient leur réponse à un tel incident.

Publié le 13 octobre 2026, le rapport examine un problème qui prend de l’ampleur à mesure que l’IA passe de la génération de contenu à l’exécution de processus opérationnels. Donner à un agent accès à des documents, à des courriels et à des systèmes d’entreprise peut le rendre utile. Cela rend aussi plus difficile à contenir une instruction erronée, des identifiants exposés ou une suite d’actions incontrôlée.

Les résultats suggèrent que l’adoption de l’IA et la préparation à réagir à ses défaillances progressent à des rythmes différents. Environ 80 % des organisations de l’échantillon utilisent l’IA générative, mais seule une sur trois soumet ses systèmes d’IA à des tests contre les attaques. La présence d’un comité de gouvernance de l’IA, signalée par les trois quarts des organisations qui utilisent l’IA, ne se traduit pas nécessairement par des mesures de défense opérationnelles testées.

Ce que le rapport considère comme un incident lié à l’IA

Le chiffre mis en avant doit être replacé dans son contexte. Le rapport adopte une définition large des incidents liés à l’IA, qui englobe les hallucinations préjudiciables, les biais, la dérive des modèles, les fuites de données, les agents poursuivant des objectifs non prévus, les défaillances entre agents interagissant entre eux et l’insuffisance des garde-fous. Ces événements peuvent avoir des causes et des conséquences très différentes.

Une réponse inexacte adressée à un client et un agent qui divulgue des informations confidentielles relèvent tous deux de cette définition élargie, mais ne constituent pas des incidents de sécurité équivalents. Le chiffre de 89 % doit donc être interprété comme le témoignage d’une expérience d’une forme ou d’une autre d’incident lié à l’IA, et non comme la preuve que près de neuf organisations sur dix ont subi une violation imputable à l’IA. Le rapport indique également que 16 % des organisations sont confrontées à un incident lié à l’IA au moins une fois par semaine, sans établir que ces incidents présentent tous le même degré de gravité.

Cette distinction compte dans la planification de la réponse. Une production préjudiciable d’un modèle peut nécessiter le retrait du contenu et un examen des décisions concernées. Un agent agissant par l’intermédiaire d’outils connectés peut nécessiter la révocation d’autorisations, la conservation des journaux d’activité et l’identification des modifications apportées à plusieurs systèmes. Un plan d’intervention classique en cas d’intrusion peut couvrir une partie de l’une ou l’autre de ces réponses, mais les équipes doivent tout de même savoir quelles mesures propres à l’IA elles peuvent prendre et qui est habilité à les prendre.

Les plans sont courants. Les plans applicables le sont moins.

Le rapport organise la préparation autour de quatre étapes : préparer, s’exercer, intervenir et rendre compte. À chacune d’elles, la faiblesse récurrente tient à l’écart entre le fait de disposer de procédures écrites et celui de pouvoir les appliquer sous pression.

• Préparer : 92 % des organisations disposent de procédures écrites de réponse aux incidents, mais seules 37 % ont des plans d’intervention propres aux rançongiciels et 29 % disposent de plans pour les incidents impliquant des tiers.
• S’exercer : 17 % n’organisent pas d’exercices sur table. Par ailleurs, 66 % en organisent une fois par an ou tous les deux ans.
• Intervenir : 67 % n’ont pas clairement désigné de responsables pour leurs processus et dépendances les plus critiques.
• Rendre compte : 69 % reconnaissent d’importantes lacunes dans la tenue des registres indiquant qui a fait quoi et à quel moment.

Par ailleurs, plus de six organisations sur dix indiquent que le nombre d’incidents a augmenté au cours des 12 mois précédents, et 84 % réexaminent leurs plans d’intervention une fois par an ou moins. Ces chiffres décrivent différents aspects de la préparation, mais, ensemble, ils soulèvent une question pratique : à quelle vitesse un plan devient-il obsolète lorsque les systèmes, les fournisseurs et les autorisations qu’il décrit ne cessent d’évoluer ?

Dans le cas des déploiements d’IA, ces changements peuvent inclure un nouveau modèle, une source de données supplémentaire ou l’autorisation d’exécuter une tâche auparavant manuelle. Chacun d’eux peut modifier la réponse requise en cas de défaillance. Un plan doit désigner le responsable du système concerné, les moyens de confinement disponibles et les éléments de preuve à préserver pendant le confinement.

Pourquoi l’infrastructure d’intervention doit avoir son propre périmètre

Seules 33 % des organisations interrogées disposent d’un environnement de commandement dédié, hors bande, que l’IA faisant l’objet de l’enquête ne peut ni observer ni influencer. Le problème architectural est simple : une équipe d’intervention a besoin d’un espace de coordination fiable, même lorsque l’environnement touché ne l’est plus.

Prenons l’exemple d’un agent qui a accès à des documents partagés et à la messagerie de l’entreprise. Si les intervenants consignent leurs notes d’enquête et leurs plans de confinement dans ces mêmes systèmes, les autorisations de l’agent peuvent également lui donner accès à la réponse. Cela ne signifie pas que tout agent défaillant cherchera à dissimuler son comportement. Cela signifie que l’architecture d’intervention ne doit pas dépendre du bon fonctionnement du système touché.

CYGNVS répond à ce besoin grâce à une plateforme qui coordonne les équipes de sécurité, les responsables d’entreprise et les spécialistes externes. Son centre de commandement des incidents liés à l’IA comprend des plans d’intervention propres à l’IA, des scénarios d’exercice et des consignes de réponse. L’entreprise indique que cet environnement fonctionne indépendamment du système d’authentification unique, de la messagerie et de l’infrastructure d’entreprise de ses clients.

Ses fonctionnalités hors bande comprennent des identités distinctes pour les utilisateurs et un mode d’isolement qui limite l’espace de travail consacré à l’incident aux participants autorisés. L’entreprise mentionne également des instantanés historiques et des attestations d’accès signées numériquement, qui permettent de documenter les activités menées en réponse à l’incident. Ces fonctionnalités servent à coordonner les interventions et à gérer les éléments de preuve ; leur efficacité dépend toutefois de la façon dont les organisations configurent les accès, attribuent les responsabilités et s’entraînent à les utiliser.

Les exercices doivent inclure les personnes qui prennent les décisions

Seulement 15 % des organisations interrogées dans le rapport organisent des exercices sur table pleinement transversaux, auxquels participent les équipes juridiques, les dirigeants et les équipes de communication. Près de la moitié considèrent encore ces exercices principalement comme des exercices de sécurité et d’informatique, et font appel aux autres fonctions au besoin.

Résultat : les décisions importantes ne sont pas suffisamment préparées. Une équipe de sécurité peut être en mesure de désactiver une intégration, mais un dirigeant peut devoir approuver l’interruption d’un service destiné aux clients. Les équipes juridiques et de communication peuvent devoir évaluer ce qui peut être dit avant la fin de l’enquête. S’exercer à ces relais permet de repérer les lacunes en matière de pouvoir décisionnel et les hypothèses contradictoires.

Les prestataires externes constituent une autre dépendance. Bien que 88 % des organisations déclarent disposer de plans de communication de crise, plus de quatre sur dix n’ont pas encore obtenu l’expertise externe sur laquelle reposent ces plans. Les listes de contacts et les accords contractuels sont des éléments opérationnels de la préparation, en particulier lorsque plusieurs organisations risquent d’avoir besoin des mêmes spécialistes lors d’un incident de grande ampleur.

Comment interpréter le rapport de référence

La méthodologie décrit plus de 9 500 questionnaires recueillis entre janvier 2023 et septembre 2026 dans 21 secteurs d’activité, au sein de pays d’Asie, d’Europe et d’Amérique du Nord. Les réponses ont été fournies par les répondants eux-mêmes, anonymisées et analysées de manière agrégée. L’ensemble de données comprend des organisations qui ont connu un incident cyber ou lié à l’IA critique au cours des 24 mois précédents, ainsi que des organisations qui n’en ont pas connu.

Il s’agit d’un recueil de réponses à des enquêtes menées sur plusieurs années, et non d’un nouveau sondage unique auprès de 9 500 entreprises distinctes. La méthodologie publiée ne garantit pas que l’échantillon probabiliste soit représentatif de toutes les organisations et n’indique pas la taille de l’échantillon pour chaque résultat mis en avant. Les pourcentages donnent des indications utiles au sein de l’ensemble de données, mais ne doivent pas être considérés comme des estimations précises de la prévalence des incidents à l’échelle de l’ensemble des organisations.

Le rapport constate que les organisations ayant récemment connu des incidents critiques tendent à afficher de meilleurs niveaux de préparation selon plusieurs critères. Cette corrélation justifie d’examiner les changements apportés par ces organisations, mais ne prouve pas à elle seule que l’expérience d’un incident a entraîné ces progrès. CYGNVS vend également des logiciels de gestion des interventions ; cet intérêt commercial doit donc être pris en compte lors de l’évaluation de ses recommandations.

Transformer les résultats en changements opérationnels

En parallèle du rapport, CYGNVS lance sa fonctionnalité d’analyse comparative de la résilience, qui, selon l’entreprise, permet aux clients de comparer leur niveau de préparation par secteur d’activité, taille et zone géographique. Les organisations qui ne sont pas clientes peuvent réaliser gratuitement une évaluation et obtenir un rapport personnalisé d’analyse comparative. Le rapport et l’évaluation sont accessibles depuis la ressource de CYGNVS consacrée à la résilience.

Le principal enseignement consiste à tester des actions concrètes : qui peut suspendre un agent, où les intervenants communiquent si les systèmes de l’entreprise sont compromis, quels dossiers restent accessibles et si des spécialistes externes peuvent intervenir sans qu’il faille improviser des accès d’urgence. Mesurer ces capacités donne aux conseils d’administration et aux responsables de la sécurité une vision plus claire de la préparation que la simple existence d’une politique.

À mesure que les organisations élargissent les pouvoirs accordés à l’IA, leur capacité à répondre aux incidents doit évoluer en parallèle. Le rapport de référence sur la résilience de CYGNVS met en évidence cette lacune. Pour la combler, les équipes doivent transformer leurs intentions écrites en décisions et en mesures de contrôle qu’elles ont déjà mises en pratique.