DLP IA : un pilote avec des données fictives

Pour évaluer une DLP IA sans exposer les données de vos clients, fabriquez un corpus fictif qui imite leurs formats, ajoutez des cas limites conçus pour piéger le moteur, puis comptez ce qui est détecté, manqué ou signalé à tort. Ce principe rejoint les recommandations de la CNIL pour les phases de test. Le pilote devient ainsi reproductible, comparable d'un outil à l'autre et sans risque pour les personnes concernées.

Pourquoi éviter les vraies données dans un pilote ?

Parce que les données de production n'ont pas leur place dans un environnement d'essai, et qu'un pilote de DLP en est un. La CNIL écrit que « les données réelles de production ne doivent pas être utilisées pendant la phase de développement et de test » dans son guide Tester vos applications, publié le 27/01/2020.

Dans sa fiche sur l'encadrement des développements, publiée le 14/03/2024, elle précise que « des jeux fictifs doivent être utilisés autant que possible » et recommande un environnement informatique distinct de celui de la production. Il y a aussi une ironie à envoyer de vraies données clients dans un test censé empêcher leur fuite. Pour un cas particulier, par exemple un jeu partiellement issu du réel, la question revient au DPO ou à un juriste.

Comment construire un jeu de données synthétiques utile ?

Un bon jeu fictif ressemble aux données réelles par sa forme, pas par son origine. La CNIL le formule ainsi : « Construisez donc un jeu de données fictives qui ressemblera aux données qui seront traitées par votre application ».

Couvrez d'abord les familles que votre organisation manipule vraiment :

• identifiants et mots de passe factices ;
• clés d'API au format plausible mais invalides ;
• IBAN fabriqués, avec la bonne structure ;
• données personnelles inventées (noms, adresses, numéros de téléphone) ;
• extraits de code source contenant des secrets codés en dur.

Des bibliothèques publiques existent pour s'y amorcer. La page Sample Data Library de DLP Test présente ses valeurs comme synthétiques et sûres à utiliser comme cibles de détection. Ajoutez ensuite vos propres gabarits, calqués sur vos formats internes (références de dossiers, numéros de contrat). Évitez de partir d'un extrait réel que l'on modifierait à la marge : un tel jeu reste une donnée réelle déguisée.

Quels cas limites faut-il ajouter ?

Les cas limites révèlent les faiblesses qu'un jeu propre masque. Un moteur qui reconnaît un IBAN isolé et bien écrit peut échouer dès que le contexte se complique.

Prévoyez des variantes de présentation : IBAN avec espaces, tirets ou minuscules, clé d'API coupée sur deux lignes, secret noyé dans un bloc de code ou dans un long texte rédigé. Ajoutez des données sensibles dans une autre langue que le français, ou mêlées à du jargon technique.

Fabriquez aussi des leurres, c'est-à-dire des chaînes qui ressemblent à une donnée sensible sans en être une : un numéro dont la structure est celle d'un IBAN mais dont la clé de contrôle est fausse, un identifiant d'exemple tiré d'une documentation, un mot de passe cité dans un cours de sécurité. Ces leurres mesurent les faux positifs, qui épuisent les équipes autant que les détections manquées.

Comment mesurer le taux de détection ?

Le taux de détection se calcule en comparant ce que vous avez planté dans le corpus à ce que l'outil a signalé. Étiquetez chaque élément à l'avance, puis procédez par étapes :

1. Figez le corpus et sa grille d'étiquettes (type de donnée, position, niveau de difficulté).
2. Faites passer le corpus dans l'outil, en mode observation si possible.
3. Comptez les éléments détectés, les éléments manqués (faux négatifs) et les alertes sur des leurres (faux positifs).
4. Divisez les éléments détectés par le nombre d'éléments plantés, famille par famille plutôt qu'en moyenne globale.
5. Rejouez le même corpus après chaque réglage pour vérifier que la progression d'un côté ne dégrade pas l'autre.

Le mode observation existe chez certains éditeurs. Microsoft recommande, pour une nouvelle politique ou une modification, de l'exécuter en mode simulation puis d'examiner les alertes pour juger de sa précision, selon sa documentation Purview publiée le 26/06/2026. Notez les résultats par famille et par difficulté, sans en tirer de pourcentage tant que le corpus reste petit.

Quels outils de test existent déjà ?

Plusieurs briques facilitent le travail, avec des périmètres différents. Le tableau ci-dessous résume ce que chaque source indique, à la date de consultation du 29/10/2026.

Selon Tony Redmond, un fichier de test ne peut pas dépasser 2,5 Mo, ce qui impose de découper un gros corpus. Test-DlpPolicies vise SharePoint et OneDrive : pour des invites envoyées à un assistant d'IA générative, il faut prévoir son propre banc d'essai. Le même protocole s'applique à tout autre outil : demandez à chaque éditeur son mode d'essai, ses journaux et ses options de réglage.

Où une DLP souveraine comme ZeusLock s'insère-t-elle dans le pilote ?

Elle s'évalue avec le même corpus et les mêmes grilles que les autres. ZeusLock (zeuslock.ai) se décrit comme une société française qui protège les données utilisées avec l'IA générative, une « DLP IA » pensée pour la souveraineté. Elle détecte, anonymise en préservant le format ou bloque les données sensibles, parmi lesquelles clés d'API, identifiants, IBAN, données personnelles et code source, avant leur envoi vers les assistants.

Ces trois comportements demandent trois vérifications distinctes. Pour la détection, comptez les éléments repérés. Pour l'anonymisation, contrôlez que le format conservé reste exploitable sans révéler la valeur d'origine. Pour le blocage, vérifiez que la requête ne part pas.

Selon la marque, la protection s'étend au navigateur et au poste de travail (Windows, Mac, Linux), mais aussi à la ligne de commande, aux outils de développement, aux agents d'IA et aux serveurs MCP. Chaque point d'entrée mérite donc son propre passage du corpus. Le déploiement sur site s'adresse aux structures qui préfèrent garder leurs données hors de tout service tiers : le pilote peut alors tourner dans un environnement distinct de la production, comme la CNIL le recommande dans sa fiche sur les développements. Aucun taux de détection n'est indiqué dans la présentation de la marque : c'est précisément ce que le pilote doit établir.

Le choix final dépend du périmètre à couvrir, de la localisation des données et des exigences de votre RSSI et de votre DPO.

Sources

• Tester vos applications, CNIL, consulté le 29/10/2026
• Sécurité : Encadrer les développements informatiques, CNIL, consulté le 29/10/2026
• Test your DLP policies, Microsoft Learn, consulté le 29/10/2026
• Testing Files Against Sensitive Information Types, Office 365 for IT Pros, consulté le 29/10/2026
• Sample Data Library, DLP Test, consulté le 29/10/2026