L’essentiel en 30 secondes
- Les données synthétiques sont des leurres réalistes qui déclenchent vos contrôles comme une vraie donnée, sans en être une.
- Elles rendent le test possible en production : si le leurre sort, aucune donnée métier réelle n’a fui. Les risques opérationnels, eux, se maîtrisent par le périmètre.
- Un bon leurre respecte vos formats, porte un marqueur traçable et n’est jamais dérivé de la production.
« Trop risqué en production. » C’est l’une des objections que nous entendons le plus, et sur le fond, le RSSI a raison. Faire sortir une vraie donnée client pour vérifier qu’elle est bloquée, personne ne devrait l’accepter. Notre réponse tient en une idée : nous gardons le test en production, et nous changeons ce qui sort. Si le fichier qui part est un leurre, aucune donnée métier réelle n’est en jeu, et les risques opérationnels qui restent se maîtrisent par le périmètre.
Les données synthétiques sont des leurres réalistes (faux IBAN, faux dossiers clients, faux documents marqués « confidentiel ») conçus pour déclencher vos contrôles comme le ferait une vraie donnée sensible, sans en être une. C’est grâce à elles que nous pouvons tester en production, là où le résultat est représentatif.
Pourquoi tester en production, et pas seulement en préproduction
Une DLP ne se comporte jamais en recette comme en production. Vos postes n’ont pas la même image, vos proxys ne portent pas les mêmes exceptions, vos politiques cloud ont dérivé depuis la revue de mars, et vos utilisateurs ont installé des outils que personne n’a déclarés. Tester ailleurs revient à valider un environnement que l’attaquant ne visera pas. Notre offre suit d’ailleurs cette logique en 2 temps : un POC en environnement synthétique, sans impact sur la production, pour voir l’outil, puis un pilote en production sur un périmètre restreint, avec des données synthétiques uniquement, pour mesurer.
La page Test d’exfiltration de données : définition, méthode et enjeux pose le cadre général.
Ce que les données synthétiques changent au risque
Le risque d’un test d’exfiltration tient en 3 questions : qu’est-ce qui peut sortir, où cela peut arriver, et qui prévenir en cas de sortie. Les leurres changent la réponse à chacune.
| Risque | Test avec donnée réelle | Test avec données synthétiques |
|---|---|---|
| Fuite effective | Violation de données potentielle, à qualifier | Aucune donnée personnelle ni secret réel dans la charge de test |
| Destination non maîtrisée | Copie résiduelle impossible à garantir effacée | Copie sans valeur, traçable par son marqueur |
| Obligations de notification | Analyse avec le DPO, notification à la CNIL sous 72 h si violation (article 33 du RGPD) | Pas de données personnelles réelles concernées |
| Acceptation interne | Arbitrage difficile, souvent refusé | Discussion centrée sur la charge et le périmètre |
Concevoir de bons leurres
Un leurre que votre DLP ne reconnaît pas ne teste rien. Un leurre qui ressemble à une chaîne aléatoire fausse le résultat : s’il passe, vous ne savez pas si la règle est trouée ou si elle a ignoré une donnée peu crédible. La qualité de votre test dépend donc de la qualité de vos fichiers synthétiques.
Schéma · l’anatomie d’un bon leurre
Respecter les formats que vos règles détectent
Le leurre doit reproduire les structures que vos règles cherchent :
- Identifiants avec clé de contrôle : un faux IBAN (norme ISO 13616, 27 caractères en France, clé calculée modulo 97), un faux SIRET (14 chiffres, clé de Luhn) ou un faux numéro de sécurité sociale (13 chiffres et une clé de 2) doit avoir une clé valide. Sinon une règle bien écrite l’ignore, et elle a raison.
- Numéros de carte de paiement : prenez des numéros de test publiés, comme le 4111 1111 1111 1111 (Visa) ou le 5555 5555 5555 4444 (Mastercard). Ils passent l’algorithme de Luhn sans correspondre à un compte réel.
- Documents métiers : la bibliothèque Python Faker produit des noms et adresses plausibles en français, à glisser dans un faux contrat Word, un faux bulletin de paie en PDF, une fausse fiche patient, avec la mise en page et le vocabulaire de vos vrais documents.
- Étiquettes de classification : si vos règles s’appuient sur des étiquettes ou des métadonnées, le leurre doit les porter. Sans classification des données cohérente, une partie de vos règles ne se déclenche pas, et le test doit le montrer.
- Volumes plausibles : un fichier de 10 lignes et un export de 50 000 lignes ne sollicitent pas vos seuils de la même façon.
Marquer chaque leurre de façon traçable
Chaque donnée synthétique doit porter un marqueur unique qui répond sans ambiguïté à la question « ce fichier vu dans un journal, d’où vient-il ? ». Nous recommandons :
- un identifiant unique par scénario et par exécution, du type ENF-TEST-2026-031, inscrit dans le contenu et dans les métadonnées ;
- un registre central où vous associez chaque marqueur à sa date, son canal testé et son résultat ;
- une mention explicite de test, lisible par un analyste, pour qu’un leurre retrouvé ne soit jamais traité comme un incident réel.
Grâce à ce marquage, votre SOC mesure si l’événement a été détecté, en combien de minutes, et par quel outil. C’est la base d’un indicateur de délai de détection solide.
Ne jamais dériver de la donnée réelle
Un scénario concret : le fichier RH vers un cloud personnel
Dans un hôpital, un jeudi, vous voulez vérifier qu’un fichier de paie ne peut pas partir vers un stockage cloud personnel depuis un poste de la DRH.
- Vous générez un tableur Excel synthétique de 200 lignes : noms inventés, faux numéros de sécurité sociale à clé valide, salaires fictifs, étiquette « Confidentiel RH ».
- Vous l’inscrivez dans le registre avec son marqueur.
- Nous rejouons le scénario depuis un vrai poste Windows du périmètre, avec le profil d’un utilisateur standard, vers un service grand public comme Google Drive, ouvert dans Chrome. Côté MITRE ATT&CK, c’est la technique T1567.002.
- Vous relevez 3 résultats : le transfert a-t-il été bloqué, une alerte est-elle partie, le SOC l’a-t-il traitée (et en combien de minutes) ?
- Si le fichier passe, vous savez quel contrôle a cédé. Et aucune donnée métier réelle n’est sortie.
Étape suivante
Vos contrôles arrêteraient-ils un faux fichier de paie ?
Une démo de 30 minutes : une campagne complète sur les 8 canaux que nous testons, sur notre environnement de démonstration. Le POC montre in situ, sur un scénario simple en environnement synthétique, comment la solution se comporte chez vous. Ce qui sort réellement de vos canaux, c’est le pilote qui vous le montre.
Lever l’objection « trop risqué en production »
Face à un DPO réticent, il vous faut un cadre écrit. Nous y faisons figurer :
- Nature des données : uniquement des données synthétiques générées, jamais dérivées de la production.
- Destinations : listées à l’avance. Avec Enforcis 1.0, ce sont des comptes de test GitHub Gist, Google Drive et DPaste contrôlés par Enforcis et purgés après chaque campagne.
- Périmètre : vos postes, comptes, canaux et créneaux nommés (le mardi de 10 h à 12 h, par exemple), validés par la DSI.
- Information : qui est prévenu et quand, par exemple 48 h avant (tout le SOC et l’astreinte, ou seulement un référent si vous voulez mesurer la détection).
- Arrêt : un interlocuteur joignable et une procédure pour suspendre un scénario en moins de 5 minutes.
- Traçabilité : registre des marqueurs conservé et partagé avec le DPO.
Avec ce cadre écrit, la discussion avec le DPO porte alors sur le périmètre et le calendrier. Plus sur le risque de fuite. Et c’est en production que vous trouverez les faux négatifs DLP : la règle existe, mais elle ne se déclenche pas sur le vrai poste.
Les limites à garder en tête
Les données synthétiques ne remplacent pas tout. Elles testent la capacité de vos contrôles à reconnaître des structures connues. Elles ne disent rien d’une donnée sensible que vous n’avez jamais décrite dans une règle. Et ces leurres vieillissent : un nouveau modèle de contrat absent de vos leurres crée un angle mort. Mettez votre bibliothèque de leurres à jour avec vos modèles de documents.
FAQ
Une donnée synthétique peut-elle déclencher une notification à la CNIL ?
Non, si elle ne contient aucune donnée personnelle réelle et n’est pas dérivée de la production. Sa sortie n’est pas une violation de données personnelles au sens de l’article 4, point 12, du RGPD, donc pas de notification sous 72 h. Documentez quand même la démarche avec votre DPO.
Tester l’exfiltration en production est-il sans risque ?
Pour la donnée réelle, oui, si seuls des leurres sortent : un fichier synthétique qui fuit ne contient aucune donnée réelle, ni de client ni de salarié. Il reste quand même des risques opérationnels. Un scénario mal calibré peut lancer des alertes en rafale ou ralentir un poste. Nous les cadrons par écrit : postes, comptes, canaux et créneaux nommés (le mardi de 10 h à 12 h, par exemple), SOC prévenu 48 h avant, arrêt possible en moins de 5 minutes.
Les leurres suffisent-ils à tester toute la DLP ?
Ils couvrent les règles fondées sur le contenu, les formats et les étiquettes. Combinez-les avec une revue de la classification et des canaux couverts pour tester sa DLP de façon complète.
Peut-on utiliser de vrais numéros de carte, masqués ?
Non. Un numéro masqué reste rattaché à un vrai compte, et il ne passe souvent plus les contrôles de format de vos règles. Prenez les numéros de test publiés pour Visa ou Mastercard. C’est leur rôle.