Données synthétiques en assurance : tester sans confondre utilité et anonymat

Les données synthétiques sont séduisantes parce qu’elles promettent trois choses à la fois : davantage de cas, moins d’exposition de données réelles et des tests plus rapides. Ces bénéfices existent dans certains périmètres, mais ils ne découlent jamais du seul mot « synthétique ». Un tableau généré à partir de dossiers clients peut conserver des relations utiles, perdre des cas rares et laisser subsister un risque de divulgation. Une image artificielle peut aider à tester un pipeline, tout en étant trop propre pour représenter les photos reçues après un sinistre.

La décision rationnelle ne consiste donc pas à demander si les données synthétiques sont « bonnes » ou « anonymes ». Elle consiste à préciser l’usage, la propriété à préserver, l’information à protéger et le niveau de preuve. Cet article propose un protocole applicable aux tables, documents et images de l’assurance, sans présenter la synthèse comme un remplacement général des observations réelles.

Distinguer synthèse, pseudonymisation et anonymisation

Une donnée synthétique est produite par un mécanisme conçu pour créer de nouveaux enregistrements : règles, simulation, modèle probabiliste ou modèle génératif. Elle peut être entièrement artificielle, ou combiner des éléments simulés et des données observées. Cette origine ne dit pas, à elle seule, si une personne peut être isolée, reliée ou inférée.

La CNIL rappelle explicitement que les données synthétiques ne sont pas systématiquement anonymes. Elle les cite comme une option susceptible d’éviter certaines collectes réelles, de modéliser des situations ou de varier des configurations, tout en demandant une analyse de leur statut et des risques. Une donnée pseudonymisée reste une donnée personnelle lorsque le lien avec une personne peut être rétabli à l’aide d’informations supplémentaires ; une donnée véritablement anonyme suppose une analyse beaucoup plus exigeante.

Cette distinction change les choix d’architecture. Tant que l’anonymat robuste n’est pas établi :

• le jeu source et le générateur restent dans un environnement autorisé ;
• la finalité, la base juridique, la minimisation, les accès et la conservation sont traités ;
• la sortie synthétique n’est pas diffusée librement par défaut ;
• les journaux et versions du générateur sont protégés comme des actifs susceptibles de révéler le processus source.

Choisir entre règles, modèles statistiques et modèles génératifs

Le mécanisme doit suivre le phénomène à tester. Plus il est flexible, plus son comportement et ses fuites potentielles demandent de contrôle.

Tableau — Trois familles de génération et leurs usages raisonnables

Famille	Principe	Atout	Limite déterminante
Règles et simulation	Valeurs produites à partir de domaines, contraintes, scénarios et lois explicitement choisis	Contrôle précis de cas de bord et reproductibilité	Ne reproduit que les relations modélisées ; les interactions oubliées restent absentes
Modèle statistique	Estimation de distributions et dépendances, puis échantillonnage de nouveaux enregistrements	Reproduction ciblée de structures tabulaires et de corrélations	Peut lisser les queues, déformer les petits groupes ou mémoriser des points atypiques
Modèle génératif	Apprentissage d’une représentation riche pour générer texte, image, document ou table	Variété de formes et production d’objets complexes	Contrôle plus difficile de la plausibilité métier, de la provenance et de la confidentialité

Une quatrième option est souvent préférable : ne pas générer. Pour vérifier qu’un formulaire accepte des dates et des montants valides, un petit jeu de règles suffit. Pour estimer un indicateur actuariel sensible, l’analyse contrôlée sur les données réelles peut être plus défendable qu’un substitut synthétique mal caractérisé. Pour valider une chaîne OCR, des documents dessinés selon des gabarits explicites peuvent couvrir la mise en page, mais ils ne prouvent rien sur les scans tachés, manuscrits ou compressés du terrain.

La bonne architecture peut combiner les familles : règles pour imposer les contraintes contractuelles, modèle statistique pour varier les distributions, et génération d’image pour créer des dégradations visuelles. Chaque couche reçoit alors son propre test. Une anomalie produite par le générateur ne doit pas être interprétée comme une anomalie réelle du portefeuille.

Attribuer aux données synthétiques le bon rôle en assurance

Tester une intégration sans exposer de dossier client

Des données entièrement fictives et spécifiées peuvent tester les formats, écrans, files de messages, volumes, erreurs de schéma et parcours de reprise. Leur utilité est fonctionnelle : identifiants conformes, relations entre tables, valeurs limites et scénarios d’erreur. Elles n’ont pas besoin de ressembler statistiquement au portefeuille si cette ressemblance n’est pas nécessaire au test.

Fabriquer des cas rares ou des contradictions

Un jeu d’évaluation peut manquer d’une facture dont le total ne correspond pas aux lignes, d’une police avec deux avenants contradictoires ou d’une photo très sombre. La génération permet de construire ces bords à partir d’une spécification métier. Ils rejoignent un lot sentinelle et restent identifiés comme synthétiques ; ils ne servent pas à estimer leur fréquence réelle.

Compléter un entraînement

Le synthétique peut enrichir une classe peu représentée ou varier des formulations. Il peut aussi amplifier la vision du générateur, réduire la diversité réelle ou améliorer le test parce que train et test partagent le même mécanisme artificiel. Toute comparaison doit conserver un lot réel protégé, pertinent et autorisé, puis mesurer séparément les segments. L’article « Votre projet IA a besoin d’un meilleur problème avant de demander plus de données » aide à vérifier qu’un ajout de volume répond bien à une limite mesurée.

Partager un jeu exploratoire

La synthèse peut permettre à des équipes de développer une requête ou un prototype avec une exposition réduite. « Réduite » n’est pas « nulle ». La destination, le contrat, les accès et les attaques plausibles restent à examiner. Un jeu acceptable dans une enclave interne peut être refusé pour une publication ouverte.

Évaluer selon trois axes indépendants : fidélité, utilité, confidentialité

Une table ronde réunie par la FCA, l’ICO et l’Alan Turing Institute propose d’examiner séparément confidentialité, utilité et fidélité. La page précise que ces enseignements reflètent les discussions des participants et non la position officielle des trois organismes. Cette séparation reste opérationnellement utile : aucun axe ne peut servir de proxy automatique aux deux autres.

Axe 1 — Fidélité : quelles propriétés de la source sont reproduites ?

Comparez d’abord le schéma, les domaines de valeurs, les taux d’absence et les contraintes. Examinez ensuite les distributions univariées, les relations entre variables, les séquences temporelles et les queues importantes. La comparaison doit être segmentée : une proximité globale peut masquer la disparition d’un petit portefeuille, d’une langue ou d’un événement coûteux.

La fidélité n’est pas une compétition de ressemblance maximale. Reproduire presque exactement un dossier rare peut améliorer une métrique de distance tout en augmentant le risque de divulgation. À l’inverse, une différence visible peut être sans conséquence pour la tâche. Définissez avant la génération les propriétés nécessaires : conservation d’un ordre de grandeur, relation entre garantie et plafond, cohérence d’une chronologie ou variété d’une mise en page.

Axe 2 — Utilité : le jeu permet-il l’action prévue ?

Le NIST souligne qu’il n’existe pas de métrique d’utilité universelle pour les données protégées : l’évaluation dépend de ce que les utilisateurs feront des données. Son analyse sur les métriques d’utilité en confidentialité différentielle recommande une suite de mesures reliées aux analyses cibles plutôt qu’un score général.

Pour un usage assurance, rejouez la tâche exacte sur réel et synthétique dans un environnement autorisé : même requête, même entraînement, même pipeline ou même scénario de charge. Comparez les décisions, l’incertitude, les erreurs par segment et les conclusions métier. Une table peut préserver moyennes et corrélations simples tout en changeant le classement des risques ou le rappel d’une classe rare.

Axe 3 — Confidentialité : que peut apprendre un attaquant plausible ?

La confidentialité s’évalue en fonction de la connaissance et des moyens de l’attaquant. Examinez la proximité anormale entre enregistrements synthétiques et réels, l’isolement d’individus, l’inférence d’attributs et l’inférence d’appartenance — déterminer si un dossier faisait partie des données utilisées. Les résultats dépendent du générateur, des paramètres, du jeu source et de l’accès offert.

L’outil SDNist illustre l’usage conjoint de métriques d’utilité et de confidentialité pour des données tabulaires. Sa page précise son périmètre et sa version ; il ne constitue pas un certificat applicable à tout jeu d’assurance. Un outil générique ne remplace ni le modèle de menace ni l’analyse juridique.

Tableau — Questions de validation avant tout usage

Axe	Tests à prévoir	Critère de refus possible
Fidélité	Contraintes, distributions, dépendances, temporalité, queues et segments	Cas métier impossibles ou disparition d’un segment nécessaire
Utilité	Résultat sur la tâche cible, erreurs par segment, stabilité des conclusions	Décision différente sur une dimension critique
Confidentialité	Proximité, singling out, inférence d’attribut et d’appartenance, attaques adaptées	Reproduction ou inférence excessive au regard du modèle de menace
Gouvernance	Provenance, droits, versions, accès, rétention, reproductibilité	Jeu source ou générateur non maîtrisé

Tester le risque de divulgation et comprendre la confidentialité différentielle

Le NIST Special Publication 800-226, finalisée en mars 2025, explique comment évaluer les garanties de confidentialité différentielle. Elle avertit que les données synthétiques générées sans confidentialité différentielle peuvent n’offrir que des garanties informelles et rester vulnérables à des attaques. Elle rappelle aussi que la synthèse ajoute de l’incertitude, peut réduire l’exactitude de sous-populations et propager des biais.

La confidentialité différentielle fournit un cadre mathématique qui borne l’influence de la présence ou de l’absence d’une personne sur une sortie. Mais une annonce « DP » ne suffit pas. Il faut examiner l’algorithme, l’unité protégée, le budget de confidentialité et sa composition, les paramètres, les prétraitements, l’implémentation et les publications successives. Une garantie mal paramétrée ou mal implémentée ne doit pas être résumée par un label.

La protection entraîne un arbitrage avec l’utilité. Le NIST note que produire des données synthétiques différentiellement privées et précises reste difficile en pratique. L’objectif n’est donc pas de maximiser simultanément trois scores abstraits ; il est de décider si une configuration satisfait un usage donné sous un risque résiduel accepté. Si l’usage exige une grande précision sur un petit segment sensible, une analyse confinée sur données réelles peut être préférable à une diffusion de microdonnées synthétiques.

Les travaux originaux sur les attaques restent utiles pour construire le test. Par exemple, van Breugel et ses coauteurs, AISTATS 2023, proposent une attaque d’inférence d’appartenance fondée sur la détection du surapprentissage des générateurs synthétiques. Ce résultat ne signifie pas que toute synthèse fuit ; il démontre pourquoi la confidentialité doit être testée contre un adversaire, pas inférée à partir de l’aspect fictif des lignes.

Scénario hypothétique : recette d’un tri de déclarations de sinistre

Le scénario suivant est pédagogique ; il ne décrit pas un déploiement réel et ne revendique aucun gain. Un assureur souhaite tester un classifieur qui oriente des déclarations habitation vers plusieurs files. Les données réelles autorisées sont peu nombreuses pour certains événements rares et ne peuvent pas être distribuées aux prestataires de développement.

L’équipe crée trois couches. Des règles produisent des messages avec formats valides, pièces absentes, dates incohérentes et identifiants impossibles. Un modèle statistique génère des tables de métadonnées afin de simuler des volumes et dépendances ciblées. Un modèle de langage produit des formulations variées à partir de scénarios fictifs, sans recevoir de texte client brut. Chaque sortie porte la méthode et la graine de génération.

La fidélité vérifie que les contraintes métier sont respectées et que les distributions explicitement nécessaires au test restent plausibles. L’utilité compare le classifieur entraîné ou testé avec ces données à un lot réel protégé, notamment par type d’événement et qualité de message. La confidentialité examine les proximités avec les données sources utilisées par le modèle statistique, puis des attaques d’appartenance et d’attribut adaptées.

Si les messages synthétiques sont trop propres, le score réel sur les e-mails incomplets se dégrade : le jeu est refusé pour l’entraînement, mais peut rester utile pour tester l’interface. Si le modèle statistique reproduit de trop près quelques combinaisons rares, la diffusion au prestataire est refusée ; l’équipe peut réduire le périmètre, renforcer la protection ou exécuter le test dans un environnement contrôlé. Une même version reçoit ainsi des décisions différentes selon l’usage.

Ce cas prolonge la méthode exposée dans l’analyse des dossiers de souscription imparfaits : l’IA ne doit pas transformer une entrée incomplète en certitude. Il complète aussi l’évaluation multimodale lorsqu’un test associe message, document et photographie.

Décider : utiliser, restreindre ou refuser

La fiche de décision croise l’usage et les trois axes :

• Utiliser. Les propriétés nécessaires sont mesurées, la tâche cible reste valide, le risque de divulgation est compatible avec le contexte, et les limites sont documentées.
• Restreindre. Le jeu convient à des tests fonctionnels internes mais pas à l’entraînement, au partage externe ou à une analyse d’un petit segment. L’accès et la durée sont adaptés.
• Régénérer. Une erreur de contrainte, une couverture insuffisante ou une attaque identifiée peut être corrigée avec une nouvelle version et une nouvelle validation.
• Refuser. L’anonymat est seulement supposé, l’utilité critique n’est pas préservée, le générateur ou les données sources ne sont pas maîtrisés, ou aucune mesure ne permet d’éclairer l’usage.

Un score agrégé ne permet pas cet arbitrage. Conservez un tableau par version indiquant les tests, résultats, seuils, exceptions, hypothèses, attaques tentées et signataires. Si la sortie sert à une décision sensible, l’évaluation sur des données réelles pertinentes et licites reste nécessaire ; le synthétique peut compléter la couverture, pas établir seul la performance en situation.

Gouverner la génération et les versions

Le registre du jeu doit contenir : finalité, propriétaire, jeu source, base d’accès, méthode de génération, code et paramètres, environnement, transformations, versions, tests, usages autorisés, destinataires, durée, seuils et décisions. Les métadonnées permettent de retirer une version si une fuite, une erreur métier ou un changement de finalité apparaît.

Réévaluez lors d’un changement de source, de générateur, de budget de confidentialité, de population, de tâche ou de destinataire. Une version validée pour simuler la charge ne devient pas automatiquement valide pour entraîner un modèle. Une version autorisée en environnement interne ne devient pas automatiquement publiable.

Enfin, attribuez un propriétaire métier à l’utilité et un propriétaire sécurité/confidentialité au modèle de menace. La data science mesure ; elle ne décide pas seule du risque résiduel. Cette séparation rend la synthèse exploitable sans lui attribuer une promesse qu’elle ne peut tenir.

Sources et références

Références consultées le 7 septembre 2026. Les publications scientifiques citées décrivent des méthodes et résultats dans leurs propres jeux ; elles ne constituent pas une validation automatique pour des données d’assurance.

• CNIL — Mobiliser la base légale de l’intérêt légitime pour développer un système d’IA, passage sur les données synthétiques.
• CNIL — Collecter et qualifier les données d’entraînement.
• NIST — Guidelines for Evaluating Differential Privacy Guarantees, SP 800-226, mars 2025.
• NIST — Differentially Private Synthetic Data.
• NIST — Utility Metrics for Differential Privacy: No One-Size-Fits-All.
• NIST — SDNist: Synthetic Data Report Tool.
• FCA — Exploring Synthetic Data Validation: privacy, utility and fidelity, 2023.
• van Breugel et al. — Membership Inference Attacks against Synthetic Data through Overfitting Detection, AISTATS 2023.