L’essentiel en 30 secondes
- Coller code, contrats ou données clients dans un assistant d’IA est un geste de productivité, invisible pour la plupart des contrôles.
- Aucun contrôle unique ne couvre tous les chemins : web, fichier, application de bureau, extension, SaaS, API.
- Pour savoir ce qui sort, rejouez ce geste avec des données synthétiques sur chaque chemin.
43 % des brèches étudiées dans le rapport IBM Cost of a Data Breach 2026 (Ponemon, 602 organisations, publié le 29 juillet 2026) impliquaient du shadow AI, contre 20 % un an plus tôt. Le chiffre a plus que doublé en 12 mois. Derrière ces fuites, il y a rarement un attaquant. Il y a quelqu’un qui veut aller plus vite, colle un contrat dans un assistant, et la plupart de vos contrôles ne voient rien.
Une fuite de données par IA générative se produit quand un collaborateur colle ou téléverse une information sensible (code source, données clients, contrat, chiffres financiers) dans un assistant conversationnel hébergé hors du contrôle de l’entreprise. Pour savoir si vos protections l’arrêtent, rejouez ce geste avec des données synthétiques et regardez ce qui passe.
Pourquoi le prompt est devenu un vrai canal de sortie
Pendant des années, votre DLP a sans doute été pensée autour de canaux identifiés : la messagerie, la clé USB, le partage de fichiers. Le prompt ne rentre dans aucune de ces cases, ce qui complique la détection. C’est un champ de texte dans un navigateur, envoyé en HTTPS vers un domaine qui change selon l’outil (chatgpt.com, claude.ai, gemini.google.com, chat.mistral.ai), parfois depuis une extension, parfois depuis une application de bureau, parfois depuis une fonction d’IA intégrée à un logiciel que vous avez vous-même déployé, comme Copilot dans Microsoft 365.
43 %
des brèches étudiées impliquaient du shadow AI, contre 20 % un an plus tôt.
Source : IBM, Cost of a Data Breach Report 2026, juillet 2026.
3 caractéristiques rendent ce canal difficile :
- Le volume est faible et fragmenté. Un de vos collaborateurs colle 30 lignes de code. Rien à voir avec une archive de 2 Go : vos seuils volumétriques ne se déclenchent pas.
- Le contenu est reformulé. Un collaborateur demande à l’assistant de « résumer ce contrat » : le texte part en clair, souvent sans les marqueurs (en-tête, étiquette de classification) sur lesquels reposent vos règles.
- L’intention est légitime. Bloquer en bloc frustre vos équipes, qui basculent sur leur téléphone personnel. Le risque ne disparaît pas pour autant. Il sort simplement de votre champ de vision.
IA générative : les chemins à cartographier avant de tester
Avant de tester, nous listons avec vous les chemins par lesquels un texte peut atteindre un modèle externe. Chacun sollicite un contrôle différent.
| Chemin | Contrôle censé agir | Angle mort fréquent |
|---|---|---|
| Copier-coller dans l’interface web d’un assistant public (Claude, Gemini, Le Chat de Mistral) | DLP endpoint ou extension navigateur, proxy avec inspection TLS | Navigateur non géré, profil personnel, domaine absent de la catégorie « IA » |
| Téléversement d’un fichier (PDF, tableur, capture) | DLP endpoint, CASB | Analyse limitée au texte, image non inspectée |
| Application de bureau de l’assistant | DLP endpoint, filtrage sortant | Règles écrites pour le navigateur uniquement |
| Extension navigateur avec IA intégrée | Gestion des extensions, DLP navigateur | Extensions installées par l’utilisateur, non inventoriées |
| IA intégrée à un SaaS métier (bureautique, CRM, support) | Paramétrage du SaaS, CASB en mode API | Fonction activée par défaut, hors du périmètre DLP |
| Appel d’API par un script Python ou un développeur | Filtrage sortant, gestion des secrets | Trafic considéré comme technique, donc non inspecté |
Aucun contrôle ne couvre donc à lui seul tous ces chemins. La DLP endpoint, le proxy et le CASB se partagent le travail, et ce qui fuit passe dans les trous entre eux. Pour le comportement de votre proxy sur ces domaines, voyez les angles morts de l’inspection TLS.
Tester le canal des prompts : une méthode en cinq temps
Une règle affichée « active » dans la console peut ne jamais se déclencher. Nous appliquons ici le principe de tout test d’exfiltration de données : rejouer le geste, observer le résultat, consigner la preuve.
- Fabriquer des données synthétiques réalistes. Nous partons de numéros de carte de 16 chiffres valides au sens de l’algorithme de Luhn mais inexistants, IBAN de 27 caractères au format correct, fiches clients synthétiques, extrait de code portant un marqueur unique, document étiqueté « Confidentiel ». La méthode est détaillée dans notre article sur les données synthétiques en production.
- Choisir des postes représentatifs. Un poste standard géré sous Windows, un poste de développeur sous Linux (souvent plus permissif), un poste en télétravail hors VPN. Le résultat varie d’un profil à l’autre, et c’est cette variation qui vous intéresse.
- Rejouer chaque chemin du tableau. Nous collons le texte, téléversons le fichier, reformulons légèrement (retirer l’en-tête, scinder en 2 prompts). Vous mesurez la tolérance de vos règles autant que leur existence.
- Observer 3 résultats distincts. L’action a-t-elle été bloquée ? Une alerte est-elle partie ? Votre SOC l’a-t-il vue, et en combien de minutes ? Un blocage sans journal, ou une alerte que personne ne lit, ce sont deux échecs différents.
- Consigner et rejouer. Une mise à jour de l’assistant, un nouveau domaine, une catégorie modifiée chez votre éditeur de proxy : le résultat d’aujourd’hui ne vaut pas pour le mois prochain. Rejouez donc ces chemins régulièrement, et après chaque changement de ce type.
Scénario concret : le développeur pressé
Un mardi, un développeur colle une fonction contenant une chaîne de connexion synthétique dans un assistant public, via Chrome, son navigateur géré. Le proxy classe bien le domaine en « IA générative » et l’autorise, comme prévu. La DLP endpoint détecte le motif de secret et bloque. Bon résultat. Le même développeur ouvre alors l’application de bureau du même assistant, sous Windows : la règle endpoint ne couvre que les processus navigateur, et le texte part. Aucune alerte. Sans le test, vous ne l’auriez pas vu. C’est un cas typique de faux négatif silencieux, que MITRE ATT&CK range sous T1567, exfiltration par un service web.
Schéma · le développeur pressé
Ce qu’un bon résultat de test doit vous donner
Un test qui se conclut par « 12 scénarios sur 18 bloqués » ne suffit pas. Il vous faut une lecture exploitable :
- quel chemin a laissé passer quel type de donnée, sur quel profil de poste ;
- quel contrôle était censé agir et pourquoi il n’a pas agi (règle absente, périmètre de processus, catégorie d’URL, seuil) ;
- une action corrective précise, classée selon la sensibilité de la donnée et la fréquence du geste ;
- la date du rejeu suivant.
Étape suivante
Que laissent passer vos contrôles vers les assistants d’IA ?
Enforcis 1.0 teste 8 canaux web, réseau et cloud, pas la messagerie ni Microsoft 365 en natif : cet article vous donne la méthode pour ceux-là. En 30 minutes, nous vous montrons une campagne complète sur les 8 canaux, sur notre environnement de démonstration.
Checklist avant votre prochain comité sécurité
- Vous disposez d’une liste à jour des assistants approuvés et de leurs modes d’accès (web, bureau, extension, API).
- Vous savez si les fonctions d’IA intégrées à vos SaaS sont activées, et pour qui.
- Vos règles DLP couvrent le copier-coller et le téléversement, en plus de l’envoi de fichiers.
- Les applications de bureau des assistants sont incluses dans votre périmètre endpoint.
- Chaque chemin a été rejoué au moins une fois avec des données synthétiques, et le résultat est daté.
- Votre SOC reçoit les alertes associées et sait les qualifier.
- Une alternative approuvée existe pour les usages légitimes.
Questions fréquentes
Faut-il bloquer tous les assistants d’IA générative ?
Rarement. Un blocage total sans alternative pousse les usages vers des appareils et des comptes personnels que vous ne voyez plus. Nous conseillons plutôt d’autoriser un outil encadré, de bloquer les autres et de contrôler le contenu envoyé, puis de vérifier par le test que ces trois mesures tiennent.
Une version « entreprise » de l’assistant suffit-elle à régler le problème ?
Elle règle une partie du sujet : conditions contractuelles, conservation, usage pour l’entraînement selon l’offre. Le contenu, lui, sort quand même. Et rien n’empêche un collaborateur d’utiliser la version grand public à côté, sauf un contrôle que vous avez testé.
L’application de bureau d’un assistant d’IA échappe-t-elle à la DLP ?
Le cas se produit si vos règles endpoint ne visent que les processus du navigateur. Dans le scénario du développeur pressé, la DLP bloque sa chaîne de connexion synthétique dans Chrome. Il ouvre alors l’application Windows du même assistant, colle le même texte, et rien ne l’arrête. Aucune alerte. Ajoutez ces applications à votre périmètre endpoint, puis rejouez le chemin avec vos leurres pour vérifier la correction.
Un assistant intégré à vos SaaS, comme Copilot, change-t-il la donne ?
Il change surtout le périmètre. La fonction vit dans un outil déjà autorisé, souvent activée par défaut, et votre DLP réseau ne la voit pas comme un nouvel assistant. Vérifiez qui y a accès et ce qu’elle peut lire, puis rejouez ce chemin avec vos leurres, comme les autres.