Évolution de schéma sans casse

Les schémas de données ne sont pas gravés dans le marbre ; ils doivent évoluer. Mais chaque changement est un risque. Un renommage de colonne anodin peut casser des dizaines de dashboards et de pipelines en aval. Le but n’est pas d’empêcher le changement, mais de le rendre prévisible et sûr. Une approche disciplinée, basée sur la compatibilité ascendante et la double publication, transforme une opération risquée en un processus maîtrisé.

le changement sauvage (ce qu’il faut éviter)

C’est le scénario classique : une modification est poussée directement, et tout casse en aval.

l’évolution contrôlée (la bonne pratique)

Ici, l’ancienne version est maintenue le temps que les consommateurs migrent vers la nouvelle.

prérequis

Des contrats de schémas qui définissent la structure attendue des données critiques.
Une intégration continue (CI) qui valide automatiquement l’impact des changements.
Un plan de dépréciation pour communiquer sur la fin de vie des anciennes versions.

idées clefs

Les principes d’une évolution de schéma réussie sont simples et s’inspirent du développement logiciel.

pas à pas

étape 1: classifier et étiqueter le changement

La première question à se poser est : “ce changement va-t-il casser les consommateurs existants ?”.

Mineur (non-cassant): Un ajout de colonne nullable. On peut incrémenter la version mineure du contrat.
Majeur (cassant): Un renommage, une suppression ou un changement de type de colonne. Il faut incrémenter la version majeure.

# contrat de données: marketing.campaigns_v
# Le changement est majeur, on passe en v2.
version: 2.0.0
compatibility: breaking
deprecation_date_v1: "2023-01-31"

étape 2: valider l’impact en ci

L’intégration continue est votre filet de sécurité. Elle doit lancer des tests qui simulent l’impact du changement sur les dépendances en aval.

# Exemple avec dbt: tester le modèle modifié et tous ses enfants
dbt test --select state:modified+

étape 3: migrer en douceur avec la double publication

Pour un changement majeur, ne modifiez jamais la version existante. Publiez la nouvelle version en parallèle et maintenez l’ancienne pendant une période de migration définie.

Publier v2: Créez une nouvelle vue ou table dataset_v2.
Maintenir v1: L’ancienne dataset_v1 continue de fonctionner. Elle peut même être une vue qui s’adapte à la nouvelle structure pour assurer la transition.
Communiquer: Annoncez la date de fin de vie de la v1 aux propriétaires des assets dépendants.
Retirer v1: Une fois la fenêtre de migration terminée, supprimez la v1.

pièges frequents

Symptôme: “L’équipe BI se plaint que tous les dashboards sont cassés ce matin.”
- Cause: Un changement sauvage a été poussé sans analyse d’impact.
- Correctif: Adopter une politique stricte de versioning (SemVer) et un plan de communication pour tout changement majeur.
Symptôme: Un changement considéré comme “sûr” a quand même provoqué un bug inattendu.
- Cause: Absence de tests de régression dans la CI.
- Correctif: La CI est obligatoire. Elle doit au minimum valider le schéma et les types de données sur les assets modifiés et leurs dépendances directes.
Symptôme: Les équipes se plaignent que la fenêtre de migration de 2 jours est trop courte.
- Cause: Mauvaise communication et planification irréaliste.
- Correctif: Annoncer les changements cassants le plus tôt possible, avec une fenêtre de migration réaliste (plusieurs semaines, voire mois, pour les assets très critiques).

faq

Pourquoi ne pas simplement utiliser une vue pour masquer les changements de la table sous-jacente ? C’est une bonne pratique (une vue sert d’interface stable), mais elle ne résout pas tout. Si vous renommez une colonne dans la table et mettez à jour la vue avec un alias, la performance peut se dégrader. Pour les changements majeurs, une nouvelle version explicite (_v2) est toujours plus claire et plus sûre.
Comment gérer les dépendances que l’on ne connaît pas ? C’est là qu’un outil de lineage (lignage de données) devient essentiel. Il vous permet de visualiser toutes les dépendances en amont et en aval d’une table ou d’une vue, et de notifier les bonnes personnes avant d’effectuer un changement.

Menu