Comment les données synthétiques permettent de meilleurs modèles d’IA

Il y a près d’un mois, j’ai participé au hackathon sur les données de santé synthétiques organisé par l’Hospital Clínico de Madrid. Ce qui m’a le plus frappé, c’est que, malgré les efforts et les investissements énormes dans les systèmes d’information, l’information de qualité est rare. Cela fait d’une éventuelle transformation du système de santé par les données et l’intelligence artificielle presque une chimère.

David Rey, docteur
18 décembre 2025

Cela dit, je n’ai pas été vraiment surpris. D’après mon expérience de ces dernières années, ce problème revient dans tous les secteurs. Même dans les entreprises nées du numérique, obtenir des données de qualité exige de changer de façon de travailler, et nous savons déjà que « la culture mange la stratégie au petit-déjeuner »… et parfois, rien n’est plus rigide que le cerveau humain.

Mais, au fil de la journée, je me suis un peu rassuré. Il semblait que, si les données réelles n’existaient pas, on pouvait construire une réplique suffisamment bonne (des données synthétiques). Même si, clairement, ce sont toujours des données « inventées », et dans un environnement aussi sensible, une deuxième question m’est venue : sont-elles assez bonnes ?

Presque immédiatement, je me suis souvenu du processus de construction de DeepSeek R1 en début d’année, où — en simplifiant à l’extrême — le modèle de raisonnement a été entraîné avec des données générées par un modèle auxiliaire (DeepSeek R1-Zero). Grâce à l’apprentissage par renforcement, le modèle a acquis des capacités de raisonnement de plus en plus sophistiquées. Une part importante de ce succès tenait précisément à l’usage de données synthétiques.

Par ailleurs, ces dernières semaines chez Tietai, nous améliorions le module d’identification d’entités de données dans le texte libre, selon le modèle de données OMOP CDM (qui se veut un modèle commun et standardisé pour tout type de donnée clinique).

Notre objectif était de créer un système très efficace et précis capable de traiter de grands volumes de textes du système de santé sans tenir compte a priori de leur structure : histoires cliniques en texte libre, comptes rendus de sortie, suivis, etc.

Le problème n’est pas nouveau : ce type de tâche souffrait d’une précision faible avec les techniques traditionnelles de traitement du langage naturel. Cependant, l’apparition récente des grands modèles de langage (LLM) et de leurs versions réduites (SLM) a ouvert une fenêtre d’amélioration : la complexité technique a baissé, mais le coût et les délais d’exécution des gros traitements restent élevés.

Serait-il possible d’améliorer les approches plus traditionnelles d’étiquetage d’entités dans le texte (plus efficaces) grâce à des données synthétiques ? Autrement dit, pouvons-nous construire un modèle capable de détecter dans le texte des éléments des types suivants ?

Plus précisément, je m’étais concentré sur des modèles spécifiques fondés sur des architectures de type BERT, comme Clinical Bert, mais orientés vers ma tâche. Le premier problème était que je devais construire une base de données, et le second, comment m’assurer de ne pas avoir commis de surapprentissage par consanguinité en consommant des données que j’avais moi-même produites.

Je me suis donc mis au travail pour construire le jeu de données dans ce format :

{
  "text": "Ibuprofen 500 mg every morning for headache after bronchoscopy of the left lung",
  "tokens": ["Ibuprofen", "500", "mg", "every", "morning", "for", "headache",
             "after", "bronchoscopy", "of", "the", "left", "lung"],
  "tags":   ["B-D", "O", "B-U", "B-T", "I-T", "O", "B-C",
             "O", "B-P", "O", "O", "B-A", "I-A"]
}

Au total, 20 873 enregistrements seraient générés, répartis en trois groupes :

• Jeu d’entraînement : 16 699 (80 %)
• Jeu de test : 2 087 (15 %)
• Jeu de validation : 2 087 (15 %)

Ces données n’ont pas été générées de façon totalement aléatoire ; on impose que les enregistrements contiennent une proportion minimale de cas positifs pour chaque catégorie, ainsi que des cas négatifs ou fortement négatifs.

Comment construire le jeu de données et le modèle ?

L’idée générale est de construire un jeu de données affiné en généralisant les erreurs observées. Le processus comprend une série d’étapes :

1. Générer des données synthétiques avec un grand modèle tuteur.
2. Valider la qualité des données synthétiques avec un autre modèle tuteur, pour garantir la qualité des données utilisées.
3. Diviser le jeu généré en 3 parties disjointes : (1) entraînement (60 %), (2) test/validation pendant l’entraînement (20 %), (3) validation hors échantillon (20 %).
4. Ajuster un modèle petit et efficace, qui intègre des connaissances du domaine mais n’inclut pas le jeu de validation. Ici, PlanTL-GOB-ES/bsc-bio-ehr-es, pré-entraîné sur 278 000 documents et notes cliniques.
5. Sur le jeu de validation d’origine, nous analysons avec un autre modèle tuteur (Gemini 2.5 Flash) pour généraliser les schémas observés dans les erreurs du jeu de test.
6. Pour chacune des erreurs, nous générons un nouveau jeu de données avec 3 observations par schéma.
7. Enfin, nous affinons à nouveau le modèle à l’étape 4 sur 3 itérations, jusqu’à ce que les métriques de validation du système cessent de s’améliorer.

L’image ci-dessus explique mieux la clé du processus : le modèle tuteur examine les erreurs et tente d’expliquer une classification incorrecte. Ce sera l’entrée pour qu’un autre modèle génère synthétiquement des observations positives qui renforcent une classification correcte.

Ces résultats sont-ils généralisables ?

Nous avons donc un modèle capable d’étiqueter l’information clinique avec précision (par rapport à notre jeu initial), mais la question est : cette qualité est-elle réelle, ou seulement due au fait que nous avons « cuisiné » les données à notre goût ?

Avant de lever le mystère, je m’arrête pour montrer le résultat du modèle. Comme on le voit, il est capable d’identifier dans le texte des schémas correspondant aux entités :

Le modèle de classification avait aussi obtenu des métriques plus qu’honorables :

• Exactitude : 98 %
• Rappel : 92 %
• F1 : 94 %

Jusque-là, tout allait bien, mais il fallait confirmer que l’expérience généralisait correctement. J’ai donc décidé de voir comment il fonctionnait sur un jeu de données public de maladies appelé CANTEMIST. Avec ces données, je m’assurais d’évaluer les résultats sur des données hors échantillon.

Par ailleurs, je voulais comparer les performances de mon modèle à celles d’un modèle similaire entraîné pour une tâche spécifique. Par chance, la SEDIA et le BSC avaient entraîné un modèle de classification sur la même base que le mien, mais en utilisant CANTEMIST comme jeu d’entraînement et de validation. Ils l’avaient entraîné avec 30 565 observations.

Pour comparer les deux modèles, j’ai utilisé des mesures d’exactitude au niveau de l’enregistrement (plutôt qu’au niveau du token, comme dans l’article du modèle cité au paragraphe précédent). Les résultats ont été plus que surprenants : les deux modèles fonctionnaient de façon très similaire.

J’étais alors un peu plus rassuré. Le modèle construit avait non seulement des niveaux de précision similaires à ceux d’un modèle entraîné spécifiquement pour la tâche, mais il était aussi capable de classer d’autres types d’entités. Mon hypothèse sur l’utilité des données synthétiques dans ce domaine était ainsi confirmée expérimentalement.

Conclusions

Pour conclure, on peut dire que l’usage de données synthétiques générées et validées de façon systématique n’est pas seulement techniquement viable : c’est une alternative adaptée lorsque les données sont difficiles à obtenir.

Dans des secteurs aussi sensibles que la santé, les données synthétiques peuvent être une bonne alternative (parfois même la seule).

Points clés à retenir :

• Il est possible de construire des modèles polyvalents offrant des performances comparables à des solutions très spécialisées, réduisant la dépendance aux développements ad hoc et facilitant la réutilisation dans différents cas d’usage.
• Le transfert de connaissances de grands modèles vers des modèles plus petits et plus efficaces permet d’équilibrer qualité et coût, et rend possibles des déploiements en production avec des besoins d’infrastructure réduits.
• Le pipeline fondé sur la génération, la validation automatique et l’affinage itératif des données synthétiques minimise les risques de surapprentissage et améliore la généralisation.
• Le coût très faible d’acquisition des données (35 $) est un avantage clair de cette méthode, surtout dans les secteurs où l’accès aux données réelles est limité ou coûteux.
• Cela dit, je tiens à préciser que l’étiquetage humain reste l’idéal, mais ce test nous permet d’affirmer qu’il s’agit d’une source valable tant que l’on dispose de jeux de validation (comme dans notre cas).