Un fichier arrive. Il pèse 412 Mo. Le fichier attendu pèse 412 Mo. La vérification de taille passe. Le workflow continue. Le chargement se déclenche. Les données intègrent votre Datahub ou votre Data Cloud.
Et quelques heures plus tard, vos équipes marketing remontent que des contacts ont disparu. Des segments sont faux. Des campagnes partent sur des bases tronquées.
La corruption était là depuis le début. Silencieuse.
Sur un transfert SFTP vers Azure Blob Storage, la connexion s'est interrompue en cours de route. Le fichier a été créé côté destination. Sa taille correspondait à ce qui avait été transféré jusquà l'interruption. Pas à ce qui aurait dû l'être.
Le fichier source était intact. Le fichier de destination était tronqué. Et les deux pesaient exactement le même nombre d'octets d'après le système de vérification, parce que ce système ne comparait pas la taille source avec la taille destination. Il vérifiait uniquement que la taille destination était supérieure à zéro.
Une vérification de taille de fichier sans référence de comparaison ne détecte pas la troncature. Elle détecte l'absence totale de fichier, et rien d'autre.
Il existe plusieurs formes de corruption silencieuse dans un flux de fichiers :
Adobe Campaign Classic et Campaign v8 proposent des activités de transfert de fichiers (Transfer File) avec des options de vérification d'existence. Mais la vérification de l'intégrité du fichier, checksum MD5, comparaison taille source/destination, comptage de lignes, n'est pas native. Elle doit être implémentée dans des activités JavaScript ou des scripts Shell appelés depuis le workflow.
Sur un Datahub connecté à un Azure Blob, la responsabilité de la vérification d'intégrité revient intégralement à l'équipe qui conçoit le workflow d'import. La plateforme charge ce qu'elle reçoit, sans valider ce qu'elle aurait dû recevoir.
Salesforce Data Cloud propose des connecteurs d'ingésion (Ingestion API, Cloud Storage Connector) avec des jobs de validation. Ces jobs vérifient le format, le schéma, les types de champs. Ils ne vérifient pas si le fichier reçu correspond au fichier envoyé.
Un fichier tronqué au bon format, avec les bonnes colonnes et les bons types, intègre Data Cloud sans erreur. Le job de validation passe au vert. Les données chargées sont incompletes.
Ni Adobe Campaign ni Salesforce Data Cloud ne comparent nativement la taille ou le checksum du fichier reçu avec le fichier source. La validation de l'intégrité est un chantier d'architecture que vos équipes doivent piloter.
Un flux de fichiers vers un CRM n'est fiable que si trois conditions sont réunies : la taille reçue est vérifiée contre une référence, l'intégrité du contenu est validée par checksum ou comptage de lignes, et le pipeline sait quoi faire en cas d'échec sans intervention manuelle.
Sans ces trois couches, vous avez un pipeline qui fonctionne jusqu'au jour où il ne fonctionne pas, et vous ne le savez qu'en regardant vos campagnes.
La question à poser sur chaque flux de fichiers en production : « Si ce fichier arrive tronqué de 30%, est-ce que notre système le détecte avant de charger les données ?» Si la réponse n'est pas immédiate, vous avez votre prochaine priorité.
Ce sujet est directement lié à l'architecture d'intégration que j'ai décrite dans mon article sur la synchronisation Salesforce et Snowflake : la robustesse d'un pipeline de données ne se mesure pas quand tout va bien, mais quand une connexion tombe au mauvais moment.
8 modules, 24 leçons pour écrire du code fiable en production : queryDef, workflows JavaScript, JSSP, webApps, API et déploiement. Accès permanent, code complet commenté.
Découvrir la formation →Cartographie des flux de fichiers, vérification des mécanismes d'intégrité en place, recommandations d'architecture. Cadrage gratuit, sans engagement.
Contact →