

- Description
- Écluse de canal vue de l'amont : l'eau passe par étapes, de bief en bief, sous le contrôle de portes.
- Source
- Poliphilo · page d’origine
- Licence
- CC0 Domaine public
Couche données et ETL
Ce thème couvre tout ce qui amène la donnée jusqu'au modèle : vues ou tables sources, Power Query (langage M), requêtes natives, query folding, dataflows, rafraîchissement incrémental…
En bref
Ce thème couvre tout ce qui amène la donnée jusqu'au modèle : vues ou tables sources, Power Query (langage M), requêtes natives, query folding, dataflows, rafraîchissement incrémental, contrats de colonnes, rejeu et idempotence. Il s'arrête où commence la modélisation (MOD) et où commence le pipeline de données en amont (matrice PD).
Niveau : 🟢→🔴 · Code thème : ETL
1. Pourquoi ce thème#
La logique de transformation placée dans le rapport (Power Query) est la plus chère à maintenir : invisible du DBA, non testée, recalculée à chaque rafraîchissement, souvent dupliquée d'un rapport à l'autre. La règle d'or des équipes mûres : transformer le plus en amont possible (vue SQL, table du datamart), le plus tard possible seulement ce qui est propre au rapport. Une étape M qui casse le query folding fait basculer un filtre de « poussé au serveur » à « tout charger puis filtrer en mémoire » : un rafraîchissement de 2 minutes devient 40.
2. Ce que mesure le thème#
- Axe : de la requête copiée-collée à une alimentation déclarative, repliée, incrémentale et contractualisée.
- Indicateurs clés : part des requêtes qui se replient (diagnostic M), nombre de sources utilisées sans vue dédiée, temps de rafraîchissement, taux d'échec, taux de rejeu réussi.
- Unités : % de requêtes repliées, minutes, nombre d'incidents/mois.
3. Les 5 niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Copié-collé | Les données arrivent quand l'auteur actualise, à la main, depuis son poste. | Source = fichier ou table brute ; 0 vue dédiée |
| 2 | Vues sources | Chaque rapport lit des vues stables ; une panne de source se comprend en une heure. | > 70 % des tables lues via vues ; diagnostic en < 1 h |
| 3 | Replié et paramétré | Le rafraîchissement est prévisible et ne dépend ni du poste ni d'une personne. | > 80 % des requêtes repliées ; sources paramétrées |
| 4 | Contractuel et rejouable | Une colonne qui change côté source est détectée avant d'atteindre l'utilisateur ; rejouer un chargement donne le même résultat. | 0 rafraîchissement cassé « silencieusement » ; rejeu idempotent prouvé |
| 5 | Incrémental outillé | Le volume croît sans que le délai ne croisse : seul le delta est traité, l'alimentation s'auto-vérifie. | Rafraîchissement ≈ proportionnel au delta, pas au total |
4. Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| BI-ETL-1.1 | Les sources sont identifiées et accessibles au service (passerelle ou connexion cloud) | Inventaire minimal des sources |
| BI-ETL-1.2 | Le rapport s'actualise sans l'intervention d'une personne précise | Un autre membre sait relancer |
| BI-ETL-1.3 | Les identifiants de connexion ne sont pas ceux d'un individu nominatif | Compte de service ou identité gérée |
| BI-ETL-2.1 | Le rapport lit des vues SQL (ou tables publiées) dédiées au BI, pas les tables applicatives | Schéma dm. / rpt. ou équivalent |
| BI-ETL-2.2 | Les noms et types de colonnes de la vue sont ceux du modèle (pas d'alias renommant en cascade) | Revue de colonne par colonne |
| BI-ETL-2.3 | Chaque requête M a un nom parlant et une seule responsabilité | Revue des requêtes |
| BI-ETL-2.4 | Un incident de chargement est diagnostiqué à partir d'un journal | Historique de rafraîchissement consulté |
| BI-ETL-3.1 | Le query folding est vérifié (Voir la requête native / diagnostic) sur les grandes tables | Capture ou test documenté |
| BI-ETL-3.2 | Serveur et base en paramètres (dev/test/prod) | Paramètres M ou règles de déploiement |
| BI-ETL-3.3 | Pas de transformation lourde non repliable sur gros volume ; sinon, déportée en SQL | Liste des étapes non repliables justifiées |
| BI-ETL-3.4 | Rafraîchissement incrémental activé sur les faits volumineux | Politique RangeStart/RangeEnd en place |
| BI-ETL-3.5 | Les sources fichiers (Excel, CSV) sont rares, contrôlées, sur dépôt géré | Chemin SharePoint/OneLake, pas poste local |
| BI-ETL-4.1 | Contrat de colonnes : liste attendue (nom, type, nullabilité) versionnée | Fichier de contrat ou test |
| BI-ETL-4.2 | Un contrôle compare le schéma attendu au schéma réel avant publication | Alerte déclenchée sur colonne manquante |
| BI-ETL-4.3 | Rejouer un chargement (même fenêtre) ne duplique ni ne perd de lignes | Test de rejeu documenté |
| BI-ETL-4.4 | Les dimensions à clé inconnue ont un membre « inconnu » plutôt que des lignes orphelines | Contrôle d'intégrité des clés |
| BI-ETL-5.1 | Partitions gérées par l'outil (partitions XMLA, actualisation ciblée) selon la période | Journal d'actualisation par partition |
| BI-ETL-5.2 | Détection de dérive source : alerte avant échec | Alerte automatique tracée |
| BI-ETL-5.3 | Reprise partielle automatique après échec (relance de la partition fautive) | Incident clos sans intervention |
| BI-ETL-5.4 | La chaîne source → modèle est tracée (lineage) | Lineage consultable |
5. Lecture détaillée par niveau#
🟢 Niveau 1 — Copié-collé#
- Signes : classeurs Excel sur un poste, requêtes dupliquées, identifiants personnels.
- Gain : démarrage immédiat. Ne garantit pas : la reprise, la fraîcheur, la sécurité.
- Difficulté : 1/5 · Effort : 1/5.
🟢 Niveau 2 — Vues sources#
- Signes : les rapports interrogent
SELECT … FROM rpt.vFactVisiteplutôt que les tables de l'application ; le DBA connaît les consommateurs. - Gain : isolation entre schéma applicatif et rapport ; une évolution de table n'impacte pas le rapport si la vue absorbe le changement.
- Limite : pas encore de contrôle du folding.
- Difficulté : 2/5 · Effort : 2/5.
Publie des vues « contractuelles » : mêmes noms de colonnes que dans le modèle, types explicites, sans SELECT *. Le rapport ne renomme rien.
🟡 Niveau 3 — Replié et paramétré#
- Signes : les filtres, jointures, regroupements sont repliés vers SQL ; un diagnostic M est fait pour chaque table volumineuse ; l'incrémental sur
dateréduit le chargement. - Gain : rafraîchissements courts et prévisibles ; mêmes sources sur dev/test/prod.
let
Source = Sql.Database(Serveur, Base),
Faits = Source{[Schema="rpt", Item="vFactVisite"]}[Data],
Fenetre = Table.SelectRows(Faits, each [Date] >= RangeStart and [Date] < RangeEnd)
in
Fenetre
- Limite : fenêtre incrémentale rarement testée en rejeu.
- Difficulté : 3/5 · Effort : 3/5.
Symptôme : le rafraîchissement incrémental recharge toute la table. Cause : le filtre sur RangeStart/RangeEnd ne se replie pas (conversion de type, fonction non repliable). Remède : filtrer la colonne native avant tout traitement ; vérifier « Voir la requête native ».
🟡 Niveau 4 — Contractuel et rejouable#
- Signes : un test compare le schéma attendu au schéma réel ; l'idempotence est démontrée (rejouer la fenêtre J−3 donne le même total). Les clés orphelines sont gérées par un membre « inconnu ».
- Gain : plus de rafraîchissement qui réussit en produisant des chiffres faux.
- Difficulté : 4/5 · Effort : 4/5.
Fil rouge SFA : l'application terrain ajoute une colonne STATUT_VISITE. Sans contrat, la vue la propage, le modèle l'ignore, rien ne casse. Avec contrat : l'alerte signale « colonne nouvelle non déclarée », l'équipe décide, la version de modèle est incrémentée.
🔴 Niveau 5 — Incrémental outillé#
- Signes : partitions pilotées par API/XMLA, reprise partielle automatique, lineage de la source jusqu'au visuel, surveillance de dérive.
- Gain : le coût d'alimentation croît moins vite que le volume.
- Limite : outillage à entretenir ; complexité d'exploitation (OPS).
- Difficulté : 5/5 · Effort : 5/5.
Pour un gros fait, préfère des partitions mensuelles figées (historique) + une partition « courante » actualisée à la demande ; l'incrémental natif d'un modèle est plus simple, mais l'actualisation par partition via XMLA offre un contrôle fin du rejeu.
L'IA écrit bien du M simple et suggère des étapes de nettoyage ; elle casse souvent le folding sans le dire et ne connaît pas vos conventions de colonnes. Fais toujours vérifier la requête native.
6. Atteinte partielle et notation#
Voir la règle commune. « Un 5 partiel » : partitions XMLA en place pour deux faits sur quatre (BI-ETL-5.1 = 0,5), alerte de dérive présente mais sans reprise automatique (5.2 = 1, 5.3 = 0) : le niveau 5 n'est pas acquis, mais la moyenne des jalons du niveau 5 (≈ 0,5) donne un score ≈ 4,5 si le niveau 4 est acquis.
7. Passer au niveau suivant#
Moyens possibles (facultatifs) :
| Passage | Leviers possibles |
|---|---|
| 1 → 2 | Créer un schéma de vues BI ; compte de service ; supprimer les classeurs locaux |
| 2 → 3 | Diagnostic de folding ; paramètres de connexion ; RangeStart/RangeEnd |
| 3 → 4 | Contrat de colonnes en dépôt ; test de schéma en pipeline ; tests de rejeu |
| 4 → 5 | Partitions XMLA ; lineage ; alertes de dérive ; scripts de reprise |
Pièges :
- Faux positif : « tout est replié » mais sur une vue qui fait elle-même un scan complet de 300 M de lignes. Le goulot a changé de place.
- Goodhart : viser « 100 % de folding » conduit à exclure des transformations utiles ; juge sur le temps de rafraîchissement et la correction.
- Réécrire en M ce qui devrait être dans le datamart : dette cachée (voir PD — modélisation).
8. Voir aussi#
- Thèmes voisins : MOD · PRF · TST · OPS
- Autres matrices : PD — sources et contrats de données · PD — délais et DataOps · PD — qualité des données
- Contenus : SQL Server SaaS — vue d'ensemble · OneLake — difficultés et pièges · GDS et données SQL/BI · CI/CD pour la data
✻ Rédigé par Claude Sonnet 5.5