86% des data engineers estiment que leur code ne respecte pas les standards du software engineering, selon McKinsey (2025). Pas de version control, du code écrit directement en production, aucun test, documentation manquante, pas de code review.
C'est comme si on développait des services web sans Git, sans CI/CD, sans tests. C'est impensable pour du code d'application mais ça l'est pour la data. Pourtant une donnée fausse en production peut coûter des millions - mauvaise stratégie commerciale basée sur un chiffre erroné.
Les données sont aussi critiques que le code applicatif, sinon plus. Les équipes data doivent adopter la rigueur du software engineering. C'est un impératif de qualité.
Discipline 1: Git pour tout
Première discipline : tout le code data doit être versionnée dans Git. Pas d'exceptions. Requêtes SQL, scripts Python, configurations dbt, tests, documentation - tout.
Chaque changement crée un commit avec message explicite. L'historique complet devient traçable : qui a changé quoi, quand, pourquoi. Pour les data warehouses, ça signifie que les scripts de transformation ne doivent pas vivre dans des interfaces graphiques d'outils (no-code BI) mais dans des fichiers texte gérés en Git.
Snowflake, BigQuery, Redshift permettent de les versionner. Cette discipline prend quelques jours à mettre en place mais élimine les regressions silencieuses.
Bonnes pratiques : main/prod en read-only, feature branches pour chaque changement, squash & merge en main pour l'historique lisible.
Discipline 2: Code review obligatoire
Aucun code data ne doit aller en production sans review par un pair. C'est une barrière simple mais redoutable.
La code review capture les bugs logiques, les cas limites non gérés, les opportunités de réutilisabilité, les incohérences avec les standards. McKinsey rapporte que les équipes pratiquant la code review systématique réduisent de 45% les anomalies en production.
Les code reviews ne doivent pas être dogmatiques : l'objectif est l'apprentissage mutuel et l'amélioration du code. Tempo important : un reviewer doit commenter dans les 24h. Une PR qui dort 2 semaines casse la productivité.
Les bons outils (GitHub, GitLab, Bitbucket) intègrent discussions, suggestions, approbations.
Discipline 3: Tests automatisés
Le code data doit avoir des tests. Tests unitaires sur les transformations, tests d'intégration sur le pipeline complet, tests de qualité de données.
Un test c'est une assertion : « cette colonne ne doit jamais être nulle », « ce nombre de lignes doit être > 1000 ». Les tests en dbt sont simples à écrire et s'exécutent en CI automatiquement.
Les tests complexes se font avec Great Expectations - assertions de schéma, distribution statistique, etc. Sans tests, vous naviguez à l'aveugle. Avec tests, vous détectez les régressions immédiatement.
Le coût d'une donnée fausse en production est estimé à 10x le coût de la prévention par test. C'est une question de ROI pur.
Discipline 4: Documentation-as-code
La documentation doit être dans le code, générée automatiquement, maintenue vivante. En dbt, c'est les fichiers YAML avec descriptions pour chaque table et colonne. En SQL, ce sont les commentaires inline. En Python, ce sont les docstrings.
La documentation morte (Word, wiki) n'existe pas : elle est obsolète dès sa rédaction. La documentation vivante (dbt docs, Sphinx) change quand le code change. Elle doit être consultable facilement : dbt Cloud expose les docs générées avec le lineage, les tests, les descriptions.
C'est la traçabilité absolue : d'où vient chaque colonne, quels tests la valident, comment elle est utilisée.
Discipline 5: CI/CD natif
Chaque push déclenche une chaîne d'exécutions. Linting du code - sqlfluff, pylint. Tests unitaires. Tests de qualité. Construction du DAG. Déploiement en staging. Tests d'intégration. Puis déploiement en production.
Si un test échoue, le déploiement s'arrête. C'est la barrière ultime contre les mauvaises transformations. dbt Cloud l'intègre nativement. Pour du code Python custom, GitHub Actions ou GitLab CI l'orchestrent.
La sécurité de ce processus réduit de 50% le temps d'onboarding des nouveaux data engineers : ils héritent d'une base de code saine, testée, documentée. C'est un gain de confiance et productivité immédiat.
En production
Chez Bomzai, on parle d'opérer. Opérer, c'est avoir confiance. Et la confiance, elle vient de la rigueur. Version control, tests, code review, documentation, CI/CD - c'est pas du luxe, c'est le minimum pour produire en production.
Les équipes qui adoptent ces disciplines réduisent les anomalies, accélèrent l'onboarding, libèrent les data engineers de l'anxiété de la production. C'est un investissement qui paie en semaines, pas en années.
La data mérite le même respect que le code d'application. Parce que les données, c'est la matière première de la décision. Et les décisions fausses coûtent cher.