Contrôle qualité des données : détecter les erreurs d'ingestion

Un pipeline d'ingestion techniquement fonctionnel peut malgré tout injecter en continu des données de mauvaise qualité dans Data Cloud : doublons, valeurs incohérentes, champs mal mappés. Ces erreurs sont souvent plus coûteuses qu'une panne franche, car elles passent inaperçues jusqu'à ce qu'une équipe métier constate des anomalies dans un segment ou une activation. Voici les mécanismes à mettre en place pour détecter ces problèmes le plus tôt possible dans la chaîne.

Catégoriser les types d'erreurs d'ingestion

Avant de construire des contrôles, il faut distinguer les familles d'erreurs, car elles n'ont ni les mêmes causes ni les mêmes remèdes :

• Erreurs de structure : type de champ incorrect, colonne manquante, encodage cassé — généralement détectées et rejetées automatiquement par Data Cloud au moment du mapping.
• Erreurs de complétude : valeurs nulles sur des champs obligatoires, enregistrements manquants par rapport au volume attendu.
• Erreurs de cohérence : valeurs hors plage (âge négatif, date future improbable), incohérences référentielles (clé étrangère pointant vers un enregistrement inexistant).
• Erreurs de duplication : même entité représentée plusieurs fois avec des identifiants différents, souvent issue d'une mauvaise résolution d'identité en amont.
• Erreurs sémantiques : donnée structurellement valide mais métier incorrecte (mauvais mapping de code pays, unité de mesure inversée) — les plus difficiles à détecter automatiquement.

Contrôles au moment de l'ingestion

Data Cloud fournit des mécanismes natifs de validation à la frontière d'entrée :

1. Validation de schéma : tout enregistrement dont un champ ne correspond pas au type déclaré (texte dans un champ numérique, par exemple) est automatiquement rejeté et journalisé dans les erreurs du data stream.
2. Contraintes de clé primaire : un enregistrement sans valeur sur le champ désigné comme clé primaire est systématiquement rejeté, car il ne peut pas être upserté.
3. Rapport d'erreurs par run : chaque exécution de data stream expose le détail des lignes en échec avec le motif, consultable dans l'historique d'exécution.

{
  "recordId": "CUST-88213",
  "status": "REJECTED",
  "reason": "FIELD_TYPE_MISMATCH",
  "field": "annual_revenue",
  "value": "N/A"
}

Contrôles post-ingestion via Data Transforms

Les contrôles natifs de Data Cloud détectent les anomalies structurelles, mais pas les incohérences métier. Il faut construire des requêtes de contrôle dédiées, exécutées régulièrement via Data Transforms ou un job planifié externe :

• Comptage d'enregistrements avec valeurs nulles sur des champs métier critiques, en pourcentage du volume total.
• Détection de doublons potentiels par correspondance approximative (mêmes email/téléphone avec ID différents).
• Vérification de plages de valeurs plausibles (dates de naissance, montants, codes postaux).
• Comparaison du nombre total d'enregistrements ingérés par run à une moyenne mobile, pour détecter une variation anormale (chute ou pic).

SELECT
  COUNT(*) AS total_records,
  SUM(CASE WHEN email IS NULL THEN 1 ELSE 0 END) AS null_emails,
  ROUND(100.0 * SUM(CASE WHEN email IS NULL THEN 1 ELSE 0 END) / COUNT(*), 2) AS null_email_pct
FROM customer_dlo
WHERE ingestion_date = CURRENT_DATE

Dédoublonnage et résolution d'identité

Le dédoublonnage est un cas particulier qui mérite une attention spécifique dans Data Cloud, car il s'appuie sur le moteur d'Identity Resolution plutôt que sur un simple contrôle SQL :

1. Définir des règles de correspondance (match rules) basées sur des combinaisons de champs (email exact, ou nom + téléphone, ou nom + adresse).
2. Configurer des règles de réconciliation (reconciliation rules) qui déterminent quelle valeur prévaut en cas de conflit entre sources (source la plus récente, source la plus fiable).
3. Surveiller le taux de fusion (match rate) dans le temps : une chute soudaine peut indiquer qu'une nouvelle source alimente des identifiants mal formatés qui ne matchent plus les règles existantes.

Un taux de duplication élevé n'est presque jamais un problème de règles de matching mal configurées en premier lieu — c'est le plus souvent un symptôme d'un problème de qualité en amont (email non normalisé, casse incohérente, espaces parasites) qu'il vaut mieux corriger à la source.

Construire un tableau de bord de qualité

Pour rendre la qualité de données actionnable au-delà de l'équipe technique, il est recommandé de construire un tableau de bord de qualité, alimenté par des Calculated Insights, exposant :

• Le taux de complétude par champ critique, par source d'ingestion.
• L'évolution du volume ingéré dans le temps, par data stream.
• Le taux d'erreur de mapping et de rejet par run.
• Le taux de fusion d'identité et son évolution.

Ce type de tableau de bord, revu périodiquement avec les propriétaires métier des données sources, permet de transformer le contrôle qualité d'une activité purement technique et réactive en une pratique de gouvernance continue et partagée.