Connecteurs CSV, S3 et fichiers plats vers Data Cloud

Malgré la montée en puissance des API temps réel, les fichiers plats (CSV, JSON en ligne, Parquet) restent le format d'échange le plus répandu entre systèmes legacy et Data Cloud. Bien configurés, les connecteurs S3 et fichiers plats offrent une fiabilité et une simplicité opérationnelle difficiles à égaler pour des flux de données de référence. Voici les points techniques à maîtriser pour éviter les pièges classiques.

Formats supportés et choix du bon format

Data Cloud accepte plusieurs formats de fichiers via ses connecteurs de stockage cloud :

• CSV : le plus universel, mais sensible à l'encodage, aux séparateurs et à l'échappement des caractères spéciaux.
• JSON Lines (NDJSON) : un objet JSON par ligne, plus robuste pour représenter des structures imbriquées ou des valeurs contenant des virgules.
• Parquet : format colonnaire compressé, recommandé pour de très gros volumes (plusieurs Go), avec typage natif embarqué qui réduit les erreurs de mapping.

Pour un volume modéré et une équipe non spécialisée data engineering côté source, le CSV reste souvent le choix par défaut. Au-delà de quelques Go par fichier ou pour des structures complexes, Parquet limite significativement les temps de traitement.

Configurer le connecteur S3

La configuration d'un connecteur S3 dans Data Cloud nécessite trois éléments côté AWS avant même de toucher à Setup :

1. Un bucket S3 dédié (ou un préfixe isolé dans un bucket partagé) pour éviter que Data Cloud ne scanne des fichiers non pertinents.
2. Un utilisateur IAM avec une politique en lecture seule limitée au bucket/préfixe concerné (principe du moindre privilège).
3. Une politique de cycle de vie (lifecycle policy) définissant la rétention des fichiers sources après ingestion, pour maîtriser les coûts de stockage.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::datacloud-ingest-bucket",
      "arn:aws:s3:::datacloud-ingest-bucket/orders/*"
    ]
  }]
}

Côté Data Cloud, la configuration se fait dans Setup > Data Cloud > Data Streams > New via le connecteur "Amazon S3", en renseignant la clé d'accès, la clé secrète (ou un rôle IAM assumable pour plus de sécurité), le nom du bucket et le préfixe de chemin à surveiller.

Structurer un header CSV propre

Le mapping vers le DMO se base sur les noms de colonnes du header CSV. Une structure de header mal pensée génère des heures de debug de mapping :

customer_id,email,first_name,last_name,created_date,country_code
CUST-10245,client@example.com,Jean,Dupont,2026-04-08,FR

• Utiliser des noms de colonnes stables dans le temps : renommer une colonne côté export casse silencieusement le mapping existant.
• Standardiser le format de date (ISO 8601 recommandé : YYYY-MM-DD ou YYYY-MM-DDTHH:MM:SSZ) pour éviter les ambiguïtés jour/mois selon la locale.
• Encoder systématiquement en UTF-8 sans BOM, source fréquente de caractères accentués corrompus lors du parsing.
• Échapper correctement les champs contenant des virgules ou guillemets, en respectant la RFC 4180.

Pièges fréquents et diagnostic

Plusieurs erreurs reviennent systématiquement lors de la mise en place de connecteurs fichiers plats :

• Colonnes désalignées : un export source contenant une virgule non échappée dans une valeur (adresse, nom d'entreprise) décale toutes les colonnes suivantes sans erreur explicite au parsing.
• Fichiers vides ou partiels ingérés : si le job d'export amont échoue en cours d'écriture, un fichier tronqué peut être détecté et ingéré tel quel — d'où l'intérêt du fichier marqueur _SUCCESS évoqué pour les connecteurs batch.
• Doublons de fichiers : un même fichier redéposé (retry manuel, job relancé) peut être réingéré s'il ne suit pas la convention de nommage horodatée attendue.
• Types de colonnes incohérents entre fichiers successifs : une colonne numérique qui devient texte sur un export ultérieur (valeur "N/A" insérée) provoque des rejets silencieux de lignes.

Avant de brancher un connecteur en production, testez systématiquement avec un fichier d'échantillon contenant les cas limites réels : valeurs nulles, caractères spéciaux, champs vides, encodages mixtes. C'est souvent là que se cachent les vrais problèmes, pas dans le cas nominal.

Suivi et validation post-ingestion

Après chaque exécution du data stream, il est recommandé de valider automatiquement le résultat plutôt que de se fier uniquement au statut "Success" :

1. Comparer le nombre de lignes du fichier source au nombre d'enregistrements effectivement présents dans le DLO.
2. Vérifier l'absence de valeurs nulles inattendues sur les champs obligatoires (clé primaire, email).
3. Archiver ou déplacer les fichiers traités vers un préfixe "processed" pour éviter toute confusion sur ce qui a déjà été ingéré.

Bien maîtrisés, les connecteurs de fichiers plats restent une solution robuste et peu coûteuse pour la majorité des flux de données de référence, en complément des approches temps réel pour les données événementielles.