Le passage de quelques analystes à plusieurs équipes change la nature du problème. Le sujet n’est plus seulement d’écrire de bons modèles SQL, mais d’organiser la contribution, la qualité, la compatibilité, l’exploitation et la responsabilité.
À retenir
- Découper les projets selon les responsabilités, pas seulement les couches techniques.
- Utiliser les contrats, les tests et la CI pour empêcher les régressions.
- Mesurer la santé du patrimoine dbt comme un produit logiciel.
- Donner un owner clair à chaque modèle publié.
1. Choisir une architecture de projets explicite
Monorepo, multirepo ou approche hybride : chaque choix a des conséquences sur les dépendances, les droits, la vitesse de livraison et la cohérence. La structure doit refléter les domaines, les produits de données et les responsabilités.
2. Limiter le nombre de couches et clarifier leur rôle
Staging, intermédiaire, mart, métriques : les noms ne suffisent pas. Chaque couche doit avoir des règles d’entrée, de sortie, de matérialisation et d’exposition. Les modèles sans rôle clair sont une source majeure de dette.
3. Définir l’ownership
Chaque modèle publié doit avoir un propriétaire, des consommateurs identifiés, un niveau de service et un processus de changement. L’ownership doit apparaître dans les métadonnées et dans le processus de revue.
4. Utiliser les contrats pour protéger les consommateurs
Les contrats rendent explicites les colonnes, types et contraintes attendus. Ils sont particulièrement utiles pour les modèles partagés et les interfaces entre domaines.
5. Construire une stratégie de tests proportionnée
Tout tester est coûteux et peu réaliste. Il faut distinguer contrôles structurels, qualité source, règles métier, réconciliation et tests unitaires. La criticité guide la profondeur.
6. Rendre la CI sélective et rapide
Une CI qui reconstruit tout le patrimoine à chaque changement devient contournée. Les mécanismes de sélection, l’état précédent, les environnements éphémères et les jeux de données ciblés permettent de maintenir un feedback rapide.
7. Gérer les changements incompatibles
Renommer une colonne ou modifier une granularité est une évolution d’interface. Une politique de dépréciation, une période de coexistence et une communication aux consommateurs réduisent les incidents.
8. Observer la fraîcheur, la durée et la qualité
La DSI doit suivre la santé des exécutions, mais aussi l’évolution du patrimoine : modèles orphelins, couverture de tests, documentation, consommation, incidents et dépendances critiques.
9. Relier les choix dbt aux coûts de plateforme
Matérialisations, fréquences, full refresh, modèles intermédiaires et requêtes répétées ont un impact direct. Le coût doit être visible au niveau du produit de données et du job.
10. Gouverner les macros et packages partagés
Un composant partagé est une dépendance logicielle. Version, compatibilité, tests, documentation et mainteneur doivent être traités comme tels.
11. Créer une capacité plateforme, pas un goulot d’étranglement
L’équipe centrale fournit les standards, composants, outillage et accompagnement. Les domaines conservent la responsabilité de leurs produits. L’objectif est d’augmenter l’autonomie, pas de centraliser chaque changement.
12. Les indicateurs utiles
- temps entre changement et production ;
- taux d’échec et temps de reprise ;
- fraîcheur et respect des SLA ;
- couverture de tests sur les objets critiques ;
- coût par job et produit ;
- modèles sans owner ou sans consommateur ;
- temps de feedback de la CI.
La maturité dbt ne se mesure pas au nombre de modèles. Elle se mesure à la capacité de plusieurs équipes à livrer rapidement sans dégrader la fiabilité du patrimoine.