Je publie dbt-grace-thd : intégrer, contrôler et exploiter les données Grace THD

Voici dbt-grace-thd, un projet dbt qui intègre, contrôle et transforme des données de réseaux fibre optique au format GRACE THD (v3.0.1) sur une base PostgreSQL/PostGIS. Il est né d’une mission menée avec Gironde Numérique, et le syndicat a joué le jeu jusqu’au bout : le résultat est publié en open source, licence MIT, utilisable tel quel ou comme package dans votre propre projet dbt.

Un problème qui ne date pas d’hier

Depuis que le modèle existe, l’intégration et le contrôle des données THD sont une difficulté récurrente chez les acteurs du secteur. Chaque livrable au format Grace THD arrive avec ses imperfections : typage approximatif, valeurs aberrantes, géométries invalides, et il faut à la fois valider la conformité du lot et ne pas rester bloqué dessus pour autant.

Les outils se sont un peu fiabilisés avec le temps, et j’y ai contribué : Quickinteg, que je maintiens toujours, m’a servi de nombreuses années sur ce sujet. C’est un outil legacy, bricolé à mes heures perdues, qui a bien rendu service, mais son paramétrage reste difficile à reproduire sans une connaissance fine de l’outil. Il manquait un socle propre du côté de la base de données : quelque chose qui accepte la donnée imparfaite en entrée, la contrôle systématiquement, et produise des données exploitables en sortie.

Ce que fait le projet

Le pipeline suit trois étapes :

1. Intégration non bloquante : les données (GeoPackage, shapefiles ou CSV) sont importées dans PostGIS telles quelles, même imparfaites. Un champ typé string au lieu de integer ne fait échouer aucun import.
2. Contrôle exhaustif : des contrôles génériques paramétrables (présence, remplissage, unicité, clés étrangères, listes de valeurs, types) et des règles métiers et topologiques vérifient les données. Tout aboutit à un rapport d’erreurs géolocalisé, chargeable dans QGIS, avec une criticité paramétrable par projet : un même défaut n’a pas la même gravité pour tous les exploitants.
3. Nettoyage et transformations : typage cohérent, clés primaires et index en couche « base » (23 tables), puis 18 vues élémentaires de jointures et projections géométriques, et enfin des vues métier : plans de boîtes, routes optiques, calcul de capacité du réseau.

L’échantillon de données inclus dans le dépôt est volontairement imparfait : c’est le meilleur moyen de voir les contrôles signaler les anomalies au lieu de les masquer. Les contrôles s’adaptent aussi au cycle de vie du réseau via les conteneurs C1 à C4.

Pourquoi dbt, et pour quoi faire ensuite

L’intérêt du projet est là, à mes yeux. Le contrôle n’est que la première moitié du travail : une fois le pipeline en place, vous disposez d’une base propre d’intégration et de traitement des données dans votre PostgreSQL. Vous pouvez :

• brancher QGIS sur le rapport d’erreurs ou directement sur les vues métier ;
• interroger les tables transformées depuis votre outillage habituel, BI compris ;
• réutiliser les données à différents niveaux de votre système d’information, sans repasser par les fichiers d’origine.

Le tout est versionné en SQL via dbt, documenté et testable. Ajouter un contrôle ou une transformation revient à ajouter un modèle au projet, sans repartir d’une page blanche à chaque nouveau besoin.

Ce projet est le fruit d’une belle collaboration avec Gironde Numérique, que je remercie d’avoir accepté de le partager : une décision qui profite à tous ceux qui se débattent encore avec leurs livrables Grace THD. Si vous en manipulez et voulez mettre ce socle en place sur votre territoire, c’est exactement mon métier : contactez digi-studio.