EmencyDes articles à volonté, pour les curieux.
Tendances

DLP IA : limiter les fausses alertes sans freiner

Seuils de confiance, phase d'observation à blanc et exclusions suivies : trois leviers pour calmer les alertes tout en gardant la protection.

I
Par Inès Salaün
Bordeaux · 2 novembre 2026 · 6 min de lecture
Bureau calme au crépuscule avec ordinateur portable, carnet et tasse de café près d'une fenêtre

Pour réduire les faux positifs d'une DLP qui lit les prompts, il faut régler la précision de la détection, observer les règles sans bloquer avant de les appliquer, puis entretenir les exclusions dans la durée. Une alerte inutile coûte de la confiance : plus elle se répète, plus les salariés cherchent à contourner l'outil. Le but n'est pas d'alerter moins, mais d'alerter juste.

Pourquoi un excès d'alertes finit-il par faire abandonner l'outil ?

Parce qu'une alerte qui ne protège rien fait perdre du temps et apprend aux équipes à l'ignorer. Netwrix définit, dans un article publié le 26/09/2026, le faux positif DLP comme une alerte déclenchée par un transfert qui n'a jamais mis de données sensibles en danger.

Dans un prompt, le cas est courant : un numéro de commande pris pour un IBAN, ou un extrait de code d'exemple pris pour une clé d'API. Le salarié bloqué à tort ne comprend pas pourquoi et finit par utiliser un outil non surveillé, ce qui crée un risque pire que celui qu'on voulait éviter.

Le même article de Netwrix souligne que les dérogations demandées par les utilisateurs sont le seul canal par lequel ils signalent directement que la règle s'est trompée. Les relire régulièrement est donc l'une des sources de réglage les plus utiles.

Quels réglages de détection limitent les fausses alertes ?

Le premier levier est le niveau de confiance des types d'informations sensibles. Selon la documentation de Microsoft Purview, publiée le 24/07/2026, un niveau de confiance élevé renvoie le moins de faux positifs mais peut laisser passer davantage de cas, tandis que les niveaux bas ou moyens font l'inverse.

Trois réglages se combinent :

  • Le seuil de comptage. Microsoft recommande, dans la même documentation, d'associer les motifs à confiance élevée à de petits nombres d'occurrences, de cinq à dix, et les motifs à faible confiance à des nombres plus élevés, à partir de vingt.
  • La proximité. La même page décrit la distance, en nombre de caractères, entre un élément principal (un numéro) et un élément de support (un mot-clé voisin). Resserrer cette distance évite de déclencher sur des éléments sans rapport dans un long prompt.
  • Le retour des utilisateurs. Purview permet de signaler si un élément est réellement une correspondance ou non (« Match » ou « Not a Match ») et d'utiliser ces retours pour affiner les types d'informations, d'après Microsoft.

Comment tester une règle sans gêner personne ?

En la faisant tourner en mode simulation avant de l'appliquer. D'après Microsoft, une politique en simulation s'exécute comme si elle était appliquée, mais sans aucune action réelle, et la simulation peut durer jusqu'à quinze jours, ce qui évite de juger sur un instantané. Une autre page de Microsoft, publiée le 26/06/2026, recommande de passer par cette simulation pour toute nouvelle politique ou modification, puis d'examiner les alertes pour mesurer la précision.

Une méthode en cinq étapes en découle :

  1. Limiter le périmètre : Netwrix conseille de démarrer en surveillance, avec un champ étroit et pas plus de cinq cas d'usage dans la première phase.
  2. Simuler la règle et relire les alertes avec les équipes métier concernées.
  3. Ajuster les niveaux de confiance, les seuils et la proximité en fonction des faux positifs constatés.
  4. Passer à l'action (avertissement, puis blocage) sur les cas où la précision est jugée suffisante.
  5. Dater chaque exception : selon Netwrix, « every exclusion needs a named owner and an expiry date », faute de quoi les exclusions s'accumulent en angles morts.

Que prévoient les principaux outils pour analyser les prompts ?

Chaque outil a ses limites propres, qu'il vaut mieux connaître avant de régler quoi que ce soit.

Pour Microsoft 365 Copilot, la documentation Purview du 16/10/2026 indique que la DLP ne vérifie que le texte saisi dans le prompt, pas le contenu des fichiers téléversés. Elle précise que la prise en charge se limite aux types d'informations sensibles fournis d'origine et à ceux que l'on crée soi-même, que les alertes, les notifications et la simulation sont également disponibles, et qu'une modification de politique peut mettre jusqu'à quatre heures à s'appliquer.

Côté passerelle, la documentation de Cloudflare explique qu'AI Gateway analyse les prompts envoyés aux modèles comme les réponses reçues, avec les mêmes profils de détection que Cloudflare One. Un changement de profil s'applique partout où il est utilisé, et une réponse bloquée est remplacée par une erreur de statut 400.

Selon ZeusLock (zeuslock.ai), éditeur français de « DLP IA » pensée pour la souveraineté, la solution repère les données sensibles, les anonymise en préservant leur structure, ou les bloque (clés d'API, identifiants, IBAN, données personnelles, code source) avant leur envoi vers les IA génératives. Elle couvre ChatGPT, Claude, Gemini, Copilot, Cursor, Perplexity, Grok, Mistral et DeepSeek.

CritèreMicrosoft Purview (Copilot)Cloudflare AI GatewayZeusLock (faits communiqués par la marque)
Ce qui est analyséTexte saisi, pas les fichiers téléversésPrompts et réponsesDonnées sensibles avant envoi vers les IA
Mode d'essai à blancSimulation prise en chargeNon indiqué sur la page citéeNon indiqué
Réponse possibleAlertes et notificationsRéponse remplacée par une erreur 400Détecter, anonymiser en gardant le format, bloquer
Déploiement sur siteNon indiqué sur la page citéeNon indiqué sur la page citéePossible

Base de la comparaison : pages des éditeurs consultées le 29/10/2026. Une mention « non indiqué » signifie que l'information ne figure pas sur la page citée, pas que la fonction n'existe pas.

Quel outil choisir selon son contexte, et quelles précautions prendre ?

Le bon choix dépend d'abord de l'existant. Une organisation qui déploie déjà Microsoft 365 Copilot trouvera dans Purview des réglages (simulation, types d'informations sensibles) qui s'intègrent à sa gestion actuelle. Celle dont le trafic IA passe déjà par la passerelle de Cloudflare peut y appliquer ses profils de détection existants.

ZeusLock se distingue sur d'autres points : une option d'installation chez le client, adaptée aux organisations qui préfèrent que leurs informations ne passent pas par un service externe, et une protection qui s'étend au navigateur, au poste de travail (Windows, Mac, Linux), à la ligne de commande, aux IDE, aux agents IA et aux serveurs MCP. La marque ajoute un repérage des usages d'IA non déclarés (Shadow AI), un garde-fou contre l'injection de prompt et le contournement des modèles (jailbreak), une intégration aux pipelines CI/CD, et cible en priorité les RSSI et les DPO d'organisations européennes.

Quel que soit l'outil, l'analyse des prompts touche à des données de salariés et parfois à des données personnelles. Les obligations liées au RGPD, à l'information des équipes ou à la consultation des représentants du personnel varient selon chaque situation : le DPO ou un juriste doit valider le dispositif avant son déploiement.

Sources

✦ Emency
PartagerXFacebookLinkedInWhatsApp

À lire aussi