ETL ou ELT : choisir où transformer vos données

Ce que l’ordre des lettres change réellement

ETL signifie Extract, Transform, Load. Une étape intermédiaire prépare les données avant leur arrivée dans la cible. ELT signifie Extract, Load, Transform : le moteur cible participe aux transformations après chargement. Dans les deux cas, il faut encore définir les règles métier et contrôler les résultats.

Les plateformes analytiques cloud rendent l’ELT intéressant dans certains scénarios, mais cela ne dispense pas de filtrer ou de protéger des données avant leur entrée. Une validation de schéma ou une restriction de périmètre peut rester nécessaire avant le chargement.

Référence technique : AWS : comprendre l’ETL

Un exemple : intégrer des ventes dans un entrepôt

Dans un flux fictif, les ventes arrivent sous forme de fichiers. Une approche ETL peut nettoyer les types, traiter les codes et produire directement une table cible préparée. Une approche ELT peut conserver un lot reçu dans une zone contrôlée, puis construire des tables de travail et des tables métier dans l’entrepôt.

Dans les deux scénarios, précisez ce qui se passe si le même fichier arrive deux fois, si une colonne manque ou si un avoir apparaît en retard. Ces situations déterminent la fiabilité du flux davantage que le choix du vocabulaire. Le consommateur doit savoir si le lot est complet et à jour.

Comparer les approches avec une grille simple

Il n’existe pas une réponse universelle pour toute l’entreprise. Une source volumineuse et un fichier de référence peu fréquent peuvent suivre des chemins différents tout en respectant les mêmes règles d’exploitation.

Concevoir le rejeu sans créer de doublons

Un traitement doit reconnaître les données déjà reçues et celles qui corrigent un état précédent. Définissez une clé métier, un identifiant de lot et la politique de mise à jour. Certaines données doivent être ajoutées, d’autres remplacées ou historisées. Le choix dépend du sens métier.

Testez le même lot deux fois et comparez le résultat. Ajoutez ensuite une correction tardive. Le pipeline ne doit pas doubler les ventes simplement parce qu’un incident a exigé une relance. Notez les conditions dans lesquelles le rejeu est possible et les étapes qui demandent une validation.

La zone brute n’est pas une zone sans règles

Conserver les entrées peut faciliter une reconstruction, mais ce stockage doit avoir des droits, une durée de conservation et un responsable. Un fichier brut peut contenir davantage d’informations que le produit de données final. Le fait qu’il ne soit pas encore utilisé dans un rapport ne le rend pas inoffensif.

Décrivez les contrôles de complétude et les conditions de promotion vers les tables utilisées par les analystes. Une donnée reçue n’est pas encore une donnée validée. Si un lot échoue, le rapport devrait signaler son état au lieu de mélanger silencieusement données anciennes et partielles.

Ce que vous devez demander dans un premier pipeline

Notre page Data Engineering présente le périmètre technique à cadrer. Le guide GCP illustre les composants cloud et la page gouvernance Data aide à attribuer les responsabilités.

1. Un schéma d’entrée et une politique de changement.
2. Des règles de transformation lisibles et versionnées.
3. Un suivi des lots, des erreurs et de la fraîcheur.
4. Une démonstration de rejeu et de correction tardive.
5. Un responsable de l’exploitation et une procédure de reprise.