SDG (hitsz-ids/synthetic-data-generator) : générer des tables synthétiques sans quitter Python
SDG is a specialized framework designed to generate high-quality structured tabular data.
En bref
- De quoi s’agit-il ?
- SDG est un cadre Python sous licence Apache-2.0 qui produit des données tabulaires structurées, avec des modèles statistiques, GAN et LLM branchés sur un même pipeline de traitement. Son intérêt réel tient moins à la liste des modèles qu'à la couche de métadonnées et de conversion qui les entoure.
- À qui s’adresse-t-il ?
- SDG convient aux équipes Python qui doivent produire des tables synthétiques à partir de schémas hétérogènes et qui veulent garder la main sur le prétraitement des colonnes. Il ne convient pas à qui cherche un service hébergé ou une bibliothèque sans dépendance à un backend de modèles.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 15 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : des tables, pas des images
La plupart des bibliothèques de données synthétiques se sont construites autour de données non structurées. SDG annonce l'inverse dès sa première phrase : c'est un cadre spécialisé dans la génération de données tabulaires structurées. Le public visé est donc l'ingénieur ou le data scientist qui dispose d'un jeu de données relationnel et qui veut en produire une copie exploitable pour le partage, l'entraînement de modèles, le débogage ou les tests système. Le README énumère ces quatre usages. L'argument mis en avant est juridique avant d'être technique : les données synthétiques ne contiennent pas d'information sensible tout en conservant les caractéristiques essentielles des données d'origine, ce qui les placerait hors du champ de règlements comme le GDPR ou l'ADPPA. C'est une affirmation de positionnement, pas une garantie. La qualité de l'anonymisation dépend du modèle entraîné et du degré de recouvrement entre les lignes générées et les lignes réelles, question que le README n'aborde pas. Un lecteur qui cherche une protection formelle devra la chercher ailleurs que dans ce dépôt.
Une architecture en deux couches : métadonnées et Data Processor
Le dépôt s'organise autour d'un paquet Python nommé sdgx, publié sur PyPI. Deux modules structurent le fonctionnement. Le premier est sdgx.data_models.metadata, dont une note de février 2024 indique qu'il décrit les tables simples et multiples, prend en charge plusieurs types de données et infère automatiquement ces types. C'est la couche qui traduit une table brute en description exploitable par un modèle. Le second est le Data Processor, fusionné en mai 2024. Ses responsabilités sont explicites : convertir le format de certaines colonnes avant l'entrée dans le modèle, par exemple les colonnes Datetime, afin qu'elles ne soient pas traitées comme des valeurs discrètes ; reconvertir les données produites par le modèle vers le format d'origine ; appliquer un prétraitement et un post-traitement personnalisés selon le type ; gérer les valeurs nulles présentes dans les données sources ; et accueillir un système de plugins. Ce découpage est le vrai contenu du projet. Les modèles génératifs sont interchangeables, la conversion des types ne l'est pas, et c'est là que se joue la fidélité d'une table synthétique.
Les modèles disponibles et ce que le dépôt en dit
Trois familles cohabitent. CTGAN est le modèle historique, présent depuis la version 0.1.0 de décembre 2023, avec une prise en charge revendiquée de volumes de données à l'échelle du milliard ; le dépôt renvoie à un benchmark hébergé dans le dossier benchmarks et à un exemple Colab dédié. GaussianCopula a été intégré en novembre 2024 au système de Data Processor, avec deux améliorations annoncées : la détection automatique des relations entre colonnes, avec possibilité de les spécifier manuellement, et une réduction de la consommation mémoire sur les données discrètes permettant l'entraînement sur des milliers d'entrées catégorielles avec une machine 2C4G. Cette dernière affirmation vient des notes de version du projet, pas d'une mesure indépendante. Enfin, sdgx.models.LLM.single_table.gpt.SingleTableGPTModel couvre la génération par LLM, avec une particularité : produire des données synthétiques sans données d'entraînement, à partir des seules métadonnées. Le README mentionne aussi une inférence hors table. Les trois versions publiées listées sont 0.2.2, 0.2.3 et 0.2.4, cette dernière datant de décembre 2024.
Mise en route et clés de configuration
L'installation passe par PyPI, le badge de version du README pointant vers le paquet sdgx. Le matériel fourni ne détaille pas la commande exacte, donc la première étape vérifiable reste de confirmer la version publiée avant d'écrire du code contre une API qui a bougé trois fois en un mois fin 2024. Le point d'entrée côté modèles est le chemin sdgx.models.LLM.single_table.gpt.SingleTableGPTModel pour la variante LLM, et sdgx.data_models.metadata pour la description des tables. Les exemples exécutables sont des notebooks Colab : un pour la synthèse par LLM, un pour l'inférence hors table, un pour le CTGAN à grande échelle, un pour les métadonnées d'une table simple, et un pour la combinaison de colonnes. La documentation de référence est hébergée sur Read the Docs, avec une page dédiée aux combinaisons de colonnes dans les guides utilisateur. Le fichier ROADMAP.md à la racine donne la trajectoire prévue. Ces éléments suffisent pour évaluer le projet, pas pour l'installer sans lire la documentation en ligne.
Le point faible : une documentation qui suppose le contexte
Le README est un journal de versions plus qu'un guide. Les fonctionnalités y arrivent sous forme de notes datées, avec des liens vers des pull requests et des notebooks, et il faut reconstituer soi-même l'ordre d'appel des modules. La phrase sur l'exemption réglementaire est présentée comme un fait alors qu'elle dépend entièrement du modèle utilisé et du niveau de ressemblance des lignes produites avec les lignes sources. Rien dans le matériel fourni ne décrit de mécanisme de mesure de cette ressemblance, ni de contrôle de fuite d'information. Autre limite : la prise en charge des tables multiples est annoncée au niveau des métadonnées, mais tous les modèles cités sont marqués single_table, ce qui suggère que la génération multi-tables n'est pas couverte par les mêmes briques. Enfin, les performances annoncées sur le CTGAN proviennent d'un benchmark interne au projet, comparé à SDV, et non d'une évaluation tierce. Un lecteur qui a besoin de garanties chiffrées sur la fidélité statistique devra les produire lui-même.
Face à SDV : deux façons d'organiser le même travail
SDV est le point de comparaison que le projet choisit lui-même, puisque le benchmark de décembre 2023 s'y réfère explicitement. La différence porte sur l'architecture, pas sur la liste des modèles. SDV s'est construit autour d'une abstraction de métadonnées unique qui pilote l'ensemble des synthétiseurs, avec une API stable et une documentation longue. SDG place la conversion des types et le post-traitement dans un module distinct, le Data Processor, avec un système de plugins, ce qui laisse davantage de prise sur les colonnes Datetime, les valeurs nulles et les formats exotiques. En contrepartie, cette souplesse se paie en surface d'API : le projet a modifié ses points d'entrée à plusieurs reprises entre 0.1.0 et 0.2.4, et une équipe qui écrit du code contre sdgx doit suivre les notes de version. SDV mise sur la stabilité et la couverture de cas standard, SDG sur la capacité à traiter une colonne récalcitrante sans réécrire le pipeline. La présence d'un modèle LLM générant sans données d'entraînement est un axe que SDV n'expose pas de la même manière dans le matériel fourni.
Maintenance, licence et coût de suivi
Le dépôt est actif, non archivé, avec un dernier push en août 2026 et une CI GitHub Actions, pre-commit et Read the Docs en place. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et de l'avis de licence, et une clause de brevets. Rien dans le matériel fourni n'indique de restriction supplémentaire côté modèles pré-entraînés, mais un modèle LLM utilisé pour la synthèse apporte ses propres conditions, qu'il faut vérifier séparément. Le coût de maintenance se concentre sur deux points : le suivi des versions de sdgx, dont l'API a changé entre 0.1.0 et 0.2.4, et la dépendance à un backend de modèles pour la partie LLM. Le CTGAN à grande échelle est présenté comme fonctionnant sur une machine modeste dans le cas de GaussianCopula, mais aucune contrainte matérielle n'est donnée pour le CTGAN lui-même au-delà du benchmark interne. Prévoir un environnement de test où l'on régénère un échantillon après chaque montée de version reste la seule façon de détecter une régression de format.
Conclusion éditoriale
SDG convient aux équipes Python qui doivent produire des tables synthétiques à partir de schémas hétérogènes et qui veulent garder la main sur le prétraitement des colonnes. Il ne convient pas à qui cherche un service hébergé ou une bibliothèque sans dépendance à un backend de modèles. Avant d'adopter, vérifier la version publiée sur PyPI, l'état des modèles listés dans ROADMAP.md et le comportement du Data Processor sur vos colonnes Datetime et vos valeurs nulles.
Notes de la communauté