La réponse courte
Le Data Mapping n'est pas un simple tableau de traduction de champs, mais bien le document stratégique où l'organisation définit la signification de chaque donnée qu'elle intègre à Salesforce. Presque toutes les erreurs de chargement, d'apparence technique (format de date, liste de sélection inconnue, relation brisée), trouvent leur origine dans une décision commerciale non prise en amont.
L'ordre de travail efficace est le suivant : déterminer d'abord quelles entités sont concernées par la migration, puis identifier les propriétaires métier de chaque entité, ensuite définir quels champs ont un consommateur réel, et seulement à la fin, rédiger les règles de transformation. Commencer dans le sens inverse expose l'équipe technique à prendre des décisions métier en toute discrétion, avec des conséquences qui se révèlent trois mois après la mise en service (Go Live), par exemple lorsqu'un rapport de revenus ne correspond pas aux attentes.
Pour une vue d'ensemble de la planification complète de la migration, consultez notre Guide de migration des données vers Salesforce.
Les trois types d'écarts révélés par le Mapping
| Type d'écart | Exemple courant | Qui décide |
|---|---|---|
| Écart sémantique | "Client actif" = a acheté cette année dans un système, = n'est pas bloqué dans un autre système | Propriétaire du processus métier |
| Écart structurel | Un client avec cinq adresses face au modèle Account/Contact | Architecte de données |
| Écart de qualité | 18 % des enregistrements sans numéro d'identification d'entreprise valide | Propriétaire des données + Réglementation |
L'écart sémantique est le plus coûteux, car il n'est pas détecté lors du chargement. La donnée est importée avec succès, l'automatisation s'exécute dessus, et le rapport affiche un chiffre incorrect mais plausible. Les écarts structurels sont identifiés lors du chargement, ce qui permet de les corriger rapidement. Les écarts de qualité ne sont détectés que si des seuils d'acceptation ont été définis au préalable.
La couche sémantique : Un dictionnaire de données avant le tableau de Mapping
Avant de procéder au mappage champ à champ, il est essentiel de rédiger une définition de glossaire pour chaque entité clé : qu'est-ce qu'un Account, ce qui distingue un Lead d'un Contact au sein de l'organisation, ou encore quand une Opportunity est-elle close. Ces définitions, bien que concises (deux lignes par entité), sont fondamentales pour résoudre les désaccords plutôt que de simplement les ignorer.
Le test simple : demandez à trois personnes de trois départements différents de définir "client" individuellement. Si les définitions varient, la migration transférera trois réalités différentes dans la même table.
Anatomie d'une ligne de Mapping correcte
Chaque ligne du tableau de mapping doit répondre à sept questions : de quel objet et champ source provient la donnée, vers quel objet et champ Salesforce elle est dirigée, quel est son type et sa longueur, quelle est la règle de transformation, que se passe-t-il en cas de valeur vide, quelle est la valeur par défaut, et qui a approuvé cette ligne. Toute ligne manquante d'une de ces colonnes ressurgira sous forme de question au milieu d'une exécution de chargement pendant la nuit du Cutover.
Trois règles de travail pour éviter les problèmes :
- Pas de transformation silencieuse. Toute valeur "corrigée" automatiquement par le système doit être enregistrée dans un journal des exceptions.
- La valeur par défaut est une décision métier. La personne qui définit
Country = FRpar défaut doit être celle qui est responsable des rapports par région. - Les identifiants externes avant tout. Pour chaque entité, conservez un External ID du système source. Sans cela, aucune réconciliation et aucune exécution répétée ne sont possibles.
Transformations : les erreurs courantes
Les transformations les plus dommageables sont souvent les plus simples. Les dates sans fuseau horaire décalent les enregistrements d'une journée ; les noms tronqués et mis en majuscules sans règle uniforme créent de nouveaux doublons juste après que nous ayons nettoyé les anciens ; les montants convertis à un taux de change quotidien uniforme génèrent des écarts de reporting par rapport à l'ERP.
La règle : toute transformation numérique ou financière est vérifiée par la comparaison des sommes, et non par la comparaison des enregistrements. Une égalité de décompte n'est pas une preuve d'exactitude.
Pour ceux qui n'ont pas encore défini la source de vérité, vous trouverez des informations de fond dans La Source de Vérité dans l'organisation, et concernant la fenêtre de migration elle-même dans Cutover et Réconciliation dans la migration Salesforce.
Scénario : Une entreprise de services avec deux systèmes source
Une organisation de services avec 90 000 clients entreprend une migration à partir de deux systèmes : un système de facturation hérité et un système de services acquis avec une filiale. Le premier tableau de Data Mapping a été marqué "prêt" en deux semaines — 340 champs mappés.
Lors de la première exécution de répétition (Rehearsal), 97 % des enregistrements ont été chargés. Le problème a été découvert lors de la réconciliation : le total des soldes dans Salesforce était inférieur de 4,1 % à celui de l'ERP. La raison n'était pas un échec de chargement, mais le fait que tous les enregistrements avec un solde négatif (crédits) étaient mappés à un champ avec une Validation Rule qui empêchait les valeurs négatives, et étaient ainsi silencieusement définis à zéro.
La correction a été effectuée à deux niveaux : une règle de transformation explicite pour les crédits, et en plus, un changement de politique – toute règle qui réinitialise ou raccourcit une valeur doit désormais générer une ligne d'exception. Lors de la deuxième exécution, le nombre d'exceptions a grimpé à 1 900, ce qui a été une avancée : les exceptions étaient visibles au lieu d'être masquées. La troisième exécution a réduit le nombre d'exceptions documentées à 40, et c'est seulement à ce moment qu'une date de Cutover a été fixée.
Risques courants et actions préventives
| Risque | Comment il se manifeste concrètement | Action préventive |
|---|---|---|
| Migration de tout l'historique | Volume excessif, doublons et informations sans valeur sont transférés vers le nouveau système | Définir des politiques de rétention et des seuils de qualité |
| Mapping purement technique | Les champs sont transférés sans compréhension de leur signification métier | Dictionnaire de données et propriétaires métier |
| Transformations silencieuses | Les valeurs sont corrigées automatiquement et personne n'est informé | Journal d'exceptions obligatoire pour chaque règle de transformation |
| Absence de Rehearsal | La fenêtre d'indisponibilité s'allonge et des surprises apparaissent | Au moins deux exécutions complètes de répétition |
| Absence d'External ID | Impossible de vérifier, de corriger ou de ré-exécuter | Conserver une clé source pour chaque entité |
Comment mesurer le succès
| Domaine | Ce qui est mesuré | Fréquence de vérification |
|---|---|---|
| Complétude | Taux de champs obligatoires renseignés dans la cible | Avant et après chaque chargement |
| Réconciliation | Concordance des décomptes, des montants et des relations avec la source | À chaque exécution de Rehearsal et lors du Cutover |
| Exceptions | Nombre de lignes d'exceptions ouvertes par degré de gravité | Quotidiennement pendant la période de migration |
| Champs sans consommateur | Combien de champs migrés n'ont pas été consultés en 90 jours | Une fois après le Go Live |
Le dernier indicateur prépare pour le cycle suivant : il révèle l'étendue du travail superflu et oriente l'ampleur de la prochaine migration.
Les organisations qui préfèrent un accompagnement professionnel pour l'élaboration du Data Mapping peuvent le faire dans le cadre de nos services d'intégrations et de données.
Checklist avant le premier chargement
- ☐ Dictionnaire de données concis pour chaque entité clé, validé par le métier
- ☐ Liste des champs avec un consommateur défini ; les autres sont archivés
- ☐ External ID pour chaque entité migrée
- ☐ Tableau de Value Mapping complet, incluant une valeur pour les valeurs inconnues
- ☐ Règle explicite pour chaque valeur vide et chaque valeur par défaut
- ☐ Chaque règle de transformation génère une ligne d'exception au lieu d'une correction silencieuse
- ☐ Scénario de réconciliation : décompte, somme, relation, échantillonnage manuel
- ☐ Seuil d'exceptions convenu au-delà duquel aucun Cutover n'est exécuté
- ☐ Version et signature du tableau de Data Mapping
- ☐ Plan de Rollback et de réexécution
Sources professionnelles
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Intégrations et Données — https://hpi.pro/integrations-data