Synthetic data : générer des données pour entraîner les LLM et tester ses applications

Documentation des fournisseurs et conditions d'utilisation des sorties vérifiées le 22 octobre 2026. Les exemples de tickets d'assistance et les volumes du pilote ci-dessous ont été conçus pour illustrer la méthode ; ils ne décrivent pas une expérience menée sur un modèle.

Synthetic data : de quelles données parle-t-on ?

Générer des données synthétiques consiste à créer des enregistrements ou des exemples artificiels pour un usage précis. Avec un grand modèle de langage, ou LLM, il s'agit généralement de produire du texte : demandes d'assistance, paires question-réponse, exemples d'extraction ou conversations, à partir d'un cahier des charges et d'un petit ensemble d'exemples approuvés.

Pensez à un simulateur de conduite. Il permet de s'entraîner autant que nécessaire à franchir un carrefour difficile, sans attendre de rencontrer cette situation sur la route. Réussir dans le simulateur ne dit pourtant rien de la fréquence de ce carrefour dans la circulation réelle, ni de votre capacité à conduire sur toutes les routes. Les jeux de données synthétiques permettent cette même distinction utile entre les situations couvertes par l'entraînement et les preuves tirées du réel.

La méthode de génération compte. Un générateur à base de règles applique des consignes, par exemple maintenir l'égalité entre le total d'une commande et la somme de ses lignes. Un synthétiseur de données tabulaires apprend les relations entre colonnes. Un LLM produit du langage à partir d'un prompt et du contexte fourni. Ces approches se combinent : du code crée une commande valide, puis un LLM rédige la réclamation du client à son sujet.

Créer des données synthétiques ne revient pas non plus à masquer un enregistrement. Remplacer le nom d'un client laisse intact le reste de son histoire. L'augmentation de données modifie un exemple existant, par exemple en reformulant une question ; les variantes restent liées à leur source. Aucune de ces opérations ne garantit à elle seule la confidentialité d'un enregistrement ni ne crée de preuve indépendante.

Évaluations : construire des cas dont les réponses sont vérifiées indépendamment

Pour développer une application, les évaluations synthétiques servent surtout à explorer des modes d'échec connus : informations manquantes, consignes contradictoires, demandes non prises en charge ou formulations inhabituelles. Une évaluation, ou eval, est un test reproductible du comportement du système.

Si un assistant doit demander des précisions lorsqu'un problème de compte est ambigu, générez volontairement des demandes ambiguës. Faites vérifier l'action attendue par une personne qui s'appuie sur les règles applicables. La réponse du générateur ne doit pas devenir le corrigé sous prétexte qu'elle paraît assurée.

Conservez un jeu d'évaluation distinct, issu d'interactions réelles que vous êtes autorisé à utiliser, lorsque c'est possible. À défaut, faites rédiger des cas indépendamment par une personne qui connaît la tâche. Cela permet de vérifier le respect du cahier des charges, mais pas d'établir la précision du système sur l'ensemble des situations rencontrées en production.

Fine-tuning : enseigner un comportement précis

Pour adapter un modèle, les exemples synthétiques peuvent illustrer un format, une règle de classification ou un style de réponse peu représenté dans les données disponibles. Le fine-tuning consiste à mettre à jour un modèle en l'entraînant sur des exemples.

Partez d'un échec observable : le modèle envoie systématiquement les tickets ambigus au service facturation. Ajoutez des cas ambigus vérifiés, puis comparez le modèle adapté au modèle de référence sur des exemples restés à l'écart de l'entraînement. La taille du fichier d'entraînement ne mesure pas, à elle seule, la réussite de l'opération.

Suivez le workflow de fine-tuning une fois la tâche et le jeu de tests d'acceptation stabilisés. Si le problème vient d'un contexte factuel absent ou changeant, corrigez d'abord le contexte fourni à l'application avant de tenter d'enseigner des faits au moyen de réponses générées.

Générer des données de test pour les logiciels

Pour développer un logiciel, les données de test synthétiques doivent mettre les règles de l'application à l'épreuve : champs manquants, soumissions en double, longueurs de texte inhabituelles, transitions d'état invalides et enregistrements liés dans la base de données.

Un test du parcours de paiement exige des relations valides entre commandes, clients et paiements. Il n'a pas besoin qu'un modèle de langage invente des calculs. Encodez ces contraintes, puis faites intervenir un LLM lorsque du langage réaliste apporte quelque chose, par exemple une consigne de livraison qui contredit l'adresse d'expédition.

Avant d'acheter un jeu de données, déterminez auquel de ces usages il répond. Des données adaptées à une démonstration ne sont pas nécessairement utiles pour entraîner un modèle, et un corpus d'entraînement ne constitue pas automatiquement un jeu d'évaluation.

Une méthode concrète : des exemples de départ aux candidats vérifiés

Commencez par une tâche délimitée dont vous pouvez expliquer les bonnes réponses sans consulter le générateur. Cette méthode produit des exemples candidats pour orienter des tickets d'assistance fictifs vers billing, access ou human_review.

La règle fictive est simple : les problèmes de paiement et de facture relèvent de la facturation ; les problèmes de connexion et de mot de passe relèvent de l'accès ; les demandes floues ou qui combinent les deux doivent être examinées par une personne. Ne déduisez pas de faits que le client n'a pas fournis.

Six exemples de départ aux étiquettes explicites

Ces exemples rédigés pour l'occasion montrent où passe la frontière :

• « Ma carte a été débitée deux fois. » → billing
• « Cette facture ne correspond pas à mon forfait. » → billing
• « Le lien de réinitialisation a expiré. » → access
• « Je n'arrive pas à me connecter après avoir réinitialisé mon mot de passe. » → access
• « J'ai payé, mais je n'arrive pas à me connecter. » → human_review
• « Ça ne fonctionne toujours pas. » → human_review

Les derniers exemples comptent autant que les plus évidents. Ils apprennent au générateur que l'incertitude est une issue valable. Le guide du few-shot prompting explique comment les exemples transmettent des règles qu'une consigne générale peut laisser floues.

Voici à quoi peut ressembler un candidat après nettoyage. Cet enregistrement est une illustration, pas une sortie d'API recueillie lors d'un appel :

{
  "case_id": "billing-frustrated-indirect-a",
  "text": "Another invoice with the wrong plan, seriously?",
  "proposed_label": "billing",
  "policy_reason": "The customer identifies an invoice problem."
}

Le résultat qui compte est un cas vérifié et traçable. Que le générateur ait renvoyé tous les candidats demandés au départ est secondaire. Ne complétez jamais une cellule de faible qualité dans le seul but d'atteindre le nombre prévu.

Outils de génération de données synthétiques : ce que promet leur documentation

Choisissez les outils selon la partie du processus qu'ils prennent en charge. L'API d'un modèle est l'interface par laquelle votre code demande des sorties ; son service de traitement par lots planifie ces requêtes. Une bibliothèque dédiée aux jeux de données organise la génération et les retours d'évaluation. Un synthétiseur tabulaire apprend les relations dans des données structurées. Aucun de ces rôles ne remplace vos critères d'acceptation.

IA générative et données synthétiques : les API de traitement par lots

OpenAI API propose Batch pour envoyer des requêtes asynchrones dans un fichier JSONL, c'est-à-dire un objet JSON par ligne. Sa documentation exige un custom_id unique et précise que l'ordre des sorties peut différer de celui des entrées. Associez les résultats par identifiant, puis examinez les échecs et les générations incomplètes avant d'analyser les candidats. Documentation d'OpenAI Batch.

Claude API, d'Anthropic, propose Message Batches pour les requêtes Messages indépendantes. Les résultats distinguent les requêtes réussies, en erreur, annulées et expirées ; custom_id relie chaque résultat à son entrée. La limite est opérationnelle : l'acceptation d'un lot ne prouve pas que chaque exemple a été produit. Relancez les requêtes manquantes par identifiant au lieu de régénérer tout le jeu de données. Documentation des lots Claude.

Gemini API, de Google, propose Batch avec des objets de requête intégrés directement à l'appel ou un fichier JSONL téléversé. Les requêtes transmises par fichier portent une key qui identifie le résultat correspondant. Utilisez le fichier pour les jeux de données volumineux traités hors ligne ; le délai annoncé dans la documentation est un objectif. Évitez donc de faire dépendre un workflow interactif d'un traitement immédiat. Documentation de Gemini Batch.

Voici les limites des lots qui déterminent le découpage des traitements, vérifiées dans les documentations liées. Elles ne limitent pas la taille totale du jeu de données que vous pouvez construire en plusieurs traitements.

Une requête de lot et un exemple candidat sont deux unités différentes. Si chaque requête réussie renvoie plusieurs candidats, suivez les deux décomptes. Consignez les erreurs d'analyse, les refus et les sorties tronquées, en plus des erreurs de transport. Une réponse HTTP réussie ne suffit pas à produire une ligne exploitable pour l'entraînement.

Distilabel : organiser la génération et les retours d'évaluation

Distilabel est un framework de données synthétiques et de retours d'évaluation par IA. Il assemble dans des pipelines les étapes de génération, d'évaluation et de traitement des données. Sa documentation décrit des usages de classification, d'extraction, de dialogue et de génération d'instructions. Il devient utile lorsqu'un script ponctuel s'est transformé en une succession d'étapes de génération et de filtrage. Documentation de Distilabel.

Le projet est sous licence Apache-2.0. Son dépôt indique aussi que les auteurs d'origine sont passés à d'autres projets et que des contributeurs de la communauté assurent la maintenance. Figez et validez la version que vous adoptez. La limite pratique reste l'évaluateur : orchestrer le jugement d'un modèle ne rend ce jugement ni indépendant ni juste. Dépôt de Distilabel.

Faker : créer des jeux de test sans modèle de langage

Faker est un paquet Python qui génère de fausses données au moyen de fournisseurs, avec prise en charge de paramètres régionaux et d'une graine pour le générateur aléatoire. Il sert à créer des jeux de test pour une application lorsque vous avez besoin de champs contrôlés plutôt que de raisonnement en langage naturel. Son dépôt indique une licence MIT. Documentation de Faker, dépôt de Faker.

Il vous revient toujours d'encoder les relations métier. Des adresses, des dates et des transactions générées indépendamment ne forment pas un historique client réaliste. Utilisez si possible des identifiants et des domaines réservés aux tests, et empêchez les données générées de déclencher des messages ou d'autres actions en production.

Synthetic Data Vault : modéliser les tables et leurs relations

Synthetic Data Vault, ou SDV, propose de la synthèse de données tabulaires et de l'évaluation statistique, avec des approches documentées pour les tables uniques, les données séquentielles et les tables liées. Ses synthétiseurs apprennent à partir des données que vous fournissez ; ils ne dispensent pas de disposer d'un jeu source que vous êtes autorisé à utiliser. Documentation de SDV.

Dans SDV, GaussianCopulaSynthesizer utilise des méthodes statistiques classiques pour apprendre les distributions des colonnes et leurs relations. CTGANSynthesizer utilise un réseau antagoniste génératif, un modèle entraîné au moyen d'un générateur et d'un discriminateur en concurrence. Tous deux prennent en entrée des données et des métadonnées qui en décrivent la structure. Ce sont des synthétiseurs tabulaires, pas des modèles conversationnels généralistes. Documentation Gaussian Copula, documentation CTGAN.

La limite est la fidélité aux exigences de la tâche. Des distributions de colonnes qui se ressemblent ne prouvent pas que les combinaisons rares, les règles entre tables ou le comportement d'un modèle en aval sont préservés. Validez les relations dont dépend votre application, y compris les clés étrangères qui relient les enregistrements enfants à leurs parents.

Choisir un générateur de données synthétiques selon ce qui reste à vérifier

Utilisez une API de modèle lorsque ce qui manque est la variété des formulations. Ajoutez Distilabel lorsque l'orchestration reproductible de la génération et des retours justifie cette dépendance supplémentaire. Choisissez Faker pour des jeux de test aux valeurs contrôlées. Envisagez SDV lorsque les relations statistiques entre tables comptent et que vous disposez de données sources que vous êtes autorisé à modéliser.

N'achetez pas un générateur plus puissant pour résoudre un problème de règles d'étiquetage floues. Ce problème se situe en amont de tous les outils présentés ici.

Ce que les fournisseurs autorisent pour l'entraînement sur leurs sorties

Vérifiez les restrictions d'utilisation des sorties avant de choisir un modèle enseignant, c'est-à-dire celui qui génère les exemples à partir desquels un autre modèle apprendra. Les lignes suivantes résument les conditions standard des trois fournisseurs de LLM hébergés présentés plus haut ; elles ne déterminent pas si un projet d'entraînement particulier y est conforme.

• OpenAI : son contrat de services restreint l'utilisation des sorties pour développer des modèles d'IA concurrents. Il prévoit des exceptions pour les modèles principalement destinés à catégoriser, classer ou organiser des données, à condition qu'ils ne soient ni distribués ni commercialisés auprès de tiers, ainsi que pour la personnalisation de modèles via les services désignés par OpenAI. Contrat de services.
• Anthropic : ses conditions commerciales interdisent d'accéder aux services pour construire des produits ou services concurrents, y compris pour entraîner des modèles d'IA concurrents, sauf accord exprès d'Anthropic. Conditions commerciales.
• Google : les conditions supplémentaires de Gemini API interdisent d'utiliser les services pour développer des modèles concurrents ; leurs dispositions Google Search Grounding interdisent séparément l'entraînement sur les Grounded Results ou les Search Suggestions. Conditions de Gemini API.

La licence logicielle d'une bibliothèque est distincte des conditions du modèle qu'elle appelle, de la licence des éventuels poids du modèle et de vos droits sur les exemples sources. La seule propriété des sorties ne règle pas toutes ces questions.

Données de test et confidentialité : une vérification à part entière

Une origine synthétique ne garantit pas la confidentialité. Si vous copiez des enregistrements confidentiels dans un service de génération non approuvé, produire ensuite des remplacements d'apparence fictive n'annule pas cette divulgation.

Les travaux de Stadler, Oprisanu et Troncoso sur la publication de données synthétiques ont montré que les gains de confidentialité et l'utilité variaient selon les modèles évalués. La conséquence pratique est d'évaluer les données diffusées et leur processus de génération, sans prendre le mot « synthétique » pour un certificat d'anonymat. Article de recherche USENIX.

Préférez des exemples de départ fictifs rédigés à partir d'un schéma et de règles approuvés lorsque cela suffit aux tests logiciels. S'il faut préserver des régularités statistiques réelles, traitez les sources dans un environnement approuvé et évaluez les informations que le jeu généré peut révéler.

Recherchez les identifiants directs, les passages copiés, les combinaisons rares et les rapprochements possibles avec des informations déjà connues d'un tiers. Remplacer un nom tout en conservant un incident distinctif, un lieu et une date peut laisser la personne reconnaissable. Pour une diffusion sensible, quelques vérifications manuelles ponctuelles et une recherche de doublons ne suffisent pas ; l'évaluation de la confidentialité doit être adaptée à la menace et aux destinataires prévus.

Les politiques d'entraînement des fournisseurs répondent à une autre question que votre droit d'entraîner un modèle sur les sorties. Par exemple, les conditions des services gratuits de Gemini mettent en garde contre l'envoi d'informations sensibles, tandis que les conditions d'utilisation des données des services payants indiquent que les prompts et les réponses ne servent pas à améliorer les produits de Google. Les conditions appliquent aussi ces règles des services payants aux usages gratuits dans l'EEE, en Suisse et au Royaume-Uni. Conditions d'utilisation des données de Gemini.

Ni l'engagement d'un fournisseur à ne pas entraîner ses modèles sur vos données, ni une exécution locale ne prouvent que le jeu obtenu peut être partagé sans risque. Conservez sa provenance et ses contrôles d'accès jusqu'à la fin de la vérification préalable à sa diffusion.

Quelles promesses sur les données synthétiques sont exagérées ?

L'exagération principale consiste à faire croire que davantage de lignes générées comble un manque de preuves. Ces lignes peuvent élargir les situations d'entraînement et révéler des échecs, mais aussi reproduire les mêmes hypothèses à grande échelle.

Des formulations différentes peuvent masquer les mêmes situations

Un jeu de données peut contenir des phrases distinctes tout en répétant un nombre très limité de situations. Après filtrage, suivez la couverture des scénarios : quelles règles métier, ambiguïtés et situations d'échec restent représentées ?

Dans l'exemple des tickets, multiplier les réclamations sur les factures ne compense pas l'absence de demandes combinant facturation et accès. Examinez les exemples les plus proches les uns des autres, ainsi que les exemples rejetés et acceptés. Un filtre qualité trop strict peut éliminer discrètement les cas difficiles que vous cherchiez justement à ajouter.

Les biais peuvent survivre à la reformulation

Ne supposez pas que reformuler un exemple biaisé efface ses présupposés. Vérifiez les choix d'étiquettes selon le style de langue, le dialecte, la qualité de l'orthographe et les groupes d'utilisateurs pertinents. Une demande agacée ou mal orthographiée ne devrait pas être orientée différemment, sauf si les règles justifient cette distinction.

Demandez aux personnes chargées de la vérification de comparer des cas appariés où seul change un attribut sans pertinence pour la décision. Si les étiquettes changent, examinez ensemble l'exemple de départ, le prompt et le filtre. Le générateur et le juge peuvent renforcer la même erreur.

Un modèle qui corrige sa propre copie peut être convaincant

Zheng et ses collègues ont documenté des biais de position, de verbosité et d'auto-préférence chez les LLM utilisés comme juges. Un modèle peut récompenser la formulation ou la présentation plutôt que la propriété que vous souhaitiez mesurer. Recherche sur les LLM juges.

Utilisez des contrôles déterministes dès que la réponse est vérifiable mécaniquement. Pour les critères subjectifs, calibrez le juge sur des décisions humaines, masquez l'identité du générateur lorsque c'est possible et examinez les désaccords. Changer de fournisseur pour le juge peut réduire une dépendance commune ; cela ne garantit pas que les erreurs soient indépendantes.

Le guide du LLM juge explique comment vérifier l'évaluateur avant de se fier à son score. Dans un processus de génération synthétique, ce contrôle doit précéder la décision du juge sur les exemples qui deviendront des références d'entraînement.

L'effondrement des modèles est un risque précis, pas une condamnation générale

Shumailov et ses collègues ont étudié l'entraînement récursif sur des données générées et montré comment les parties moins fréquentes de la distribution d'origine peuvent disparaître. Leurs travaux invitent à la prudence lorsqu'on remplace de façon répétée les observations sources par les propres descendants d'un modèle. Ils n'établissent pas que tout fine-tuning synthétique, vérifié et ciblé sur une tâche, soit voué à l'échec. Article de recherche dans Nature.

Conservez les observations d'origine dont l'utilisation est autorisée, préservez volontairement les cas rares et comparez le comportement en aval à une référence restée intacte. Aucun ratio universel entre données synthétiques et réelles ne peut remplacer cette évaluation.

Que changer concrètement dès lundi ?

Passez à l'action si vous pouvez nommer un cas manquant, décrire le comportement correct et vérifier les candidats générés à l'aide d'une règle stable. Commencez par la petite grille de couverture, puis développez uniquement les cellules qui apportent des cas utiles.

Reportez le fine-tuning si les personnes chargées de la vérification ne s'accordent pas sur les étiquettes cibles ou si vous n'avez pas de jeu de tests d'acceptation indépendant. Réglez d'abord le problème de règles et d'évaluation.

Utilisez des jeux de test classiques si le besoin consiste à remplir une base de données, à tester des valeurs limites ou l'intégrité des transactions. Ajoutez du langage généré uniquement lorsqu'il met à l'épreuve un comportement que des données plus simples ne permettent pas de tester.

Avant la prochaine mise en production, comparez le système de référence et le système modifié sur les mêmes cas restés à l'écart du développement. Pour l'orientation des tickets, examinez par catégorie les mauvaises affectations et les demandes qui auraient dû être transmises à une personne. Ne conservez les données synthétiques que si elles améliorent le comportement visé sans régressions inacceptables ailleurs.

Questions fréquentes sur les données synthétiques

Abonnez-vous à la newsletter pour recevoir des guides pratiques sur la création et l'évaluation de systèmes d'IA.