Seules 29% des équipes de sécurité peuvent régulièrement rendre compte des données sensibles que les employés envoient aux outils d’IA

Cet article s’appuie sur les conclusions du rapport d’enquête 2026 de la Cloud Security Alliance (CSA), La prévention des pertes de données à l’ère de l’IA, commandé par Jazz.

En juin et juillet, la CSA a demandé à 433 professionnels de l’informatique et de la sécurité si leur équipe pouvait produire un rapport indiquant combien de fois des données sensibles avaient été envoyées à des outils d’IA générative au cours des 30 derniers jours. Vingt-neuf pour cent ont répondu qu’elle pouvait le produire régulièrement.

Ce chiffre serait moins important si les répondants considéraient l’IA générative comme un canal secondaire. Ils l’ont classée au premier rang des risques d’exfiltration de données, 48 % la plaçant parmi leurs trois principaux risques.

Je dirige l’ingénierie d’une entreprise qui développe des solutions de prévention des pertes de données. L’essentiel de mon travail consiste à déterminer où, au sein d’un système, se trouvent les preuves des transferts de données et pourquoi les risques associés apparaissent. De ce point de vue, l’écart entre ce que les équipes pensent pouvoir voir et ce qu’elles peuvent démontrer découle directement de la façon dont les contrôles de l’IA générative ont été conçus.

La confiance dans la visibilité sur l’IA générative dépasse largement ce que les équipes peuvent démontrer

Un peu plus de la moitié des répondants ont évalué leur visibilité sur l’IA générative à 4 ou 5 sur 5. Pourtant, seules 29 % des équipes pouvaient régulièrement étayer cette évaluation à l’aide d’un rapport indiquant simplement combien de fois des données sensibles avaient été envoyées à un outil d’IA.

Source : Cloud Security Alliance, DLP in the AI Era (2026), n=433. Reproduction à partir des graphiques du rapport, p. 22 et 23.

Les mesures de contrôle suivent la même tendance. Seuls 22 % des répondants bloquent systématiquement les données sensibles sur le canal de l’IA générative. Les supports amovibles, que les répondants ont classés comme présentant le risque d’exfiltration le plus faible, affichent le taux de blocage systématique le plus élevé, à 31 %. Le blocage systématique se concentre sur les canaux équipés des outils les plus anciens.

Source : Cloud Security Alliance, DLP in the AI Era (2026), n=433. Reproduction à partir des graphiques du rapport, p. 23 et 26 ; barres ramenées à 100 % lorsque les arrondis donnaient 99 % ou 101 % pour une ligne.

Jazz a également publié des données de télémétrie issues des environnements de ses clients, en complément de l’enquête. Dans ces données, les organisations utilisaient en moyenne 169,5 outils d’IA différents, dont 9,8 étaient approuvés, ce qui laissait 94,2 % des outils en dehors de la liste approuvée.

Pourquoi cet écart existe : une liste d’outils ne consigne aucun événement

La réponse habituelle aux risques liés à l’IA générative consiste à approuver quelques services d’IA dans le cadre de contrats d’entreprise et à déconseiller ou à bloquer les autres. Le chiffre de 94,2 % montre à quel point cette liste est en décalage avec la réalité. Face à une échéance, un ingénieur utilise l’outil qui résout le problème du jour, car il faut des semaines pour obtenir l’approbation de l’outil autorisé.

Même une liste complète ne permettrait pas de produire le rapport demandé par la CSA. Votre équipe de gestion des incidents, ou un auditeur, vous demandera des précisions sur un événement particulier au cours duquel des données ont quitté l’organisation ; or, une liste d’outils ne consigne aucun événement.

Pour montrer ce qui s’est passé lors de cet événement, il faut connaître quatre éléments : quelles données sensibles étaient concernées, quel outil les a reçues, quel compte a été utilisé et pourquoi la personne les a envoyées.

C’est au niveau du compte que la gouvernance des outils échoue en premier. Un même site web donne accès aussi bien au compte professionnel de votre entreprise, avec ses paramètres de conservation des données et ses conditions contractuelles, qu’au compte personnel gratuit d’un employé, qui ne comporte ni les uns ni les autres. Un outil approuvé utilisé avec une connexion personnelle ne fournit guère plus d’éléments probants qu’un outil non approuvé.

L’objectif est plus difficile à déterminer, alors qu’il permet de savoir si quelque chose s’est mal passé. Une analyste financière qui colle un modèle de revenus dans un chatbot pour corriger une formule erronée fait son travail. Le même geste de la part d’une personne qui a remis sa démission vendredi appelle une tout autre discussion. Ce qui les distingue, c’est le contexte propre à la personne, qui n’apparaît jamais dans les données transmises.

Les contrôles utilisés ne voient chacun qu’un seul point

L’enquête n’a révélé aucune méthode dominante pour contrôler les données sensibles envoyées aux outils d’IA. Le blocage au niveau du réseau des domaines d’IA, l’inspection du contenu dans le navigateur et les politiques d’utilisation acceptable prises isolément ont chacun recueilli entre 21 % et 23 %, tandis que les plateformes d’IA d’entreprise dotées d’une fonction intégrée de prévention des pertes de données ont obtenu 10 %.

Chacun de ces contrôles a été conçu autour d’un seul point d’inspection. Le blocage d’un domaine autorise ou interrompt une connexion et consigne le site auquel elle aboutit. Une extension de navigateur voit ce qui est saisi dans ce navigateur, mais ne détecte rien de ce qui est envoyé depuis une application de bureau, un assistant de programmation intégré à un éditeur de code ou un outil en ligne de commande. La fonction intégrée de prévention des pertes de données d’une plateforme d’IA d’entreprise voit ce qui entre dans cette plateforme. Chacun de ces contrôles choisit un seul endroit où chercher et espère que les données y passeront.

Le point d’inspection unique explique également les chiffres du blocage. Si un contrôle ne peut pas distinguer un compte professionnel d’un compte personnel, ni un copier-coller habituel d’un copier-coller risqué, il doit tout bloquer ou ne rien bloquer. Le blocage systématique entrave alors les activités légitimes autant que les activités risquées. Interrogés sur la principale raison pour laquelle ils n’étaient pas passés à un blocage actif plus étendu, 46 % des répondants ont cité la crainte de perturber les processus de travail, et 39 % leur manque de confiance dans la précision des outils de prévention des pertes de données.

Réserves à garder à l’esprit

Les chiffres de l’enquête sont autodéclarés, et celle-ci n’a pas comparé les niveaux de visibilité déclarés à la couverture réelle. Les répondants sont majoritairement issus des Amériques (80 %) et d’organisations comptant moins de 5 000 employés (67 %) ; les résultats ne sont donc pas nécessairement transposables de manière uniforme aux grandes entreprises mondiales. Les données de télémétrie proviennent d’organisations qui ont choisi de déployer ce type de dispositif de visibilité, ce qui peut biaiser les résultats en faveur de celles qui s’inquiétaient déjà de la prolifération des outils d’IA.

Les outils approuvés et les agents rendront la liste encore moins fiable

À mesure que les produits SaaS approuvés intègrent des assistants d’IA, la question de savoir quel outil a reçu les données admet souvent deux réponses : l’application ouverte par l’employé et le fournisseur du modèle d’IA qui la sous-tend. Les agents d’IA compliquent encore les choses. Lorsqu’un agent récupère un fichier et l’envoie quelque part pour le compte d’un employé, le qui et le pourquoi relèvent désormais en partie du logiciel. Comme le soutient un récent article de Unite.AI sur les attaques par injection de prompt dans les agents en production, un agent peut être influencé par le contenu qu’il lit ; son propre récit de ses actions ne peut donc pas tenir lieu de preuve de son objectif.

Un test à réaliser ce mois-ci

Examinez les 30 derniers jours et choisissez la donnée la plus sensible qui, selon vous, a été transmise à un outil d’IA. Vérifiez ensuite si votre équipe peut fournir les éléments suivants sans devoir les reconstituer manuellement :

• La nature des données et leur provenance
• L’outil qui les a reçues, y compris les outils ne figurant pas sur votre liste d’outils approuvés
• Si elles ont été transmises au moyen d’un compte d’entreprise ou d’un compte personnel
• La tâche sur laquelle la personne travaillait au moment de leur envoi

Si vous obtenez rapidement les deux premières réponses, mais que les deux dernières nécessitent d’interroger l’employé, votre gouvernance couvre la liste de vos outils, mais très peu vos données.