Le rapport 2026 d’IBM sur les violations de données révèle une faille de 92 % dans le contrôle des accès à l’IA

Le rapport 2026 d’IBM sur les violations de données a fait son apparition sur Google News avec un constat saisissant : 92 % des organisations touchées via des systèmes d’IA ne disposaient apparemment pas de contrôles d’accès adéquats.

Ce chiffre est important, car les entreprises n’utilisent plus l’IA uniquement pour rédiger des textes ou résumer des documents. Les modèles et les agents se connectent de plus en plus aux données de l’entreprise, aux services cloud, aux outils logiciels et aux flux de production. Des erreurs d’accès peuvent donc exposer des informations ou autoriser des actions dans plusieurs systèmes.

Le titre illustre également un renversement plus large dans l’IA d’entreprise. Les entreprises ont adopté l’IA pour accroître leur productivité et renforcer leur sécurité, mais beaucoup l’ont déployée sans les protections d’identité habituellement exigées pour les employés et les applications traditionnelles. Les conclusions d’IBM suggèrent que les attaquants ont repéré cette faille.

Le titre d’IBM dans Google News signale une évolution plus large de la sécurité de l’IA

La statistique sur le contrôle des accès est alarmante, mais les conclusions plus générales d’IBM montrent que l’IA influence désormais les deux côtés d’une violation de données.

IBM a publié son rapport 2026 sur le coût d’une violation de données le 29 juillet. L’étude a été menée par le Ponemon Institute, puis financée et analysée par IBM. Elle a examiné les violations subies par 602 organisations dans 17 secteurs entre mars 2025 et février 2026.

Le chiffre annoncé de 92 % concerne les organisations ayant subi des attaques impliquant leurs modèles ou applications d’IA. Concrètement, ces organisations ne disposaient pas de contrôles permettant de limiter de manière fiable qui ou quoi pouvait accéder aux systèmes d’IA affectés.

Le contrôle des accès détermine si une personne, une application ou une identité machine peut atteindre une ressource. Il définit également les actions que cette identité peut effectuer. Pour un agent d’IA, ces autorisations peuvent inclure la lecture de dossiers clients, l’appel d’une interface de programmation applicative, la modification d’un ticket ou le déclenchement d’un flux de travail automatisé.

Cette statistique ne doit pas être interprétée comme la preuve que 92 % de toutes les entreprises ne disposent pas de contrôles d’accès à l’IA. IBM a étudié des organisations ayant subi des violations, et ce chiffre s’applique à un groupe plus restreint confronté à des incidents liés à l’IA. Cette distinction est importante pour évaluer l’ampleur du problème.

Même au sein de ce groupe plus restreint, la conclusion décrit une grave défaillance des contrôles. Plus de 20 % des organisations de l’échantillon d’IBM ont signalé une violation visant des modèles ou des applications d’IA. Les API, applications ou plug-ins compromis représentaient 27 % des causes citées. Les mauvaises configurations cloud affectant les charges de travail d’IA représentaient 27 % supplémentaires.

Ces conclusions détournent l’attention des scénarios spectaculaires dans lesquels un modèle contournerait spontanément la sécurité. Les faiblesses les plus immédiates se situent souvent autour du modèle. Les attaquants peuvent exploiter des interfaces exposées, des comptes de service aux privilèges excessifs, des plug-ins vulnérables et des ressources cloud mal configurées.

Le rapport 2026 d’IBM sur les violations de données replace également les enjeux financiers dans leur contexte. Le coût moyen mondial d’une violation a atteint 4,99 millions de dollars, soit une hausse annuelle de 12 %. IBM a qualifié ce chiffre de record historique.

Les incidents liés à l’IA ont encore modifié cette équation économique. IBM a indiqué qu’une violation malveillante sur quatre était facilitée par l’IA, en hausse de 56 % par rapport à l’année précédente. Ces incidents ont coûté aux organisations 6 millions de dollars en moyenne, soit environ 1 million de dollars de plus que la moyenne mondiale.

Cela ne signifie pas que chaque attaque facilitée par l’IA visait directement un modèle d’IA. IBM utilise cette catégorie pour inclure les attaques dans lesquelles des acteurs malveillants ont employé l’IA, notamment l’usurpation par deepfake et les malwares assistés par IA. Cette distinction sépare les attaques utilisant l’IA des attaques contre les systèmes d’IA.

Ensemble, ces catégories décrivent un risque à double face. Les attaquants peuvent utiliser l’IA pour accroître la vitesse ou l’ampleur de tactiques établies. Ils peuvent également cibler les modèles, agents, magasins de données et interfaces que les entreprises ajoutent rapidement à leur infrastructure.

C’est pourquoi l’angle de Google News ne doit pas être réduit à un pourcentage sensationnaliste. L’événement sous-jacent est une transformation de la surface d’attaque des entreprises, l’IA devenant à la fois un outil pour les attaquants et une cible.

Le véritable point faible se situe autour du modèle

Les chiffres d’IBM indiquent que les défaillances classiques liées aux identités, aux API et au cloud restent au cœur de violations prétendument nouvelles liées à l’IA.

Les discussions sur la sécurité de l’IA se concentrent souvent sur le comportement des modèles, comme les hallucinations, les sorties nuisibles ou l’injection de prompts. Ces risques restent pertinents, mais les données d’IBM pointent vers un problème moins exotique. Les organisations connectent l’IA à des ressources précieuses sans appliquer systématiquement des contrôles de sécurité éprouvés.

Un modèle seul ne peut généralement pas accéder à une base de données clients ni déployer un logiciel. Il obtient cette capacité grâce aux composants qui l’entourent. Ceux-ci comprennent les plug-ins, les identifiants d’API, les systèmes de récupération, les rôles cloud, les comptes de service et les couches d’orchestration des agents.

Chaque connexion augmente le nombre de décisions qu’une organisation doit gouverner. Quels documents le système peut-il récupérer ? Peut-il consulter les dossiers de tous les clients ? Peut-il appeler un service externe ? Peut-il écrire des données, ou seulement les lire ? Son accès expire-t-il à la fin d’une tâche ?

Une identité agentique est l’identité numérique attribuée à un agent d’IA agissant dans des systèmes connectés. Les programmes traditionnels de gestion des identités se concentrent généralement sur les employés, les sous-traitants, les appareils et les charges de travail logicielles. Les agents introduisent une autre catégorie capable de prendre des décisions et d’invoquer des outils avec une implication humaine limitée.

IBM recommande des contrôles dynamiques fondés sur l’identité pour ces agents. L’entreprise préconise également des autorisations strictement limitées, une application des règles en temps réel, une attribution humaine et une activité auditable. L’application des règles en temps réel consiste à vérifier les autorisations pendant le fonctionnement d’un agent, plutôt qu’à approuver un accès étendu une seule fois lors du déploiement.

Cette approche répond à un décalage essentiel. Un employé s’authentifie généralement via un compte connu, tandis qu’un agent peut agir au moyen de plusieurs identifiants partagés. Si les journaux n’enregistrent que le compte de service partagé, les enquêteurs peuvent avoir du mal à déterminer quel agent a lancé une action ou quel employé l’a demandée.

Il en résulte une lacune de responsabilité. Une entreprise peut savoir qu’un jeton d’API a accédé à des données sensibles sans savoir quel modèle, flux de travail ou utilisateur a provoqué la demande. Il devient alors plus difficile d’arrêter une activité inappropriée et de reconstituer ultérieurement une violation.

Le principe du moindre privilège offre une réponse bien connue. Il accorde à chaque identité uniquement l’accès nécessaire à une tâche définie. Son application à l’IA peut toutefois être difficile, car les agents effectuent souvent un travail évolutif en plusieurs étapes.

Des autorisations étendues rendent un agent plus utile dans davantage de situations. Elles augmentent aussi les dommages potentiels causés par un prompt manipulé, un identifiant volé, une décision défaillante ou une intégration compromise. Le même accès qui permet l’automatisation peut élargir le rayon d’impact d’une violation.

Prenons un assistant de recherche interne connecté à des documents, des e-mails, des dossiers clients et des systèmes de projet. Une configuration restreinte pourrait lui permettre de récupérer des fichiers approuvés pour une équipe. Une configuration large pourrait exposer des informations présentes dans les référentiels juridiques, financiers, d’ingénierie et de vente.

La différence de sécurité ne réside pas dans la capacité rédactionnelle du modèle. Elle dépend de la qualité de la frontière d’identité qui entoure ses données et ses outils.

L’accès aux connaissances mérite également une attention particulière. Les organisations souhaitent que les assistants trouvent un contexte pertinent sans exposer toutes les sources à tous les utilisateurs. Une base de connaissances IA soigneusement conçue doit préserver les autorisations sur les sources au lieu de créer une nouvelle voie permettant de les contourner.

Le même problème apparaît dans les flux de travail autonomes. Un agent qui traite des demandes de support peut avoir besoin de lire un profil client et de proposer une réponse. Il n’a pas automatiquement besoin d’être autorisé à exporter la base de données clients, modifier les informations de facturation ou désactiver les paramètres de sécurité.

L’IA peut brouiller ces frontières, car le contexte utile est souvent traité comme un réservoir unique. Lorsque les autorisations disparaissent durant l’indexation, la récupération ou l’exécution d’un agent, le système peut révéler des informations auxquelles l’utilisateur demandeur ne pouvait pas accéder directement.

L’empoisonnement du contexte crée un autre risque. Il survient lorsque des informations trompeuses ou malveillantes intègrent les éléments qu’une IA utilise pour prendre des décisions. Un attaquant peut, par exemple, placer des instructions dans un document qu’un agent récupérera ultérieurement.

Le filtrage traditionnel des sorties ne répond pas pleinement à ce scénario. L’organisation doit contrôler les sources auxquelles l’agent fait confiance, les outils qu’il peut invoquer et déterminer si les actions sensibles nécessitent une approbation. Les journaux doivent aussi conserver suffisamment de contexte pour expliquer la décision.

Les garde-fous d’un modèle et les contrôles d’accès d’une entreprise servent des objectifs différents. Les garde-fous peuvent influencer le contenu produit par un modèle. Les contrôles d’accès déterminent s’il peut atteindre un système de paie, un référentiel de code source ou une console de production.

Confondre les deux peut créer un faux sentiment de sécurité. Un modèle au comportement approprié, mais doté d’autorisations excessives, reste dangereux si ses identifiants sont volés ou si ses entrées sont manipulées. À l’inverse, un accès strictement limité peut restreindre les dégâts, même lorsqu’un modèle se comporte de manière inattendue.

Le rapport d’IBM remet donc en question l’idée selon laquelle la sécurité de l’IA exigerait un univers de sécurité entièrement distinct. De nombreuses défaillances concernent toujours la découverte des actifs, la gestion des identifiants, la configuration cloud, la surveillance et la réponse aux incidents. La nouvelle difficulté consiste à appliquer ces contrôles à des systèmes qui agissent avec une plus grande autonomie.

L’adoption de l’IA a promis de la rapidité, mais les équipes de sécurité ont hérité du risque

Le conflit principal oppose le déploiement rapide de l’IA au travail plus lent de définition des identités, des autorisations, de la propriété et des preuves.

Les équipes d’entreprise sont fortement incitées à déployer l’IA rapidement. Les employés utilisent déjà des assistants grand public, des extensions de navigateur, des services de transcription et des fonctionnalités d’IA intégrées aux logiciels métier. Les unités opérationnelles peuvent souvent activer ces services avant que les équipes de sécurité ne les aient recensés.

Ce comportement produit de l’IA fantôme, c’est-à-dire des outils ou modèles d’IA utilisés sans approbation formelle ni gouvernance. Cela ressemble au shadow IT, mais l’exposition peut dépasser le stockage ou l’acquisition de logiciels. Un modèle non autorisé peut traiter des données sensibles, conserver des prompts, appeler des outils ou influencer des décisions métier.

Les recherches d’IBM en 2025 ont établi une référence importante. À cette époque, 13 % des organisations étudiées ont signalé des violations impliquant des modèles ou des applications d’IA. Parmi ces organisations, 97 % ont déclaré ne pas disposer de contrôles d’accès à l’IA adéquats.

Les conclusions de 2025 ont également révélé que 63 % des organisations victimes de violations ne disposaient pas d’une politique de gouvernance de l’IA ou étaient encore en train de l’élaborer. Seules 34 % des organisations ayant une politique réalisaient régulièrement des audits pour détecter l’IA non autorisée.

Une organisation sur cinq dans cette étude a signalé une violation impliquant de l’IA fantôme. Les organisations ayant un usage élevé d’IA fantôme ont subi des coûts moyens de violation supérieurs de 670 000 dollars à ceux des organisations ayant une utilisation faible ou inexistante de l’IA fantôme.

Le passage de 97 % dans le sous-groupe d’organisations victimes de violations en 2025 aux 92 % rapportés en 2026 suggère une amélioration limitée, et non un problème résolu. Les échantillons et les définitions précises des incidents peuvent différer ; ces pourcentages ne doivent donc pas être considérés comme une mesure annuelle parfaitement comparable.

Néanmoins, les deux chiffres vont dans le même sens. Presque toutes les organisations affectées dans les groupes concernés ne disposaient pas de contrôles adéquats autour de l’accès à l’IA. Cette cohérence est plus significative que l’écart de cinq points.

Les équipes de sécurité subissent des pressions de plusieurs côtés à la fois. Elles doivent repérer les usages de l’IA autorisés et non autorisés, désigner des responsables, classifier les données connectées, gouverner les identités non humaines, examiner les plug-ins et surveiller les actions en temps réel.

Pendant ce temps, les équipes produit étendent les capacités des agents. Un assistant qui se contente de rédiger du texte ne dispose que d’une autorité opérationnelle limitée. Un agent qui met à jour des dossiers clients, fusionne du code, planifie des paiements ou modifie des ressources cloud entre dans une tout autre catégorie de risque.

Cela crée un retard de gouvernance. Les achats peuvent approuver le logiciel alors que les équipes identité ignorent encore l’existence de ses comptes de service. Un développeur peut connecter un agent à des données de production avant que l’équipe confidentialité n’évalue le flux.

L’organisation peut alors se retrouver avec plusieurs visions incomplètes. La sécurité voit le trafic API, l’IT voit les licences, le juridique voit les contrats fournisseurs et les équipes métier voient la productivité. Personne ne détient un inventaire complet de l’agent, de ses données, de ses identifiants et de ses actions autorisées.

Les politiques seules ne peuvent pas combler cet écart. Un document peut interdire aux employés d’envoyer des informations confidentielles vers des modèles publics. Il ne peut pas empêcher cette activité si l’entreprise ne peut pas détecter l’outil, classifier les données et appliquer la restriction.

Les contrôles techniques seuls restent eux aussi insuffisants sans attribution claire des responsabilités. Une plateforme de sécurité peut signaler un accès inhabituel, mais quelqu’un doit déterminer à quoi ressemble une activité normale pour chaque agent. Le responsable doit savoir de quels outils il a besoin et quelles actions doivent exiger l’approbation d’une personne.

La tension s’accentue lorsque les dirigeants exigent une adoption mesurable de l’IA. Les équipes peuvent considérer le nombre de licences activées, de tâches automatisées ou d’employés utilisateurs comme des indicateurs de progrès. Ces métriques récompensent la portée et la vitesse, tandis que les revues de permissions et la préparation aux audits semblent ralentir le déploiement.

Les recherches d’IBM suggèrent que le coût caché apparaît après le déploiement. L’absence de responsable désigné rend les incidents plus difficiles à contenir. Les identifiants partagés compliquent l’attribution des actions. Des accès excessifs permettent à un seul composant compromis d’atteindre davantage de données.

Les organisations les plus sous pression incluent les services financiers et les entreprises énergétiques. IBM a constaté que les secteurs d’infrastructures critiques représentaient 62 % des attaques pilotées par l’IA signalées. Le coût moyen des violations dans les services financiers s’élevait à 6,3 millions de dollars, contre 5,2 millions dans l’énergie.

Ces secteurs exploitent des systèmes interconnectés dont une perturbation peut affecter les clients, les chaînes d’approvisionnement ou les services essentiels. Ils détiennent également des données financières, d’identité, opérationnelles et de propriété intellectuelle de grande valeur. Les intégrations d’IA peuvent créer de nouvelles voies d’accès à ces environnements.

Les développeurs en subissent également les conséquences pratiques. Les revues de sécurité exigent de plus en plus des schémas d’architecture, des inventaires de flux de données, une documentation sur les modèles, la propriété des identifiants et des preuves de test. Une équipe incapable d’expliquer les accès d’un agent aura du mal à démontrer que le déploiement est maîtrisé.

Les acheteurs en entreprise devraient donc regarder au-delà de la simple présence de l’authentification unique. Ils doivent savoir si un produit préserve les permissions à la source, prend en charge des rôles granulaires, sépare les locataires, enregistre les appels d’outils et permet une révocation rapide des identifiants.

Une case à cocher dans un processus d’achat peut confirmer qu’un contrôle existe. Elle ne peut pas établir que chaque agent utilise correctement ce contrôle. Le véritable test consiste à déterminer si une organisation peut retracer une action sensible depuis la personne qui la demande, en passant par le modèle, jusqu’au système cible.

L’IA augmente les coûts des violations tout en les réduisant

Le renversement central mis en évidence par IBM est que l’IA amplifie les attaques, tandis que l’automatisation de la sécurité peut réduire substantiellement le coût qui en résulte.

Le rapport 2026 ne présente pas l’IA comme uniformément nuisible. Les organisations qui utilisaient largement l’IA et l’automatisation dans leurs opérations de sécurité ont économisé en moyenne 1,93 million de dollars par rapport à celles qui n’en utilisaient aucune.

Cette conclusion crée le principal compromis du rapport. Refuser d’utiliser l’IA n’élimine ni les attaquants assistés par IA ni les services tiers vulnérables. La déployer sans précaution peut toutefois ajouter des identités et des chemins de données non gérés.

IBM indique que les attaques activées par l’IA ont augmenté de 56 % sur un an. L’usurpation d’identité par deepfake représentait la catégorie la plus fréquente dans les analyses secondaires, citée par 45 % des répondants. Les malwares et le phishing activés par l’IA ont également contribué à cette hausse.

Ces outils réduisent le coût de production de messages ciblés, d’usurpation de personnes de confiance et de modification de code malveillant. Ils ne suppriment pas le besoin d’un point d’entrée. Les identifiants volés, les services exposés, les logiciels vulnérables et la tromperie humaine restent des éléments essentiels de nombreuses attaques.

L’IA peut aussi aider les défenseurs à trier les alertes, détecter les comportements inhabituels, corréler les événements et contenir les incidents. L’automatisation est importante, car le coût des violations augmente lorsque les organisations mettent plus de temps à découvrir et à corriger les systèmes compromis.

La dirigeante sécurité d’IBM, Suja Viswesan, a présenté le problème comme un déséquilibre économique. Les attaquants peuvent lancer leurs opérations plus rapidement et à moindre coût, tandis que les victimes dépensent des millions pour détecter, contenir et réparer les conséquences d’une violation.

Sa recommandation se concentre sur la réduction du délai entre la découverte et la correction. Cela comprend l’intégration des correctifs dans les workflows de développement, la sécurisation des identités pendant l’exploitation et le traitement des faiblesses à la vitesse à laquelle les attaquants les exploitent.

L’adoption reste inégale. Une organisation sur quatre dans l’étude d’IBM n’avait pas introduit l’IA et l’automatisation dans ses opérations de sécurité. Plus de la moitié utilisait des agents pour la détection et le confinement des menaces, mais seulement 18 % les appliquaient à la gestion des vulnérabilités.

Cet écart est important, car la détection intervient après l’apparition d’une activité suspecte. La gestion des vulnérabilités traite les faiblesses connues avant qu’un attaquant ne les exploite. Une détection rapide ne peut pas compenser des systèmes exposés qui restent non corrigés ou mal configurés.

L’étude IBM a également constaté que 85 % des répondants à une recherche complémentaire prévoyaient d’augmenter leurs dépenses de sécurité après avoir pris connaissance des capacités avancées des modèles frontier. Seuls 64 % avaient prévu une hausse des dépenses après avoir subi une violation dans l’étude initiale.

Ce résultat suggère que les organisations commencent à réagir à des capacités anticipées, et pas seulement à des incidents déjà survenus. Toutefois, l’intention de dépenser ne permet pas d’établir si les investissements amélioreront les contrôles d’identité ou s’ils se contenteront d’ajouter davantage de produits de détection.

La méthodologie du rapport mérite également un examen attentif. IBM et Ponemon ont étudié des organisations ayant subi des violations, et non un échantillon représentatif de l’ensemble des entreprises. Les estimations de coûts combinent plusieurs catégories, dont la détection, l’escalade, les pertes commerciales, la notification et la réponse post-violation.

Le rapport peut identifier des tendances au sein de son échantillon. Il ne peut pas prouver que l’ajout d’un produit de sécurité produira les économies moyennes citées dans chaque organisation. Les grandes entreprises, les secteurs réglementés et les incidents complexes peuvent présenter des structures de coûts très différentes.

Les incitations commerciales des fournisseurs doivent également rester visibles. IBM vend des logiciels et des services de sécurité liés à l’identité, à la protection des données, à la gestion du cloud et à la réponse aux incidents. Son rapport peut contenir des recherches précieuses tout en soutenant un discours commercial.

Cela n’invalide pas les données. Cela signifie que les lecteurs doivent distinguer les résultats mesurés des affirmations prescriptives. L’échantillon montre des associations entre une automatisation étendue de la sécurité et des coûts moyens inférieurs, mais la maturité organisationnelle peut contribuer aux deux.

Un programme de sécurité mature est plus susceptible d’adopter efficacement l’automatisation. Il peut aussi disposer de meilleurs inventaires, d’équipes formées, de plans de réponse testés et d’un soutien de la direction. Ces facteurs peuvent réduire les coûts des violations indépendamment des outils.

Le constat de 92 % sur le contrôle d’accès exige une prudence similaire. Ce pourcentage ne montre pas que l’absence de contrôles a causé chaque incident. Il démontre un fort chevauchement entre les violations liées à l’IA et des contrôles inadéquats dans le groupe concerné.

Les API compromises et les mauvaises configurations cloud fournissent un mécanisme plausible reliant des contrôles faibles aux incidents. Toutefois, la causalité peut varier. Un attaquant peut exploiter une vulnérabilité logicielle même lorsque des politiques d’identité existent, ou voler un identifiant disposant légitimement de privilèges.

Une couverture indépendante a mis en lumière la même double menace. Une analyse sectorielle a relevé que les criminels ciblent à la fois les systèmes d’IA et utilisent l’IA pour accélérer des attaques établies. Ce cadrage reflète mieux le rapport qu’une simple affirmation selon laquelle les modèles causent des violations.

La conclusion pratique n’est pas de choisir entre l’IA et la sécurité. Les entreprises doivent gouverner les déploiements d’IA tout en utilisant l’automatisation là où elle améliore la défense. Le résultat dépend de la capacité des organisations à relier les capacités à une autorité étroitement définie.

Ce que le chiffre de 92 % ne prouve pas

Le titre met en évidence une crise des contrôles, mais il ne révèle pas la qualité des contrôles de chaque organisation et n’établit pas un taux d’incident universel.

Les pourcentages peuvent circuler sur Google News plus vite que leurs définitions. Les lecteurs peuvent rencontrer le chiffre de 92 % sans voir les limites de l’échantillon, la période de recherche ou la distinction entre les attaques activées par l’IA et les attaques ciblant l’IA.

La première incertitude concerne la terminologie. Les « contrôles d’accès appropriés à l’IA » peuvent couvrir plusieurs pratiques, notamment l’authentification, la conception des rôles, la rotation des identifiants, les permissions à la source, les politiques d’exécution et la journalisation d’audit. Une mesure binaire peut masquer de grandes différences de maturité.

Une organisation peut n’avoir aucun contrôle dédié. Une autre peut utiliser des systèmes d’identité établis, mais ne pas les appliquer à un plug-in. Toutes deux pourraient apparaître dans la même catégorie de contrôles inadéquats, même si leur posture de sécurité diffère.

La deuxième incertitude concerne la détection. Les organisations ne peuvent pas signaler les incidents qu’elles ne découvrent jamais. Les entreprises disposant d’une surveillance plus robuste peuvent identifier davantage d’activités liées à l’IA que celles ayant une visibilité limitée, créant une hausse apparente qui reflète en partie une meilleure observation.

Huit pour cent des organisations de l’étude 2025 d’IBM ont déclaré ne pas savoir si des modèles ou applications d’IA avaient été compromis. Cette incertitude illustre le problème d’inventaire. Une entreprise ne peut pas évaluer un modèle dont elle ignore l’existence.

La troisième incertitude concerne la signification d’une violation liée à l’IA. Un attaquant peut cibler un endpoint de modèle, voler des données d’entraînement, exploiter une API associée ou utiliser du phishing généré par IA contre un employé. Ces événements ont des mécanismes différents et exigent des défenses différentes.

L’inversion de modèle, par exemple, vise à déduire des informations sensibles à partir des sorties d’un modèle. IBM a rapporté un coût moyen mondial de 6 millions de dollars pour les violations impliquant ce type d’attaque. Ce scénario diffère d’un bucket de stockage cloud exposé via une application d’IA mal configurée.

L’usurpation d’identité par deepfake diffère encore. Elle utilise des médias synthétiques pour imiter une personne de confiance, souvent afin de manipuler un employé ou un processus métier. Les contrôles d’accès peuvent limiter les dommages qui en résultent, mais la vérification d’identité et les contrôles de processus comptent également.

La quatrième incertitude concerne les comparaisons de tendances. Le rapport 2025 d’IBM a étudié 600 organisations ayant subi des violations entre mars 2024 et février 2025. Le rapport 2026 a étudié 602 organisations au cours des 12 mois suivants.

Ces échantillons de taille similaire permettent une comparaison générale, mais les organisations participantes et la composition des incidents peuvent changer. Les lecteurs ne devraient pas interpréter chaque variation comme une mesure précise du taux mondial de violations.

La cinquième incertitude concerne les moyennes de coûts. Un petit nombre d’incidents coûteux peut faire augmenter une moyenne. Le secteur, la taille de l’entreprise, la réglementation, les perturbations opérationnelles et le temps de rétablissement influencent tous le montant final.

La moyenne mondiale d’IBM est passée de 4,44 millions de dollars en 2025 à 4,99 millions de dollars en 2026. Cette hausse est notable, mais elle ne signifie pas que chaque entreprise doit s’attendre à ce qu’un incident coûte exactement ce montant.

Une approche plus utile consiste à interpréter ces conclusions comme des indicateurs de tendance. Les systèmes d’IA deviennent des composantes importantes de l’infrastructure des entreprises. Les attaquants interagissent avec ces systèmes, et de nombreuses organisations touchées ne leur ont pas étendu les contrôles de base.

Les responsables de la sécurité devraient vérifier si ce chiffre phare correspond à leur propre environnement. Peuvent-ils répertorier chaque modèle et chaque agent ? Peuvent-ils identifier le responsable ? Peuvent-ils voir à quelles sources de données chaque système accède ? Peuvent-ils révoquer ses identifiants sans désactiver toute une plateforme ?

Ils devraient également se demander si les journaux conservent l’attribution humaine. Si un employé demande à un agent de mettre à jour une fiche client, la piste d’audit devrait relier l’employé, l’agent, l’identifiant, l’appel d’outil et la modification finale.

Une surveillance continue est importante, car le comportement d’un agent peut évoluer avec son contexte. De nouveaux outils, prompts, sources de données et versions de modèles peuvent modifier ses actions, même lorsque ses autorisations formelles restent inchangées.

Des analyses externes de la sécurité des agents ont mis l’accent sur les identités, les accès étroitement contrôlés, les actions auditables, les voies d’escalade et les mécanismes d’arrêt d’urgence. Ces mesures traitent l’autonomie comme un risque opérationnel, et non comme un simple problème de qualité des modèles.

Un mécanisme d’arrêt d’urgence est un dispositif qui stoppe un agent ou révoque sa capacité à agir. Il doit fonctionner rapidement et de manière prévisible, surtout lorsqu’un agent peut accéder à des systèmes financiers, de production ou clients.

L’approbation humaine reste également utile pour les actions à fort impact. Un agent peut préparer un paiement, une modification de code ou un changement de compte sans recevoir l’autorité nécessaire pour le finaliser. Cette séparation préserve l’automatisation tout en limitant les conséquences irréversibles.

Les contrôles doivent correspondre au risque. Un assistant qui résume des documents publics nécessite moins de restrictions qu’un agent accédant à des informations sur les patients ou à une infrastructure de production. Appliquer la même politique aux deux peut créer soit des frictions excessives, soit une protection insuffisante.

La valeur de ce chiffre phare réside donc dans les questions concrètes qu’il suscite. Sa limite est qu’il ne peut répondre à ces questions pour chaque organisation.

Trois signaux à surveiller après le rapport 2026 d’IBM

Le prochain test consistera à voir si les entreprises transforment leurs préoccupations en contrôles d’identité mesurables, en correction des vulnérabilités et en résultats vérifiables de manière indépendante.

Le premier signal est l’adoption de contrôles d’identité propres aux agents. Les organisations devraient aller au-delà des clés API partagées et attribuer des identités distinctes aux agents, charges de travail et workflows.

Les signes de progrès incluraient des identifiants de courte durée, des autorisations au niveau des tâches, une attribution humaine et des journaux couvrant chaque appel d’outil. Les fournisseurs de sécurité élargiront probablement leurs offres dans ce domaine, mais les indicateurs d’adoption comptent davantage que les annonces de fonctionnalités.

Si les organisations peuvent inventorier les identités agentiques et les révoquer individuellement, l’avertissement central d’IBM commencera à perdre de sa force. Si les agents continuent d’hériter de comptes de service aux privilèges étendus, le chiffre de 92 % restera pertinent.

Le deuxième signal est de savoir si les équipes de sécurité appliquent l’automatisation à la gestion des vulnérabilités. IBM a constaté que plus de la moitié des organisations utilisaient des agents pour la détection et le confinement des menaces, tandis que seulement 18 % les utilisaient pour la gestion des vulnérabilités.

Ce déséquilibre favorise la réaction plutôt que la prévention. Les progrès impliqueraient de relier les inventaires d’actifs, les données d’exposition, la responsabilité du code et les workflows de correction afin que les faiblesses connues parviennent rapidement à l’équipe compétente.

L’indicateur à suivre n’est pas le nombre d’alertes IA. C’est le délai entre la découverte d’une faiblesse exploitable et le déploiement d’un correctif vérifié. Des délais de correction plus courts appuieraient l’argument d’IBM selon lequel les défenseurs peuvent contrer des attaques plus rapides grâce à l’automatisation.

Le troisième signal est l’existence de preuves indépendantes sur la fréquence et les coûts des violations. Le rapport annuel d’IBM fournit un repère largement cité, mais les acheteurs devraient le comparer aux déclarations réglementaires, aux données d’assurance, aux conclusions des réponses aux incidents et aux recherches évaluées par les pairs.

Des résultats cohérents entre ces sources renforceraient la conclusion selon laquelle de faibles contrôles d’accès à l’IA entraînent des pertes significatives. De fortes divergences suggéreraient que les définitions, l’échantillonnage ou les pratiques de détection expliquent une partie de la tendance.

Les entreprises devraient également surveiller l’évolution du chiffre de 92 % communiqué dans la prochaine étude d’IBM. Une baisse significative, accompagnée de meilleurs résultats d’inventaire et d’audit, indiquerait que la gouvernance rattrape son retard.

Un pourcentage plus faible à lui seul ne suffirait pas. Les organisations pourraient simplement détecter moins d’incidents ou redéfinir ce qui est considéré comme un système d’IA. Une amélioration crédible exige des preuves que les contrôles sont déployés, testés et appliqués en production.

La question plus large est de savoir si l’IA d’entreprise peut passer de l’expérimentation à une infrastructure responsable. Les modèles et les agents interagissent désormais avec des documents, des données clients, du code, des communications et des processus métier. La sécurité doit suivre ces connexions.

Google News peut amplifier cette statistique, mais les conseils d’administration et les équipes techniques doivent la traduire en questions au niveau des systèmes. Quelles identités existent, à quoi peuvent-elles accéder et qui reste responsable lorsqu’un agent agit ?

Les conclusions d’IBM constituent un avertissement, pas un verdict définitif. Les trois prochains mois devraient montrer si les entreprises traitent l’accès à l’IA comme un problème central de gestion des identités ou comme un autre document de politique en attente de mise en œuvre.

Examinez chaque agent IA pouvant accéder à des données sensibles ou déclencher une action externe. Attribuez-lui un responsable désigné, une identité distincte, des autorisations strictement limitées et une piste d’audit remontant jusqu’à la personne à l’origine de la demande. Testez ensuite la capacité de l’organisation à l’arrêter rapidement.

Ce travail est moins spectaculaire qu’un titre de Google News. C’est aussi là que le prochain incident IA coûteux a le plus de chances d’être évité.