Sources et contrats de données

Un datamart dépend de systèmes qu'il ne contrôle pas : l'application terrain évolue, une colonne change de type, un code valeur est ajouté, une extraction est déplacée. Sans accord, chaque…

Guide≈ 8 min de lectureVérifiéLecture

Sur cette page

Pourquoi ce thème
Ce que mesure le thème
Les cinq niveaux
Jalons par niveau
Lecture détaillée par niveau
Atteinte partielle et notation
Passer au niveau suivant
Voir aussi

Niveau : 🟢→🔴 · Code thème : CTR

Pourquoi ce thème#

Un datamart dépend de systèmes qu'il ne contrôle pas : l'application terrain évolue, une colonne change de type, un code valeur est ajouté, une extraction est déplacée. Sans accord, chaque changement amont est une panne aval découverte au chargement suivant, voire un chiffre faux silencieux. Un contrat de données est l'engagement explicite et vérifiable d'un producteur envers ses consommateurs : schéma, sémantique, fraîcheur, qualité, évolution. Son coût est faible comparé à celui d'une nuit de consolidation perdue. Ce thème est le pendant, côté sources, de la qualité (QUA) et de la gouvernance (GOV). Le comportement attendu en cas de dérive de schéma pour un reporting est détaillé côté Power BI dans le dossier OneLake et SaaS mobile — difficultés.

Ce que mesure le thème#

Axe : de la dépendance subie à l'engagement bilatéral testé automatiquement.
Indicateur clé : part des sources critiques couvertes par un contrat testé, et nombre de ruptures non annoncées par trimestre.
Unité : % de sources sous contrat ; nombre de pannes causées par un changement amont non annoncé.

Les cinq niveaux#

Niveau	Nom court	Promesse	Indicateur type (ordre de grandeur)
1	Subi	Les données arrivent tant que la source ne change pas ; les changements se découvrent par la panne.	Majorité des ruptures non annoncées
2	Connu	On sait qui contacter, quand les sources changent (calendrier de versions) et comment elles sont extraites.	100 % des sources avec contact et mode d'extraction
3	Écrit	Chaque source critique a un contrat écrit : schéma, sémantique, fraîcheur, volumes, responsable.	≥ 80 % de sources critiques sous contrat
4	Testé	Le contrat est vérifié automatiquement à chaque livraison ; les changements sont versionnés et préavisés.	Ruptures non annoncées < 1 par trimestre
5	Piloté par le producteur	Les producteurs publient et font évoluer leurs contrats ; les consommateurs valident avant déploiement.	Zéro rupture non annoncée sur 12 mois

Jalons par niveau#

ID	Jalon	Preuve vérifiable
PD-CTR-1.1	Les sources alimentant le datamart sont inventoriées (système, version, mode d'accès).	Inventaire daté.
PD-CTR-1.2	L'extraction (complète, incrémentale, par interface) est décrite pour chaque source.	Fiche source avec mode et fenêtre horaire.
PD-CTR-1.3	Un incident lié à un changement de source laisse une trace.	Registre d'incidents avec cause « changement amont ».
PD-CTR-1.4	Les accès techniques aux sources sont nominatifs et en lecture seule.	Revue de comptes de service.
PD-CTR-2.1	Un contact (producteur) est nommé pour chaque source critique.	Annuaire à jour, testé par un message.
PD-CTR-2.2	Le calendrier des versions amont est connu de l'équipe data.	Calendrier des mises en production applicatives partagé.
PD-CTR-2.3	Les volumes et la fenêtre de disponibilité de chaque source sont connus.	Valeurs de référence consignées.
PD-CTR-2.4	Un test de non-régression de schéma est lancé après chaque version amont (même manuel).	Compte rendu de test après chaque version.
PD-CTR-3.1	Un contrat écrit par source critique décrit schéma, types, clés, nullabilité, valeurs autorisées.	Document de contrat versionné avec propriétaire.
PD-CTR-3.2	La sémantique est décrite (signification métier des colonnes, unités, fuseaux, règles de gestion).	Dictionnaire rattaché au contrat (MET).
PD-CTR-3.3	Les engagements de fraîcheur et de qualité du producteur sont explicites.	Section SLA du contrat (liée à QUA).
PD-CTR-3.4	La règle d'évolution est écrite : ce qui est compatible, ce qui est cassant, le préavis.	Politique de compatibilité signée.
PD-CTR-4.1	Une vérification automatique compare le schéma réel au contrat à chaque chargement.	Test de conformité de schéma dans le pipeline, avec échec explicite.
PD-CTR-4.2	Les versions du contrat sont numérotées ; un changement cassant impose une nouvelle version.	Historique de versions du contrat.
PD-CTR-4.3	Les consommateurs sont préavisés d'un changement dans le délai convenu.	Notifications archivées avec délai constaté.
PD-CTR-4.4	Le comportement en cas de dérive est défini : rejet, quarantaine, adaptation automatique tracée.	Test d'une dérive simulée ; résultat conforme à la règle.
PD-CTR-5.1	Les producteurs exécutent les tests de contrat dans leur livraison avant mise en production.	Résultats de contrat dans les pipelines amont.
PD-CTR-5.2	Les consommateurs déclarent leurs dépendances (colonnes utilisées) pour mesurer l'impact.	Registre de dépendances par contrat.
PD-CTR-5.3	Un changement cassant n'est jamais livré sans période de double fonctionnement.	Cas réel avec deux versions en parallèle.
PD-CTR-5.4	Les contrats sont lisibles par machine et publiés dans un catalogue.	Format normalisé et publié (ex. ODCS/Bitol, état de la norme à vérifier).

Lecture détaillée par niveau#

🟢 Niveau 1 — Subi#

Signes : « ça a cassé cette nuit, l'application a changé » ; on découvre une nouvelle valeur de code par un chiffre aberrant.
Gain : aucun engagement à tenir.
Ne garantit pas : la continuité de service ; la compréhension de la sémantique.
Difficulté : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Connu#

Signes : on connaît le calendrier de sortie des versions applicatives ; on teste après chaque version ; les contacts sont à jour.
Gain : les ruptures sont anticipées et non plus subies à l'aveugle.
Ne garantit pas : que le producteur prévienne de tout.
Difficulté : 2/5 · Effort : 2/5.

🟡 Niveau 3 — Écrit#

Signes : un contrat par source critique, avec colonnes, types, clés et règles ; la politique de compatibilité est lue par les deux parties.
Gain : une discussion factuelle quand un conflit survient ; l'onboarding d'une nouvelle personne devient possible.
Ne garantit pas : que le contrat soit respecté (un document peut diverger de la réalité).
Difficulté : 3/5 · Effort : 3/5.

🧪 Exemple

Un contrat minimal pour une table de relevés d'une application SFA : REL_ID (entier, clé, non nul), PDV_ID (non nul, référence PDV), REL_DAT (date, fuseau d'enregistrement du terminal converti en UTC côté producteur), REL_QTE (≥ 0 ; NULL interdit), disponibilité à 5 h, préavis de 30 jours pour tout changement cassant, nouvelle valeur d'une liste fermée = changement compatible mais notifié.

🟡 Niveau 4 — Testé#

Signes : un test compare le schéma réel au contrat à chaque chargement ; un changement non conforme est mis en quarantaine plutôt que chargé.
Gain : une rupture devient un échec explicite et rapide, plutôt qu'un chiffre faux.
Ne garantit pas : la détection d'un changement de sens à schéma identique (un code recyclé) ; combinez avec les contrôles de distribution de QUA.
Difficulté : 4/5 · Effort : 3/5.

-- Vérification de conformité de schéma contre un contrat (T-SQL, extrait)
SELECT C.COLONNE, C.TYPE_ATTENDU, T.DATA_TYPE AS TYPE_REEL
FROM   [ctr].[ContratColonne]       AS C WITH (NOLOCK)
LEFT JOIN INFORMATION_SCHEMA.COLUMNS AS T
       ON T.TABLE_SCHEMA = C.SCHEMA_SRC AND T.TABLE_NAME = C.TABLE_SRC AND T.COLUMN_NAME = C.COLONNE
WHERE  T.COLUMN_NAME IS NULL OR T.DATA_TYPE <> C.TYPE_ATTENDU;   -- tout résultat = rupture de contrat

🔴 Niveau 5 — Piloté par le producteur#

Signes : les tests de contrat tournent dans le pipeline du producteur ; une double publication de versions accompagne tout changement cassant.
Gain : disparition des pannes par surprise ; responsabilité là où le changement naît.
Ne garantit pas : l'adhésion d'un éditeur SaaS externe, qui ne publiera pas de contrat pour vous ; il reste alors une couche d'isolation (voir ci-dessous).
Difficulté : 5/5 · Effort : 5/5.

💡 Astuce d'expert

Avec un producteur externe (éditeur de SaaS, API tierce) vous n'obtiendrez pas un contrat : construisez un contrat unilatéral en aval (zone de réception qui valide, quarantaine, versionnement de l'interprétation). Il offre 80 % du bénéfice sans accord.

Atteinte partielle et notation#

Notez sur vos cinq sources les plus critiques. Un jalon vaut 1 s'il est vrai pour les cinq, 0,5 pour deux à quatre, 0 sinon. Pour les producteurs externes, un contrat unilatéral testé vaut 0,5 sur les jalons de niveau 5.

Un « 5 partiel » : le producteur interne principal exécute les tests de contrat dans sa livraison (5.1 à 0,5), un changement cassant a déjà été livré en double fonctionnement (5.3 à 1), les contrats sont des tableurs partagés non lisibles par machine (5.4 à 0), les dépendances de consommateurs sont partiellement déclarées (5.2 à 0,5).

⚠️ Piège

Le contrat décoratif : un document de 40 pages que personne ne teste. Symptôme : le contrat dit une chose, la source en fait une autre. Remède : ne comptez un jalon de niveau ≥ 4 que si une exécution automatique l'atteste.

⚠️ Piège

Dérive silencieuse de sémantique : un statut « 3 » passe de « livré » à « livré partiellement » sans changement de schéma. Remède : les valeurs d'une liste fermée et la distribution des codes sont des clauses du contrat, surveillées.

Passer au niveau suivant#

Moyens possibles (facultatifs)

Passage	Leviers possibles
1 → 2	S'abonner aux notes de version de l'application source ; une rencontre trimestrielle avec l'éditeur interne.
2 → 3	Rédiger le contrat à partir du schéma réel, puis le faire relire par le producteur (le geste le moins coûteux).
3 → 4	Une zone de réception (staging) qui valide le schéma avant chargement ; versionner les contrats dans le dépôt (GDS et SQL/BI).
4 → 5	Publier des contrats dans un catalogue ; intégrer leurs tests dans les pipelines des producteurs (CI/CD pour la data).

Pièges transverses : (1) Faux positif — contrat testé sur le schéma mais jamais sur la fraîcheur ni les valeurs. (2) Goodhart — viser « nombre de contrats » produit des contrats triviaux. (3) Rigidité — un contrat trop strict bloque l'évolution ; prévoyez des changements compatibles qui ne demandent pas de version.

🤖 IA

Elle génère un projet de contrat à partir d'un schéma, compare deux versions de schéma et rédige les notes de migration. Elle ne devine pas la sémantique métier ni les engagements du producteur ; un contrat généré sans validation du producteur est une hypothèse.

Voir aussi#

Même matrice : 03 Qualité · 05 Modélisation · 06 DataOps · 12 Métadonnées · README
Autres matrices : DL — architecture et conception · DL — intégration et livraison continues · BI — couche données et ETL
Pratique : méthodes spécifiques data · CI/CD pour la data · SQL Server SaaS — architecture · OneLake — architecture
Glossaire · Notation

✻ Rédigé par Claude Sonnet 5.5