Matrice : Traitements

Comment les données sont transformées et chargées : enchaînement, reprise, incrémental, contrôles, journal et performance.

≈ 13 min de lectureLecture

En bref

8 dimensions, niveaux 0 à 5, 112 critères.
Outil : état des lieux en choisissant « Traitements ».
Niveaux et critères : synthèse originale, références citées en bas de page.

Sur cette page

Vue d'ensemble
Conception des traitements
Fiabilité
1. Reprise et idempotence
Qualité et preuve
1. Contrôles de données dans les traitements
2. Journal, mesure et alertes
Performance et évolution
1. Chargement incrémental
2. Performance et ressources des traitements
Sources et vérification

Périmètre

Ce qui transforme et charge les données : enchaînement et planification, reprise après incident, chargement par différence, règles de transformation, contrôles, journal d'exécution, performance. La conservation des résultats relève du thème « Stockage », l'arrivée des données du thème « Alimentation », leur mise en forme pour les rapports du thème « Couche d'abstraction ».

8 dimensions, six niveaux (0 à 5) et 112 critères observables. Pour situer votre produit : ouvrir l'état des lieux de ce thème. Les règles de calcul sont ici.

Vue d'ensemble#

Chaque cellule est la signature du niveau pour la dimension.

Dimension	0 · Artisanal	1 · Local outillé	2 · Partagé	3 · Industrialisé	4 · Intégré et gouverné	5 · Autonome
Orchestration et ordonnancement	Traitements lancés à la main, dans un ordre connu d'une seule personne.	Ordre écrit et lancements planifiés isolément.	Un enchaînement unique, dépendances déclarées.	Priorités, fenêtres et calendriers maîtrisés.	Orchestration pilotée par les événements et les métadonnées.	Orchestration adaptative.
Écriture ensembliste et déterminisme	Transformations écrites ligne à ligne, résultat pouvant varier d'une exécution à l'autre.	Transformations isolées et identifiées.	Ensembles privilégiés.	Préparation avant frappe.	Déterminisme exploité et vérifié.	Mesure et garde-fous automatiques.
Règles de transformation et paramétrage	Règles enfouies dans du code et des valeurs en dur.	Règles listées.	Paramètres externalisés.	Paramètres gérés et hiérarchisés.	Règles documentées et testées.	Règles pilotées par les métiers.
Reprise et idempotence	Un échec laisse des données dans un état inconnu ; la reprise est manuelle et risquée.	Échecs connus.	Relance possible sans doublon.	Traitements idempotents, reprise à l'étape.	Reprise testée et périodes rejouables.	Reprise automatique et diagnostic assisté.
Chargement incrémental	Rechargement complet à chaque exécution.	Rechargements par périodes.	Détection des changements.	Incrémental complet.	Incrémental bout en bout.	Flux continu quand il est utile.
Contrôles de données dans les traitements	Aucun contrôle : on suppose que les données sont correctes.	Contrôles manuels.	Contrôles systématiques.	Contrôles déclarés et décision sur anomalie.	Contrôles de cohérence métier.	Contrôles adaptatifs.
Journal, mesure et alertes	Aucune trace des exécutions.	Traces dispersées.	Journal unique.	Journal exploitable.	Fraîcheur publiée, indicateurs de santé.	Détection proactive.
Performance et ressources des traitements	Durée subie : on découvre qu'un traitement est trop long quand il dépasse.	Durées connues.	Fenêtre tenue.	Parallélisme et ressources.	Évolution du volume anticipée.	Ressources élastiques.

Lien avec le modèle global

Dimensions du modèle global les plus concernées : Sources et flux de données, Qualité des données, Tests et corrections et Disponibilité et performance. Sur la manière d'écrire les traitements, voir la programmation ensembliste et la démarche.

Conception des traitements#

Orchestration et ordonnancement#

Qui décide de l'ordre des traitements, de leur déclenchement et de leur dépendance ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Traitements lancés à la main, dans un ordre connu d'une seule personne.	Point de départ : aucun critère.
1 · Local outillé	Ordre écrit et lancements planifiés isolément.	L'ordre des traitements est écrit quelque part. Les traitements récurrents sont déclenchés par un planificateur.
2 · Partagé	Un enchaînement unique, dépendances déclarées.	Un enchaînement unique exécute tous les traitements du produit. Les dépendances entre traitements sont déclarées, pas supposées par l'heure de lancement. Un traitement ne démarre que si ceux dont il dépend ont réussi.
3 · Industrialisé	Priorités, fenêtres et calendriers maîtrisés.	Les traitements sont ordonnés par priorité (par exemple : alimentation, dimensions, faits, publication). Les fenêtres d'exécution et les calendriers (jours ouvrés, clôtures) sont paramétrés. Le chemin le plus long de l'enchaînement est connu.
4 · Intégré et gouverné	Orchestration pilotée par les événements et les métadonnées.	Le déclenchement peut dépendre d'un événement (arrivée d'un fichier, fin d'un traitement amont). L'enchaînement est décrit dans des métadonnées, et non dans du code répété. On peut simuler un enchaînement sans l'exécuter, pour vérifier l'ordre et les dépendances.
5 · Autonome	Orchestration adaptative.	L'enchaînement se réordonne ou se parallélise automatiquement selon les durées observées. Les traitements inutiles (aucune donnée nouvelle en amont) sont évités automatiquement. Une dérive de durée ou de séquence est détectée et signalée avant l'incident.

Effet sur l'utilisateur

Les données arrivent à l'heure annoncée, dans le bon ordre, sans que personne n'ait à lancer quoi que ce soit.

Écriture ensembliste et déterminisme#

Les transformations sont-elles écrites pour traiter des ensembles, avec un résultat qui ne dépend que des données ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Transformations écrites ligne à ligne, résultat pouvant varier d'une exécution à l'autre.	Point de départ : aucun critère.
1 · Local outillé	Transformations isolées et identifiées.	Chaque transformation est un objet identifié (procédure, requête nommée, étape). Les boucles ligne à ligne sont repérées.
2 · Partagé	Ensembles privilégiés.	Les transformations courantes sont écrites en requêtes sur des ensembles plutôt qu'en boucles. Les dates de calcul sont passées en paramètre et non lues à l'horloge dans le traitement. Le résultat d'une transformation ne dépend pas de l'ordre des lignes en entrée.
3 · Industrialisé	Préparation avant frappe.	Le modèle (tables, index, périmètres) est préparé avant le calcul, et non pendant. Chaque traitement se compose de peu de grosses requêtes plutôt que de beaucoup de petites. Les fonctions utilisées dans les calculs sont déterministes, ou leur usage est justifié.
4 · Intégré et gouverné	Déterminisme exploité et vérifié.	Le déterminisme est déclaré et exploité (colonnes calculées, vues indexées, code généré avec valeurs en dur). Un test relance un traitement sur les mêmes données et compare les résultats. Aucun bloc non déterministe n'est appelé depuis une boucle.
5 · Autonome	Mesure et garde-fous automatiques.	Le coût de chaque traitement (lectures, instructions) est mesuré et suivi dans le temps. Une revue ou un contrôle automatique détecte les boucles et les fonctions coûteuses introduites par un changement. Les écarts de résultat entre deux exécutions identiques déclenchent une alerte.

Effet sur l'utilisateur

Le même jeu de données donne toujours le même résultat, et le temps de traitement croît peu avec le volume.

Règles de transformation et paramétrage#

Où vivent les règles métier et les paramètres, et peut-on les expliquer et les changer sans réécrire ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Règles enfouies dans du code et des valeurs en dur.	Point de départ : aucun critère.
1 · Local outillé	Règles listées.	Les règles de transformation principales sont décrites par écrit. Les valeurs en dur sont repérées.
2 · Partagé	Paramètres externalisés.	Les valeurs qui varient (seuils, périmètres, listes de codes) sont stockées hors du code. Chaque règle a un nom et une description lisible par un métier. Le code des traitements est versionné.
3 · Industrialisé	Paramètres gérés et hiérarchisés.	Les paramètres sont stockés en base avec leur description et leur valeur par défaut. Une valeur spécifique à un client ou à un projet remplace le standard sans modifier le code. La modification d'un paramètre est tracée : qui, quand, ancienne et nouvelle valeur.
4 · Intégré et gouverné	Règles documentées et testées.	La documentation des règles est produite à partir du code et des métadonnées, pas rédigée à part. Chaque règle importante a un jeu de cas de test avec résultat attendu. L'impact d'un changement de règle (tables et rapports touchés) est connu avant livraison.
5 · Autonome	Règles pilotées par les métiers.	Les métiers peuvent proposer ou valider un changement de règle dans un circuit défini, sans passer par le code. Les règles de plusieurs produits ou clients sont comparables et réutilisables. Une règle jamais utilisée ou contradictoire est détectée automatiquement.

Effet sur l'utilisateur

Une règle métier se lit, se discute et se change à un seul endroit, avec une trace de qui l'a modifiée.

Fiabilité#

Reprise et idempotence#

Que se passe-t-il quand un traitement échoue ou est relancé ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Un échec laisse des données dans un état inconnu ; la reprise est manuelle et risquée.	Point de départ : aucun critère.
1 · Local outillé	Échecs connus.	Un échec de traitement est constaté (message, courriel, journal). Une procédure de relance manuelle est écrite.
2 · Partagé	Relance possible sans doublon.	Relancer un traitement ne crée pas de doublon. Un échec ne laisse pas de résultat partiel visible des rapports. On sait à quelle étape un enchaînement s'est arrêté.
3 · Industrialisé	Traitements idempotents, reprise à l'étape.	Chaque traitement donne le même résultat à chaque exécution sur les mêmes données (idempotence). La reprise d'un enchaînement redémarre à l'étape en échec, sans tout rejouer. Les tentatives automatiques sont bornées et espacées avant de déclarer un échec.
4 · Intégré et gouverné	Reprise testée et périodes rejouables.	Une période passée peut être recalculée à la demande, sans effet sur les autres périodes. La reprise après échec est testée à intervalle régulier (échec provoqué en environnement de test). Les données sont publiées par bascule atomique : les rapports voient l'ancien ou le nouveau jeu, jamais un mélange.
5 · Autonome	Reprise automatique et diagnostic assisté.	Les échecs transitoires sont repris automatiquement, sans intervention. Pour chaque échec, une cause probable et une action sont proposées automatiquement. Le temps moyen de reprise est suivi et il décroît.

Effet sur l'utilisateur

Un incident coûte une relance, pas une intervention manuelle ni un doute sur l'état des données.

Qualité et preuve#

Contrôles de données dans les traitements#

Les traitements vérifient-ils leurs entrées et leurs sorties, et que font-ils d'une anomalie ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Aucun contrôle : on suppose que les données sont correctes.	Point de départ : aucun critère.
1 · Local outillé	Contrôles manuels.	Des contrôles sont faits à la main après certains chargements. Les volumes chargés sont comparés à ceux de la source.
2 · Partagé	Contrôles systématiques.	Chaque chargement vérifie des règles simples : unicité des clés, valeurs obligatoires, valeurs permises. Les écarts de volume sont chiffrés après chaque chargement. Une anomalie est consignée avec la ligne concernée.
3 · Industrialisé	Contrôles déclarés et décision sur anomalie.	Les contrôles sont déclarés dans des définitions réutilisables, pas écrits au cas par cas. Chaque contrôle précise s'il bloque la publication, s'il met la ligne en quarantaine ou s'il alerte seulement. Les lignes rejetées sont conservées et consultables.
4 · Intégré et gouverné	Contrôles de cohérence métier.	Des contrôles de cohérence entre sources et entre périodes existent (totaux, rapprochements, tendances). Le taux d'anomalies est suivi dans le temps, par source et par contrôle. Un contrôle défaillant ou obsolète est repéré et revu.
5 · Autonome	Contrôles adaptatifs.	Des seuils d'alerte se calculent à partir de l'historique observé. Une anomalie nouvelle déclenche la proposition d'un nouveau contrôle. Le résultat des contrôles est visible des utilisateurs avec les rapports.

Effet sur l'utilisateur

Un chiffre faux est arrêté ou signalé avant publication, et non découvert par un utilisateur.

Journal, mesure et alertes#

Peut-on dire ce qui s'est exécuté, combien de temps, avec quel résultat, et qui est prévenu ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Aucune trace des exécutions.	Point de départ : aucun critère.
1 · Local outillé	Traces dispersées.	Chaque exécution laisse une trace (fichier, message) consultable. Les erreurs sont lisibles par une personne autre que l'auteur du traitement.
2 · Partagé	Journal unique.	Un journal central consigne début, fin, durée et résultat de chaque traitement. Les messages d'erreur sont enregistrés complets, avec le traitement concerné. Les échecs déclenchent une alerte à une personne ou une boîte désignée.
3 · Industrialisé	Journal exploitable.	Le journal enregistre le nombre de lignes lues, écrites, rejetées par étape. L'historique des durées permet de repérer les traitements qui dérivent. Une alerte distingue les incidents bloquants des simples avertissements.
4 · Intégré et gouverné	Fraîcheur publiée, indicateurs de santé.	La date de dernière mise à jour est visible des utilisateurs pour chaque jeu de données. Un tableau de bord suit la santé des traitements (réussite, durée, retard). Les alertes ont un responsable et un délai de prise en charge.
5 · Autonome	Détection proactive.	Un retard probable est annoncé avant la fin du traitement, d'après les durées passées. Les utilisateurs concernés sont prévenus automatiquement d'un retard de données. Les causes d'incident sont classées et leur fréquence suivie pour décider des améliorations.

Effet sur l'utilisateur

On sait avant les utilisateurs si les données sont à jour, et on sait pourquoi quand elles ne le sont pas.

Performance et évolution#

Chargement incrémental#

Traite-t-on seulement ce qui a changé, ou tout à chaque fois ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Rechargement complet à chaque exécution.	Point de départ : aucun critère.
1 · Local outillé	Rechargements par périodes.	Les gros jeux de données sont rechargés par période plutôt qu'en totalité. Le périmètre rechargé est choisi à la main.
2 · Partagé	Détection des changements.	Chaque source expose un moyen de repérer ce qui a changé (date de modification, version, journal). Les traitements chargent les lignes nouvelles ou modifiées. Un rechargement complet reste possible pour vérification ou reprise.
3 · Industrialisé	Incrémental complet.	Les suppressions de la source sont détectées et répercutées. Les données arrivant en retard ou dans le désordre sont traitées correctement. Un contrôle compare régulièrement le résultat incrémental à un rechargement complet.
4 · Intégré et gouverné	Incrémental bout en bout.	Chaque couche (brute, validée, prête à l'emploi) se met à jour de façon incrémentale. Les agrégats se recalculent seulement pour les périodes touchées. La fréquence de mise à jour est choisie selon le besoin métier, couche par couche.
5 · Autonome	Flux continu quand il est utile.	Les données qui le justifient arrivent en flux continu ou quasi continu. La fréquence s'adapte automatiquement à la disponibilité des données et à la charge. Le coût et le délai de chaque mode (continu, planifié) sont comparés pour décider.

Effet sur l'utilisateur

Les données sont à jour plus souvent, pour moins de ressources, même quand l'historique grossit.

Performance et ressources des traitements#

Les traitements tiennent-ils leur fenêtre, et savent-ils tirer parti des ressources disponibles ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Durée subie : on découvre qu'un traitement est trop long quand il dépasse.	Point de départ : aucun critère.
1 · Local outillé	Durées connues.	La durée des traitements principaux est relevée. Le traitement le plus lent est identifié.
2 · Partagé	Fenêtre tenue.	Une fenêtre d'exécution cible est fixée pour chaque enchaînement. Les traitements les plus coûteux ont été optimisés au moins une fois. Les durées sont comparées d'une exécution à l'autre.
3 · Industrialisé	Parallélisme et ressources.	Les traitements indépendants s'exécutent en parallèle. Les ressources de calcul sont dimensionnées d'après les mesures, et non au jugé. Une mesure reproductible (lectures, instructions) complète la durée, qui varie selon la charge.
4 · Intégré et gouverné	Évolution du volume anticipée.	Des essais sur un volume plus grand que l'actuel sont réalisés avant une montée en charge. La durée d'un traitement est suivie en fonction du volume traité. Un changement qui dégrade la durée est détecté avant mise en production.
5 · Autonome	Ressources élastiques.	La capacité de calcul s'ajuste automatiquement à la charge de l'enchaînement. Les ressources sont libérées dès la fin des traitements. Les arbitrages entre durée et coût sont revus à partir de mesures régulières.

Effet sur l'utilisateur

Les données sont prêtes quand les utilisateurs arrivent, et une croissance du volume ne remet pas en cause la fenêtre.

Origine des critères

Les dimensions s'inspirent des références citées ci-dessous ; les niveaux et les critères sont une synthèse originale, pas une reprise d'un référentiel. Ils sont proposés pour être discutés et adaptés, pas pour faire foi.

Sources et vérification#

Kimball Group — ETL Architecture's 34 Subsystems — quatre familles de sous-systèmes (extraire, transformer, charger, gérer) ; la gestion couvre audit, reprise, planification et alertes
Apache Airflow — Best Practices — tâches idempotentes (même résultat à chaque réexécution), niveaux de test d'un enchaînement, éviter le code coûteux au niveau supérieur
dbt — Add data tests to your DAG — un test de données est une requête qui renvoie les lignes en défaut ; quatre tests génériques : unique, not_null, accepted_values, relationships
Microsoft Learn — What is the medallion lakehouse architecture? (Azure Databricks) — validation et dédoublonnage dans la couche validée, lectures incrémentales, compromis entre coût et latence selon la fréquence d'ingestion
DAMA International — DAMA-DMBOK2 — le domaine « Data Integration and Interoperability » ; référentiel payant, donc non relu ligne à ligne