Ingestion et fraîcheur — comment la donnée entre, et comment elle vieillit

Vous êtes ici : Comprendre — les fondations : le premier maillon de la chaîne de données. Comment les données externes entrent dans la plateforme, et ce qui décide de leur fraîcheur. Lecture 9 min. Audience : devs, analystes, auditeurs. Date : 2026-08-11 | Version : 1.0 — créée par la refonte de l’architecture d’information

Le principe central — on ne recopie pas tout, chaque nuit

Recharger l’intégralité d’un système source chaque nuit serait simple, lent et coûteux. La plateforme fait donc de l’extraction incrémentale : elle ne demande que ce qui a changé depuis la dernière fois.

Tout repose alors sur une seule information par table : jusqu’où on était rendu. Ce curseur — le point de reprise — est le point le plus critique du pipeline. Quand il fonctionne, personne ne le voit. Quand il se bloque, rien ne casse : c’est précisément ce qui le rend dangereux.

TL;DR

Question	Réponse	Détail
D’où viennent les données ?	D’un ERP interne en lecture seule, et de sources complémentaires en cours d’intégration	§ Les sources
Tout est rechargé chaque nuit ?	Non — extraction incrémentale bornée par un point de reprise par table	§ Le point de reprise
Que se passe-t-il si ce curseur se bloque ?	Le chargement reste vert et la fraîcheur peut même sembler bonne — le coût est ailleurs	§ Le mode de panne
Comment on le sait, maintenant ?	Une garde vérifie le contrat au démarrage, un détecteur observe la signature du défaut	§ Les trois défenses
Et les corrections saisies en retard ?	Une fenêtre de rattrapage relit volontairement un passé récent	§ Le rattrapage
Deux chargements peuvent-ils se percuter ?	Non — verrou par source, avec récupération des verrous orphelins	§ Le verrou

1 · Les sources

Les données de la plateforme viennent de systèmes externes qu’elle ne contrôle pas. Le système principal aujourd’hui est l’ERP interne ; d’autres sources (télématique, carburant, location, outils de gestion) sont intégrées progressivement selon le même patron.

Trois invariants, quelle que soit la source :

• Lecture seule — le compte utilisé vers un système source n’a que le droit de lire. La plateforme ne modifie jamais un système amont.
• Colonnes explicites — un extracteur déclare les colonnes qu’il prend. Jamais de « prends tout » : une colonne ajoutée à la source ne peut pas entrer par surprise, et les champs sensibles ne sont pas extraits du tout (voir Cycle de vie).
• Copie fidèle d’abord — la première couche reproduit la source telle quelle, dans sa langue et ses types. La traduction et le nettoyage viennent après, dans une couche séparée (voir Aiguillage des couches).

2 · Le point de reprise — le curseur qui décide de tout

Pour chaque table suivie, un registre de contrôle conserve jusqu’où l’extraction était rendue. Au chargement suivant, la plateforme ne redemande que ce qui vient après ce curseur.

Le cycle nominal, pour une table :

1. Lire le point de reprise courant dans le registre de contrôle.
2. Extraire de la source ce qui se situe au-delà de ce point, moins une fenêtre de rattrapage (§ 5).
3. Écrire dans la couche de copie fidèle.
4. Faire avancer le point de reprise à la plus grande valeur plausible rencontrée.
5. Journaliser le tout (voir Lire un journal ETL).

Pourquoi « plausible » et pas simplement « la plus grande »

Les systèmes sources contiennent des valeurs aberrantes — des dates saisies à la main, parfois situées des siècles dans le futur. Faire avancer un curseur jusqu’à une telle valeur le rendrait définitivement inatteignable : plus aucune ligne réelle ne serait jamais « après » lui, et la table cesserait de se charger pour de bon.

La plateforme filtre donc les valeurs avant de faire avancer le curseur : une valeur hors d’une plage crédible est rejetée. Cette garde est indispensable — et c’est en la rendant trop stricte qu’on crée le défaut décrit ci-dessous.

3 · Le mode de panne silencieux

Le filtre de plausibilité doit décider si une valeur est crédible. Il a d’abord été écrit pour des colonnes stockées sous forme de texte — la vérification portait alors sur la forme de la chaîne (longueur, caractères attendus).

Appliqué tel quel à une colonne réellement temporelle, ce contrôle de forme devient impossible à satisfaire : la valeur, convertie implicitement en texte, ne ressemble pas à ce que la garde attend. Aucune valeur n’est jugée plausible, donc le curseur ne peut plus avancer.

Ce qui rend ce défaut particulier :

• Le chargement reste vert de bout en bout. Les lignes sont extraites, écrites, comptées. Rien n’échoue. La seule chose qui n’arrive pas, c’est l’avancement d’un curseur — et rien ne surveillait cet avancement.
• Le type de la colonne prédit exactement quelles tables gèlent. Les tables dont le curseur pointe une colonne texte fonctionnaient ; celles pointant une colonne temporelle gelaient. Sans exception.

Le paradoxe — un curseur bloqué peut *préserver* la fraîcheur

L’intuition dit : curseur bloqué, donc données périmées. C’est l’inverse qui se produit.

Le curseur définit le plancher de la zone rechargée. S’il ne bouge plus, ce plancher reste fixe pendant que le présent avance : la zone rechargée grandit d’un jour chaque nuit et la table se recharge intégralement sur toute sa queue récente. Les données restent donc à jour.

Les vrais coûts sont ailleurs, et ils sont sérieux : un volume de rechargement qui croît sans borne à chaque nuit, et une fenêtre de rattrapage définitivement gelée sous le plancher — les corrections portant sur un passé antérieur ne seront plus jamais reprises.

La leçon vaut au-delà de ce cas : un indicateur vert et des données fraîches ne prouvent pas que le mécanisme fonctionne.

4 · Les trois défenses posées

Le correctif ne s’est pas limité à réparer le filtre. Trois défenses indépendantes ont été posées, parce que la panne venait moins du calcul que du silence autour de lui.

Défense	Ce qu’elle fait	Ce qu’elle empêche de reproduire
Filtre conscient du type	Le contrôle de plausibilité s’adapte au type réel de la colonne : encadrement de plage sur une colonne temporelle, contrôle de forme sur une colonne texte	Le défaut lui-même
Contrat vérifié au démarrage	Le type réel de la colonne de reprise est confronté, à chaque extraction, à ce que le moteur sait traiter — à partir de métadonnées déjà lues, sans requête supplémentaire. Type inattendu : échec bruyant	Le même défaut sur une autre colonne, un autre jour
Détecteur de signature	Un avertissement est émis dès qu’une zone rechargée contient des lignes mais qu’aucune valeur n’en est retenue — la signature exacte du curseur bloqué	Le silence : le défaut devient visible dès le premier chargement concerné

Pourquoi un détecteur de signature plutôt qu'un compteur de jours

Surveiller « le curseur n’a pas bougé depuis N jours » suppose de mémoriser la date du dernier avancement — donc une colonne de plus, une migration, un état à maintenir.

Observer la signature du défaut (« il y avait des lignes, aucune n’a été retenue ») ne demande aucun état : l’information est entièrement disponible pendant le chargement lui-même, et l’alerte tombe dès la première exécution concernée au lieu d’attendre que le retard devienne visible. Le filet temporel reste possible ; il n’était simplement pas le premier à poser.

5 · Le rattrapage — pourquoi on relit le passé

Une extraction strictement « après le curseur » manquerait une catégorie entière de changements : les saisies rétroactives. Un pointage corrigé la semaine suivante porte une date passée — il est donc antérieur au curseur, et ne serait jamais repris.

La plateforme relit donc volontairement une fenêtre de rattrapage avant le curseur. Le dimensionnement de cette fenêtre est un arbitrage explicite :

• Trop courte : les corrections saisies au-delà du délai sont perdues, silencieusement — un second défaut, indépendant du précédent, et tout aussi discret.
• Trop longue : on repaye chaque nuit le rechargement d’un passé qui ne bouge plus.

La valeur par défaut est désormais explicite dans le code. Auparavant, une configuration qui omettait ce réglage héritait d’une fenêtre nulle — donc d’une absence totale de rattrapage, sans que rien ne le signale.

6 · Le verrou et la reprise

• Un verrou par source empêche deux chargements de la même source de se marcher dessus, avec récupération automatique des verrous laissés par un processus disparu.
• Les écritures sont rejouables : une table se recharge par remplacement de sa zone active, pas par accumulation. Relancer un chargement interrompu est sans danger.
• Une remise à zéro reste possible : supprimer l’entrée de contrôle d’une table déclenche un rechargement complet au passage suivant. C’est le geste de remédiation quand un curseur a laissé un trou dans le passé — un curseur ne redescend jamais de lui-même.

L'ordre compte — réparer avant de réinitialiser

Réinitialiser un curseur avant d’avoir corrigé la cause ne répare rien : le chargement suivant reproduit le blocage et efface le geste. La remise à zéro est une étape de rattrapage après correctif, jamais un correctif déguisé.

Pour aller plus loin

• Qualité des données — ce qui est vérifié une fois la donnée entrée, et le contrôle qui s’auto-étend.
• Lire un journal ETL — suivre une exécution et diagnostiquer un chargement.
• Aiguillage des couches — où va la donnée après la copie fidèle.
• Cycle de vie des données — la vue d’ensemble, de l’ingestion à la destruction.
• Architecture de données — la carte des schémas et l’isolation par compagnie.