Bonjour à tous,
Je souhaite soumettre au forum une demande d’évolution concernant Kwikly et, plus largement, la restitution du dictionnaire des données du SNDS.
Le besoin
À ma connaissance, les restitutions actuelles du dictionnaire sont pensées pour une consultation humaine (interface web, exports bureautiques). Or de plus en plus d’équipes outillent leurs entrepôts et leurs bacs à sable SNDS avec des solutions de gestion de documentation des bases de données : OpenMetadata, DataHub, Amundsen, Collibra… Ces outils savent ingérer automatiquement des définitions et les rattacher aux tables et colonnes réellement présentes dans la base, à condition de disposer d’une source machine-readable.
Aujourd’hui, chaque équipe reconstitue ce lien à la main, ou via des scripts de scraping fragiles, avec le double coût d’une ressaisie et d’une perte de traçabilité vis-à-vis de la définition officielle.
Une API REST de restitution, en lecture seule, exposant le contenu du dictionnaire en JSON. Par exemple :
GET /bases— les périmètres (DCIR, PMSI MCO/SSR/HAD/RIM-P, CépiDc, référentiels bénéficiaires…)GET /tablesetGET /tables/{id}— nom technique, schéma, libellé, définition, granularité, historique de disponibilité par annéeGET /tables/{id}/colonnes— nom technique, libellé, définition, règle de gestion, type et longueur, caractère clé, nomenclature associéeGET /nomenclatures/{id}/valeurs— les valeurs de codes et leurs libellés
Avec quelques propriétés qui font la différence côté intégration :
- des identifiants stables et versionnés (une variable renommée ou supprimée doit rester traçable) ;
- une date de dernière mise à jour et un numéro de version du dictionnaire, pour ne réingérer que le delta ;
- de la pagination et un filtrage simple (par base, par table, par année) ;
- une documentation OpenAPI.
Un alignement, même partiel, sur les modèles d’entités d’OpenMetadata (Table, Column, GlossaryTerm) ou sur DCAT-AP faciliterait beaucoup l’écriture de connecteurs réutilisables par tous.
Une solution a minima
Si le développement d’une API complète est hors scope à court terme, un export bulk du dictionnaire en JSON, publié à une URL stable et régénéré à chaque mise à jour, couvrirait déjà l’essentiel du besoin pour un coût très inférieur. C’est le point de départ que je suggérerais.
Mes questions au forum
- Une telle exposition est-elle déjà prévue dans la feuille de route de Kwikly, ou existe-t-il un point d’entrée technique non documenté que certains utilisent déjà ?
- D’autres équipes ont-elles branché le dictionnaire SNDS sur un catalogue de données ? Si oui, avec quelle approche ?
- Y a-t-il un intérêt à mutualiser un connecteur open source, une fois la source machine-readable disponible ?
Je suis volontiers disponible pour préciser le besoin, tester une première version ou contribuer à humble échelle à la spécification.
Bien cordialement,
Dr Basile Fuchs — CHU de Brest