Des données de test sans jamais copier la production

OUTILS IA — CHOISIR, MESURER, CONTRÔLER · DES DONNÉES DE TEST SANS LA PROD

Sources vérifiées au 19 juillet 2026, sur publication du NIST, textes de licence réels, dépôts publics et documentation officielle d'éditeur.

La copie de la base de production dans un environnement de test se justifie toujours par le même argument, et cet argument est bon : rien ne ressemble autant aux données réelles que les données réelles. Un jeu fabriqué à la main rate les cas tordus ; la production, elle, les contient tous, puisqu'elle les a produits.

Le problème n'est pas la qualité du raisonnement, c'est ce qu'il coûte quand il échoue. Cet article n'aborde pourtant pas la question par la conformité, mais par un constat de marché : ce secteur a enterré deux de ses acteurs les plus visibles en dix-huit mois. Choisir un fournisseur pour fabriquer ses données de test, c'est parier sur sa survie — un pari qui se juge sur des constats HTTP et DNS reproductibles, pas sur des impressions.

Cet article est le pendant direct de notre article sur l'anonymisation des données avant de les confier à une IA. Celui-là traite de données réelles que l'on transforme ; celui-ci, de données qui n'ont jamais été réelles. La différence décide de ce que l'on peut garantir.

Pourquoi la copie de production finit toujours par fuiter

La copie de production ne fuite pas parce que quelqu'un est négligent. Elle fuite parce que le duplicata hérite de la valeur des données originales sans hériter des dispositifs qui les protègent. La base de production vit derrière un contrôle d'accès entretenu, des journaux relus, une rotation de secrets. Sa copie vit dans un environnement dont la raison d'être est d'être plus permissif : accès larges, contraintes désactivées, outils tiers branchés, instantanés gardés « le temps de reproduire le bug ».

Chaque copie multiplie donc la surface exposée sans multiplier la surveillance. Et le duplicata survit à son motif : l'environnement de recette d'un projet clos reste en ligne des mois, avec les mêmes adresses et les mêmes historiques que l'original. Le problème est structurel ; il ne se corrige pas par de la discipline. C'est la mécanique décrite dans notre article sur ce qui quitte réellement votre machine : ce n'est jamais l'intention qui déplace la donnée, c'est la commodité.

D'où la thèse méthodologique de cet article : la seule protection robuste consiste à ce que la donnée sensible ne soit jamais entrée dans l'environnement de test. Non pas transformée, non pas masquée : absente.

Trois familles de données de test — et la seule qui garantit quelque chose

La taxonomie du NIST rappelée plus haut n'est pas un exercice de vocabulaire. Elle départage ce qui est garanti de ce qui est espéré.

Prenez la famille « données de test » : c'est celle des générateurs par règles, dont Faker est le représentant le plus employé — licence MIT, gratuit, version 40.31.0 publiée le 14 juillet 2026. Ces outils fabriquent des noms, des adresses et des numéros valides au regard du format attendu. Ils ne modélisent rien de votre métier : ni vos distributions, ni vos corrélations, ni la forme réelle de votre clientèle. C'est exactement ce que dit la définition du NIST — syntaxiquement valides, sans information exacte à l'analyse. Ce n'est pas un défaut, c'est le contrat.

La deuxième famille, les « données de test réalistes », est celle où la plupart des équipes croient se trouver. Relisez la condition du NIST : la garantie de confidentialité ne vient pas du réalisme, elle vient de la non-dérivation. Des données peuvent être criantes de vraisemblance et parfaitement sûres si aucune donnée confidentielle n'a servi à les produire — et médiocrement réalistes mais dangereuses si un modèle ajusté sur la production les a engendrées.

La troisième famille, les données pleinement synthétiques, est celle qui se vend. Un modèle apprend la structure statistique des données réelles, puis produit des enregistrements nouveaux qui la reproduisent. La promesse est séduisante — la fidélité analytique sans les personnes — et c'est précisément là que le NIST pose sa réserve.

Fig. 1 — Les trois familles de données de test. La ligne qui décide n'est pas celle du réalisme mais celle de la dérivation : tant qu'aucune donnée confidentielle ni aucun modèle appris sur elle n'intervient dans la production du jeu, la confidentialité de l'original n'est pas engagée. Dès que la génération dérive des données réelles, la garantie change de nature.

Le compromis central : fidélité contre fuite

Voici la phrase qui devrait figurer en tête de toute évaluation d'outil de données synthétiques. Le NIST l'écrit au paragraphe 4.4.4 de la publication citée :

« Both high-fidelity models and synthetic data generated from models may leak personal information that is potentially re-identifiable. The amount of leakage can be controlled using formal privacy models (e.g., differential privacy) that typically involve the introduction of noise. »

« Les modèles à haute fidélité comme les données synthétiques générées à partir de modèles peuvent laisser fuir des informations personnelles potentiellement ré-identifiables. Le volume de cette fuite peut être maîtrisé au moyen de modèles formels de confidentialité — par exemple la confidentialité différentielle — qui supposent généralement l'introduction de bruit. »

Trois conséquences pratiques en découlent, et aucune n'est intuitive.

La fidélité et la protection tirent en sens contraire. Un modèle qui reproduit fidèlement les données réelles reproduit aussi ce qui, dans ces données, est rare et donc distinctif. Plus un jeu synthétique est utile analytiquement, plus il porte de signal issu de l'original.

La fuite se maîtrise, elle ne s'annule pas. Le NIST parle de contrôler le volume de fuite, pas de le supprimer. Le levier cité — la confidentialité différentielle — fonctionne par introduction de bruit, c'est-à-dire par dégradation délibérée de la fidélité. Ce n'est pas une case à cocher, c'est un curseur avec un coût des deux côtés.

« Synthétique » n'est pas un synonyme de « anonyme ». Aucune équivalence de principe n'existe entre les deux termes, et une organisation qui traiterait un jeu pleinement synthétique comme dépourvu de toute donnée personnelle, sans analyse propre, s'appuierait sur une hypothèse que la publication citée ne soutient pas. On rejoint le mécanisme décrit à propos de l'entraînement d'un modèle sur des données produites par un modèle : ce qui est reproduit statistiquement ne cesse pas d'être une trace de l'original.

Conserver les contraintes qui font échouer un test

Il existe un piège symétrique, plus fréquent que le précédent : un jeu de test trop propre ne teste rien. Il produit une chaîne d'intégration verte et une mise en production rouge. Quatre propriétés méritent d'être vérifiées explicitement, parce que ce sont elles qui font échouer un test — et donc elles qui lui donnent sa valeur.

L'intégrité référentielle. Une commande renvoie à un client qui existe, une ligne à un article qui existe, et les cardinalités sont plausibles. Un générateur qui remplit chaque table indépendamment produit des tables individuellement valides et une base globalement incohérente, où aucune jointure ne se comporte comme en production.

Les valeurs nulles et les champs partiels. La production est pleine de champs vides, d'adresses incomplètes et de codes obsolètes. Un jeu qui remplit tout systématiquement n'exercera jamais les branches de code qui traitent l'absence — en pratique, la moitié des incidents.

Les distributions. Si une poignée de clients concentre l'essentiel du volume, un jeu uniformément réparti ne détectera ni la lenteur de la requête sur les gros comptes, ni la pagination qui casse au-delà d'un certain nombre de lignes.

Les cas limites. Montants négatifs, doublons, caractères non latins, dates antérieures à la création du système, chaînes à la longueur maximale du champ. En production ils existent parce que la réalité les a produits ; dans un jeu fabriqué, seulement si quelqu'un a décidé de les écrire.

Ce marché a enterré deux de ses vedettes en dix-huit mois

C'est ici que le sujet cesse d'être méthodologique. Deux des noms les plus cités du domaine ne sont plus, aujourd'hui, ce que la documentation en circulation prétend qu'ils sont.

Gretel a été racheté par NVIDIA, et le produit s'est éteint par redirection silencieuse. Trois constats, relevés le 19 juillet 2026 et reproductibles en trois commandes :

1. Le domaine gretel.ai répond en HTTP 301 vers une page NVIDIA consacrée à la génération de données synthétiques pour l'IA agentique.
2. Le sous-domaine de documentation docs.gretel.ai ne résout plus en DNS — réponse NXDOMAIN. Il n'a pas été redirigé : il a cessé d'exister au niveau du nommage.
3. Le mot « Gretel » n'apparaît nulle part sur la page NVIDIA d'atterrissage.

Aucune notice publique de fin de service n'a été retrouvée. La formulation compte : c'est un constat de recherche infructueuse, pas la preuve qu'une telle notice n'existe pas. La conséquence opérationnelle, elle, est indiscutable — tout script citant l'interface applicative de ce produit est aujourd'hui non seulement périmé mais non exécutable, et la documentation qui aurait permis de s'en apercevoir a disparu avant lui.

Du côté du remplacement, l'offre existe mais a changé de nature. NeMo Data Designer est un dépôt vivant sous Apache-2.0, version 0.8.0 publiée le 15 juillet 2026 ; son fichier de présentation ne mentionne jamais Gretel. Un second composant, NeMo Safe Synthesizer, est présenté officiellement comme créant « des versions préservant la confidentialité de données sensibles, avec des configurations par défaut conçues pour satisfaire des réglementations de protection des données telles que HIPAA et le RGPD ». Retenez la substitution : là où il y avait une plateforme en libre-service avec console, clés et palier gratuit, il y a désormais un dépôt de code à intégrer soi-même. Ce n'est pas un remplacement équivalent, c'est un transfert de charge.

MOSTLY AI illustre un second mode de disparition, plus discret. Syntho a annoncé, le 9 juin 2026, avoir acquis la marque MOSTLY AI — le communiqué dit « acquired the MOSTLY AI brand ». C'est un rachat d'actif de marque, et il faut se garder d'en déduire une fusion d'entreprises. Le constat vérifiable est ailleurs : la page tarifaire répond en HTTP 404, tandis que le kit de développement reste publié sous Apache-2.0, dernière activité le 8 mai 2026. Le dépôt a ralenti — deux mois et demi sans mouvement — mais il n'est pas archivé. Vivant en sursis, donc, et non mort : la nuance sépare un risque à surveiller d'un fait acquis.

Fig. 2 — La chaîne de constats qui date la disparition d'un fournisseur. Aucun de ces relevés ne demande de compte, d'accès privilégié ni d'outil payant : un code de réponse HTTP, une résolution DNS et une recherche de chaîne dans une page suffisent à établir un statut que la communication commerciale n'énonce nulle part.

Le piège de licence : lire la clause, pas l'étiquette

SDV, le Synthetic Data Vault publié par DataCebo, est régulièrement présenté comme un projet open source. Il est régulièrement présenté, en réaction, comme inutilisable en entreprise. Les deux affirmations sont fausses, et la seconde plus dangereuse que la première, parce qu'elle écarte un outil parfaitement employable sur la foi d'une étiquette.

Le texte réel est une Business Source License 1.1, et sa clause d'usage est étroite. Elle autorise l'usage de l'œuvre sous licence à condition de ne pas s'en servir pour proposer un « Synthetic Data Service » — c'est-à-dire un service de génération de données synthétiques vendu à des tiers. L'usage interne est explicitement autorisé. Une équipe qui génère ses propres jeux de test pour ses propres environnements est dans le périmètre permis, y compris dans un contexte commercial.

Second point, tout aussi mal connu : la licence prévoit une date de bascule fixée à quatre ans après la publication de chaque version, avec le MIT pour licence de destination. Ce n'est pas le projet qui bascule d'un bloc : c'est chaque version qui devient MIT à son quatrième anniversaire. Qui accepte de travailler avec un décalage de quatre ans dispose donc, en permanence, d'un socle sous licence permissive.

La règle vaut bien au-delà de cet outil : lisez la clause, jamais l'étiquette. Le résumé affiché par une forge, la mention d'un comparatif ou l'affirmation d'un commercial ne sont pas des sources. Le fichier de licence en est une, il tient en quelques paragraphes, et sa lecture coûte cinq minutes contre des mois de reprise.

Ce que des données synthétiques ne remplaceront jamais

Reste à délimiter ce que cette approche ne fait pas, faute de quoi elle sera adoptée pour de mauvaises raisons puis abandonnée pour de bonnes.

Un jeu synthétique ne valide pas une migration de données. Le jour où il faut vérifier qu'un traitement de reprise n'a rien perdu, ce sont les données réelles — et elles seules — qui font foi. Aucune fidélité statistique ne remplace un rapprochement enregistrement par enregistrement.

Il ne reproduit pas ce que personne n'a modélisé. Un générateur produit ce qu'on lui a décrit ou ce qu'un modèle a appris. Les anomalies dont l'organisation ignore l'existence — un encodage qui a dérivé lors d'une reprise ancienne, une convention de saisie propre à une agence — ne se retrouvent pas dans le jeu synthétique. Elles restent en production, où elles attendent.

Il ne remplace pas la mesure de charge sur volumétrie réelle. Un jeu synthétique peut approcher les distributions ; il n'a ni l'historique, ni la fragmentation d'index, ni les années d'accumulation qui expliquent la plupart des lenteurs constatées.

Il ne dispense d'aucune analyse juridique. Un jeu pleinement synthétique dérivé de données personnelles reste, au regard de la publication du NIST citée plus haut, susceptible de laisser fuir de l'information potentiellement ré-identifiable. Le qualifier de « non personnel » engage l'organisation et relève de son analyse propre, pas d'une propriété acquise de la technique.

Ces limites ne condamnent pas la démarche, elles la cadrent. Les données synthétiques sont excellentes pour le développement quotidien, les démonstrations, la formation, les tests fonctionnels et l'ouverture d'environnements à des prestataires. Elles sont faibles là où c'est l'exactitude de l'original qui est en cause. Tout revient, ici encore, à la donnée elle-même — c'est le sujet de notre article sur le socle invisible de toute IA.

🔬 Comment le vérifier vous-même

Aucun des outils cités n'a été installé ni exécuté, et aucune mesure n'est revendiquée ici. En revanche, tout ce qui précède est vérifiable par vous, sans compte et sans budget. Le protocole ci-dessous prend moins d'une heure.

Il reste une décision, et elle n'appartient pas à l'équipe technique. Cesser de copier la production, c'est accepter que les environnements de test soient un peu moins commodes, et que quelqu'un consacre du temps à décrire ce que les données doivent contenir. Ce coût est visible, immédiat, porté par une équipe identifiée ; celui qu'il évite est invisible, différé, et porté par toute l'organisation le jour où il se matérialise. Aucun outil n'arbitre cela — et l'outil qui prétendrait le faire pourrait fort bien ne plus répondre dans dix-huit mois.

Cet article clôt la série Outils IA — choisir, mesurer, contrôler. Le précédent portait sur l'interrogation des données métier en langage naturel, et posait déjà la même question sous un autre angle : qu'est-ce qui, dans un dispositif, est garanti par écrit, et qu'est-ce qui n'est qu'espéré ?

Une question, un projet IA ?

Vous voulez sortir vos données de production de vos environnements de test sans casser vos jeux d'essai ? Échangeons sur votre contexte.

Prendre contact →