Le Wavestone AI Cyber Benchmark 2026 révèle une gouvernance en avance sur la sécurité opérationnelle

Wavestone a publié un benchmark 2026 qui met en évidence un contraste net : les organisations gouvernent bien mieux l’IA qu’elles ne la sécurisent après son déploiement. Le Wavestone AI Cyber Benchmark 2026 a constaté que 88 % de son panel disposaient de mécanismes de gouvernance. Pourtant, seules 8 % relient les journaux des applications d’IA à la surveillance des centres opérationnels de sécurité.

Cet écart est important, car les organisations assument davantage de responsabilités pour leurs systèmes d’IA. La moitié des organisations évaluées conçoivent désormais des systèmes à partir de frameworks existants ou de modèles préentraînés, contre 35 % en 2025. Quarante pour cent supplémentaires gèrent l’ensemble de la chaîne de développement.

Le benchmark mesure donc davantage que les progrès réalisés dans la rédaction de politiques. Il reflète un transfert du risque opérationnel des fournisseurs de technologies vers les équipes d’ingénierie, de sécurité, de données et métiers des entreprises. Ces équipes sont désormais responsables de systèmes capables de récupérer des informations sensibles, d’appeler des outils et d’exécuter des actions.

La conclusion centrale de Wavestone est inconfortable. La gouvernance peut autoriser un système d’IA, mais cette autorisation ne le rend ni observable, ni récupérable, ni sûr lors d’un incident. Les organisations qui progressent le plus rapidement vers les modèles personnalisés et les workflows agentiques sont confrontées à la forme la plus importante de ce problème.

Le Wavestone AI Cyber Benchmark 2026 révèle un vaste écart de contrôle

Les organisations ont mis en place une gouvernance de l’IA plus rapidement que les contrôles opérationnels nécessaires pour contenir les défaillances, enquêter sur les incidents et restaurer des systèmes de confiance.

Wavestone a publié le benchmark le 14 septembre 2026. Son panel couvre 30 grandes organisations publiques et privées. L’évaluation intègre également les observations issues des travaux de conseil du cabinet sur la sécurité de l’IA au cours des trois années précédentes.

Le cadre utilise cinq fonctions adaptées du NIST Cybersecurity Framework. Chaque fonction comprend plus de 30 questions d’évaluation, notées sur une échelle de maturité allant de zéro à 100 %.

Les résultats diminuent à mesure que les fonctions se rapprochent des opérations de sécurité en production :

• Govern a obtenu 54 %.

• Identify a obtenu 55 %.

• Protect a obtenu 48 %.

• Detect a obtenu 40 %.

• Respond a obtenu 29 %.

Le score le plus élevé concerne l’identification des risques, tandis que le plus faible concerne la réponse lorsque le risque devient un événement réel. Cette répartition étaye la conclusion de Gérôme Billois, associé chez Wavestone : les organisations sont plus compétentes pour gouverner l’IA que pour l’exploiter de façon sécurisée en production.

Les résultats détaillés renforcent ce contraste. Selon le benchmark 2026, 88 % du panel avaient mis en œuvre des mécanismes de gouvernance de l’IA. Toutefois, seules 32 % avaient clairement défini les activités, les parties prenantes et les modèles de responsabilité.

Cette distinction sépare une politique d’un modèle opérationnel. Une politique peut exiger des revues de sécurité sans identifier qui surveille un système approuvé. Elle peut imposer une escalade sans établir qui enquête sur une base de connaissances compromise.

Le tableau des compétences reste tout aussi inégal. Seules 44 % des organisations ont identifié des experts dédiés à la sécurité de l’IA capables d’accompagner les équipes techniques et métiers tout au long du cycle de vie du système.

Les organisations ont davantage progressé dans les tests. Deux tiers réalisent des tests d’intrusion dédiés à la sécurité de l’IA, tandis que la moitié mène des évaluations avancées axées sur l’IA. Cinquante pour cent intègrent des évaluations de l’IA dans leurs programmes récurrents d’audit et de tests d’intrusion.

Néanmoins, un test capture un système à un instant donné. Les modèles, sources de récupération, autorisations, intégrations et comportements des utilisateurs évoluent après le déploiement. Une évaluation réussie ne peut remplacer une visibilité continue sur ces changements.

La méthodologie du benchmark impose également la prudence. Ses pourcentages décrivent 30 organisations évaluées, et non l’ensemble du marché mondial. Wavestone avertit explicitement qu’il ne faut pas interpréter le panel comme une estimation représentative du marché.

Même avec cette limite, la tendance interne est significative. Les contrôles associés à l’approbation et à l’évaluation sont bien plus répandus que ceux liés à la détection, à l’enquête et à la reprise. C’est là la véritable information du benchmark.

Les entreprises passent de la consommation d’IA à la maîtrise de l’IA

L’écart de sécurité prend davantage d’importance à mesure que les entreprises construisent une plus grande part de leur pile IA et héritent de responsabilités auparavant assumées par les fournisseurs.

En 2025, 30 % du panel de Wavestone se contentaient d’utiliser des fonctionnalités d’IA fournies par des produits existants. Cette part est tombée à 10 % en 2026. Ce changement signale un mouvement décisif au-delà de la consommation passive.

La moitié du panel 2026 conçoit en interne des systèmes d’IA à partir de frameworks existants ou de modèles préentraînés. Cette proportion est passée de 35 % un an auparavant. Les organisations gérant l’ensemble de la chaîne de développement sont passées de 35 % à 40 %.

Ces catégories impliquent des obligations de sécurité différentes. Une entreprise qui consomme une fonctionnalité d’IA gère principalement l’exposition des données, l’accès des utilisateurs, la configuration et le risque fournisseur. Une organisation qui construit un système de récupération doit également sécuriser son pipeline de données, sa base de données vectorielle, ses connexions aux modèles et sa logique applicative.

Une base de données vectorielle stocke des représentations mathématiques utilisées pour récupérer des informations pertinentes dans une réponse d’IA. Si des attaquants manipulent ce référentiel, le système peut récupérer du contenu empoisonné sans compromettre le modèle sous-jacent.

Le problème de la maîtrise s’étend aux référentiels de connaissances. Les organisations considèrent souvent les documents internes comme des informations métier gouvernées, mais non comme des composants actifs d’une surface d’attaque IA. La récupération change cette hypothèse, car les informations stockées peuvent influencer directement le comportement du système.

Wavestone a constaté que 72 % du panel avaient commencé à mettre en œuvre des mesures de protection de la vie privée pour l’entraînement de l’IA. Soixante-cinq pour cent effectuaient des contrôles de qualité des jeux de données. Seules 9 % évaluaient systématiquement à la fois la qualité et la sécurité des jeux de données avant la mise en production.

Les contrôles de qualité déterminent si les données sont exactes, complètes et adaptées à une tâche. Les contrôles de sécurité déterminent si les données ont été manipulées, exposées ou obtenues par une voie non autorisée. Un processus ne peut se substituer à l’autre.

Les contrôles des fournisseurs offrent un autre exemple. Les plateformes cloud et de modèles fournissent une authentification, des journaux, des filtres et des mécanismes de protection de configuration. Pourtant, ces protections ne couvrent que les responsabilités conservées par le fournisseur.

Seules 11 % du panel de Wavestone avaient commencé à évaluer ou à mettre en œuvre des protections allant au-delà des contrôles natifs des fournisseurs. Cela devient plus préoccupant lorsque les équipes ajustent finement les modèles, auto-hébergent des composants ou relient des agents à des outils internes.

Le benchmark ne soutient pas que les organisations devraient éviter le développement interne. Construire des systèmes peut améliorer le contrôle sur l’architecture, l’emplacement des données et les dépendances. Cela rend également l’organisation responsable de la sécurisation de chaque composant ajouté.

Les résultats de 2025 de Wavestone pointaient déjà vers cette question. Ils distinguaient les utilisateurs d’IA des organisations orchestrant des modèles tiers et des développeurs avancés créant des systèmes propriétaires.

Les résultats de 2026 montrent que davantage d’organisations sont entrées dans les catégories les plus exigeantes. Leurs programmes de sécurité n’ont pas progressé de manière uniforme avec cette transition.

C’est pourquoi la sécurité opérationnelle de l’IA exerce désormais une pression sur plusieurs équipes. L’ingénierie doit produire une télémétrie exploitable. Les opérations de sécurité doivent l’interpréter. Les équipes d’identité doivent limiter les autorisations, tandis que les responsables métiers doivent décider de ce que les agents peuvent faire.

La documentation et les connaissances opérationnelles consultables deviennent également importantes durant cette transition. Les équipes ont besoin de registres d’appropriation à jour, de dépendances système, de décisions et de procédures de réponse. Une base de connaissances consultable maintenue peut soutenir ce travail, même si elle ne peut remplacer les contrôles de sécurité.

La gouvernance de la sécurité de l’IA n’est pas synonyme de contrôle en production

Le principal enjeu oppose une gouvernance documentée à un contrôle appliqué en continu, et non les organisations disposant de politiques d’IA à celles qui n’en ont pas.

La gouvernance crée des limites nécessaires. Elle peut définir les usages acceptables, classer la criticité des systèmes, attribuer des exigences de revue et établir des voies d’escalade. Ces fondations sont précieuses, mais elles n’exploitent pas automatiquement le système.

Le contrôle opérationnel pose des questions différentes. L’organisation peut-elle détecter les comportements suspects ? Peut-elle isoler un agent ? Les enquêteurs peuvent-ils reconstituer ce qui s’est passé ? Les équipes peuvent-elles restaurer un modèle, un jeu de données ou un référentiel de connaissances de confiance ?

Le Wavestone AI Cyber Benchmark 2026 a constaté que 88 % des organisations collectent les journaux des applications d’IA. Seules 8 % acheminent ces journaux vers la surveillance des centres opérationnels de sécurité.

Il ne s’agit pas principalement d’un échec de collecte de données. Il s’agit d’un échec d’intégration entre les opérations IA et les opérations de sécurité.

Les équipes applicatives d’IA surveillent généralement la latence, le coût, la qualité des sorties, les requêtes échouées et les performances des modèles. Les équipes de sécurité recherchent les identités compromises, les accès anormaux, les entrées malveillantes, l’extraction de données et les modifications non autorisées.

Le même événement peut sembler différent à chaque groupe. Une hausse des appels d’outils peut indiquer un workflow populaire, une boucle d’agent défectueuse ou une attaque. Une détection utile nécessite du contexte à la fois de l’application et de l’environnement de sécurité.

La journalisation doit aussi répondre à un objectif défini. Collecter des prompts sans événements d’accès, invocations d’outils, versions de modèles, sources de récupération ou décisions d’autorisation peut laisser aux enquêteurs un dossier incomplet.

Le AI RMF Core du NIST traite la surveillance post-déploiement, la réponse aux incidents, la reprise et la gestion des changements comme des résultats liés. Il appelle également à mettre en place des processus documentés pour suivre les incidents et erreurs, et s’en remettre.

Cette approche fondée sur le cycle de vie entre en conflit avec l’approbation ponctuelle. Un système d’IA peut évoluer sans version logicielle conventionnelle. Un fournisseur peut mettre à jour un modèle, une équipe peut remplacer une source de récupération, ou des administrateurs peuvent étendre les autorisations d’un agent.

Ces changements peuvent invalider des hypothèses antérieures. Une revue ayant approuvé la récupération de documents en lecture seule ne dit presque rien d’un workflow ultérieur capable de modifier des enregistrements ou d’envoyer des messages.

Le même problème affecte les tests. Deux tiers du panel de Wavestone réalisent des tests d’intrusion dédiés à la sécurité de l’IA. Toutefois, le benchmark estime que les organisations matures doivent rendre les tests récurrents plutôt qu’exceptionnels.

Les tests récurrents doivent suivre les changements importants. Ces changements incluent de nouveaux modèles, outils, jeux de données, ajustements fins, périmètres d’accès et étapes autonomes. Le programme de test doit également couvrir l’ensemble du portefeuille IA de l’organisation.

L’analyse automatisée peut détecter des composants vulnérables et des erreurs de configuration. Elle ne peut pas reproduire entièrement les interactions adverses impliquant des instructions ambiguës, un contexte empoisonné ou plusieurs outils connectés.

Le red teaming de l’IA traite ces interactions au moyen de tests adverses structurés. Pourtant, même le red teaming ne fournit que des éléments probants sur les conditions testées, et non une garantie permanente. La surveillance et la réponse doivent prendre en charge les comportements que les tests ne détectent pas.

L’écart entre gouvernance et opérations reflète donc des tâches distinctes. La gouvernance décide de ce qui devrait se produire. La sécurité opérationnelle détecte lorsque la réalité s’écarte de cette décision et donne aux équipes un moyen d’intervenir.

L’IA agentique transforme les faibles contrôles d’identité en risque métier

Un agent d’IA disposant d’un accès excessif peut transformer une entrée trompeuse ou une erreur de modèle en une action métier non autorisée.

L’IA agentique désigne des systèmes capables de planifier des tâches, d’appeler des outils et d’exécuter des actions avec une supervision humaine limitée. Cette capacité fait évoluer l’objectif de sécurité : il ne s’agit plus de contrôler le texte généré, mais les comportements autorisés.

Trente-trois pour cent du panel de Wavestone avaient intégré le risque lié à l’IA agentique dans leurs cadres de gouvernance. Seuls 17 % incluaient l’accès sécurisé aux fonctions et outils d’IA dans leurs standards de développement.

Le taux de mise en œuvre est encore plus faible pour les contrôles d’identité. À peine 15 % disposaient de garanties dédiées de gestion des identités et des accès pour les systèmes et agents d’IA.

Cet écart est important, car les agents relient des décisions probabilistes de modèles à des systèmes d’entreprise déterministes. Un modèle peut sélectionner une action à partir d’un contexte incertain, mais la base de données ou le workflow en aval exécute cette action de manière concrète.

Le risque ne nécessite pas un modèle malveillant. Un document manipulé, une injection indirecte de prompt, une demande ambiguë ou une étape de planification défaillante peuvent rediriger un agent pourtant légitime.

L’OWASP décrit l’autonomie excessive comme un comportement dommageable rendu possible par un excès de fonctionnalités, de permissions ou d’autonomie. Ses recommandations préconisent des outils limités, des privilèges minimaux, une autorisation en aval et le suivi des activités.

Ces contrôles placent l’application des règles en dehors du modèle. Ce choix de conception est important, car demander à un modèle de contrôler ses propres permissions crée une dépendance circulaire.

Prenons un agent interne de recherche qui lit des fichiers et prépare des synthèses. Il doit accéder à des référentiels approuvés, mais n’a probablement pas besoin de droits de suppression. Son connecteur de fichiers ne devrait exposer que les opérations nécessaires.

Un agent de service client présente un risque différent. Il peut consulter les informations de compte, accorder des crédits et modifier les paramètres de service. Chaque action nécessite une limite définie, une vérification d’autorisation et une trace d’audit.

Un agent logiciel peut interagir avec le code source, les outils de suivi des tickets, les systèmes de déploiement et l’infrastructure cloud. Utiliser une identité privilégiée unique dans ces systèmes complique l’attribution et augmente l’impact potentiel d’une seule défaillance.

Le principe du moindre privilège limite chaque agent au plus petit ensemble nécessaire de ressources et d’actions. Des identifiants à courte durée de vie réduisent la durée d’exposition. Des identités propres à chaque agent facilitent la traçabilité de l’activité.

Les actions à fort impact peuvent également nécessiter une approbation humaine. Le contrôle doit s’appliquer avant l’exécution, et non après que le modèle a déjà modifié un système critique.

Wavestone souligne que les actions des agents doivent rester limitées, traçables et interruptibles. L’interruption exige davantage qu’un bouton d’arrêt dans une interface utilisateur. Les équipes de sécurité ont besoin d’un moyen fiable de révoquer les identifiants et de bloquer les accès en aval.

L’AI Controls Matrix propose un cadre de contrôle plus large pour les systèmes d’IA basés sur le cloud. Son édition 2026 comprend 247 objectifs répartis dans 18 domaines de sécurité.

La disponibilité des cadres n’est toutefois pas la principale contrainte. Le benchmark montre que les organisations reconnaissent déjà de nombreux risques au niveau de la gouvernance. Leur mise en œuvre dans l’architecture applicative et les opérations de sécurité reste la tâche la plus difficile.

L’IA agentique rend cette mise en œuvre urgente. Un chatbot soumis à des contrôles faibles peut divulguer des informations ou produire une réponse nuisible. Un agent soumis à des contrôles faibles peut aussi agir sur la base de cette réponse.

La réponse aux incidents et la reprise restent les maillons les plus faibles

Les organisations ne peuvent pas revendiquer une résilience opérationnelle lorsque la plupart ne disposent pas d’enquêtes, de plans de réponse et de pratiques de reprise standardisées propres à l’IA.

Le benchmark de Wavestone attribue à Respond le score de maturité le plus faible, à 29 %. Les mesures qui le soutiennent expliquent pourquoi.

Seules 8 % des organisations évaluées pouvaient mener des enquêtes forensiques sur des plateformes d’IA. La forensique de l’IA consiste à reconstituer les prompts pertinents, les contenus récupérés, l’activité des outils, les versions des modèles, les permissions et les changements de système.

La moitié du panel recourait encore à une remédiation ad hoc, sans processus de réponse structuré. Seules 13 % disposaient de plans documentés de réponse aux incidents spécifiques à l’IA, et Wavestone indique que ces plans n’étaient pas appliqués de manière systématique.

La reprise était également limitée. Vingt-deux pour cent sauvegardaient les actifs liés à l’IA, selon des pratiques largement non standardisées.

Une sauvegarde applicative traditionnelle peut préserver le code et les bases de données. Un service d’IA peut dépendre d’actifs supplémentaires, notamment de configurations de modèles, de données de fine-tuning, d’embeddings, de politiques de sécurité, de prompts et de sources de connaissances externes.

Rétablir la disponibilité ne rétablit pas la confiance. Un référentiel de connaissances restauré peut encore contenir des documents empoisonnés. Un agent restauré peut conserver des identifiants compromis ou des permissions dangereuses.

Le premier défi de la réponse est la classification. Les équipes doivent distinguer les événements de sécurité des défaillances de fiabilité, des violations de politiques, des erreurs de modèle et des erreurs ordinaires d’utilisateurs. Certains incidents relèvent de plusieurs catégories.

Une action non autorisée d’un agent peut commencer par une injection de prompt, exposer des données et créer des enregistrements incorrects. Les intervenants peuvent avoir besoin d’expertises en sécurité, confidentialité, droit, ingénierie, risque lié aux modèles et métiers.

Le deuxième défi est la preuve. Les enquêteurs ont besoin de données synchronisées entre les services de modèles, les systèmes d’identité, les composants de récupération, les passerelles d’outils et les applications cibles. L’absence de contexte peut empêcher toute reconstitution.

Le chiffre de 88 % de Wavestone concernant la journalisation peut donc sembler plus rassurant qu’il ne l’est réellement. Les logs n’aident la réponse que si les équipes conservent les bons événements, les corrèlent et les mettent à la disposition des enquêteurs.

Le troisième défi est le confinement. Les organisations doivent savoir comment désactiver un agent, révoquer ses identifiants, mettre un jeu de données en quarantaine, changer de modèle ou suspendre un outil connecté sans provoquer de perturbations plus larges.

Le quatrième défi est la reprise. Les équipes ont besoin d’un état connu comme fiable et d’un test d’intégrité avant de remettre le système en service. Sinon, la reprise peut restaurer la même vulnérabilité ou les mêmes informations compromises.

Cette complexité opérationnelle explique pourquoi la maturité de la réponse reste en retard sur la gouvernance. Les politiques peuvent souvent s’appuyer sur les structures existantes de gestion des risques. La réponse aux incidents d’IA exige de nouvelles preuves techniques, des procédures interéquipes et des exercices.

Le petit panel du benchmark demeure une limite importante. Ces pourcentages ne doivent pas devenir des affirmations concernant toutes les grandes entreprises. Les organisations qui se sont portées volontaires pour des évaluations détaillées peuvent également différer du marché dans son ensemble.

La méthode de mesure a également évolué. Wavestone a élargi son évaluation 2026 afin d’inclure la sécurité des agents, les protections spécialisées, la surveillance et la réponse. Les comparaisons directes d’une année sur l’autre devraient donc se concentrer sur des mesures clairement équivalentes.

Néanmoins, le schéma observé correspond aux recommandations établies en matière de risques. Le profil d’IA générative du NIST met l’accent sur la documentation des incidents, la journalisation, le signalement et le partage d’informations tout au long du cycle de vie.

L’interprétation sceptique n’est pas que la gouvernance a échoué. Elle est que la maturité de la gouvernance peut créer un faux sentiment de confiance lorsque les preuves opérationnelles restent limitées.

Une politique peut satisfaire un jalon interne. Elle ne démontre pas qu’une équipe de sécurité peut détecter une récupération compromise, retracer les actions d’un agent ou restaurer un système digne de confiance.

Trois signaux montreront si les opérations rattrapent leur retard

La prochaine étape de la maturité de la sécurité de l’IA se mesurera à travers une télémétrie connectée, des permissions d’agent applicables et une reprise répétée en exercice.

Le premier signal est le pourcentage d’organisations qui injectent les événements d’IA dans une surveillance de sécurité active. Wavestone a constaté un écart de 80 points entre la collecte des logs applicatifs et leur intégration à la surveillance du SOC.

Combler cet écart exige des cas de détection définis, et pas simplement la transmission de chaque enregistrement. Les équipes devraient identifier les événements indiquant une récupération suspecte, une escalade de privilèges, une utilisation inhabituelle d’outils ou une tentative d’extraction de données.

Les preuves d’amélioration comprendraient des alertes testées, des playbooks d’investigation et une responsabilité partagée entre les équipes IA et SOC. Un document de politique supplémentaire ne résoudrait pas le déficit opérationnel.

Le deuxième signal est l’adoption de contrôles d’identité dédiés aux agents. Le résultat actuel de 15 % montre que la reconnaissance par la gouvernance a devancé l’application technique.

Les progrès devraient se manifester par des identités d’agent distinctes, des accès étroitement définis, des identifiants à courte durée de vie et des autorisations appliquées au sein des services en aval. Les actions à fort impact devraient être soumises à des exigences d’approbation explicites.

Ce signal gagnera en importance à mesure que les organisations introduiront des agents dans la finance, les opérations client, la livraison logicielle et les workflows de connaissances internes. Chaque outil supplémentaire élargit les conséquences d’un accès excessif.

Le troisième signal est la capacité des organisations à exercer la reprise après incident spécifique à l’IA. Un plan écrit est utile, mais les équipes doivent tester le confinement, l’enquête, la restauration et la validation de l’intégrité.

Les exercices devraient couvrir les jeux de données compromis, les sources de connaissances empoisonnées, les identifiants divulgués, les modifications dangereuses de modèles et les actions non autorisées d’agents. Ils devraient aussi vérifier si l’organisation peut poursuivre ses activités critiques pendant le confinement.

Ces signaux renforceront ou affaibliront l’évaluation centrale de Wavestone. Une meilleure intégration à la surveillance montrerait que la gouvernance passe aux opérations. De meilleurs contrôles d’identité montreraient que les politiques relatives aux agents deviennent applicables.

Des exercices de reprise réussis apporteraient la preuve la plus solide. Ils montreraient que les organisations peuvent garder le contrôle lorsque la prévention échoue, plutôt que de supposer que chaque protection fonctionnera.

Le Wavestone AI Cyber Benchmark 2026 présente un compromis que les dirigeants d’entreprise ne peuvent résoudre par un simple ralentissement de l’adoption. Un développement plus internalisé peut améliorer l’autonomie et le contrôle de l’architecture, mais il transfère également la responsabilité en interne.

Les responsables de la sécurité devraient exiger des preuves derrière chaque jalon de gouvernance. Quels systèmes envoient des événements exploitables au SOC ? Quelles permissions d’agent peuvent être révoquées immédiatement ? Quels actifs d’IA disposent de procédures de reprise testées ?

Les responsables de l’ingénierie et des métiers devraient poser des questions parallèles. Qui est responsable de chaque système déployé après son approbation ? Quels changements déclenchent une réévaluation ? Quel humain peut arrêter une action autonome avant qu’elle n’atteigne une application critique ?

La question décisive n’est plus de savoir si une organisation dispose d’une politique d’IA. Elle est de savoir si cette organisation peut détecter, contenir, enquêter et se rétablir lorsqu’un système d’IA se comporte hors des attentes.