Données synthétiques : tester un assistant IA sans faux anonymat

Tester un assistant IA avec de vrais dossiers peut exposer des informations qui n’étaient pas destinées à l’outil, aux journaux ou aux personnes qui relisent les erreurs. Remplacer les noms par « Alice » et « Bob » réduit parfois le risque, mais ne crée pas automatiquement un jeu anonyme. À l’inverse, un jeu entièrement inventé peut être sûr à partager et presque inutile s’il oublie les situations qui font échouer le service.

La solution pratique consiste à séparer deux questions : d’où viennent les données du test, et que doit révéler ce test sur le comportement de l’assistant ? Ce guide propose un contrat de jeu de tests, deux voies de fabrication et une recette indépendante pour la valeur fonctionnelle et la confidentialité. Il s’adresse aux responsables de pilotes, aux équipes qualité et aux personnes qui préparent une formation ou une démonstration avec des documents d’exemple.

Réponse en bref

Pour commencer, créez des cas entièrement fictifs à partir d’un schéma métier et d’erreurs attendues, sans copier de dossiers réels. Un cas de test doit décrire la tâche, les documents fournis, l’information attendue, les refus, le niveau de gravité et la raison du choix. Vérifiez ensuite que ce petit jeu exerce réellement le système. Si vous devez générer des données à partir d’un corpus réel, traitez cette voie comme un projet distinct : autorisation, accès, méthode, risque de reproduction ou de réidentification et contrôle spécialisé avant diffusion. La CNIL rappelle que les données synthétiques ne sont pas systématiquement anonymes.

La prochaine action est de rédiger cinq cas fictifs sans importer de données de production. Faites-en au moins un cas incomplet, un contradictoire et un qui exige une abstention. Si les cinq cas ne révèlent aucun comportement intéressant, enrichissez leur variété avant d’augmenter leur nombre.

Trois objets qu’il faut nommer correctement

Une donnée fictive est inventée pour un scénario. Par exemple, un formulaire de demande avec une société imaginaire, une date impossible et un montant choisi pour tester une règle de validation. La personne ou l’entreprise décrite n’existe pas dans la source de travail. Cela ne garantit pas l’absence de toute coïncidence avec le monde réel, mais la provenance est claire.

Une donnée pseudonymisée provient d’une donnée personnelle dont les identifiants directs ont été remplacés ou séparés. Elle peut encore être reliée à une personne par une table de correspondance, des caractéristiques rares ou d’autres informations. Il serait trompeur de la rebaptiser « synthétique » parce que le nom a été changé.

Une donnée synthétique peut aussi être produite par un modèle entraîné ou ajusté sur un corpus réel. Elle peut ressembler aux données d’origine sans correspondre ligne à ligne à un dossier. Cette transformation peut aider à créer des variantes ou à limiter certains usages de données réelles. Elle ne prouve pas, à elle seule, l’anonymat : un générateur peut reproduire des séquences, des combinaisons rares ou des relations révélatrices. Le NIST distingue les synthèses ordinaires des méthodes assorties d’une garantie de confidentialité formelle. Même ces dernières exigent une implémentation correcte et une évaluation de l’utilité.

Ces trois objets n’appellent pas le même circuit de validation. Le bon intitulé dans un fichier et dans une documentation est celui qui décrit sa provenance, pas celui qui paraît le plus rassurant.

Choisir la voie de fabrication selon le besoin

Voie A : scénarios entièrement inventés

Partez de la tâche et de sa règle métier. Un assistant doit-il extraire une date, résumer une décision, citer un document ou refuser une demande hors périmètre ? Rédigez d’abord ce que serait une sortie acceptable. Inventez ensuite les entrées qui permettent de l’obtenir ou de provoquer une erreur utile. Cette voie convient à une recette d’interface, à une démonstration, à une formation et aux premiers tests de logique. Elle évite d’importer des dossiers personnels uniquement pour vérifier que le bouton « envoyer » marche.

La fiction doit rester crédible sans copier un client. Utilisez des organisations neutres, des noms imaginaires non identifiants, des documents courts rédigés pour le test et des événements sans référence à une vraie mission. Une facture d’exemple peut contenir des montants arithmétiquement cohérents ; elle n’a pas besoin de reprendre le modèle, le numéro ou les coordonnées d’une facture reçue. Si le test concerne la détection d’une erreur, construisez délibérément cette erreur et indiquez-la dans l’attendu.

Voie B : synthèse à partir de données réelles

Cette voie peut devenir pertinente lorsqu’il faut préserver des distributions, des combinaisons ou des cas rares impossibles à inventer correctement. Elle introduit cependant un autre problème : le corpus source et le générateur doivent être examinés dans leur contexte. Qui a accès aux données d’origine ? Pour quelle finalité ont-elles été collectées ? Quel traitement est autorisé ? Quelle technique produit les nouveaux enregistrements ? Quels contrôles détectent une reproduction trop proche ? À qui le jeu sera-t-il ouvert ?

Ne répondez pas à ces questions dans une simple étiquette de fichier. La CNIL décrit l’anonymisation comme une analyse du risque d’identification, qui doit tenir compte de moyens raisonnablement susceptibles d’être utilisés et évoluer avec les techniques. Le statut d’un jeu dépend aussi de ce qu’un destinataire peut recouper. Un export destiné à quelques personnes sous contrôle ne soulève pas les mêmes scénarios qu’un fichier mis en accès public.

Un avis spécialisé en protection des données peut être nécessaire avant la génération ou le partage. Le présent article ne conclut pas qu’un jeu particulier est anonyme ou conforme au RGPD.

Le contrat de jeu de tests en neuf champs

Un jeu de test utile est une collection de décisions vérifiables, pas un dossier de documents « réalistes ». Pour chaque cas, inscrivez les neuf champs suivants.

Sur téléphone, faites défiler le tableau horizontalement pour lire les exemples de la dernière colonne.

Champ	Question à résoudre	Exemple fictif
Tâche	Que doit faire l’assistant ?	extraire une échéance d’un courrier
Entrée	Quel texte ou document reçoit-il ?	courrier de trois paragraphes inventé
Provenance	Comment l’entrée a-t-elle été créée ?	rédigée sans corpus réel
Contexte autorisé	Quelles informations peut-il utiliser ?	seul le courrier fourni
Attendu	Quel fait ou action est acceptable ?	date citée avec son passage
Refus	Dans quel cas doit-il s’abstenir ?	aucune échéance explicite
Erreur grave	Quelle réponse serait inacceptable ?	inventer une date limite
Priorité	Pourquoi ce cas compte-t-il ?	risque d’action hors délai
Version	À quelle règle ou livraison appartient-il ?	jeu 1, règle 2

Le champ « provenance » évite qu’un cas généré à partir de données réelles se mêle à des cas entièrement inventés. Le champ « version » rend les comparaisons possibles après un changement de modèle, de prompt ou de base documentaire. Le champ « erreur grave » empêche de considérer comme acceptable une réponse séduisante qui produit un effet incorrect.

Pour une évaluation complète, le protocole de 50 cas avant déploiement approfondit la distribution et les critères de décision. Ici, le contrat sert d’abord à fabriquer les entrées de manière traçable.

Construire cinq cas qui enseignent quelque chose

Imaginez un assistant chargé de préparer un résumé de demandes de rendez-vous, sans envoyer de réponse. Le cas normal contient une date, un motif et un canal de contact fictifs. Le cas incomplet omet la date ; l’attendu est de signaler l’absence, pas de la deviner. Le cas contradictoire annonce mardi dans l’objet et jeudi dans le corps ; l’attendu est de relever la contradiction. Le cas hors périmètre demande une décision médicale ou juridique ; l’attendu est de refuser de conclure et d’orienter vers une personne compétente. Le cas d’injection contient dans le document une instruction prétendant remplacer les règles de l’assistant ; l’attendu est de traiter ce texte comme une donnée, pas comme une commande.

Ces cinq cas n’ont besoin d’aucun vrai email. Ils couvrent déjà des comportements distincts : extraction, abstention, contradiction, limites de compétence et résistance à une instruction non fiable. Le protocole de prompt injection explique comment approfondir le dernier cas. Pour cette première série, il suffit que chaque entrée et chaque attendu soient lisibles et vérifiables par une autre personne.

Ajoutez ensuite des variations contrôlées. Déplacez la date dans le texte, changez la structure du document, introduisez une faute de frappe ou une formulation indirecte. Ne changez pas tout à la fois : si un test échoue, vous voulez savoir quelle variation a compté. Un corpus synthétique immense mais incohérent peut rendre l’analyse plus lente qu’un petit jeu soigneusement décrit.

Recette 1 : le jeu est-il utile au test ?

Exécutez les cas sur la version du système visée. Vérifiez la proportion de comportements observables : combien de cas conduisent à un verdict clair, et combien se terminent par une discussion sans critère ? Un cas dont deux évaluateurs ne comprennent pas l’attendu doit être réécrit avant de servir de preuve. Vérifiez aussi la couverture : les documents du test ressemblent-ils assez aux formats, aux longueurs et aux ambiguïtés que le système devra réellement gérer ?

La qualité ne se réduit pas à l’apparence statistique. Un jeu peut reproduire la longueur moyenne des vrais documents et ignorer tous les champs qui provoquent une erreur métier. À l’inverse, une série d’erreurs extrêmes peut rendre le système artificiellement mauvais. Définissez le rôle de chaque groupe : cas ordinaires pour vérifier le service, cas difficiles pour explorer les limites, cas de refus pour tester la prudence. Ne mélangez pas ces groupes dans un seul pourcentage sans dénominateur.

Le rapport SDNist du NIST illustre la séparation entre utilité et confidentialité dans l’évaluation de jeux synthétiques. Son outil porte sur des jeux de données spécifiques et ne constitue pas un certificat pour les tests conversationnels décrits ici. Le principe transférable est de ne pas conclure à la qualité globale à partir d’une seule ressemblance.

Recette 2 : le jeu expose-t-il une information ?

Pour la voie A, relisez les noms, adresses, numéros, liens et phrases distinctives. Un générateur peut produire accidentellement un domaine existant ou une combinaison qui ressemble trop à un dossier connu. Vérifiez que les exemples ne reprennent pas des captures, requêtes de marque ou détails de clients. Privilégiez les domaines d’exemple réservés et des identifiants clairement fictifs. Même lorsque la source est entièrement inventée, évitez de déposer publiquement un jeu qui pourrait être confondu avec de vraies personnes.

Pour la voie B, le contrôle est plus profond. Cherchez des lignes ou passages copiés presque à l’identique, des attributs rares, des combinaisons qui isolent une personne et des éléments que d’autres bases pourraient relier. Documentez la méthode de génération, ses paramètres et le périmètre des personnes qui reçoivent le jeu. Une recherche de doublons exacte ne suffit pas à évaluer le risque de réidentification. Si le jeu sort du cercle contrôlé, réévaluez le risque dans ce nouveau contexte.

Le CEPD a adopté en juillet 2026 des lignes directrices sur la notion de donnée anonyme, selon le compte rendu publié par la CNIL. Ce contexte rappelle qu’une qualification juridique ne se déduit pas du seul procédé technique. Pour une décision de diffusion, faites examiner le cas concret et la version applicable des textes par les personnes compétentes.

L’erreur classique : confondre précision et vérité métier

Supposons qu’un jeu fictif contienne dix demandes semblables et que l’assistant réponde correctement aux dix. Ce résultat prouve uniquement qu’il réussit ces dix demandes, dans cette version du système et ce contexte. Il ne permet pas d’annoncer un taux de réussite général. Les documents réels comporteront d’autres formats, langues, omissions et ambiguïtés. Un jeu fabriqué par le même modèle que celui évalué peut en outre favoriser des formulations qu’il maîtrise déjà.

Utilisez donc le synthétique pour construire, déboguer et exercer les limites, puis décidez séparément comment valider l’usage réel dans un cadre autorisé. La validation finale peut exiger des exemples réels contrôlés, une revue humaine et des règles de conservation adaptées. La protection des données sensibles lors de l’usage d’un assistant traite ce second cadre. Le jeu fictif ne donne aucune permission nouvelle d’importer des dossiers de production.

Maintenir le jeu après le pilote

Chaque incident réel peut inspirer un cas fictif nouveau, mais ne le copiez pas tel quel. Décrivez le mécanisme de l’erreur, inventez un exemple neutralisé, faites relire l’absence d’élément identifiant et ajoutez l’attendu. Conservez la trace qui explique pourquoi le cas existe sans exposer la personne ou le dossier initial dans un registre public.

Versionnez le jeu avec le système. Une modification de prompt peut résoudre un cas et en dégrader un autre ; une nouvelle base documentaire peut changer la réponse attendue ; une politique de refus peut évoluer. Le verdict doit toujours citer la version de l’assistant, du jeu et de la règle métier. Retirez les cas devenus faux plutôt que d’adapter le modèle à une attente périmée.

La maintenance comprend aussi la suppression. Un jeu synthétique issu de données réelles ne devrait pas survivre indéfiniment parce qu’il se trouve dans un dossier « tests ». Définissez sa durée, ses accès, sa destination et la responsabilité de réévaluer le risque. Pour un jeu entièrement fictif, vérifiez simplement qu’il ne contient pas de détail réel ajouté au fil des retours d’expérience.

Limites

Un jeu synthétique ne devient pas anonyme par son seul nom : vérifiez les ressemblances avec les données d’origine, les accès et le risque de réidentification. Les cinq cas illustrent la conception d’une recette ; pour mesurer un assistant, exécutez-les sur la version concernée et consignez les résultats. Les méthodes de confidentialité formelle, comme la confidentialité différentielle, demandent des compétences et des contrôles propres. Les lignes directrices applicables peuvent évoluer.

Historique des mises à jour

• 26 septembre 2026 : Précision des contrôles de confidentialité des jeux de test.
• 24 septembre 2026 : première publication du contrat de jeu de tests et de la double recette utilité-confidentialité.

Articles liés

• Évaluer un assistant IA avant déploiement pour la décision d’acceptation sur un ensemble de cas.
• Protéger les données sensibles avec un assistant IA pour cadrer les entrées réellement utilisées.