Chaque fois qu'on agrémente un SaaS de reporting, d'IA ou de synchronisation externe, on crée un nouveau flux de données. Ces flux finissent par s'entremêler si personne n'impose de plan de vol.
Les règles que je fixe
- Les pipelines doivent être idempotents et versionnés. Chaque transformation a une signature (input, output, version) et un changelog.
- Je collecte les logs d'ingestion, je les expose à des dashboards et je configure des alertes sur les anomalies de volume ou de format.
- Les données critiques traversent un bus: ingestion, transformation, stockage, et chaque étape est automatisée (GitOps + tests). Même le midpoint entre deux jobs est décrit dans une doc.
Une équipe data sans équipe data
Modifier un pipeline ne doit pas casser l'analytique. Pour cela, je crée des simulateurs locaux (fixtures) et je couple chaque transformation à des tests d'intégrité. Les commits passent par une validation qui compare les outputs attendus avec les nouveaux outputs. Les runbooks Documentent les cas d'usage : "modifier la source X" doit avoir une doc associée.
Ainsi, on garde des données fiables sans faire exploser la dette technique ni multiplier des copies de tables.