Migration ratée : le jour où un mauvais mapping a écrasé 50 000 contacts

Le scénario est tristement classique. Vous reprenez la base d'un client qui migre d'un ancien CRM vers Service Cloud. 50 000 contacts à charger, avec un identifiant externe (external ID) censé garantir que chaque enregistrement source corresponde au bon enregistrement cible. Vous lancez un upsert via Data Loader pour mettre à jour les contacts existants et créer les nouveaux en une seule passe.

L'erreur : la colonne désignée comme external ID dans le mapping pointe vers un champ qui n'est pas réellement unique — un code postal, un nom de société, un champ vidé lors d'un précédent nettoyage. Le Data Loader, lui, ne pose aucune question. Il fait exactement ce qu'on lui dit : pour chaque ligne dont la clé correspond à plusieurs enregistrements ou à un mauvais enregistrement, il écrase les champs cibles avec les valeurs de la ligne source.

Au matin, les commerciaux découvrent des contacts avec des numéros de téléphone mélangés, des adresses email qui ne correspondent plus à la bonne personne, des historiques d'opportunités rattachés au mauvais compte. La base n'est pas vide : elle est corrompue, ce qui est bien pire, car le client a continué à travailler dessus quelques heures avant de comprendre.

La plupart des consultants se rassurent : « En cas de problème, je restaure depuis la corbeille. » Cette intuition est dangereusement incomplète.

• Suppression (delete) : les enregistrements partent en corbeille (Recycle Bin) et y restent environ 15 jours. Une restauration partielle est possible. Sauf si vous avez coché hard delete, qui contourne la corbeille et rend la suppression définitive immédiate.
• Mise à jour destructive (update / upsert) : c'est le cas du sinistre. Il n'y a aucune corbeille pour les anciennes valeurs de champs. La donnée d'origine est simplement remplacée. Le seul recours est une sauvegarde antérieure.

Le Field History Tracking ne sauve pas non plus la mise : il ne trace qu'un nombre limité de champs, conserve un historique partiel, et n'est d'aucune aide pour restaurer en masse 50 000 lignes.

Le vrai filet de sécurité aurait été un export complet préalable (un full backup via Data Loader ou un outil de sauvegarde tiers) réalisé juste avant la migration. Son absence, ou sa réalisation négligée, est précisément le point sur lequel votre responsabilité sera examinée.

Le préjudice d'une migration ratée déborde très largement la facture de reprise technique :

Sur des données personnelles (contacts, prospects), la corruption ou la perte constitue une violation de données au sens du RGPD. Le responsable de traitement — votre client — peut être tenu de notifier la CNIL sous 72 heures et, selon la gravité, d'informer les personnes concernées. Cette obligation déclenche un coût et un risque réputationnel que le client cherchera à vous refacturer.

Un sinistre de migration mobilise deux logiques d'assurance distinctes, qu'il ne faut pas confondre :

La RC Pro répond sur le terrain de la faute professionnelle : c'est elle qui indemnise les dommages immatériels causés au client par votre erreur de mapping et qui prend en charge vos frais de défense face à sa réclamation.

Le volet cyber, lui, intervient sur la gestion de l'incident sur les données : assistance d'experts en réponse à incident, accompagnement à la notification CNIL, frais de reconstitution des données, et prise en charge des conséquences d'une violation. Sur des prestations où vous manipulez des bases de dizaines de milliers de contacts, ce volet n'est plus un luxe : c'est le complément naturel d'une couverture conçue pour le métier.

L'articulation est simple à retenir : la RC Pro répond de ce que vous avez mal fait, le cyber gère ce qui arrive aux données. Un freelance qui pilote des migrations a intérêt à couvrir les deux.

Un point d'attention contractuel mérite d'être souligné : la plupart des contrats RC Pro fonctionnent en base réclamation. Cela signifie que c'est la garantie en vigueur au moment où le client formule sa réclamation qui joue — pas celle en vigueur le jour de la migration. Une migration menée alors que vous n'étiez pas assuré, mais dont les conséquences ne se révèlent que des mois plus tard, peut donc rester non couverte si vous souscrivez trop tard. Souscrire avant la première mission, et maintenir la couverture sans interruption, est la seule façon de fermer cette brèche temporelle.

Un sinistre particulièrement humiliant — et plus fréquent qu'on ne l'admet — naît d'une simple confusion d'environnement. Le Data Loader mémorise les identifiants de connexion, et il suffit d'une session ouverte sur la production alors qu'on croyait travailler en sandbox pour lancer un traitement de masse sur les vraies données.

Le risque est amplifié par plusieurs facteurs propres aux missions de migration :

• Les URL de connexion (login.salesforce.com vs test.salesforce.com) se ressemblent et se sélectionnent d'un clic distrait.
• Les sandbox portent souvent des noms peu explicites, et l'interface est visuellement identique à la production.
• La pression du planning pousse à enchaîner les opérations sans relire l'environnement cible.

Une règle simple sauve des carrières : personnaliser le bandeau de couleur et le nom de l'organisation en sandbox, et vérifier à voix haute l'environnement cible avant chaque clic sur « Insert » ou « Upsert ». Le coût de cette vérification est de cinq secondes ; le coût de son oubli se compte en jours-homme.

Cette discipline relève de la même logique que la sauvegarde préalable : elle ne supprime pas le risque mais en réduit drastiquement la probabilité, et elle documente votre rigueur professionnelle si un litige survient malgré tout.

La meilleure assurance reste la prévention. Avant chaque opération destructive de masse, ces réflexes réduisent drastiquement le risque :

1. Sauvegarde complète de tous les objets impactés, horodatée, vérifiée et conservée hors plateforme.
2. Test sur sandbox full avec un volume réaliste, pas trois lignes de démonstration.
3. Vérification de l'unicité de l'external ID : le champ utilisé comme clé est-il réellement unique et renseigné sur 100 % des lignes ?
4. Run à blanc sur un échantillon de 50 lignes avant de lancer les 50 000.
5. Fenêtre de gel : interdire toute saisie utilisateur pendant l'opération pour éviter d'écraser du travail en cours.
6. Trace écrite de la validation client avant le go-live.

Cette checklist, documentée et signée, ne supprime pas le risque mais constitue votre meilleure pièce de défense : elle démontre que vous avez agi en professionnel diligent. Pour un freelance, mieux vaut perdre une heure de préparation que de découvrir qu'aucune sauvegarde n'existait. Consultez aussi notre page dédiée au métier de consultant Salesforce pour les autres risques spécifiques.