Par Olivia Dubois
·
1 août 2026
Le sujet tient en une phrase : le DLP centré sur les fichiers ne suffit plus face aux usages IA dans le SaaS. Aujourd’hui, une fuite passe souvent par un prompt, un copier-coller ou une automatisation entre outils, pas par une pièce jointe. Et le trou de visibilité est net : 68 % des utilisateurs ne déclarent pas leurs usages IA, tandis que 92 % des organisations n’ont pas de vue complète sur leurs agents et assistants IA.
En lisant cet article, je retiens surtout ceci : pour garder le contrôle, je dois voir les usages IA, classer les données sensibles, puis agir au moment exact de l’échange avec des règles de blocage, d’alerte ou de masquage. Le but n’est pas de tout fermer. Le but est de laisser travailler les équipes sans laisser partir des données RH, finance, clients ou R&D.
En bref :
| Point à vérifier | Ce que je cherche |
|---|---|
| Visibilité | Quels outils IA sont utilisés, par qui, et sur quelles données |
| Détection | RH, finance, clients, code, clés API, données perso |
| Contrôle | Prompt, copier-coller, fichier, automatisation |
| Réponse | Blocage, alerte, masquage |
| Traçabilité | Journaux, règles appliquées, suivi dans le temps |
La suite de l’article détaille ces angles morts, les méthodes de détection et les couches de contrôle à mettre en place pour reprendre la main sans freiner l’adoption.
Les fuites ne passent plus seulement par des fichiers. Elles passent aussi par le navigateur, les invites IA et les automatisations SaaS. Le risque se loge d'abord dans des gestes de tous les jours, discrets, presque banals, et pourtant souvent hors du radar des contrôles classiques.
Le scénario est simple. Un collaborateur copie un extrait de contrat dans ChatGPT, « juste pour résumer », ou colle une liste de clients dans un assistant IA, « juste pour rédiger un mail ». Aucun fichier n'est envoyé. Mais la donnée, elle, a déjà quitté le périmètre de l'entreprise.
Ce qui passe le plus souvent entre les mailles du filet, ce sont les échanges de texte hors du flux fichier : copier-coller, prompt, commentaire, automatisation. Cette exfiltration sans fichier transite par une zone de texte dans un navigateur, parfois depuis un compte personnel, hors de tout tenant géré par l'entreprise. Même problème avec les automatisations SaaS-to-SaaS, qui déplacent des données entre CRM, ERP et outils d'IA sans contrôle précis.
Les situations les plus sensibles touchent les RH, la finance, le juridique, les ventes et la R&D : salaires, données M&A, exports CRM, code source, clés API.
Sur le papier, ces usages semblent légitimes. L'utilisateur est authentifié. L'action est volontaire. Mais dès que ces échanges sortent des garde-fous de l'entreprise, des données sensibles peuvent partir avec. Le point de rupture n'est pas toujours l'intention. C'est souvent le geste.
Les expositions les plus fréquentes se regroupent ainsi :
| Catégorie de données | Scénario d'exfiltration concret |
|---|---|
| Finance & M&A | Coller des tableurs financiers ou des documents M&A dans un outil IA |
| Données clients | Copie de listes issues du CRM vers un assistant externe pour rédiger des messages personnalisés |
| R&D / Technique | Collage de code source propriétaire ou de clés API dans un assistant de débogage |
Le point commun de ces cas saute aux yeux : ils sortent du champ de détection pour lequel le DLP historique a été pensé. Face au trafic HTTPS, aux interfaces de chat et aux automatisations SaaS-to-SaaS, le DLP classique ne voit ni ce qui passe dans une fenêtre de navigateur, ni ce qu'un agent IA autonome envoie via une API vers un service externe.
| Dimension | DLP classique | AI DLP |
|---|---|---|
| Canal principal | E-mail, partages de fichiers, SaaS géré | Prompts dans le navigateur, interfaces de chat, comptes personnels |
| Méthode de détection | Signatures, empreintes, patterns réseau | Analyse textuelle en temps réel, interception côté navigateur |
| Angles morts | Copier-coller, prompts, SaaS-to-SaaS | Usages hors navigateur, applications natives non gérées |
Un autre angle mort pèse encore plus lourd : 92 % des organisations n'ont pas de visibilité complète sur leurs identités IA [2] - ces agents autonomes capables d'accéder à des systèmes critiques comme Salesforce ou SAP - et 86 % n'ont pas de politiques d'accès spécifiques pour ces identités IA [2]. En clair, une partie des flux est maintenant pilotée par des agents IA non gouvernés, sans supervision directe.
Ces angles morts ne se corrigent pas avec une pile de règles en plus. Ce qui change la donne, c’est la lecture du contexte. En clair, l’AI DLP s’appuie sur trois leviers : classifier les données, repérer les anomalies, puis appliquer des contrôles selon la situation.
Les solutions AI DLP modernes combinent plus de 350 types de données préconfigurés avec du machine learning pour repérer les données sensibles dans les documents, tableurs, prompts et chats [1]. Pour les entreprises françaises, cela comprend la détection native du NIR, de l’IBAN, des bulletins de paie et même de codes projets internes comme PROJ-.*-CONF.
Et ce n’est pas limité aux fichiers stockés quelque part dans un dossier. La détection s’applique aussi au texte collé dans un navigateur, à un prompt saisi dans un outil IA, ou à un fichier comme employees.csv envoyé dans Claude [4].
Repérer la donnée, c’est une première étape. Mais seule, elle ne suffit pas. Il faut ensuite la rapprocher de l’usage réel pour savoir s’il y a un risque ou non.
Le signal ne vient pas seulement du contenu. Il vient du croisement entre ce qui est manipulé et la manière dont cela est fait.
Un export CRM massif, puis une série de prompts envoyés vers un service IA externe à des heures inhabituelles : là, on a un vrai signal. Même logique pour une requête sur des données salariales transmise à un copilot.
Cette détection repose sur l’analyse d’anomalies comportementales, comme :
Quand les usages IA ne sont pas déclarés d’eux-mêmes, cette couche d’analyse devient souvent le seul moyen de voir ce qui resterait sinon invisible.
Ce signal sert ensuite à alimenter les politiques de blocage, d’alerte ou de masquage.
Au lieu d’un blocage bête et méchant, les politiques contextuelles permettent une réponse graduée selon le niveau de risque réel.
| Mode d'action | Déclencheur typique | Impact sur la productivité |
|---|---|---|
| Bloquer | Code source, clés API, fichiers financiers vers un outil non géré | Élevé - arrêt de l'action |
| Avertir | Données PII dans un prompt, export partiel de CRM | Modéré - demande de justification |
| Masquer / pseudonymiser | Noms, e-mails, NIR, IBAN dans un prompt de rédaction | Faible - traitement transparent |
Le mode Masquer / pseudonymiser est particulièrement utile. Il anonymise automatiquement les données personnelles avant qu’elles n’atteignent le fournisseur IA. Résultat : l’employé peut continuer à utiliser l’outil pour résumer ou rédiger, sans exposer les vraies données [4].
Autrement dit, on garde la main sans casser l’usage.
Repérer un risque, c’est une chose. Le bloquer, le tracer et le gouverner, c’en est une autre. Ici, la réponse tient en trois couches fonctionnelles : contrôle natif, contrôle réseau et contrôle navigateur.
Microsoft Purview et Google Workspace gèrent la classification, l’étiquetage et les règles de partage sur les fichiers, les e-mails et les espaces de travail collaboratifs. Pour l’IA, ils couvrent aussi les échanges avec les outils maison, comme Microsoft 365 Copilot et Google Gemini pour Workspace.
Purview permet par exemple de définir des règles DLP qui s’appliquent aussi aux prompts envoyés à Copilot [3]. En clair, on peut bloquer l’envoi de fichiers non étiquetés ou déclencher une alerte si un utilisateur colle des données sensibles dans une conversation.
Le point fort est clair : ces contrôles marchent bien dans l’écosystème interne. Mais dès que l’usage sort du cadre Microsoft ou Google, la couverture baisse nettement. C’est là que la limite apparaît.
Netskope et Zscaler regardent le trafic web et SaaS pour repérer les applications IA non sanctionnées. Avec son AI Security Suite, Zscaler inventorie les services, les modèles et les agents GenAI utilisés, les classe par niveau de risque et applique des règles d’accès fines, comme la lecture seule ou le blocage des envois [3].
Autrement dit, ces outils répondent surtout à une question simple : l’utilisateur peut-il accéder à cet outil IA ou non ?
En revanche, la visibilité réseau s’arrête vite. Elle permet de voir le service utilisé, mais pas ce que l’utilisateur colle dans le prompt au mot près.
Le point le plus sensible reste l’échange lui-même : le prompt, le copier-coller, l’envoi de fichier. C’est précisément là qu’Avanoo intervient. La solution agit au niveau du navigateur, donc à l’endroit exact où l’action se produit.
Elle intercepte les prompts, les actions de copier-coller et les envois de fichiers en temps réel, avant que les données n’atteignent le fournisseur IA [4]. Avec les modes Alerter ou Remplacer, elle peut masquer discrètement des données sensibles sans bloquer le travail de l’utilisateur [4].
Avanoo cartographie aussi les SaaS et les usages IA non déclarés, identifie quels outils accèdent à des données sensibles et centralise la gestion des accès avec des contrôles automatisés alignés sur le RGPD, NIS2 et DORA. En juin 2026, Efficy a déployé Avanoo pour reprendre le contrôle de ses usages numériques et sécuriser ses interactions IA [1][2].
Le rôle de chaque couche se résume ainsi :
| Couche | Outils | Ce qu'elle couvre | Limite |
|---|---|---|---|
| Contrôle natif | Purview, Workspace | Fichiers, e-mails, IA interne (Copilot, Gemini) | Données sorties de l'environnement Microsoft ou Google |
| Contrôle réseau | Zscaler, Netskope | Trafic web, découverte de l'IA non déclarée, accès SaaS | Contenu des prompts, copier-coller |
| Contrôle navigateur | Avanoo | Interactions navigateur, IA non déclarée, conformité RGPD/NIS2/DORA | Applications hors navigateur, appareils non gérés |
La vraie question, maintenant, c’est la couverture sur le terrain, la précision de détection et la vitesse de déploiement.
Après avoir repéré les angles morts, l'étape suivante est simple sur le papier, mais plus délicate en pratique : vérifier si le programme peut les couvrir sans casser les usages.
Le point de départ, c'est l'équilibre. Une solution AI DLP doit limiter les fuites de données, tout en laissant les équipes travailler avec les outils d'IA dont elles ont besoin.
La couverture doit aller au-delà des documents classiques. Elle doit aussi inclure les prompts, le copier-coller et les fichiers envoyés vers les outils d'IA. Sinon, on surveille la porte d'entrée tout en laissant les fenêtres ouvertes.
Autre point clé : la précision. La détection sur les données RH, financières et clients doit être assez fine pour éviter une avalanche de faux positifs. Si l'outil bloque tout, les équipes vont vite chercher des chemins de contournement.
Voici les critères à vérifier pendant l'évaluation :
Une fois les critères posés, il faut passer du diagnostic à l'exécution.
Les organisations qui traitent l'AI DLP comme un programme de gouvernance - appuyé sur la classification des données, l'analyse comportementale et la visibilité SaaS - peuvent reprendre la main sans freiner l'adoption.
Shadow AI Expert & Chief AI Officer
Olivia Dubois est Shadow AI Expert et Chief AI Officer chez Avanoo. Diplômée d'HEC Paris et ancienne consultante chez BCG, elle accompagne les entreprises dans la détection et la gouvernance du Shadow AI et du Shadow IT.
Découvrez comment Avanoo peut cartographier votre paysage SaaS et IA, réduire les risques et optimiser les coûts. Une plateforme fiable avec un accompagnement humain dédié.
