Le Manifeste DataOpsde la qualité
Après des années de travail avec des équipes data de toutes tailles et de toutes architectures, nous sommes convaincus que la qualité ne vient que des tests, et que la qualité qui mérite d’être testée est celle de toute la livraison, pas seulement celle des données. Des données parfaites qui passent par le mauvais code, le mauvais rapport ou le mauvais modèle restent une erreur, et votre client ne voit pas la différence. Nous avons été le casse-pieds de service de la qualité des données. Nous avons compté les lignes à l’œil en croisant les doigts. Nous avons mené l’audit de 12 mois qui a produit un document et n’a rien corrigé. Nous avons construit le tableau de bord que personne n’a ouvert, et nous avons appris par le client, à 9 h, que les données étaient fausses. Nous voulons une méthode qui prouve la qualité à chaque étape, avec des tests qui tournent sans héros au clavier, et des preuves que nous pouvons remettre à quiconque peut corriger le problème. Le Manifeste DataOps dit que la qualité est primordiale. Le Manifeste Data Journey dit qu’il n’est pas acceptable que les clients trouvent les problèmes. Voici comment nous mettons les deux en pratique.
Signez le ManifestePar notre travail, nous en sommes venus à privilégier :
- Les tests automatisés plutôt que l’espoir et les contrôles manuels
- La pratique continue plutôt que les projets ponctuels
- La mesure plutôt que l’opinion
- Les tests générés plutôt que les règles écrites à la main
- La couverture de tests plutôt que les diagrammes de lignage
- Des postes qualité tout au long de la chaîne plutôt que l’inspection en bout de chaîne
- L’influence et les preuves plutôt que les injonctions
- Fonctionner à 70 % aujourd’hui plutôt que la perfection un jour
24 principes en six groupes, plus un. Choisissez-en un pour y accéder.
1-4
Preuves
-
1
Vous ne savez que ce que vous avez testé
L’espoir n’est pas un test. Une revue métier ou un pipeline au vert non plus. Si aucun test ne l’a vérifié, vous ne savez pas si c’est juste.
-
2
Testez les données, surveillez les outils
La qualité, c’est la qualité des données plus la qualité des processus. Une table parfaite ne sert à rien si le rafraîchissement n’a jamais tourné, et un job au vert ne dit rien des chiffres qu’il contient. Vérifiez chaque outil, pour les erreurs comme pour les délais.
-
3
Pas de contrôles manuels
Les contrôles manuels tournent quand quelqu’un y pense, et personne n’y pense à 2 h du matin. Vos données arrivent tous les jours, donc chaque test s’exécute automatiquement, à chaque chargement. Le Manifeste Data Journey le dit sans détour : fuyez les tests de qualité manuels comme la peste.
-
4
Mesurez avant de fixer des normes
Profilez vos données, créez des tests, et laissez la référence vous dire quelles normes fixer. Un comité qui les rédige d’abord retarde toutes les décisions qui suivent. Sans résultats de tests, vous n’êtes qu’une personne de plus avec une opinion.
5-6
Personnes
-
5
Commencez avec une seule personne
Une personne motivée avec un outil gratuit vaut mieux qu’un comité de pilotage avec une charte. Trouvez le casse-pieds de la qualité et donnez-lui des preuves.
-
6
Influencer, c’est le travail
Celui qui trouve un défaut possède rarement le système qui l’a produit. Les données sources sont assez bonnes pour l’usage pour lequel elles ont été conçues, donc leur propriétaire n’a aucune raison de les changer. Rendez la correction facile à accepter.
7-9
Tests
-
7
Laissez le profil écrire les tests
Coder à la main des centaines de tests par table, on n’en voit jamais le bout. Générez-les, et gardez votre SQL pour les règles métier que seuls vos experts du domaine connaissent.
-
8
Les tests sont une ressource partagée
L’analyste, le data steward, l’ingénieur et le modèle touchent tous la même règle, et un seul d’entre eux a un compte Git. Conservez chaque test et chaque résultat dans une seule base de référence, accessible à une personne par une UI, au code par une API et à un modèle par MCP. Une seule copie fait foi, et chaque modification part dans Git pour le diff, la revue et le retour arrière.
-
9
70 % aujourd’hui vaut mieux que parfait un jour
Livrez un test qui marche cet après-midi. Chaque boucle vous apprend quelque chose sur vos données, et les normes s’améliorent à chaque tour.
10-13
Scores et action
-
10
Notez ce qui compte
Personne ne change de comportement pour une colonne de numéros de fax. Notez les éléments qui comptent pour votre client, et construisez un score différent pour chaque client.
-
11
Chaque score remonte à un test
Un score sans chemin de correction, c’est du bruit. Chaque chiffre du tableau de bord remonte à un test qui montre le problème et prouve la correction.
-
12
Facilitez l’action
Chaque tableau de bord a un client nommé et une personne nommée capable de corriger les données. Remettez-leur le problème, son impact, la façon de le reproduire et ce qu’il faut changer, dans l’outil de tickets qu’ils utilisent déjà.
-
13
Gardez la courbe de tendance
Un score, c’est une opinion. Six mois de scores liés à un KPI que quelqu’un au-dessus de vous suit déjà, c’est un budget. Commencez par deux chiffres : les erreurs en production et le délai pour livrer une modification. La tendance, c’est ce que vous montrez quand vous demandez plus de marge.
14-19
Pratique
-
14
Aimez vos erreurs
Chaque défaut vous apprend quelque chose sur vos données ou votre processus. Passez-les en revue ensemble dans un cercle de qualité et corrigez l’étape qui les a produits. Blâmez l’étape, pas la personne.
-
15
Mettez les conditions de livraison dans des tests
Un contrat de données est un ensemble de tests sur lequel les deux parties s’accordent. Des conditions que vous pouvez exécuter valent mieux que des promesses qui ne s’exécutent pas.
-
16
Prouvez la migration
Une migration promet que le nouveau système contient la même vérité que l’ancien. Testez les deux côtés et prouvez-le, du nombre de lignes jusqu’aux valeurs des colonnes.
-
17
Coupez le bruit
Une alerte à laquelle personne ne croit est pire que pas d’alerte du tout. Ajustez chaque test jusqu’à ce qu’un échec veuille dire quelque chose, et envoyez-le à la personne qui peut agir. Rétrogradez ceux qui se déclenchent toutes les nuits. Ne les faites jamais taire.
-
18
En production, c’est à vous
Le déploiement, c’est le milieu du travail, pas la fin. Quelqu’un surveille la chaîne, et ce quelqu’un, c’est vous.
-
19
Testez ce que l’agent a écrit
Un agent livre une transformation en quelques secondes et ne garde rien du pipeline en tête. Laissez-le rédiger le ticket de correction et le SQL sur mesure. Tout le reste de ce qu’il touche n’est pas testé tant qu’un test ne prouve pas le contraire.
20-24
Prouver la qualité à chaque étape
-
20
Tester… à la source
Prouvez que la source est adaptée à l’usage, une table et une colonne à la fois. Elle ne vous appartient pas, donc vos preuves doivent convaincre la personne à qui elle appartient.
-
21
Tester… à l’ingestion
Surveillez chaque table : fraîcheur, volume, changements de schéma et dérive. Vous ne pouvez pas surveiller 6 000 tables à la main. La détection d’anomalies, si.
-
22
Tester… en production
Posez un garde-fou entre chaque couche et arrêtez la chaîne au moindre défaut. Tous les échecs ne méritent pas un arrêt, alors décidez à l’avance lesquels bloquent et lesquels avertissent. La production reste sur les dernières données valides connues pendant que quelqu’un regarde.
-
23
Tester… en développement
Exécutez le code du jour sur un clone ou un extrait des données de production de la veille avant de déployer. Renommez une colonne, et un voyant rouge doit vous dire quel rapport en aval vous avez cassé. Un bug repéré ici coûte cent fois moins cher que celui que trouve votre client.
-
24
Tester… partout, à chaque fois, automatiquement
Un même contrôle de valeurs nulles remplit quatre rôles à quatre endroits. Sautez-en un, et vous raterez cet échec. Couvrez chaque table, chaque colonne, chaque outil et chaque chiffre que lit votre client. Aucun test manuel.
Commencez le DataOps par la qualité
Le Manifeste DataOps compte 18 principes, et personne ne les adopte tous du jour au lendemain. Commencez par les tests de données automatisés. C’est l’étape la moins chère, et votre client en sent les effets en premier. L’orchestration, la CI/CD et l’observabilité dépendent toutes d’une chose : savoir si les données sont justes.
Signez le Manifeste DataOps de la qualité
Ajoutez votre nom si vous préférez prouver la qualité par des tests automatisés plutôt que de l’espérer.
Mettez le manifeste en pratique avec l’open source
DataOps TestGen
Profile your data and generate the quality tests automatically. Full coverage in minutes, with no hand-written rules to maintain.
Install TestGenDataOps Process Observability
Watch every tool and every run from source to the dashboards that depend on it. Catch errors, late arrivals, and bottlenecks before your customer does.
Get Process ObservabilityPour aller plus loin
Free Books
Free Training & Certification
Lire les autres manifestes
The DataOps Manifesto
18 principles for delivering analytics, plus one: start with data testing.
Read the DataOps ManifestoThe Data Journey Manifesto
22 principles for observing the paths your data takes, so you find the problem before your customer does.
Read the Data Journey Manifesto