Comprendre une base SQL Server sans documentation grâce au reverse engineering et à Copilot

Dans de nombreux projets data, les équipes doivent travailler avec des bases SQL Server existantes, parfois anciennes, peu documentées ou dont la documentation n’est plus à jour. Avant une migration, un audit ou une modernisation, il devient essentiel de comprendre rapidement où sont les données importantes, comment les tables sont structurées et quelles zones méritent une attention particulière.

Lorsqu’une entreprise souhaite moderniser son système d’information, migrer vers le cloud ou fiabiliser ses indicateurs, une question revient très vite :

Comprend-on réellement les données existantes ?

Dans beaucoup de cas, la réponse n’est pas immédiate.

Une base SQL Server peut contenir :

• des dizaines ou centaines de tables
• des milliers de colonnes
• des vues créées au fil du temps
• des tables historiques
• des relations partiellement documentées
• des objets techniques dont l’usage exact n’est plus clair

Le risque est alors de commencer à faire des hypothèses :

“Cette table doit sûrement contenir les commandes.”

“Cette colonne doit probablement être l’identifiant client.”

“Ces deux tables doivent se joindre comme ça.”

Ces hypothèses peuvent sembler raisonnables, mais elles peuvent entraîner des erreurs : indicateurs incohérents, migrations incomplètes, doublons, pertes de données ou mauvaise estimation de la charge projet.

Le reverse engineering permet de limiter ce risque en partant d’un principe simple :

avant de deviner, on interroge ce que SQL Server sait déjà de sa propre structure.

La première étape consiste à mesurer le terrain.

Avant d’analyser le détail d’un modèle, il faut savoir si l’on fait face à une petite base de quelques tables ou à un système beaucoup plus large.

Pour cela, on peut commencer par quelques indicateurs simples :

• nombre de tables
• nombre de vues
• nombre de colonnes

Encadré technique — Mesurer le périmètre

Ces premières mesures ne donnent pas encore la compréhension métier du modèle, mais elles permettent déjà de calibrer l’effort d’analyse.

Une base avec 20 tables peut parfois être explorée manuellement.

Une base avec 300 tables et plusieurs milliers de colonnes nécessite une méthode beaucoup plus structurée.

À ce stade, on sait donc si le périmètre semble simple, dense ou potentiellement complexe.

Une fois le périmètre global connu, l’étape suivante consiste à repérer les tables à analyser en priorité.

Deux signaux sont particulièrement utiles :

• les tables les plus larges, c’est-à-dire celles qui contiennent beaucoup de colonnes
• les tables les plus volumineuses, c’est-à-dire celles qui contiennent beaucoup de lignes

Une table très large peut représenter un objet métier riche, une table historique ou une table qui a évolué pendant plusieurs années.

Une table très volumineuse peut contenir des transactions, des factures, des événements, des logs ou des historiques.

Dans un projet de migration ou d’audit, ces tables doivent être identifiées tôt, car elles peuvent avoir un impact sur :

• les performances
• les temps de traitement
• les coûts de migration
• les tests de non-régression
• les règles de qualité de données

Encadré technique — Identifier les tables volumineuses

Cette requête donne une estimation du volume par table. Elle ne remplace pas un comptage exact, mais elle est suffisante pour prioriser une analyse. L’objectif n’est pas encore de comprendre tout le modèle, mais de répondre à une question simple :

par quelles tables faut-il commencer ?

Une base SQL Server n’est pas seulement une collection de tables.

Pour comprendre réellement un modèle, il faut comprendre comment les tables sont reliées entre elles.

Deux notions sont essentielles :

• la clé primaire, qui identifie une ligne de manière unique
• la clé étrangère, qui relie une table à une autre

En simplifiant :

• la clé primaire répond à la question : qui suis-je ?
• la clé étrangère répond à la question : à quoi suis-je lié ?

Par exemple, une table Commande peut être reliée à une table Client via une colonne ClientId.

Encadré technique — Vérifier la présence de clés primaires et étrangères

Si la base contient beaucoup de clés primaires et étrangères, SQL Server possède déjà une partie importante de la carte relationnelle.

Si les clés étrangères sont rares, cela ne signifie pas qu’il n’existe pas de relations. Cela signifie simplement qu’elles ne sont pas déclarées explicitement dans la base. Il faudra alors compléter l’analyse par d’autres moyens : noms de colonnes, profils de données, règles métier ou traitements existants.

Toutes les tables n’ont pas la même importance.

Certaines sont isolées.

D’autres sont reliées à de nombreuses tables.

Les tables les plus connectées sont souvent les meilleurs points d’entrée pour comprendre un modèle. Elles peuvent représenter des objets métier centraux : clients, contrats, commandes, factures, produits, comptes ou entités organisationnelles.

C’est comme dans une organisation : pour comprendre comment tout fonctionne, on commence souvent par les services qui interagissent avec tout le monde.

Dans une base de données, c’est la même logique.

Encadré technique — Identifier les tables les plus connectées

Cette requête permet de faire ressortir les tables les plus reliées au reste du modèle.

Une table avec beaucoup de relations entrantes est souvent utilisée par plusieurs autres tables.

Une table avec beaucoup de relations sortantes dépend souvent de plusieurs objets du modèle.

Dans les deux cas, ce sont des tables à analyser en priorité.

Une fois les premières métadonnées extraites, Copilot peut aider à transformer ces résultats techniques en documentation plus lisible.

Mais il faut garder une règle importante :

Copilot n’est pas la source de vérité.

La source de vérité reste SQL Server et ses métadonnées.

Copilot peut aider à :

• structurer les informations
• générer un premier dictionnaire de données
• résumer les tables principales
• identifier les points de vigilance
• produire une synthèse compréhensible par une DSI ou une équipe projet

Pour cela, il est utile de lui fournir des données structurées, par exemple au format JSON.

Encadré technique — Exporter les métadonnées au format JSON

Cette requête produit une liste structurée des tables, colonnes et types de données.

Ce JSON peut ensuite être fourni à Copilot pour générer une première version de dictionnaire de données.

Exemple de prompt Copilot

Résumé de réponse Copilot :

Le modèle semble structuré autour de plusieurs domaines fonctionnels :

– ventes et facturation

– achats et fournisseurs

– stock et logistique

– données de référence

Certaines tables ressortent comme centrales, notamment les clients, commandes, factures, fournisseurs et mouvements de stock.

Les tables d’historique ou d’archive doivent être analysées avec attention, car elles peuvent avoir un impact sur les performances, les coûts de stockage et les stratégies de migration.

Certaines relations doivent également être vérifiées afin de distinguer les faits déclarés dans SQL Server des hypothèses à valider avec les équipes métier.

Le résultat ne doit pas être considéré comme une documentation définitive.

Il s’agit d’une première base de travail, à relire et à enrichir avec les équipes techniques et métier.

Cette démarche permet de passer d’une base inconnue à une première compréhension structurée.

Elle aide à répondre à plusieurs questions clés :

• Quelle est la taille du périmètre ?
• Quelles tables doivent être analysées en priorité ?
• Où sont les gros volumes ?
• la base déclare-t-elle des relations ?
• quelles tables semblent centrales ?
• quels éléments doivent être documentés ou validés ?
• comment produire rapidement une première documentation ?

Elle apporte de la valeur à plusieurs profils :

• les équipes techniques, qui disposent de requêtes concrètes pour explorer la base
• les chefs de projet, qui obtiennent une première vision des risques
• les métiers, qui peuvent valider progressivement le sens des données
• la DSI, qui dispose d’une base factuelle pour cadrer une migration ou une modernisation

Le reverse engineering SQL Server est utile dans plusieurs contextes.

Migration vers une nouvelle plateforme data : Avant de migrer vers Microsoft Fabric, Azure SQL Database, Azure Synapse Analytics, un Lakehouse ou un Data Warehouse moderne, il est indispensable de comprendre l’existant. Le reverse engineering permet d’identifier les tables critiques, les volumes, les dépendances et les points de vigilance.

Audit d’un système existant : Dans un audit, l’objectif est souvent de produire rapidement une première vision fiable. Les métadonnées SQL Server permettent d’identifier les tables majeures, les zones complexes, les relations importantes et les objets à valider avec les équipes métier.

Reprise d’un projet sans documentation : Lorsqu’une nouvelle équipe arrive sur un système existant, le manque de documentation peut ralentir fortement la montée en compétence. Une analyse structurée permet de créer un dictionnaire de données initial, une liste des tables prioritaires et un parcours d’onboarding.

Gouvernance des données : Une démarche de gouvernance nécessite de savoir quelles données existent, où elles se trouvent et comment elles sont reliées. Les métadonnées extraites peuvent alimenter un catalogue de données, un dictionnaire métier ou une cartographie applicative.

Le reverse engineering est puissant, mais il n’est pas magique.

Il dépend de la qualité de l’existant.

Si les clés étrangères ne sont pas déclarées, les relations doivent être déduites autrement.

Si les noms de colonnes sont ambigus, il faut compléter l’analyse avec les métiers.

Si Copilot propose une interprétation, elle doit être considérée comme une hypothèse tant qu’elle n’a pas été validée.

Quelques bonnes pratiques sont essentielles :

• distinguer les faits techniques des hypothèses
• ne pas confondre nommage et preuve
• conserver les scripts SQL utilisés
• documenter progressivement
• faire relire les interprétations par les métiers
• utiliser Copilot comme assistant, pas comme arbitre

Comprendre une base SQL Server sans documentation peut sembler complexe, mais la base contient souvent déjà une partie importante des réponses : tables, colonnes, volumes, clés et relations.

Le reverse engineering permet de révéler ces informations, de les organiser et de les transformer en connaissance exploitable.

L’approche peut se résumer ainsi :

1. mesurer le périmètre
2. identifier les tables prioritaires
3. analyser les clés et les relations
4. repérer les tables centrales
5. utiliser Copilot pour accélérer la documentation
6. valider les hypothèses avec les experts techniques et métier

SQL Server fournit les faits.

Copilot aide à les structurer.

Les experts valident le sens.

C’est cette combinaison qui permet de transformer une base peu documentée en patrimoine data plus lisible, maîtrisé et prêt à évoluer.

Ecrit par Bruno LY, Consultant Senior Data chez Expertime