Test technique gouvernance d une équipe data : standards, processus, culture

1Définir et maintenir des standards de code

• Convention de nommage — préfixes clairs : stg_ staging, int_ intermediate, fct_ faits, dim_ dimensions. Documenté dans CONTRIBUTING.md
• Pre-commit hooks — sqlfluff (lint SQL), black (Python), dbt compile (valider le SQL dbt avant commit)
• Template de modèle — un template dbt avec les sections obligatoires : description, columns, tests
• Seuil de coverage — 100% des colonnes clés testées (PKs, FKs, colonnes critiques pour les KPIs)
• Living document — les standards évoluent. Process pour les modifier : PR avec discussion d équipe

2Code review efficace pour la data

• Checklist de review — la même checklist pour tous : tests ajoutés, documentation à jour, performance vérifiée, cohérence avec les standards
• Reviewer != approver — séparer la revue technique (n importe quel pair) de l approbation (référent technique)
• PR Size — les PRs > 400 lignes sont rarement bien reviewées. Encourager les petites PRs incrémentales
• Feedback constructif — 'cette approche créera des doublons si...' plutôt que 'c est mal fait'
• Automated checks — laisser les outils (linters, tests automatiques) gérer les problèmes mécaniques. Les humains se concentrent sur la logique

3Gouvernance des définitions de métriques

• Single source of truth — les définitions de métriques sont dans le code dbt (mesures LookML ou modèles dbt). Pas dans les dashboards
• Semantic layer — dbt Semantic Layer, Looker LookML, Cube.js : centraliser les calculs de métriques
• Glossaire data — documenter en langage naturel chaque métrique clé : formule, périmètre, cas particuliers. Dans Confluence ou dbt docs
• Process de création — toute nouvelle métrique doit être validée par l équipe data ET le métier avant d être publiée
• Breaking changes — tout changement de définition d une métrique existante doit être notifié à tous les consommateurs

4Documentation vivante

• Documentation as code — la documentation est dans le repo Git, révisée comme le code. Pas dans un wiki séparé
• dbt docs — documentation auto-générée depuis les fichiers YAML dbt. Toujours synchronisée avec le code
• README par domaine — chaque dossier de modèles dbt a un README qui explique le contexte métier
• ADR (Architecture Decision Records) — documenter les décisions techniques importantes avec leur contexte et les alternatives considérées
• Rotation de responsabilité — chaque membre de l équipe est responsable de la documentation d un domaine en rotation

5Gérer la dette technique data

• Rendre la dette visible — un fichier DEBT.md ou des tickets taggés 'tech-debt' dans le backlog. Ce qui n est pas visible n est jamais traité
• 20% du temps — allouer systématiquement 20% du temps de sprint à la réduction de la dette. Pas négociable
• Priorisation — dette critique (ralentit chaque run ou cause des bugs) > dette majeure (complexifie les évolutions) > dette mineure (refactoring cosmétique)
• Ne pas s endetter inutilement — 'faire vite maintenant et nettoyer après' fonctionne rarement. Poser les bases correctement dès le départ

6Créer une culture d excellence

• Célébrer les tests — féliciter publiquement quand un test détecte un vrai bug en CI avant la production
• Post-mortems sans blame — quand un incident de données survient, l analyse est axée sur le système, pas sur les individus
• Guild technique — réunion hebdomadaire de l équipe data pour partager les apprentissages, les outils découverts, les améliorations
• Lead par l exemple — le Lead Data Engineer doit écrire du code avec les mêmes standards qu il demande aux autres

7Grille par niveau