Lire un journal ETL — suivre et diagnostiquer un chargement

Vous êtes ici : Guides pratiques — vous regardez une exécution de chargement et vous voulez savoir ce qu’elle raconte. Lire un journal d’exécution, distinguer une exécution de ses sous-étapes, et savoir ce que la durée affichée vaut. Lecture 6 min. Audience : administrateurs, devs, analystes. Date : 2026-08-11 | Version : 1.0 — créée par la refonte de l’architecture d’information

Le principe central — une exécution, plusieurs étapes, un seul niveau à lire d'abord

Un chargement complet est une exécution (le run) qui contient plusieurs sous-étapes (une par table ou par transformation). Les deux s’écrivent dans le même journal.

Tant que les deux niveaux se lisaient à plat, l’affichage pouvait présenter une sous-étape courte comme s’il s’agissait de l’exécution entière — et annoncer « terminé en quelques secondes » pendant qu’une exécution de plusieurs minutes était toujours en cours. Le journal est désormais hiérarchique : on lit les exécutions, on déplie les étapes.

Ce que vous regardez

Niveau	Ce que c’est	Où il apparaît
Exécution (run)	Un déclenchement complet — manuel depuis la console, ou programmé	Une ligne dans la liste des journaux
Sous-étape	Une table extraite, une transformation exécutée	Au dépliage de son exécution

Chaque exécution affiche le nombre de sous-étapes qu’elle contient et combien sont en erreur. Une exécution qui contient des erreurs le montre sans qu’on ait besoin de la déplier : l’information la plus importante ne se cache jamais derrière un clic.

Les statuts

Statut	Ce qu’il veut dire	Ce qu’il faut en faire
ok	L’étape a terminé dans ses seuils	Rien
partial	L’étape a terminé, mais hors d’un seuil attendu	Ne pas ignorer — un partial qui se répète est un incident, pas du bruit
error	L’étape a échoué	Déplier l’exécution : l’étape fautive est nommée, avec son message

Un `partial` répété est un incident

Le piège classique est de traiter partial comme une variante d’ok. Un partial isolé peut être une variation d’activité ; le même partial, plusieurs exécutions de suite, décrit un état stable et anormal — c’est-à-dire une panne qui a trouvé son équilibre. Les règles de triage sont écrites dans les procédures internes d’exploitation.

La durée : une estimation, ou rien

L’estimation de durée d’une exécution en cours suit une règle explicite : elle est publiée seulement si elle est défendable. Sinon, l’interface affiche l’absence d’estimation et la raison.

Situation	Ce qui est affiché
Assez d’exécutions comparables, durées homogènes	Une estimation, fondée sur la médiane des exécutions récentes de même niveau
Trop peu d’exécutions comparables	Pas d’estimation — données insuffisantes
Durées trop dispersées	Pas d’estimation — trop dispersées

Comparer ce qui est comparable

L’estimation ne compare que des exécutions racines entre elles. C’était la source d’une erreur d’affichage tenace : les sous-étapes héritent des attributs de leur exécution parente et s’écrivent après elle — un classement par date les faisait donc systématiquement gagner. L’interface estimait alors la durée d’une exécution complète à partir de la durée de trois sous-étapes, et sous-estimait d’un ordre de grandeur.

Le correctif n’est pas un ajustement de seuil : c’est la distinction de niveau, posée dans la donnée elle-même.

Pourquoi il n’y a pas de barre de progression

C’est un choix, pas un manque.

Une barre de progression suppose qu’on connaisse l’avancement réel du travail. Le moteur de chargement n’émet pas ce signal : ce qu’on sait, c’est le temps écoulé et une estimation de la durée totale. Une barre construite sur écoulé / estimé n’affiche donc pas une position — elle affiche une extrapolation présentée comme une mesure.

Le résultat est pire qu’une absence d’information : la barre atteint 100 % et continue, ou reste bloquée, et l’utilisateur perd confiance dans tout le reste de l’écran. Un indicateur de phases construit sur le même calcul a le même défaut, simplement découpé en segments — il a été retiré avec la barre.

La règle générale

Une estimation absente vaut mieux qu’une estimation fausse. Une interface a le droit de dire « je ne sais pas » ; elle n’a pas le droit d’inventer une précision qu’elle n’a pas. Le jour où le moteur émettra un avancement réel, une barre deviendra légitime — pas avant.

Diagnostiquer, dans l’ordre

1. Repérer l’exécution, pas une étape. La liste ne montre que les exécutions ; le compteur d’erreurs vous dit s’il faut aller plus loin.
2. Déplier pour voir les sous-étapes. L’étape en échec est nommée — un échec porte le nom de l’étape fautive, pas une étiquette générique.
3. Croiser avec la fraîcheur : une exécution verte ne garantit pas que les données avancent. Le cas le plus instructif est décrit dans Ingestion et fraîcheur — un chargement parfaitement vert dont le curseur de reprise ne bouge plus.
4. Croiser avec les assertions de qualité : elles répondent à une autre question que le journal. Le journal dit l’exécution s’est-elle bien passée ; les assertions disent le résultat est-il utilisable. Voir Qualité des données.

Le journal ne suffit jamais seul

Les trois signaux se recoupent et aucun ne remplace les autres : exécution (le journal), fraîcheur (le curseur de reprise avance-t-il), exactitude (les assertions). Le mode de panne le plus coûteux observé sur la plateforme était vert sur le premier et invisible aux deux autres tant qu’ils n’existaient pas.

Pour aller plus loin

• Ingestion et fraîcheur — ce que le journal exécute, et ce qu’il ne mesure pas.
• Qualité des données — la vérification du résultat, complémentaire du journal.
• Compute et exécution — où tournent ces traitements.
• Cycle de vie des données — la place de l’exécution dans la gouvernance d’ensemble.