Transformer vos données avant et après ingestion

L'une des décisions d'architecture les plus structurantes d'un projet Data Cloud est de choisir où transformer la donnée : avant qu'elle n'entre dans la plateforme (ETL classique), ou après, une fois dans le Data Lake (approche ELT native à Data Cloud). Chaque choix a des implications concrètes sur la maintenabilité, la performance et la gouvernance du pipeline.

ETL vs ELT : deux philosophies

L'approche ETL (Extract, Transform, Load) transforme la donnée avant son chargement, typiquement via un outil externe (MuleSoft/DataWeave, Informatica, un script Python) qui produit un fichier ou un payload déjà conforme au schéma cible. L'approche ELT (Extract, Load, Transform) charge la donnée brute telle quelle dans un DLO, puis applique les transformations à l'intérieur de Data Cloud via les Data Transforms et les Calculated Insights.

• L'ETL est préférable quand la transformation dépend de règles métier complexes partagées entre plusieurs systèmes cibles (pas seulement Data Cloud).
• L'ELT est préférable quand on veut conserver une trace brute de la donnée source (auditabilité) et itérer rapidement sur les règles de transformation sans redéployer de pipeline externe.

Transformations en amont (pré-ingestion)

Certaines transformations doivent impérativement se faire avant l'ingestion, car Data Cloud ne peut pas les réaliser efficacement en aval :

1. Normalisation de format : conversion d'un export EDI, XML ou d'un format propriétaire vers du JSON/CSV exploitable par un connecteur.
2. Filtrage volumétrique : exclure des enregistrements non pertinents en amont (test, environnement de dev, données archivées) pour éviter de saturer le DLO avec du bruit.
3. Chiffrement/masquage de données sensibles non destinées à transiter dans Data Cloud, avant même l'export.
4. Jointures multi-systèmes nécessitant un accès à des sources que Data Cloud ne peut pas interroger directement.

Transformations natives Data Cloud : Data Transforms

Une fois la donnée dans un DLO, Data Cloud propose une interface de Data Transforms (accessible dans Data Cloud > Data Transforms) permettant de créer des pipelines de transformation SQL-like sans quitter la plateforme :

SELECT
  customer_id,
  UPPER(TRIM(email)) AS email_normalized,
  CASE
    WHEN country_code IN ('FR','BE','LU') THEN 'EMEA-FR'
    ELSE 'OTHER'
  END AS region_segment
FROM raw_customer_dlo
WHERE email IS NOT NULL

Deux modes existent : batch transform (planifiable, pour des recalculs périodiques sur de gros volumes) et streaming transform (déclenché en continu sur les nouvelles données entrantes, pour des besoins de fraîcheur élevée). Le résultat d'un Data Transform peut alimenter un nouveau DLO ou directement un DMO via le mapping standard.

Calculated Insights : la transformation orientée métrique

Pour des calculs analytiques (LTV client, score de récence-fréquence, agrégats par segment), les Calculated Insights offrent un moteur dédié, distinct des Data Transforms, optimisé pour produire des métriques réutilisables dans les segments et l'activation :

• Définition via une interface SQL simplifiée, avec dimensions et mesures explicites.
• Recalcul automatique planifiable, découplé du cycle d'ingestion source.
• Consommation directe dans Segment Builder sans étape de transformation supplémentaire.

Où placer la validation et le nettoyage

Le nettoyage de données (dédoublonnage, normalisation d'adresses, validation de format email) peut se faire à plusieurs niveaux, et le bon choix dépend du coût de l'erreur :

• En amont si l'erreur doit bloquer l'ingestion entière (schéma invalide, fichier corrompu) — mieux vaut échouer tôt et explicitement.
• En aval, via Data Transforms si la règle de nettoyage est susceptible d'évoluer fréquemment (seuils métier, règles de segmentation) — modifier une requête SQL dans Data Cloud est plus rapide que redéployer un pipeline ETL externe.

Règle générale : gardez toujours une copie brute et non transformée de la donnée source dans un DLO dédié. Si une règle de transformation s'avère erronée après coup, vous pourrez rejouer les Data Transforms sans devoir réingérer depuis le système source.

Impact sur la gouvernance et la traçabilité

Le choix ETL vs ELT a aussi une dimension gouvernance : transformer en amont dilue la traçabilité (la donnée arrivée dans Data Cloud n'est plus identique à la source, sans lien explicite conservé), tandis que transformer en aval dans Data Cloud conserve une chaîne de lineage visible nativement via les Data Transforms, ce qui facilite les audits de conformité (RGPD notamment) sur l'origine et les traitements appliqués à chaque donnée personnelle.

En pratique, la plupart des architectures matures combinent les deux : un ETL léger en amont pour la normalisation de format et le filtrage grossier, puis des Data Transforms et Calculated Insights dans Data Cloud pour toute la logique métier susceptible d'évoluer.