Objectif
Savoir lire une chaîne de données sans être ingénieur.
Un pipeline n'est pas un tuyau. C'est une suite de décisions.
Le mot évoque un transport : les données partent d'un endroit et arrivent à un autre. Cette image cache l'essentiel, car chaque étape applique des règles qui changent ce que la sortie signifie.
Cette fiche donne une grille de lecture pour suivre un trajet de données et poser les quatre questions qui font apparaître les endroits où la confiance se gagne ou se perd.
Principe
La valeur ne vient pas du déplacement, mais des règles appliquées.
Entre la source et l'écran final, des choix ont été faits : ce qui est exclu, ce qui est corrigé, ce qui est agrégé, ce qui est considéré comme un doublon. Ces choix sont des décisions métier déguisées en traitements techniques.
Comprendre un pipeline consiste donc à retrouver ces décisions et à savoir qui les a prises. C'est ce qui permet de dire pourquoi deux chiffres divergent, et lequel répond réellement à la question posée.
Deux sorties différentes peuvent être exactes et ne pas répondre à la même question.
Source
Ce qui produit la donnée, et à quel rythme.
Collecte
Ce qui est récupéré, et ce qui est laissé.
Transformation
Filtres, calculs, corrections, jointures.
Stockage
Ce qui est conservé, et sous quelle forme.
Usage
Qui lit la sortie, et pour quelle décision.
Approche
Partir de l’usage, puis remonter le trajet.
La lecture se fait avec la personne qui exploite la chaîne. L'objectif n'est pas d'auditer le code, mais de rendre visibles les règles et leurs propriétaires.
Pars de la sortie, puis remonte.
Commencer par l'écran final oblige à formuler l'usage réel avant de discuter des traitements.
Identifie la source et sa fréquence.
Une source qui se met à jour une fois par jour interdit toute promesse de temps réel en aval.
Fais expliciter les règles de transformation.
Exclusions, déduplication, corrections manuelles. Ce sont elles qui expliquent les écarts entre deux chiffres.
Demande qui voit les erreurs.
Un traitement qui échoue en silence produit une sortie plausible et fausse, ce qui est pire qu'une absence de sortie.
Vérifie la reprise après incident.
Rejouer un traitement sans double comptage ne s'improvise pas le jour de la panne.
Points d’attention
Reconnaître une chaîne tenue d'une chaîne subie.
Ces signaux se constatent sans accès au code, en écoutant la façon dont l'équipe parle de sa chaîne.
Bon signal
- Les règles de transformation sont écrites et citées avec la sortie.
- Les échecs sont visibles par une personne nommée.
- La fraîcheur en sortie tient compte de l’âge à la source et des délais de collecte, de traitement et de publication.
À surveiller
- Les écarts entre chiffres s'expliquent au cas par cas, oralement.
- Les corrections manuelles ne laissent aucune trace.
- Une panne se découvre parce qu'un utilisateur trouve le chiffre étrange.
À retenir
Un pipeline transporte des données et applique des règles qui déterminent leur usage.
C'est pourquoi la bonne question n'est pas « où est stockée la donnée ? », mais « qui a décidé de cette règle, et où est-elle écrite ? ».
En pratique
Fais raconter une chaîne et contrôler sa sortie.
L’exercice se fait avec l’équipe qui exploite la chaîne. Il doit rendre visibles les règles et vérifier l’âge réellement disponible en sortie.
Une chaîne réelle, pas un schéma d'architecture.
Si une ligne reste vide, elle indique exactement où regarder ensuite.
Source
Le système d'origine et sa fréquence de mise à jour.
Transformations
Les deux ou trois règles qui changent le sens de la donnée.
Erreurs
Qui les voit, par quel canal, en combien de temps.
Usage
La décision que la sortie doit éclairer.
Fraîcheur
L’âge des données réellement disponibles en sortie, avec les délais de collecte, de traitement et de publication. La fréquence de la source seule ne le garantit pas.