Plateforme de traçabilité des données SQL (SDLP)

SDLP (SQL Data Lineage Platform) is Gudu Software’s enterprise lineage system of record. It computes column-level data lineage for an entire SQL estate by parsing the estate’s actual code — stored procedures, views, functions, triggers, jobs — and stores every derived lineage edge as an auditable fait dans un dépôt réglementé, avec un registre complet de tout ce qu'il pouvait pas résolution. Le résultat est une lignée que vous pouvez défendre devant un organisme de réglementation : les faits et les rejets représentent toujours 100% de l’héritage, rien n’est omis discrètement et rien n’est fabriqué.

Position de SDLP au sein de la famille SQLFlow : Il est construit sur le même noyau d'analyseur SQL général que Gudu SQLFlowSQLFlow, quant à lui, résout un problème différent. Il affiche la traçabilité des requêtes SQL fournies, tandis que SDLP conserve l'historique de traçabilité certifié de l'ensemble de votre système. Le tableau comparatif ci-dessous illustre cette distinction.

SQLFlow ou SDLP — lequel vous faut-il ?

Gudu SQLFlow est une lignée interactive moteur d'analyse et de visualisationIl vous suffit de lui fournir du SQL (collé, importé, extrait d'une base de données, d'un projet dbt ou de l'historique des requêtes, dans l'un des 39 dialectes disponibles) et il génère en quelques secondes un diagramme de lignage interactif au niveau des colonnes. C'est l'outil idéal pour les ingénieurs et analystes de données qui ont besoin de comprendre, de déboguer et de documenter les flux de données. SQLFlow Cloud, SQLFlow sur site, une API REST et une bibliothèque Java.

SDLP est une lignée d'entreprise plate-forme — un système d'enregistrement. Il n'analyse pas un script à la fois : il exporte l'ensemble de la base de données (métadonnées et code source SQL de chaque module), l'analyse par lots suivis et fusionne les résultats dans un référentiel canonique de données de traçabilité, avec preuves, scores de qualité, gouvernance, contrôle d'accès et une piste d'audit inviolable. C'est l'outil idéal pour les équipes de gouvernance des données des banques, des compagnies d'assurance et autres entreprises réglementées qui doivent prouver d'où proviennent les données — en continu, à l'échelle du domaine, en tenant compte des lacunes.

Gudu SQLFlowSDLP
Qu'est-ce que c'estMoteur interactif d'analyse et de visualisation de lignéesSystème d'information sur la traçabilité des entreprises avec gouvernance
Vous le donnezScripts SQL, connexion à une base de données, artefacts dbt, historique des requêtesUn ensemble complet de bases de données SQL, exporté sous forme de bundle métadonnées + code source
Vous obtenezUn diagramme de lignage interactif au niveau des colonnes, exportable aux formats JSON/CSV/PNGUn référentiel contrôlé de données de traçabilité vérifiables, un registre des rejets, des lots d'analyse avec score de qualité et des exportations conformes aux exigences réglementaires
Requête SQL non résolueDiagramme au mieux de mes connaissances sur ce qui a été analyséEnregistré dans un registre des rejets avec code de motif et justificatifs — faits + rejets = 100% de la succession
Couverture dialectale39 dialectes SQLDes environnements Microsoft SQL Server complets sont disponibles dès aujourd'hui ; d'autres types d'environnements sont prévus, reposant sur la même famille d'analyseurs syntaxiques.
Utilisateur typeIngénieurs de données, analystes, architectesÉquipes de gouvernance des données, opérateurs d'analyse, responsables, auditeurs
GouvernanceClassification des données personnelles, analyse d'impact des flux sensibles, données de référence, accès basé sur les rôles, journal d'audit chiffré.
Idéal pourComprendre et documenter les flux de données pendant le développementTraçabilité réglementaire (type BCBS 239), catalogues d'entreprises, éléments probants d'audit

Les deux produits sont complémentaires : les équipes utilisent généralement SQLFlow en phase de développement pour comprendre et corriger les flux de données, et SDLP en production pour maintenir l’enregistrement de lignage attesté auquel l’organisation se réfère dans ses rapports.

Lignée honnête : rejeter, ne pas deviner

La plupart des outils de traçabilité échouent aux audits sur silencesCe que l'outil n'a pas compris n'existe tout simplement pas, et personne ne peut dire ce qui manque. La doctrine fondatrice du SDLP est différente. Rejetez, ne devinez pas et expliquez 100%Chaque instruction ou référence que l'analyseur ne peut résoudre avec certitude est consignée dans le registre des rejets, avec un code de motif lisible par machine, un niveau de gravité et les données SQL brutes. L'ambiguïté n'est jamais instrumentalisée pour présenter une interprétation plausible, et les références externes sont classées comme telles plutôt que supposées. « Faits + rejets = enregistrement complet » est une équation vérifiable, et non un slogan.

La même honnêteté imprègne le modèle de données. Chaque information relative à la lignée comporte un rôle qui déclare comment La colonne source affecte la cible : les rôles porteurs de valeur (DIRECT, TRANSFORM, AGGREGATE, DERITED) signifient que les données sources sont effectivement intégrées à la cible ; les rôles d’influence uniquement (FILTER, JOIN, CONDITION) signifient que la colonne source a façonné le résultat sans que sa valeur n’y soit jamais intégrée. Cette distinction est la différence entre « ce rapport » et « ce rapport ». contient « les informations personnelles des clients » et « ce rapport n'était qu'un simple rapport » filtré par une colonne PII » — exactement ce dont un responsable de la protection de la vie privée ou un organisme de réglementation a besoin, et SDLP n'exagère jamais le premier point quand seul le second est vrai.

Comment ça marche

  1. Exporter. Un exportateur unique et autonome se connecte au serveur source avec un accès en lecture seule et transfère l'ensemble des données (métadonnées du catalogue et texte SQL de chaque module) dans un ensemble fragmenté. Il lit métadonnées uniquement, ne stocke jamais de données tabulaires et s'exécute à l'intérieur de votre zone réseau ; seul le paquet en sort.
  2. Balayage. Le scanner analyse chaque module avec l'analyseur SQL général, normalise les résultats et les fusionne dans le référentiel canonique sous forme de lot suivi et reprenable. Une analyse interrompue reprend à partir de son point de contrôle au lieu de recommencer depuis le début.
  3. Valider. Un validateur indépendant — une implémentation délibérément séparée — recalcule le hachage d'identité de chaque ligne stockée et exécute un catalogue de règles qui se condense en un score de qualité de 0 à 100 par lot : un nombre pour juger chaque analyse.
  4. Consommer. Un catalogue Web propose des fonctions de recherche, des graphiques de lignage interactifs et des flux de travail de gouvernance ; le centre d’exportation fournit des fichiers CSV, JSONL ou Parquet aux systèmes en aval, y compris un fichier CSV de lignage compatible avec Microsoft Purview.

Chaque étape s'effectue en ligne de commande, via un navigateur ou en mode mixte : les trois méthodes permettent de lire et d'écrire dans le même référentiel, sous le même contrat d'identité. Ainsi, le choix d'une interface n'entraîne jamais de duplication des données. Les équipes chargées des opérations d'analyse exécutent généralement des analyses planifiées via l'interface de ligne de commande, les analystes et les responsables de la gestion des données interagissent en direct avec l'interface web, et les flux de données en aval sont exécutés via l'API d'exportation.

Preuves que vous pouvez remettre à un auditeur

Chaque fait du référentiel est traçable jusqu'à son origine par une chaîne inviolable : fait → occurrence → un localisateur précis au bit près dans le fichier source exporté, revérifié par un hachage SHA-256 à chaque lecture. Le texte SQL n'est pas dupliqué dans le référentiel ; le fichier source exporté constitue l'unique système d'enregistrement, ce qui permet de détecter toute modification ou dérive du code source au lieu de la diffuser silencieusement. Dans le catalogue web, l'option « Afficher les preuves SQL » ouvre la portion d'instruction exacte, mise en évidence dans le code source original du module et vérifiée en temps réel par hachage.

  • Piste d'audit chaînée par hachage : Chaque classification, exportation et recalcul est consigné dans un journal d'événements en mode ajout uniquement, avec une chaîne de hachage, ce qui permet de détecter toute falsification de la trace elle-même.
  • Vérification indépendante : Les auditeurs peuvent exécuter le validateur autonome sur le référentiel sans faire confiance au scanner qui l'a écrit, y compris en recalculant l'identité de chaque ligne.
  • Lignes de base : Figez la traçabilité « telle qu’acceptée à la date X » et attestez-la. Un organisme de réglementation s’enquiert de la traçabilité du rapport du quatrième trimestre, et non des résultats de l’analyse effectuée la veille ; les données de référence en font un élément essentiel.
  • Comptabilité 100% affichée : Le registre des rejets est une exportation comme une autre : la liste complète de ce qui n’a pas été résolu et pourquoi fait partie du livrable, ce n’est pas un secret.

La gouvernance intégrée

Les responsables de la gestion des données classent les points de terminaison (tables, vues, colonnes) selon des niveaux de sensibilité tels que les données personnelles identifiables (DPI). Le moteur de propagation calcule ensuite le flux des données classifiées en aval et, surtout, comment: chaque constatation comporte un type d'impact honnête (CONTIENT_DES_DONNÉES, FILTRED_PAR, REJOINT AVEC, INFLUENCED_BYLes rôles sont définis dans la lignée des informations recueillies, avec attribution au propriétaire et au responsable, de sorte qu'une découverte soit attribuée à une personne. Chaque action du responsable est attribuée et vérifiée.

Le contrôle d'accès repose sur deux axes indépendants : sept rôles définissent les actions autorisées pour un utilisateur (consulter le catalogue, gérer les classifications, effectuer des analyses, administrer les sources), et l'appartenance à un espace de travail définit son emplacement. Les espaces de travail constituent des barrières d'isolation strictes : les faits, les exportations, les enregistrements de gouvernance et les événements d'audit ne sont jamais divulgués. Les environnements de production bénéficient d'un contrôle d'accès supplémentaire côté serveur qui sépare les utilisateurs autorisés à analyser la production de ceux autorisés à analyser tout autre élément. L'identité peut être gérée par votre fournisseur d'identité via OIDC.

Déploiement et mise à l'échelle

SDLP se déploie sur site, aussi bien sous Linux que sous Windows, et son seul prérequis logiciel est Java. Le référentiel de traçabilité propose deux systèmes de stockage compatibles, sélectionnables par un simple bloc de configuration : une base de données SQL Server pour les déploiements de production partagés, ou un système embarqué ne nécessitant aucune installation (un répertoire local, sans serveur de base de données ni mot de passe), qui effectue une première analyse du téléchargement vers la traçabilité en une quinzaine de minutes. L’ensemble du système fonctionne en mode totalement isolé du réseau : aucune dépendance au cloud, aucune connexion sortante, et l’accès en lecture aux données des tables n’est jamais requis pour la connexion côté source.

La plateforme est conçue pour les grands ensembles de données : une analyse complète d’un parc de 122 bases de données (environ 29 000 unités d’analyse générant près de 450 000 faits de traçabilité au niveau des colonnes) est réalisée en moins de deux heures sur un serveur quadricœur colocalisé. Les analyses ultérieures sont fusionnées dans le même référentiel canonique, de sorte que les faits réobservés restent des faits uniques avec leur historique intact. Les exportations delta incrémentales permettent de déterminer les modifications apportées depuis la dernière analyse, sans avoir à comparer les fichiers manuellement.

Alimentation de Microsoft Purview et d'autres systèmes en aval

Le centre d'exportation propose huit types d'exportation via le référentiel : traçabilité au niveau des champs avec preuves, logique de transformation, impact des procédures, zones d'ombre de la couverture, deltas incrémentaux, rejets, qualité des lots, et un Fichier CSV de lignée prêt pour Purview Chaque fichier est exporté au format CSV, JSONL ou Parquet. L'exportation Purview est versionnée par contrat et optimisée pour l'ingestion : une ligne par fait actif, les noms qualifiés avec points et leurs composantes séparées, le rôle de lignage, une expression de transformation garantie sur une seule ligne et un GUID de fait stable permettant des insertions/mises à jour idempotentes via l'API Purview Atlas. Les exportations volumineuses s'exécutent comme des tâches asynchrones qui restent actives même lorsque le navigateur est fermé.

Foire aux questions

En quoi SDLP diffère-t-il de Gudu SQLFlow ?

SQLFlow est un outil d'analyse interactif : il vous suffit de lui fournir du SQL pour qu'il génère le diagramme de traçabilité au niveau des colonnes, dans l'un des 39 dialectes disponibles. SDLP est une plateforme d'entreprise basée sur le même analyseur : elle analyse l'intégralité des bases de données selon une planification définie, stocke chaque arête de traçabilité comme un fait auditable dans un référentiel contrôlé, enregistre les éléments non résolus dans un registre de rejets et ajoute la classification, l'analyse des flux sensibles, la gestion des accès basée sur les rôles, les référentiels et une piste d'audit chaînée par hachage. Utilisez SQLFlow pour comprendre les flux de données ; utilisez SDLP pour maintenir l'historique de traçabilité attesté par votre organisation.

Quelles bases de données SDLP prend-il en charge ?

SDLP prend en charge l'intégralité des environnements Microsoft SQL Server : exportateur, analyseur et référentiel. D'autres types d'environnements sont prévus et bénéficieront de la prise en charge des dialectes de la même famille d'analyseurs SQL généraux qui alimente les 39 dialectes de SQLFlow. Il peut également analyser directement les répertoires de fichiers SQL.

Est-ce que SDLP lit mes données ?

Non. SDLP fonctionne par analyse statique du code SQL. L'exportateur lit les métadonnées du catalogue et le texte source des modules avec une authentification en lecture seule, sans accès aux lignes des tables. L'analyseur fonctionne ensuite exclusivement à partir de ce bundle exporté. Aucun chemin de code ne permet d'accéder aux données métier.

SDLP peut-il fonctionner dans un environnement isolé du réseau ?

Oui. SDLP est un logiciel installé sur site, sans dépendance au cloud ni connexion sortante. Grâce à son système de référentiel intégré, il ne nécessite que Java et un répertoire local, ce qui le rend également pratique sur les serveurs de rebond et les machines d'analyse isolées.

Qu'est-ce qui confère à la traçabilité de SDLP un niveau de qualité requis pour un audit ?

Trois propriétés interagissent : la comptabilité 100% (les faits et un registre des rejets motivés couvrent l'ensemble du système), une chaîne de preuves inviolable (chaque fait correspond à une portion de la requête SQL originale vérifiée par hachage) et une vérification indépendante (un outil de validation distinct recalcule l'identité de chaque ligne stockée sans se fier au scanner). Un auditeur peut ainsi remonter en temps réel à la requête SQL exacte qui a généré n'importe quelle donnée d'un rapport.

Consultez le programme SDLP pour votre propre domaine. Nous fournissons un package d'évaluation prêt à l'emploi avec un démarrage rapide de 15 minutes — aucun serveur de base de données n'est requis pour la première analyse.