rédactionFonctionne bien avec ClaudeFonctionne bien avec ChatGPT

Dictionnaires de données et documentation de requêtes rédigés à partir du SQL lui-même

La dette de documentation est universelle : des tables que personne n'a définies, des colonnes aux noms cryptiques, des indicateurs dont la définition ne vit que dans la tête d'un analyste senior. Fournir à l'IA le DDL ou le modèle SQL et obtenir un premier jet de descriptions de colonnes et un dictionnaire de données résorbe rapidement l'arriéré — mais seulement si le modèle indique clairement ce qu'il devine, pour qu'un propriétaire puisse en confirmer le sens réel.

Vous êtes analytics engineer et rédigez une documentation claire pour un modèle de données. Rédigez un dictionnaire de données à partir du SQL que je vous fournis.

Le DDL ou la définition du modèle SQL : {{ddl_or_sql}}
Contexte métier de cette table : {{business_context}}
Définitions d'indicateurs déjà validées (à utiliser telles quelles) : {{known_definitions}}

Produisez :
1. Résumé de la table — ce que représente une ligne (la granularité), la clé primaire, et comment la table est alimentée, en vous basant uniquement sur le SQL.
2. Dictionnaire des colonnes — un tableau avec : nom de la colonne, type déduit, et une description en une ligne.
3. Indicateurs — tout indicateur calculé dans le SQL, avec sa définition exacte issue de ma liste de « définitions validées » quand j'en ai fourni une.

Règles :
- Décrivez uniquement les colonnes et la logique présentes dans le SQL. N'inventez ni colonne ni signification. Si le rôle d'une colonne n'est pas clair à partir de son nom et du contexte fourni, écrivez la description sous la forme « [À CONFIRMER PAR LE PROPRIÉTAIRE] » plutôt que de deviner.
- Pour tout indicateur absent de ma liste validée, décrivez comment le SQL le calcule et marquez-le « définition non encore confirmée » — n'affirmez pas de sens métier.
- Signalez les colonnes dont les noms sont ambigus ou pourraient être mal interprétés, afin qu'un humain puisse les clarifier.

Renseignez vos informations : le prompt se met à jour en direct — puis copiez-le.

DDL ou modèle SQL (à coller)À quoi sert cette tableDéfinitions d'indicateurs validées (telles quelles)

Ce que vous obtenez (extrait)

Table : fct_orders Granularité : une ligne par commande complétée. Clé primaire : order_id. Alimentée depuis la source orders, filtrée sur le statut « complétée ». | Colonne | Type | Description | |-------------|---------|---------------------------------------------------------| | order_id | string | Identifiant unique de la commande (clé primaire). | | customer_id | string | Le client ayant passé la commande. | | order_date | date | Date à laquelle la commande a été complétée. | | net_amount | numeric | Brut moins remises et remboursements, hors taxes/livraison. | | is_repeat | boolean | [À CONFIRMER PAR LE PROPRIÉTAIRE] — semble signaler les clients récurrents ; logique non visible dans ce SQL. | L'indicateur net_amount utilise la définition confirmée ci-dessus.

Le flux de travail complet

Collez le DDL ou le modèle SQL ainsi que les définitions d'indicateurs déjà validées avec le métier
Faites confirmer chaque [À CONFIRMER PAR LE PROPRIÉTAIRE] et chaque indicateur non confirmé par le propriétaire des données, pas de mémoire
Vérifiez que les définitions d'indicateurs documentées correspondent exactement à votre couche sémantique ou à votre outil de BI
Versionnez le dictionnaire relu aux côtés du modèle pour qu'il reste sous contrôle de version

Attention à

Le modèle devinera avec assurance le sens d'une colonne au nom cryptique, et se trompera. Traitez chaque définition rédigée par l'IA comme un brouillon tant que le propriétaire de la table ne l'a pas confirmée — une définition erronée dans le dictionnaire de données induit en erreur tout le monde en aval.

Les définitions d'indicateurs doivent correspondre à la source de vérité. Si la définition documentée dévie de la couche sémantique ou de la logique du tableau de bord, vous avez créé deux définitions contradictoires au lieu d'une seule.

Ne collez pas de schémas de production contenant des noms de tables ou de colonnes sensibles, ou des identifiants embarqués, dans un outil grand public — caviardez d'abord et utilisez une instance approuvée.

D’où ça vient

Chaque cas d’usage de ce site s’appuie sur des témoignages réels rapportés par les analystes de données en exercice — rien n’est inventé par nous.

Plus de cas d’usage de l’IA pour les analystes de données

automatisation

Dictionnaires de données et documentation de requêtes rédigés à partir du SQL lui-même

Le flux de travail complet

Attention à

D’où ça vient

Plus de cas d’usage de l’IA pour les analystes de données

Requêtes SQL rédigées et déboguées à partir d'un schéma décrit

Scripts de nettoyage et de profilage de données en Python, faciles à auditer

Synthèses pour décideurs qui transforment un graphique en décision

Des demandes floues des décideurs transformées en plan d'analyse cadré

Le bon graphique pour le message, pas seulement pour la donnée