Une direction demande le chiffre d’affaires du mois. La finance répond 4,8 millions d’euros. Le CRM affiche 5,1. Le tableau de bord commercial annonce 5,4. Les trois chiffres peuvent être justes : facturé contre signé, devise comptable contre devise du contrat, annulations déduites à des dates différentes.
Le problème n’est pas l’absence de données. C’est l’absence d’un système qui conserve leur sens d’un bout à l’autre.
Cette discipline construit le système. Elle relie les applications, rend les transformations reproductibles, détecte les anomalies et publie des données accompagnées d’une définition. Son travail est invisible lorsque tout fonctionne. Il devient soudain stratégique lorsque les résultats divergent ou qu’une source change sans prévenir.
1. Chiffres clés : beaucoup de logiciels, moins de données réellement utilisées
Eurostat indique qu’en 2025, 53 % des entreprises de l’Union européenne d’au moins dix personnes utilisaient au moins une application spécialisée de type ERP, CRM ou business intelligence. Dans le détail, 46,45 % utilisaient un ERP, 28,51 % un CRM et seulement 16,28 % un outil de BI.
L’écart de taille reste considérable. L’usage d’un ERP allait de 41 % dans les petites entreprises à 89 % dans les grandes. Pour la BI, il passait de 11 % à 69 %, soit 58 points d’écart. Accumuler des applications transactionnelles ne garantit donc pas une capacité homogène à analyser ce qu’elles produisent.
Une autre publication d’Eurostat mesure que 33,02 % des entreprises réalisaient des analyses de données avec leurs propres salariés en 2025 et 13,85 % en confiaient à un prestataire externe. En combinant les deux modalités sans double compte, 39,85 % effectuaient une forme d’analyse. Autrement dit, une majorité des entreprises de l’échantillon ne déclarait toujours pas cette pratique.
À très grande échelle, Google décrit un système de validation utilisé par des centaines d’équipes produit pour surveiller plusieurs pétaoctets de données de production par jour. Le volume est propre à Google, mais l’enseignement se transpose : une pipeline peut continuer à fonctionner techniquement tout en ingérant un schéma inattendu, une valeur absurde ou une distribution qui dérive.
Le même groupe de recherche a proposé un « ML Test Score » comprenant 28 tests et besoins de surveillance pour réduire la dette des systèmes de machine learning. Cette grille rappelle que la performance d’un modèle ne couvre qu’une petite partie de la fiabilité. Les données, le code, l’infrastructure et le monitoring doivent être testés ensemble.
2. Le passeport d’un produit de données
Une table n’est pas encore un produit. Pour devenir consommable, elle possèd'un passeport compréhensible par les métiers et par les équipes techniques.
| Champ | Exemple pour « chiffre d’affaires net » |
|---|---|
| Décision servie | pilotage mensuel et prévision de trésorerie |
| Propriétaire métier | direction financière |
| Producteur technique | équipe data plateforme |
| Définition | factures émises, hors taxes, avoirs déduits |
| Grain | une ligne par facture et devise comptable |
| Sources | ERP, référentiel client, taux de change |
| Fraîcheur | disponible à J+1 avant 7 h |
| Qualité | complétude > 99,5 %, devise renseignée à 100 % |
| Accès | finance et direction, agrégats pour le commerce |
| Historique | corrections conservées avec date d’effet |
| SLA | rétablissement en quatre heures ouvrées |
| Contact | canal et astreinte définis |
Ce passeport évite deux conversations stériles. Les métiers ne demandent plus « toutes les données en temps réel » sans expliquer la décision. Les ingénieurs ne publient plus une colonne revenue_v2_final sans définition partagée.
Le propriétaire métier tranche le sens et les usages autorisés. Le producteur technique garantit le fonctionnement et la qualité convenue. Ces responsabilités sont complémentaires.
3. Le voyage d’une donnée en neuf étapes
Suivons une commande depuis un site e-commerce jusqu’au tableau de marge.
3.1. Production dans le système source
La commande naît dans l’application transactionnelle. Ce système optimise la vente, pas l’analyse historique. Une modification de statut peut écraser l’ancienne valeur ; un remboursement peut arriver plusieurs semaines plus tard.
L’équipe data documente les champs, les événements et les identifiants. Elle évite de lire directement une base de production sans contrat, car une requête analytique peut gêner le service ou dépendre d’un schéma privé.
3.2. Extraction
Trois méthodes dominent : export périodique, API et capture de changements. L’export est simple mais moins frais. L’API respecte les règles du produit mais peut être limitée. La capture de changements reproduit rapidement les insertions et mises à jour, au prix d’une architecture plus exigeante.
Le choix dépend du besoin. Un reporting quotidien n’a pas besoin d’une chaîne événementielle milliseconde. Un système antifraude peut la justifier.
3.3. Zone brute
Les données sont conservées dans leur forme d’origine, horodatées et immuables. Cette zone permet de rejouer un traitement après correction. Elle ne doit pas devenir un dépotoir illimité : chiffrement, accès, catalogue et durée de conservation s’appliquent dès l’ingestion.
On enregistre la source, la version du schéma et le lot. Sans ces métadonnées, le retour en arrière reste théorique.
3.4. Validation à l’entrée
Le pipeline vérifie les règles élémentaires : colonnes attendues, types, identifiants uniques, dates plausibles, montants non négatifs et références connues. Une anomalie critique met le lot en quarantaine. Une anomalie tolérée est comptée et signalée.
Il ne faut pas « nettoyer » silencieusement. Remplacer une devise absente par EUR peut fabriquer une marge fausse. La correction est documentée ou renvoyée au système source.
3.5. Transformation
Les données brutes deviennent des entités stables : commande, client, produit, paiement. Les règles de change, d’annulation et de rattachement sont versionnées comme du code. Les tests couvrent les cas connus.
Une transformation doit être idempotente : rejouer le même lot produit le même résultat. Cette propriété simplifie les reprises après incident.
3.6. Réconciliation
Le pipeline compare les totaux entre étapes. Nombre de commandes, somme des montants et répartition par statut doivent s’expliquer. Une différence de 2 % n’est pas masquée par une moyenne.
La réconciliation avec la source financière demeure indispensable. Le data warehouse ne devient pas une vérité parce qu’il est moderne.
3.7. Modélisation métier
Les tables sont organisées selon les décisions : ventes nettes, marge, rétention, stock disponible. Le modèle sémantique définit les métriques une fois, puis les expose aux tableaux de bord et analyses.
Le grain est explicite. Additionner une valeur déjà agrégée au niveau client dans une table au niveau commande produit des doublons subtils. Un bon modèle rend l’erreur difficile.
3.8. Publication
Le produit de données est publié dans le catalogue avec son passeport, ses droits et son niveau de service. Les consommateurs sont avertis des changements. Une version majeure peut coexister pendant une période de migration.
Le libre-service ne signifie pas accès universel. Il signifie que l’utilisateur autorisé trouve, comprend et utilise sans ticket manuel.
3.9. Observation
La plateforme surveille fraîcheur, volume, schéma, valeurs, distribution, lignée et consommation. Elle relie une alerte à ses impacts : quels tableaux de bord, modèles ou décisions dépendent de la table ?
Une pipeline verte qui livre zéro ligne reste un incident. L’observabilité technique et la qualité métier se complètent.
4. Batch, micro-batch ou temps réel : choisir par coût de retard
« Temps réel » est souvent une préférence exprimée avant que le besoin ne soit calculé. Logiks propose une question plus utile : combien coûte une donnée vieille de cinq minutes, une heure ou une journée ?
Le batch traite des lots selon un horaire. Il convient au reporting financier, à la facturation consolidée et aux analyses dont le cycle de décision est quotidien ou mensuel. Il est plus facile à rejouer, tester et auditer.
Le micro-batch exécute de petits lots toutes les quelques minutes. Il offre un compromis pour le pilotage commercial, les stocks ou certaines alertes.
Le streaming traite les événements à leur arrivée. Il est adapté à la fraude, la personnalisation immédiate, les capteurs critiques ou les opérations où une minute perdue coûte réellement. Il introduit gestion de l’ordre, doublons, retard, relecture, état distribué et supervision continue.
Pour choisir, on compare quatre coûts : préjudice du retard, coût de construction, coût d’exploitation et coût d’une décision erronée. Une donnée instantanée mais non réconciliée peut être moins utile qu’un lot fiable à J+1.
5. Contrats de données : rendre le changement négociable
Un contrat décrit ce qu’un producteur promet à ses consommateurs : schéma, sens, fraîcheur, qualité, disponibilité, classification et règles d’évolution. Il peut être représenté dans un fichier versionné et contrôlé automatiquement.
Exemple : le champ customer_id est non nul, stable et pseudonymisé ; amount_ht est exprimé en centimes dans currency ; une commande annulée conserve son historique ; la table est complète à 6 h 30.
Lorsqu’un producteur veut renommer un champ, les tests identifient les consommateurs. Le changement passe par une version et une fenêtre de migration. Le contrat ne bloque pas l’évolution ; il évite la surprise.
Il existe une limite. Un contrat ne corrige pas une responsabilité floue. Si personne ne possède la définition du client actif, le schéma le mieux documenté ne tranchera pas.
6. Qualité : mesurer selon l’usage
La qualité n’est pas un score universel. Elle se décline par dimension.
Complétude. Les valeurs et lignes nécessaires sont-elles présentes ?
Exactitude. Correspondent-elles au phénomène réel ou à la source de référence ?
Unicité. Un objet est-il compté une seule fois ?
Cohérence. Les règles entre champs et systèmes sont-elles respectées ?
Fraîcheur. Les données arrivent-elles avant la décision ?
Validité. Respectent-elles le format et le domaine attendus ?
Traçabilité. Peut-on expliquer leur origine et leurs transformations ?
Les seuils viennent de l’impact. Une adresse manquante dans une liste marketing n’a pas le même coût qu’un IBAN absent avant paiement. On définit aussi la réaction : bloquer, isoler, dégrader, avertir ou accepter.
Le score global est dangereux s’il compense une dimension critique. Une table peut être « à 98 % » tout en contenant 20 % d’erreurs sur le segment le plus rentable.
7. Architecture : entrepôt, lac et lakehouse
Un entrepôt de données structure fortement les informations pour l’analyse. Il offre SQL, gouvernance et performances prévisibles. Un lac conserve des volumes variés à coût réduit, mais exige une discipline pour rester exploitable. Le lakehouse cherche à combiner formats ouverts, transactions et capacités analytiques.
Le choix ne se résume pas à une mode. Il dépend des formats, volumes, compétences, besoins d’IA, portabilité et outils existants. Une PME avec dix sources structurées peut réussir sur un entrepôt géré. Ajouter un lac distribué augmenterait les opérations sans créer de valeur.
La séparation stockage-calcul facilite l’élasticité et la concurrence entre moteurs. Les formats ouverts améliorent la réversibilité. Mais une plateforme ouverte peut rester captive si toutes les transformations dépendent d’un service propriétaire.
Le Data Act, applicable dans l’Union depuis le 12 septembre 2025, renforce le cadre de changement entre services de traitement de données, dont cloud et edge. La Commission indique notamment des exigences de transparence contractuelle, d’interface ouverte pour certains services et de suppression complète des frais de changement, y compris certains frais de sortie, à compter du 12 janvier 2027. L’architecture doit préparer l’export avant qu’un départ devienne urgent.
8. Observabilité : de l’alerte au diagnostic
Une alerte utile contient le produit affecté, la règle brisée, l’écart, les dépendances et le propriétaire. « Job failed » reste trop pauvre.
On suit notamment :
- taux de succès et durée des pipelines ;
- retard par rapport au SLA ;
- variation anormale de volume ;
- évolution du schéma ;
- taux de null, doublons et valeurs hors domaine ;
- dérive de distribution ;
- coût par pipeline et par produit ;
- requêtes et consommateurs actifs ;
- incidents, temps de détection et temps de rétablissement.
La lignée relie un champ source aux métriques finales. Lorsqu’un ERP change la définition d’un statut, l’équipe peut identifier les rapports touchés. Sans lignée, elle cherche après que les dirigeants ont constaté le problème.
Les alertes possèdent un budget. Trop de notifications non actionnables entraînent leur ignorance. Une règle sans propriétaire ni procédure n’est pas du monitoring ; c’est du bruit.
9. Cas pratique : unifier ventes, stock et marge
Un distributeur possèd'un ERP, un site e-commerce, deux marketplaces et un outil logistique. Les équipes consolident vingt fichiers chaque lundi. Le chiffre de vente est disponible à J+3 et les ruptures sont analysées après coup.
Le projet ne commence pas par « centraliser toutes les données ». Il cible trois décisions : réapprovisionner, ajuster les promotions et clôturer la marge.
Les commandes sont ingérées toutes les quinze minutes. Le stock physique arrive toutes les heures. La comptabilité reste en batch quotidien. Chaque source conserve un identifiant et un horodatage. Les règles de retour et de commission sont versionnées.
Un produit « disponibilité vendable » combine stock, réservations et commandes non expédiées. Son SLA est de vingt minutes, car au-delaux campagnes peuvent promouvoir un article indisponible. Le produit « marge comptable » reste à J+1 avec réconciliation financière.
Après le lancement, la chaîne détecte qu’une marketplace renvoie parfois le même événement. Le contrat d’unicité bloque le doublon avant la marge. Le gain le plus important n’est pas un tableau de bord plus joli : c’est la possibilité d’expliquer chaque chiffre et de rejouer une journée.
10. Coûts : mesurer par produit, pas par plateforme globale
Le coût inclut connecteurs, stockage, calcul, transfert, licences, orchestration, observabilité, astreinte et temps métier consacré aux définitions. Une migration ajoute le double fonctionnement temporaire.
On attribue chaque dépense à un produit de données. Une table non consultée depuis six mois n’a pas la même priorité qu’un flux qui alimente les paiements. Le coût par requête ne suffit pas ; on suit le coût par décision ou processus servi.
Les principaux leviers sont la fréquence, le partitionnement, les requêtes incrémentales, la rétention, les formats, la compression et l’arrêt des produits inutilisés. L’optimisation doit conserver le SLA. Réduire le calcul en livrant après la réunion détruit la valeur.
Un budget de fraîcheur aide : le temps réel est réservé aux produits qui démontrent le coût du retard. Cette règle évite que chaque équipe demande une infrastructure maximale.
11. Équipe et responsabilités
L’ingénieur data construit et exploite les pipelines. L’analytics engineer transforme les données en modèles métier. L’analyste explore et aide à décider. Le spécialiste statistique développe les modèles. Le steward porte définitions, qualité et usages. L’architecte assure la cohérence. Le propriétaire métier décide du sens.
Dans une petite organisation, une personne peut couvrir plusieurs rôles. Les responsabilités ne disparaissent pas. Un tableau RACI léger précise qui produit, approuve, consulte et intervient lors d’un incident.
La plateforme data ne doit pas devenir un service de tickets. Des templates, contrats et composants réutilisables permettent aux domaines de contribuer avec des garde-fous. La centralisation totale ralentit ; la décentralisation sans standards fragmente.
12. Feuille de route en cent jours
Jours 1 à 20 : choisir deux décisions. Inventorier les sources, définir le grain, nommer les propriétaires et mesurer le délai actuel. Construire le passeport.
Jours 21 à 40 : créer la chaîne minimale. Ingérer une source principale, conserver le brut, tester le schéma et produire un modèle métier. Établir une réconciliation manuelle.
Jours 41 à 60 : fiabiliser. Ajouter contrats, tests automatiques, lignée, alertes et procédure de reprise. Simuler une source en retard et un changement de colonne.
Jours 61 à 80 : ouvrir. Publier dans le catalogue, appliquer les droits, documenter les métriques et accompagner les premiers consommateurs. Mesurer les usages.
Jours 81 à 100 : étendre avec preuve. Ajouter une deuxième source, automatiser la réconciliation et comparer valeur, qualité et coût. Décider des produits suivants selon les décisions servies.
Le succès se mesure par la réduction du temps de réponse, des divergences et des reprises. Le nombre de tables n’est pas un indicateur de maturité.
13. Questions fréquentes
13.1. Faut-il centraliser toutes les données ?
Non. Centralisez ce qui sert une décision, une obligation ou une réutilisation démontrée. Certaines données restent mieux dans le système source et sont consultées à la demande.
13.2. Quel outil choisir pour commencer ?
Un service géré, SQL et un orchestrateur simple suffisent souvent. Le choix vient après l’inventaire des sources, volumes, délais, compétences et exigences de réversibilité.
13.3. Une base vectorielle fait-elle partie de la plateforme data ?
Oui lorsqu’elle sert la recherche ou l’IA, mais elle ne remplace pas le stockage source, le catalogue, les permissions ou les contrôles de qualité. Les embeddings sont des dérivés versionnés.
13.4. Comment savoir si une pipeline est fiable ?
Elle respecte son SLA, détecte les anomalies avant les consommateurs, peut être rejouée, explique la lignée et possèd'une procédure de reprise testée. Un historique sans incident peut simplement indiquer l’absence de surveillance.
13.5. Qui doit définir les métriques ?
Le métier décide du sens, avec la finance ou le domaine concerné. L’équipe data formalise, teste et publie. Une définition imposée uniquement par la technique manque souvent les exceptions opérationnelles.
14. Ce que le data engineering peut prouver en recette
La recette ne valide pas seulement qu’un pipeline « tourne ». Elle part de décisions connues, sélectionne des enregistrements de référence et suit chaque valeur depuis la source jusqu’au produit final. Pour une vente annulée puis remboursée partiellement, l’équipe doit retrouver le statut brut, la règle de transformation, le taux de change, la date de rattachement et le montant publié.
Le dossier contient trois jeux : cas nominaux, limites documentées et anomalies volontairement injectées. Les seuils portent sur exactitude, complétude, fraîcheur, réconciliation et délai de détection. Une erreur bloquante arrête la publication ; une dérive modérée peut isoler le lot et maintenir la dernière version fiable.
Avant l’ouverture à tous les consommateurs, le propriétaire métier signe la définition, l’équipe technique démontre la reprise après échec, la sécurité vérifie les accès et un analyste indépendant reproduit plusieurs indicateurs sans aide orale ; cette séquence, plus exigeante qu’une capture d’écran verte, établit que le système résiste à une source retardée, à un schéma incomplet, à un doublon et à une correction rétroactive tout en conservant l’historique nécessaire pour expliquer la décision.
La sortie de recette est courte : preuves, écarts acceptés, dette, responsable et date. Le passage en production n’efface jamais les limites connues.
Après trente jours, la revue confronte incidents, latence, réconciliations, coûts, usages et demandes de support aux hypothèses de conception, puis décide de renforcer un contrôle, simplifier une transformation, modifier le contrat de source ou retirer une table peu utilisée, afin que la plateforme apprenne de son exploitation au lieu d’accumuler silencieusement des pipelines dont la valeur n’est plus démontrée.
15. Ce que Logiks recommande
Commencez par deux décisions coûteuses ou lentes. Donnez à chaque produit de données un passeport, un propriétaire, un contrat et un SLA. Conservez le brut, testez chaque frontière et rendez les transformations explicables. L’objectif n’est pas de déplacer toutes les données : c’est de pouvoir faire confiance à celles qui déclenchent une action.
16. Sources principales
- Eurostat, Larger enterprises used more e-business apps in 2025 : https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20260520-1
- Eurostat, Digital economy and society statistics — enterprises, données 2025 : https://ec.europa.eu/eurostat/statistics-explained/SEPDF/cache/33473.pdf
- Google Research, Data Validation for Machine Learning : https://research.google/pubs/data-validation-for-machine-learning/
- Google Research, The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction : https://research.google/pubs/the-ml-test-score-a-rubric-for-ml-production-readiness-and-technical-debt-reduction/
- Commission européenne, Data Act explained : https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained
- Commission européenne, application du Data Act depuis le 12 septembre 2025 : https://digital-strategy.ec.europa.eu/en/news/eu-data-act-gives-users-control-over-data-connected-devices