Ce que les données de fuites 2025 d'IBM révèlent sur le coût réel du Shadow AI

Un quart de vos effectifs colle déjà des données de l'entreprise dans des outils d'IA que vous ne contrôlez pas, et la facture financière de ce comportement est désormais mesurable. Le rapport 2025 d'IBM sur le coût d'une fuite de données (Cost of a Data Breach Report) donne aux conseils d'administration ce qui manquait au débat sur le Shadow AI : non pas une frayeur, mais un prix. Les fuites qui impliquent un niveau élevé de Shadow AI coûtent en moyenne environ 670 K$ de plus — 4,63 M$ contre 3,96 M$. Cet écart, c'est le coût d'un angle mort, et le rapport est d'une clarté inhabituelle sur les raisons de son existence.

Pour un RSSI qui présente à un conseil, le bon réflexe n'est pas de tirer la sonnette d'alarme. C'est de traduire trois des chiffres d'IBM en la décision de contrôle précise qu'ils imposent — car le même rapport qui quantifie la perte nomme aussi la mesure de protection manquante.

Le chiffre qui devrait recadrer la conversation

Commençons par l'écart phare. Une surcote de 670 K$ sur les fuites impliquant le Shadow AI n'est pas une abstraction ; c'est à peu près la différence entre un incident gérable et un incident important. Associez-le à un second chiffre : 20 % des organisations du rapport ont subi une fuite via le Shadow AI. C'est une sur cinq, et ce n'est pas une projection sur l'avenir — c'est ce qui s'est déjà produit.

Les conseils ont l'habitude de pondérer la probabilité et l'impact. Ici, les deux ont bougé dans le mauvais sens en même temps. La probabilité, c'est un cinquième des organisations. L'impact porte une surcote à six chiffres par rapport à la fuite moyenne, qui s'établit elle-même à 4,44 M$ à l'échelle mondiale et bien plus dans les secteurs réglementés — les fuites aux États-Unis atteignent en moyenne 10,22 M$ et le secteur de la santé 7,42 M$. Ajoutez le Shadow AI à un modèle de menace en santé ou en services financiers, et les chiffres cessent d'être le problème de quelqu'un d'autre.

Ce qui distingue cela de la statistique de fuite habituelle, c'est l'origine de l'exposition. Elle ne passe pas par le périmètre. Elle entre par le navigateur, dans une zone de saisie de prompt, sous les doigts d'un employé qui tente simplement de faire son travail plus vite.

Pourquoi la perte se répète : les contrôles ne sont pas là

Le rapport est direct sur le mécanisme. 97 % des organisations ayant subi une fuite liée à l'IA n'avaient pas de contrôles d'accès à l'IA adéquats. Pas la majorité — la quasi-totalité. C'est une corrélation quasi parfaite entre « nous avons eu une fuite » et « rien ne surveillait l'usage de l'IA ».

Creusez une couche de plus et le constat s'affine. 63 % des organisations n'ont aucune politique de gouvernance de l'IA, et seulement 17 % disposent de contrôles techniques pour caviarder ou bloquer les données sensibles au point d'entrée. Lisez ces deux chiffres ensemble : même parmi la minorité dotée d'une politique, la plupart n'ont aucun moyen de la faire respecter là où les données sortent réellement. Une politique qui dit « ne collez pas de données clients dans ChatGPT » n'est qu'une phrase dans un document. Le chiffre de 17 %, c'est la part des organisations capables d'agir concrètement sur cette phrase au moment où cela compte.

C'est la faille que la plupart des piles de sécurité ne couvrent pas. Les outils traditionnels de prévention des pertes de données ont été conçus pour des fichiers circulant sur les réseaux et par courriel — ils ne voient pas un paragraphe tapé dans un formulaire web et envoyé à un fournisseur d'IA. La zone de saisie de prompt est un canal que les contrôles existants n'ont jamais été conçus pour surveiller.

À quoi ressemble une surcote de 670 K$ dans un seul prompt

Rendons cela concret. Une analyste des revenus est sous pression pour expliquer un écart au conseil. Elle a le modèle trimestriel ouvert — réalisés, prévisions, quelques noms de clients rattachés à des montants de transactions. Elle colle l'onglet pertinent dans un assistant d'IA et lui demande de rédiger le récit. L'ébauche est bonne. Le travail est livré à temps.

Ce qui s'est aussi produit : des données identifiant des clients, des chiffres financiers et de l'information interne sur des transactions ont été soumis à un outil d'IA public. Une fois ce prompt envoyé, il ne peut plus être rappelé. Il peut être conservé, traité par des sous-traitants, ou utilisé pour entraîner le modèle du fournisseur, et le contenu collé devient soumis aux conditions d'utilisation de ce fournisseur. Aucune malveillance, aucun attaquant externe, aucune alerte. Et rien dans l'environnement n'a vu la chose se produire — ce qui correspond exactement à la situation que décrivent les 97 % d'IBM.

Multipliez cette analyste par chaque équipe qui manipule des données sensibles sous la pression des échéances, et vous obtenez la forme de la statistique d'une organisation sur cinq. Le comportement est rationnel pour l'individu et invisible pour l'organisation. C'est cette combinaison que la surcote de 670 K$ chiffre réellement.

La décision de contrôle vers laquelle pointent les données

Le propre cadrage d'IBM resserre les options. La corrélation n'est pas entre les fuites et le fait d'avoir de l'IA — c'est entre les fuites et l'absence de contrôles sur la façon dont l'IA est utilisée. Interdire les outils ne répond donc pas au constat ; les gens migrent vers des comptes personnels et l'usage passe simplement dans l'ombre, ce qui aggrave le problème de visibilité au lieu de l'améliorer. La solution implicite du rapport, c'est le contrôle des 17 % : la capacité de caviarder ou de bloquer les données sensibles au point d'entrée, avant qu'elles ne quittent les mains de l'organisation.

Ce cadrage au point d'entrée compte à cause de l'irréversibilité. Après la soumission, il ne reste plus rien à gouverner — les données sont déjà sorties. Le seul endroit où un contrôle peut changer l'issue, c'est avant que le prompt n'atteigne l'outil d'IA. C'est aussi là que vit l'éducation en temps réel : un prompt arrêté avec une explication claire de ce qui a été signalé apprend à l'analyste pourquoi, et transforme une quasi-fuite en habitude plutôt qu'en incident qui se répète.

C'est le principe sur lequel Sanitized AI est bâti — repérer les données sensibles dans un prompt et les caviarder ou les bloquer avant qu'elles n'atteignent l'outil d'IA, avec un registre des événements de politique destiné à la direction qui ne capture jamais ce que la personne a réellement tapé. Pour un conseil, ce registre est aussi la réponse à la question de la diligence : la preuve que l'organisation est passée des 63 % sans gouvernance vers les 17 % capables d'agir.

Ainsi, la question à apporter à votre prochaine revue des risques n'est pas de savoir si les employés utilisent l'IA — présumez que oui. C'est une question plus tranchante : si un prompt sensible était soumis aujourd'hui, quelque chose dans votre environnement l'aurait-il intercepté avant qu'il ne parte ? Si la réponse honnête est non, vous faites partie des 97 %. Si vous voulez voir à quoi ressemble concrètement la fermeture de cette faille, demandez une démo.