J'ai mené la migration de Dynamics 365 vers Salesforce pour Best Western : cartographie des objets, mapping des champs, reprise de données et recette complète. Ce qui suit vient de cette mission et de celles qui ont suivi.
Le constat central est toujours le même. La technique n'est presque jamais le problème. Les outils d'import fonctionnent, les connecteurs existent, les formats se convertissent. Ce qui fait dérailler ces projets, c'est ce qu'on découvre sur les données au moment de les déplacer.
Le vrai sujet : la reprise de données
Un CRM en service depuis plusieurs années contient l'histoire de l'entreprise. Il contient aussi ses approximations.
Quand on ouvre une base Dynamics vieille de cinq ans, on trouve systématiquement les mêmes choses : des comptes en double créés par des commerciaux différents, des champs libres utilisés pour stocker ce que le modèle ne prévoyait pas, des dates au format incohérent selon la période de saisie, et des enregistrements rattachés à des utilisateurs qui ont quitté l'entreprise depuis longtemps.
Migrer, c'est déplacer cette histoire. Et c'est le moment où l'entreprise découvre l'état réel de ses données — souvent pour la première fois.
Ce moment est inconfortable, mais il est utile. C'est aussi la seule occasion, dans la vie d'une entreprise, où nettoyer les données devient une priorité budgétée.
Les cinq pièges les plus fréquents
Les correspondances qui n'existent pas. Les deux CRM ne modélisent pas le monde de la même façon. Certaines notions de Dynamics n'ont pas d'équivalent direct dans Salesforce, et inversement. Chacune de ces divergences est une décision métier, pas une décision technique — et elle doit être tranchée par quelqu'un qui connaît l'activité.
Les listes de valeurs. Un champ à choix multiples accumule les valeurs au fil des années. On en trouve souvent trois qui veulent dire la même chose, écrites différemment. Les migrer telles quelles revient à importer le désordre.
Les doublons. Il faut décider d'une règle de rapprochement — sur quel critère deux fiches sont-elles la même entreprise ? — et l'assumer. Aucune règle n'est parfaite, et repousser cette décision revient à la reporter sur les utilisateurs, qui la trancheront chacun à leur façon.
L'historique. Faut-il tout reprendre, ou seulement les trois dernières années ? Reprendre l'intégralité coûte cher et alourdit l'outil ; laisser l'historique derrière soi inquiète les équipes. La bonne réponse dépend de l'usage réel, et elle se décide en amont, pas pendant la bascule.
Les utilisateurs et les droits. Les profils Dynamics ne se transposent pas directement. C'est l'occasion de reprendre la question des accès à zéro plutôt que de reproduire un existant dont plus personne ne connaît la logique.
La méthode qui limite la casse
L'ordre compte plus que les outils.
- Cartographier avant de mapper. Comprendre ce que chaque objet représente réellement dans l'activité, avant de décider où il atterrit. Cette étape se fait avec les métiers, pas seul devant un écran.
- Nettoyer à la source. Corriger dans Dynamics ce qui peut l'être avant de partir. Chaque anomalie non traitée en amont sera plus coûteuse à corriger après la bascule.
- Migrer un échantillon d'abord. Quelques centaines d'enregistrements représentatifs, examinés en détail. C'est là qu'on découvre les surprises, pendant qu'elles sont encore réversibles.
- Faire recetter par les utilisateurs, pas par l'informatique. Un commercial repère en dix minutes qu'un champ manque sur ses fiches. Un test technique ne le verra jamais.
- Prévoir une période de double lecture. L'ancien système reste consultable quelques semaines. Cela coûte un peu de licence et évite beaucoup d'angoisse.
Combien de temps, et quel effort côté client
Pour une migration de taille moyenne, l'essentiel de la charge ne porte pas sur la configuration de Salesforce. Elle porte sur les décisions de correspondance et sur la recette — deux étapes qui exigent du temps de vos équipes, pas seulement du prestataire.
C'est le point que je préfère annoncer clairement dès le départ : une migration réussie mobilise vos gens. Si personne côté métier n'a de disponibilité pour arbitrer et pour recetter, le calendrier glissera, quelle que soit la qualité de l'intégrateur.
Avant de vous engager
Si une migration est à l'étude chez vous, la première chose utile n'est pas de choisir l'outil cible — c'est de savoir dans quel état sont vos données actuelles. Un audit CRM de trois jours vous donne cette réponse, et transforme un devis de migration approximatif en une estimation défendable.
Parlons de votre contexte — je vous dirai franchement ce que la migration implique dans votre cas.