Données synthétiques : évaluer le risque résiduel

Des données synthétiques peuvent réduire l’exposition des dossiers réels, mais leur mode de fabrication ne prouve pas leur anonymat. Avant un partage, il faut établir ce que le jeu permet de savoir sur des personnes, dans les conditions concrètes où il sera utilisé. Un fichier sans nom, sans adresse et sans correspondance ligne à ligne peut encore révéler des informations individuelles.

La bonne décision porte sur un usage précis : montrer un écran, mesurer une performance, transmettre un fichier à un partenaire ou publier des données. Ces opérations n’exigent ni la même fidélité au réel ni les mêmes garanties. Commencez par ce besoin, avant de commander une génération.

Séparer trois objets dans le dossier de conformité

Le premier objet est la base source : les dossiers personnels utilisés pour produire les données. Le deuxième est le procédé, éventuellement un modèle entraîné et conservé. Le troisième est le jeu livré. Une conclusion sur le troisième ne dispense pas d’encadrer les deux premiers.

L’Art. 5(1)(b) et (c) du RGPD impose de respecter la finalité et de limiter les données au nécessaire. L’Art. 6(1) exige un fondement pour le traitement des données personnelles. Le projet « fabriquer des données anonymes » ne permet donc pas d’aspirer librement tous les dossiers disponibles.

Si la fabrication constitue une réutilisation, examinez les conditions applicables à ce nouvel objectif, notamment l’Art. 6(4), ainsi que l’information des personnes. Si la source contient des données relevant de l’Art. 9(1), il faut aussi identifier une exception applicable de l’Art. 9(2). Une promesse d’effacement après entraînement ne remplace pas ces vérifications préalables.

La CNIL indique expressément que les données synthétiques ne sont pas systématiquement anonymes dans ses recommandations sur le développement des systèmes d’IA. Cette réserve doit figurer dans la décision d’utilisation, pas seulement dans une annexe technique ignorée des acheteurs.

Anonyme pour quel usage et dans quel contexte ?

Le considérant 26 du RGPD demande de tenir compte des moyens raisonnablement susceptibles d’être utilisés pour identifier une personne, notamment des coûts, du temps et des technologies disponibles. L’examen ne se réduit donc pas à rechercher une colonne « nom ».

Décrivez le destinataire et ses connaissances accessibles : possède-t-il déjà certains dossiers, des plannings, un annuaire ou des informations publiques sur les situations représentées ? Reçoit-il un fichier unique, plusieurs versions ou l’accès au générateur ? Peut-il rapprocher les sorties ? Ces faits font partie de la justification de votre conclusion.

Une interdiction contractuelle de réidentifier peut contribuer aux garanties. Elle ne supprime pas une possibilité technique évidente ni un accès déjà accordé à des informations complémentaires. La distinction entre pseudonymisation et anonymisation reste nécessaire : remplacer les identifiants et conclure à l’absence de nom ne suffit pas à sortir du RGPD.

En cas d’information manquante, écrivez « anonymat non établi dans ce contexte ». Cette formule ne prétend pas que chaque ligne désigne nécessairement une personne ; elle évite de transformer une incertitude en autorisation de diffusion publique.

Lire une promesse fournisseur sans confondre les preuves

Trois affirmations fréquentes répondent à des questions différentes.

« Aucune ligne n’est identique à la source. » Ce contrôle peut détecter des copies exactes. Il ne démontre pas, à lui seul, qu’une combinaison de caractéristiques ou des générations répétées ne révèle rien sur une personne. Demandez quelles colonnes ont été comparées et si les textes libres ont été inclus.

« Les distributions sont très proches. » Cette mesure concerne l’utilité statistique. Elle n’établit pas le caractère anonyme. Un rapport doit expliquer ce qui a été comparé, avec quels écarts, pour quels groupes et pour quel besoin. Un résultat global satisfaisant peut ne rien dire sur le parcours rare qui vous intéresse.

« Le générateur applique la confidentialité différentielle. » Faites préciser le mécanisme, les paramètres, les hypothèses et le périmètre de la garantie par une personne compétente. Le nom de la technique ne permet pas au DPO de conclure sans examiner son application au produit et à la diffusion envisagée.

Le laboratoire d’innovation de la CNIL distingue notamment l’inférence d’appartenance — déduire la présence d’une personne dans la source — et l’inférence d’attribut — déduire une caractéristique la concernant. Son analyse souligne aussi le compromis entre utilité et protection. Ce sont des risques à évaluer, sans prétendre qu’une attaque réussira dans tous les projets.

Exemple S-22 : choisir le bon jeu pour une démonstration

Le dossier suivant est entièrement hypothétique ; il ne décrit aucun essai réel de logiciel. Orbe Réparation veut présenter à un intégrateur quatre fonctions : créer une intervention, affecter un créneau, ajouter une pièce et clôturer le dossier. L’intégrateur demande mille lignes « proches de la production ».

Trois options sont proposées. A consiste à renommer les clients d’un export réel. B consiste à entraîner un générateur sur les historiques. C consiste à écrire des dossiers inventés à partir de la description des quatre fonctions, sans lire ni copier de dossiers clients.

La responsable produit prépare douze dossiers inventés : trois par fonction, pour représenter un chemin ordinaire et deux variantes utiles. Les références sont des codes de démonstration ; aucun téléphone ni email réel n’est utilisé. Les textes décrivent des réparations imaginaires, sans reprendre un récit client reconnaissable.

Le nombre douze est un choix pédagogique de cet exemple, pas un seuil de sécurité. Il ne permet aucune conclusion sur la tenue en charge du logiciel ni sur les proportions réelles de pannes. L’intégrateur reçoit précisément cette limite. Les comptes de ses utilisateurs demeurent, quant à eux, des données personnelles : le caractère fictif des interventions n’anonymise pas l’environnement entier.

Cette décision répond au besoin sans devoir démontrer l’anonymat d’une transformation de l’historique. Elle complète la méthode de préparation des données de test.

Si le besoin statistique est réel, instruire une autre décision

Supposons maintenant qu’Orbe veuille comparer des méthodes de planification selon les délais et les catégories de panne. Les douze dossiers précédents ne répondent pas à cette question. Il faut un dossier distinct, qui précise les propriétés nécessaires et les catégories exclues.

Avant toute extraction, la responsable métier justifie les variables utiles. L’équipe technique décrit la chaîne de fabrication et la personne chargée de l’évaluation prépare les critères d’utilité et de confidentialité. Le responsable du traitement tranche, avec le conseil du DPO lorsqu’il existe. L’Art. 25(1) et (2) du RGPD impose d’intégrer la protection dès la conception et par défaut.

Voici la fiche initiale renseignée pour cette seconde hypothèse, sans résultat d’évaluation inventé :

• Objectif : comparer des délais par grandes catégories de panne ; aucune décision individuelle sur les clients.
• Source envisagée : interventions clôturées, après détermination de la période strictement nécessaire ; extraction non encore autorisée.
• Champs demandés : catégorie, durée et séquence des étapes ; noms, coordonnées et commentaires libres exclus du besoin formulé.
• Destinataire envisagé : équipe de planification ; transmission externe et publication hors périmètre.
• Éléments manquants : justification du traitement source, méthode, évaluations des risques et mesures d’utilité.
• Décision actuelle : pas de génération à partir de l’historique tant que ces réserves ne sont pas levées.

L’absence de commentaires libres ne suffit pas à approuver les autres champs. La durée et la séquence peuvent conserver une particularité reconnaissable. La revue des petits groupes et des recoupements aide à identifier les combinaisons qui demandent une attention spécifique.

Organiser une évaluation dont la conclusion reste lisible

Le protocole doit préciser l’objet effectivement examiné : version du jeu, générateur, paramètres, accès accordés et connaissances utilisées pour rechercher les risques. Conservez également les limites : types d’attaques non évalués, groupes peu représentés, usages exclus. Un résultat sans ce périmètre est difficilement réutilisable pour une décision.

La comparaison avec la source doit elle-même rester protégée. Ne transmettez pas les dossiers originaux à tous les destinataires pour leur permettre de vérifier le jeu. Organisez l’évaluation dans un environnement approprié, avec des accès et des extractions limités conformément à l’Art. 32(1) et (2).

Si une information individuelle réapparaît, suspendez la diffusion concernée et recherchez son origine : copie, mémorisation, variable trop précise ou rapprochement. Une correction exige une nouvelle appréciation de l’ensemble utile ; retirer la seule ligne découverte ne prouve pas que le problème est terminé. Si des données personnelles ont déjà été divulguées sans autorisation, examinez aussi les obligations des Art. 33(1), 33(5) et 34(1), selon la qualification et les risques de la violation.

L’analyse d’impact est obligatoire avant un traitement susceptible d’engendrer un risque élevé, dans les conditions de l’Art. 35(1). L’étiquette « synthétique » ne dispense pas de cette appréciation du traitement source et du projet.

Fixer les conditions de remise et de réexamen

La note finale doit dire quel usage est accepté, par qui et sur quelles preuves. Si le jeu reste personnel ou si son anonymat n’est pas suffisamment établi, un usage restreint ne devient envisageable qu’avec le cadre juridique et les garanties appropriés. La confidentialité contractuelle ne suffit pas à elle seule.

Prévoyez une nouvelle revue si la source, le procédé, les variables, le destinataire ou le mode d’accès change. Une conclusion portant sur un fichier remis une fois ne couvre pas automatiquement une interface permettant des générations répétées. Les versions antérieures déjà distribuées doivent aussi être prises en compte dans le contexte du réexamen.

Ce qu’il faut retenir

• Séparez le traitement source, le générateur et le jeu remis.
• Évaluez la confidentialité et l’utilité pour un usage et des destinataires définis.
• Une preuve de non-copie ne démontre pas, seule, l’absence d’informations individuelles.
• Préférez des dossiers entièrement inventés lorsque le besoin n’exige pas les caractéristiques du réel.

FAQ

Le mot « synthétique » doit-il apparaître dans le fichier ?

Il est utile de l’indiquer dans la documentation et dans les interfaces concernées. Les utilisateurs doivent comprendre qu’ils ne lisent pas des faits individuels vérifiés et ne doivent pas les rattacher arbitrairement à des personnes.

Faut-il supprimer la source après la génération ?

Sa durée dépend de ses finalités licites et de ses obligations propres. La copie préparée pour la génération doit avoir une durée justifiée ; sa suppression ne règle pas automatiquement le devenir du modèle et des sorties.

Un bon rapport fournisseur dispense-t-il d’une revue interne ?

Non. Vérifiez que son objet et ses hypothèses correspondent à votre version, à votre public et à votre usage. Un rapport portant sur un autre jeu ne répond pas nécessairement aux risques du vôtre.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.