Une migration de données Salesforce se gagne ou se perd avant le premier chargement. Les outils de chargement existent et font leur travail. Ce qui manque, en général, ce sont les décisions : qui possède chaque objet, quel comptage prouve que rien ne manque, combien de répétitions avant la vraie bascule, et qui dit « go » ou « retour arrière ».
« Zéro perte de données » figure dans beaucoup de cahiers des charges. Tant que personne n’a écrit ce que la formule couvre et qui la vérifie, elle ne peut pas servir de critère d’acceptation.
Trois pertes, trois preuves
La perte physique est la plus simple : un enregistrement présent dans la source n’existe pas dans la cible. Un comptage par objet, source contre cible, la détecte.
La perte sémantique passe ce comptage. L’enregistrement est là, mais sa signification a changé : une valeur de Status mal mappée, une relation parent-enfant inversée, une devise mal convertie. Seul quelqu’un qui connaît le métier la repère, sur un échantillon choisi pour ses cas limites.
La perte de contexte passe les deux contrôles. Les valeurs sont justes, mais le propriétaire d’origine, la date de création ou l’historique ont été écrasés au chargement. Sur des données personnelles, c’est aussi une question RGPD, que la qualité des données ne tranche pas à elle seule.
Chaque type de perte demande sa propre preuve et son propre signataire. Un programme qui ne produit que des comptages a traité le premier cas et laissé les deux autres à la production.
Un propriétaire par objet, avant le premier chargement
La propriété précède toutes les autres décisions. Pour chaque objet migré (Account, Contact, Opportunity, Case, objets personnalisés), une personne du métier répond des règles de transformation, du sort des enregistrements orphelins et de la clé qui identifie un enregistrement de façon fiable.
L’équipe projet peut proposer les règles de transformation. Leur validation revient à quelqu’un qui sait ce que signifie un statut ou un type de compte dans l’activité. Quand ces règles vivent dans la tête d’un consultant ou dans un script que personne n’a relu, la perte sémantique devient probable.
Les orphelins (contacts sans compte, opportunités dont le propriétaire est parti, tâches rattachées à des enregistrements supprimés) ne se migrent pas tels quels. Archiver, supprimer ou rattacher à un enregistrement générique : c’est une décision métier, et elle prend du temps. Prise pendant le chargement, elle bloque le planning.
Les identifiants Salesforce ne sont pas portables d’une org à l’autre. Les relations entre enregistrements se reconstruisent avec des clés métier : numéro client, code produit, référence de contrat. Si ces clés manquent ou sont peu fiables dans la source, un nettoyage passe en premier, et c’est le propriétaire de l’objet qui dit quelle clé fait foi.
Sur le programme Sanofi (client Cognizant, 2021-2022), six systèmes ont été migrés vers une org Salesforce unique. Le modèle de contrôle reposait sur des mappings source-cible explicites, des gabarits réutilisables pour les mappings et les contrôles, des contrôles de réconciliation et des conditions d’arrêt qui font remonter les écarts avant l’acceptation. Avec six sources, la question « quelle source fait foi pour ce client ? » se tranche avant tout chargement. L’outil n’y répond pas.
La réconciliation se signe
Un rapport de réconciliation que personne ne signe reste un document technique. Pour chaque lot, le programme produit les comptages source et cible par objet, les rejets avec leur motif et les exceptions acceptées. Le propriétaire métier de l’objet signe ce rapport, pas l’équipe qui a chargé les données.
Le seuil d’erreur acceptable se fixe avant le projet, objet par objet, en nombre d’enregistrements plutôt qu’en pourcentage. Un taux qui paraît faible sur un gros volume représente des milliers de fiches, chacune avec un client ou un contrat derrière.
Le contrôle sémantique demande un jeu de référence : des enregistrements représentatifs, choisis avec le métier pour couvrir les cas limites (relations complexes, champs à valeurs multiples, historiques longs). Des référents métier le vérifient à la main après chaque répétition. Aucun contrôle automatisé ne remplace ce regard pour la perte sémantique.
Les données ne sont pas seules en cause. Un Account chargé correctement peut déclencher un Flow qui échoue parce qu’un type d’enregistrement a changé de nom dans la cible. Les automatisations, règles de validation, profils et intégrations qui touchent les objets migrés font partie du périmètre de test. La note sur la dette technique Salesforce décrit comment ces dépendances s’accumulent.
Répéter, geler, décider
Une bascule se répète. Une répétition complète, sur un volume réaliste et dans un environnement proche de la production, donne ce que le planning ne donne pas : la durée réelle du chargement et le temps que mettent les référents à valider. Ces durées fixent la fenêtre de bascule.
Pendant la migration, la source passe en lecture seule, ou chaque modification est tracée pour être rejouée dans la cible. Sans gel ni mécanisme de delta, les données migrées sont périmées dès le lendemain. La date de gel est une décision métier, parce que ce sont les équipes métier qui arrêtent de saisir.
Le retour arrière se décide à l’avance. Le plan décrit comment revenir à l’état initial si le chargement échoue à mi-parcours, et il a été testé en sandbox. Il fixe aussi un point de décision : l’heure, dans la fenêtre de bascule, après laquelle le retour arrière n’est plus possible, et les critères qui obligent à le déclencher avant.
Reste à savoir qui dit « go ». Le sponsor ou le propriétaire du programme décide sur la base des rapports signés, pas l’intégrateur sur la base de son planning. Si ce nom n’est pas écrit avant la répétition générale, la décision sera prise à deux heures du matin par la personne la plus fatiguée de la salle.
À vérifier
- Chaque objet migré a un propriétaire métier nommé, qui valide les règles de transformation et le sort des orphelins.
- « Zéro perte » est défini par écrit : orphelins, historiques d’activité, pièces jointes et champs chiffrés inclus ou exclus.
- Les seuils d’erreur sont fixés par objet, en nombre d’enregistrements, avant le premier chargement.
- Une répétition complète a eu lieu et ses durées ont servi à fixer la fenêtre de bascule.
- Le plan de retour arrière a été testé et son heure limite figure dans le planning de bascule.
- Le nom de la personne qui dit « go » est écrit.