Données synthétiques pour tester une IA : utiles, mais pas automatiquement anonymes

Intelligence artificielle Publié le 28/10/2026 Dimitri Jorand Gérant de DEMETER SANTE

Inventer des dossiers d’essai peut limiter l’exposition de données réelles. Cela ne garantit ni l’anonymat d’un jeu généré à partir de dossiers existants ni la fiabilité de l’IA.

Les données synthétiques peuvent aider à tester une IA en limitant le recours à des informations réelles, mais elles ne sont pas automatiquement anonymes. Pour un premier prototype, des cas entièrement fictifs, créés sans copier de dossiers personnels, constituent souvent un point de départ utile. Ils ne démontrent toutefois pas que le système fonctionnera correctement en conditions réelles.

Ce guide porte sur la préparation d’essais pédagogiques et organisationnels, notamment pour un assistant documentaire ou une application interne. Il ne propose ni méthode d’anonymisation certifiée, ni validation clinique, ni avis juridique individualisé. Les traitements de données personnelles demandent une analyse adaptée avec les interlocuteurs compétents.

Trois situations à distinguer avant de commencer

Un cas fictif rédigé à partir d’une règle de fonctionnement imaginaire n’a pas le même point de départ qu’un jeu produit par un modèle entraîné sur des dossiers réels. Une troisième situation consiste à modifier quelques champs d’un dossier existant. Changer le nom ne suffit pas à faire disparaître les informations qui peuvent identifier une personne.

La CNIL distingue l’anonymisation de la pseudonymisation et rappelle, dans ses recommandations sur le développement de l’IA, que les données synthétiques ne sont pas systématiquement anonymes. Ces distinctions empêchent une conclusion trop rapide : « c’est généré, donc ce n’est plus personnel ». L’origine, le procédé et les possibilités de rapprochement doivent être examinés.

Commencer par ce que le test doit apprendre

Définissez la décision que vous souhaitez éclairer. Un assistant trouve-t-il la bonne procédure ? Une application refuse-t-elle un formulaire incomplet ? Un résumé conserve-t-il une réserve importante ? Ces questions appellent des cas et des critères différents. Un ensemble de textes plausibles mais sans réponse attendue ne permet pas de conclure grand-chose.

Pour chaque cas, notez l’entrée, la ressource autorisée, le comportement attendu et les erreurs inacceptables. Dans un assistant documentaire, citer une version périmée peut constituer un échec même si la réponse semble bien rédigée. Distinguez aussi une erreur de récupération du document d’une erreur dans l’explication produite.

Exemple fictif : un assistant de réservation de salle

Une organisation fictive prépare un assistant qui explique les règles de réservation de ses salles. Le règlement de test inventé prévoit un responsable, une capacité maximale et une validation pour certains créneaux. Aucun nom de salarié réel ni agenda existant n’est utilisé.

Le jeu comporte une demande complète, une demande sans capacité, deux règles contradictoires et une question sans réponse dans les documents. Le comportement attendu dans ce dernier cas est de reconnaître la limite et d’orienter vers le rôle compétent, pas d’inventer une autorisation. Cet exemple illustre la conception d’essais ; il n’affirme aucune performance d’un outil commercial.

Varier les cas sans fabriquer une preuve de fiabilité

Ajoutez des formulations courtes, longues, ambiguës, avec une faute ou une information manquante. Modifiez un élément à la fois lorsque vous voulez comprendre une différence de résultat. Gardez également des situations plus complexes où plusieurs contraintes se rencontrent. Un cas facile répété avec des noms différents apporte peu d’information nouvelle.

Séparez les exemples utilisés pour régler l’assistant de ceux réservés à sa vérification. Si l’équipe adapte continuellement le système aux mêmes questions, elle peut améliorer la réussite sur ce petit ensemble sans améliorer son comportement général. Conservez donc des cas de contrôle distincts et documentez les versions testées.

Contrôler la provenance et les sorties

Si vous utilisez un outil génératif pour créer les cas, ne lui fournissez pas de dossiers réels non autorisés. Demandez des situations imaginaires à partir de règles artificielles ou de documents publics adaptés. Relisez ensuite : une sortie peut contenir un nom, une adresse ou un détail plausible qui ressemble à une information réelle. Supprimez les détails inutiles et marquez clairement le caractère fictif.

Lorsque des données réelles entrent dans la fabrication du jeu, traitez cette étape comme un projet de données à part entière. Faites examiner la finalité, les accès, l’environnement, les conditions de conservation et les risques. Le fait de ne diffuser que la sortie générée ne permet pas de négliger le traitement initial.

Organiser la transition vers un usage réel

Un prototype testé sur des exemples fictifs peut démontrer qu’un parcours est compréhensible. Il ne prouve pas la représentativité du jeu, l’absence de biais ou la sécurité de l’ensemble. Avant un usage réel, identifiez les vérifications complémentaires proportionnées au contexte et les responsabilités. Un usage clinique ne peut pas être validé par la seule grille présentée ici.

Conservez un registre simple : version du jeu, provenance, objectif, résultats, erreurs et décisions. Reliez-le à la gestion des versions de la base documentaire et aux règles qui évitent le shadow AI. Les services IA de DEMETER SANTÉ présentent les axes de cadrage et d’accompagnement ; le périmètre d’une intervention se définit selon votre besoin.

Questions fréquentes

Des données synthétiques sont-elles toujours anonymes ?

Non. La CNIL rappelle que ce n’est pas systématique. La provenance des données, leur mode de génération et les risques de rapprochement doivent notamment être examinés.

Remplacer le nom suffit-il pour tester une IA avec un dossier réel ?

Non. D’autres informations peuvent permettre une identification. Un simple remplacement d’identifiants directs peut relever de la pseudonymisation, pas d’une anonymisation.

Quel cas utiliser pour un premier prototype sans données personnelles ?

Vous pouvez construire un scénario entièrement fictif avec des règles imaginaires, une entrée et une réponse attendue. Vérifiez qu’il ne reprend pas une situation réelle reconnaissable.

Peut-on mesurer la fiabilité avec des exemples générés par la même IA ?

Ces exemples peuvent enrichir une exploration, mais ne suffisent pas à établir la fiabilité. Leur qualité, leur diversité et les réponses attendues doivent être contrôlées indépendamment du résultat produit.

Un test sur données fictives valide-t-il une application de santé ?

Non. Il peut explorer un fonctionnement limité, mais ne remplace aucune validation, analyse de risque ou exigence applicable au produit et à son usage réel.

Sources et méthode

Article rédigé le 28 octobre 2026 sous la signature éditoriale de Dimitri Jorand. Sources primaires consultées à cette date. Préparation rédactionnelle assistée par IA et contrôle documentaire des références. Les exemples sont fictifs ; les grilles et propositions pratiques sont originales. Ce support d’information ne remplace pas une analyse de votre situation par les interlocuteurs compétents ni les procédures de votre structure.

• CNIL : Mobiliser la base légale de l’intérêt légitime pour développer un système d’IA ; consultation : 2026-10-28
• CNIL : L’anonymisation de données personnelles, 19 mai 2020 ; consultation : 2026-10-28