Pipelines de données : maîtriser sa donnée en un seul endroit plutôt que multiplier les interconnexions

Un chiffre d’affaires différent dans le tableau de bord commercial et dans le fichier de la comptabilité, un client en double dans trois logiciels, une mise à jour qui oublie un des outils : ces symptômes ont souvent la même cause. La donnée vit à plusieurs endroits, reliée par une toile de connexions point à point que chacun a ajoutée au fil du temps. Cet article défend une idée simple : maîtriser sa donnée en un seul endroit, la préparer, puis la publier partout, plutôt que multiplier les interconnexions.

Le plat de spaghettis

Chaque fois qu’un logiciel doit échanger avec un autre, on crée une liaison. Avec quatre outils, cela fait jusqu’à six liaisons ; avec dix, jusqu’à quarante-cinq. Le nombre de liaisons croît bien plus vite que le nombre d’outils. On parle de « plat de spaghettis » : personne ne sait plus quel flux alimente quoi.

• Le coût : chaque liaison se développe, se teste et se maintient. Changer un outil oblige à refaire toutes ses liaisons.
• La fragilité : une mise à jour chez un éditeur casse un flux, et la panne se propage sans qu’on la voie.
• La divergence des chiffres : chaque liaison transforme la donnée à sa façon (arrondis, règles de calcul, filtres), donc deux outils affichent deux vérités.
• La sécurité : des identifiants d’accès dispersés, des copies de données un peu partout, difficiles à inventorier et à effacer.

Le principe : un endroit, une vérité, plusieurs publications

L’alternative consiste à faire converger toutes les sources vers un système unique, qui devient la source de vérité, puis à publier depuis lui vers les consommateurs. Au lieu de dix outils qui se parlent entre eux, chacun parle à un seul point central : un entrepôt ou une plateforme de données, ou, pour un besoin plus modeste, le modèle de données d’un produit décisionnel (BI).

Le schéma est le suivant :

1. Sources (logiciel de gestion, boutique, tableurs, API) ;
2. Ingestion vers un espace de stockage central ;
3. Transformation et modélisation, en couches successives ;
4. Contrôle de la qualité, avec des règles explicites ;
5. Publication vers les consommateurs : tableaux de bord, API, exports, applications.

Chaque règle de calcul n’est écrite qu’une fois, à un seul endroit. Quand elle change, tous les consommateurs en bénéficient.

L’ingestion : faire entrer la donnée

Il existe deux grandes manières de charger les données : par lots (un export chaque nuit, chaque heure) ou en continu (chaque événement est transmis dès qu’il se produit). Le lot suffit à la plupart des besoins de pilotage ; le continu se justifie quand la fraîcheur compte. Dans les deux cas, je garde la donnée brute, telle qu’elle est arrivée, avant toute modification : elle sert de preuve et permet de tout recalculer.

ETL ou ELT ?

Dans l’approche ETL, on extrait, on transforme, puis on charge : la transformation a lieu avant l’arrivée dans le système central. Dans l’approche ELT, on extrait, on charge la donnée brute, puis on la transforme dans le système central, qui a la puissance pour le faire. L’ELT est aujourd’hui répandu parce qu’il conserve la donnée d’origine et permet de refaire une transformation sans relancer l’extraction. L’ETL reste pertinent quand il faut filtrer ou anonymiser avant de stocker.

Les couches bronze, argent, or

L’architecture en médaillon organise la donnée en trois couches :

Couche	Contenu	Usage
Bronze	Données brutes, conservées telles que reçues, avec leur date d’arrivée	Traçabilité, reprise en cas d’erreur
Argent	Données nettoyées : types corrigés, doublons retirés, formats harmonisés, référentiels rapprochés	Socle fiable pour l’analyse
Or	Données prêtes à l’emploi, modélisées par sujet métier (ventes, clients, stocks) avec les indicateurs calculés	Tableaux de bord, API, exports

Chaque couche répond à une question différente. Le bronze dit « qu’est-ce qui est arrivé ? », l’argent « qu’est-ce qui est correct ? », l’or « qu’est-ce qui sert à décider ? ».

La modélisation

Modéliser, c’est décider comment la donnée est organisée pour répondre aux questions de l’entreprise. Pour l’analyse, une organisation courante sépare les faits (ce qui se produit : une vente, une commande, un passage) et les dimensions (ce qui les décrit : le client, le produit, la date, le lieu). Elle rend les questions naturelles : « les ventes par produit et par mois ». Le point important est de définir chaque indicateur une fois : qu’est-ce qu’un client actif ? un chiffre d’affaires net ? Voir aussi choisir ses indicateurs pour décider.

Qualité et contrats de données

Une donnée centralisée mais fausse est pire qu’une donnée dispersée, car elle inspire confiance. Je prévois donc des contrôles à chaque passage de couche :

• complétude : les champs obligatoires sont renseignés ;
• unicité : pas de doublon sur l’identifiant ;
• cohérence : les montants et les dates restent dans des bornes plausibles ;
• fraîcheur : la dernière mise à jour est assez récente ;
• rapprochement : le total d’une couche correspond à celui de la précédente.

Un contrat de données formalise l’accord entre celui qui produit une donnée et ceux qui la consomment : les champs, leurs types, leur signification, leur fréquence de mise à jour, et ce qui se passe quand le format change. Il évite qu’une modification côté source casse silencieusement les tableaux de bord.

La gouvernance

• Un responsable par donnée : quelqu’un décide de sa définition et répond de sa qualité.
• Un catalogue : ce qui existe, d’où cela vient, ce que cela signifie.
• Des droits d’accès limités à ce qui est nécessaire, et journalisés.
• Les données personnelles identifiées : où elles sont, pourquoi on les garde, quand on les supprime (RGPD).
• Une traçabilité : pour un chiffre affiché, retrouver les données sources qui l’ont produit.

Publier vers les consommateurs

Une fois la donnée prête, on la distribue sans la recopier à la main :

• tableaux de bord (BI) : ils lisent la couche or, sans recalculer leur propre version ;
• API : une application, un site ou un partenaire récupère la donnée par une interface contrôlée ;
• exports planifiés : un fichier propre et identique envoyé à qui en a besoin ;
• applications : un outil interne alimenté par le même socle.

Le gain est que tous affichent les mêmes chiffres, calculés de la même façon. Pour la partie consommation, voir du tableur au tableau de bord.

Des exemples concrets

• Ventes en ligne et en magasin : deux sources aux formats différents, rapprochées en couche argent par un référentiel produit commun, puis un indicateur de chiffre d’affaires défini une fois en couche or.
• Fichiers Excel de plusieurs services : au lieu d’échanger des fichiers par courriel, chaque service les dépose, ils sont historisés en bronze, nettoyés en argent et consolidés en or.
• Un client présent dans plusieurs logiciels : un identifiant unique est établi en argent, et tous les outils lisent la même fiche.

Et les outils d’intégration ?

Supprimer toutes les interconnexions n’est ni réaliste ni nécessaire. Il faut bien brancher les systèmes sources à la plateforme centrale, et parfois renvoyer une donnée vers un outil qui n’offre pas d’autre moyen. C’est le rôle d’un outil d’intégration (middleware) : recevoir, transformer, router. La différence est que ces liaisons deviennent des entrées et des sorties d’un point central, et non un maillage entre tous les outils. C’est ce que j’ai exploré dans La Passerelle, l’un de mes projets personnels. Pour les bases, voir middleware : rendre compatibles les échanges de données.

Par où commencer

1. Recenser les sources et les consommateurs, et dessiner les liaisons existantes.
2. Choisir un sujet (par exemple les ventes) et en définir les indicateurs une fois.
3. Conserver la donnée brute avant toute transformation.
4. Mettre en place quelques contrôles de qualité simples.
5. Brancher d’abord un seul tableau de bord sur la couche or, puis étendre.

Les erreurs courantes

• Tout centraliser d’un coup : on choisit un sujet, on le réussit, puis on étend.
• Transformer sans garder le brut : impossible de refaire un calcul ou de prouver un chiffre.
• Laisser chaque outil recalculer ses indicateurs : on retombe sur des chiffres divergents.
• Oublier le propriétaire de la donnée : sans responsable, les définitions dérivent.

Les outils : une question de taille, pas de mode

L’outillage peut rester modeste. Pour une petite structure, un modèle de données bien conçu dans un produit décisionnel, alimenté par des imports planifiés, peut suffire. Un entrepôt ou une plateforme de données devient pertinent quand les volumes, le nombre de sources ou le nombre de consommateurs augmentent. Ce qui compte d’abord, c’est la discipline : donnée brute conservée, règles écrites une fois, qualité contrôlée.

En résumé

Une donnée unique, préparée en couches, contrôlée et publiée à partir d’un seul endroit, coûte moins cher à faire évoluer, tombe moins en panne et donne les mêmes chiffres à tout le monde. On n’a pas besoin d’une grande plateforme pour commencer : un sujet, une source de vérité et des règles écrites suffisent.