Changer de CRM ne corrige pas automatiquement une base commerciale. Les doublons, les champs contradictoires et les historiques incomplets suivent souvent les fichiers d’export. Ils deviennent parfois plus difficiles à voir, parce que le nouvel outil affiche des écrans plus propres.
Une migration CRM réussie préserve les relations utiles entre les données, explique les exclusions et permet aux équipes de reprendre leur travail. Le nombre de lignes importées compte, mais il ne prouve ni la qualité de la reprise ni sa conformité aux règles de l’entreprise.
La méthode ci-dessous convient à un projet de petite ou moyenne organisation. Les jeux de données et chiffres sont fictifs. Les exigences de conservation, de sécurité et de traitement des données personnelles doivent être adaptées à l’activité réelle.
En bref — Inventoriez les objets, définissez les règles de correspondance, mettez les données ambiguës en quarantaine et testez les parcours commerciaux. Conservez une table reliant les identifiants anciens et nouveaux. Ne basculez pas sans rapprochement des volumes, des relations et des montants utiles.
Le CRM est un réseau de relations, pas un carnet d’adresses
Un export de contacts semble rassurant : une ligne par personne, une colonne par champ. Mais le travail commercial dépend aussi des entreprises, opportunités, activités, pièces jointes, responsables et autorisations.
Un contact peut travailler pour une entreprise, participer à plusieurs opportunités et avoir changé de poste. Une opportunité peut contenir des produits, une devise, une date de clôture et un historique de changements. Réduire ces objets à quelques champs de texte peut rendre la reprise techniquement simple et opérationnellement inutile.
Commencez donc par un inventaire des objets. Pour chacun, relevez le volume, l’identifiant, les relations, les champs obligatoires, les utilisateurs concernés et les modalités d’export. Vérifiez séparément les pièces jointes, qui ne sont pas toujours incluses dans le fichier principal.
Ajoutez les automatisations dépendantes : formulaire du site, outil d’envoi, facturation, reporting et synchronisation de comptes. Leur migration peut être distincte de celle du CRM. Un ancien connecteur encore actif peut réintroduire des données ou modifier les statuts après la bascule.
Le cahier des charges fondé sur des critères vérifiables aide à transformer cet inventaire en recette. « Reprendre l’historique » devient, par exemple, « retrouver les activités des opportunités ouvertes, avec leur date et leur auteur, dans le dossier correspondant ».
Enfin, choisissez les éléments qui doivent rester accessibles sans être importés dans le CRM courant. Certaines archives peuvent être conservées dans un espace distinct, selon des règles documentées. Migrer tout par défaut augmente le bruit, les coûts et les risques de réutiliser une donnée inappropriée.
Définir le sens des champs avant leur conversion
Deux champs nommés « statut » peuvent exprimer des concepts différents. Dans l’ancien CRM, « actif » signifie peut-être qu’un contact a reçu un e-mail. Dans le nouveau, il peut désigner une relation commerciale ouverte. Une correspondance de libellés ne suffit pas.
Créez un dictionnaire de migration : objet source, champ source, définition, champ cible, transformation, règle en cas d’absence et responsable de validation. Une catégorie « autre » utilisée pour toutes les valeurs inconnues peut masquer un problème au lieu de le résoudre.
Les dates méritent une attention spéciale. Précisez le fuseau, le format et le sens de chaque date : création initiale, dernière modification ou import. Il faut éviter qu’une migration fasse apparaître des contacts anciens comme fraîchement créés dans les rapports commerciaux.
Les montants doivent conserver leur devise et leur signification. Un montant estimé, un montant signé et un revenu encaissé ne sont pas équivalents. Si l’outil cible gère les taxes ou les lignes de produit autrement, documentez la conversion avant d’importer des totaux.
Vérifiez les listes de valeurs autorisées et les règles de champs obligatoires. Une absence doit rester une absence lorsqu’elle est pertinente. Remplir une date manquante avec celle du jour produit une précision artificielle qui peut déclencher des relances ou déformer les analyses.
Pour les responsables de dossiers, construisez une table de correspondance des comptes utilisateurs. Un salarié parti ne doit pas devenir un compte actif par simple import. Les opportunités encore ouvertes doivent recevoir une règle de réaffectation approuvée par l’équipe commerciale.
Dédupliquer sans fusionner des personnes différentes
Le dédoublonnage est un arbitrage, pas seulement une suppression. Une adresse e-mail partagée peut appartenir à un service. Une personne peut utiliser deux adresses. Deux entreprises peuvent avoir des raisons sociales proches sans être la même entité.
Utilisez d’abord des critères déterministes fiables lorsqu’ils existent : identifiant externe stable, identifiant d’entreprise vérifié ou relation documentée. Les rapprochements approximatifs servent à proposer des candidats, pas à autoriser automatiquement toutes les fusions.
Définissez une règle de survivance pour chaque champ. Faut-il conserver la valeur la plus récente, celle issue d’un système de référence ou celle vérifiée par un commercial ? Il n’existe pas de bonne réponse unique. La valeur la plus récente peut provenir d’un import incorrect.
La fusion doit préserver les relations. Si deux fiches de contact sont regroupées, leurs activités et opportunités doivent rester rattachées à la fiche retenue. Enregistrez les anciens identifiants et la raison de fusion pour pouvoir expliquer le résultat.
Voici un rapprochement fictif sur 10 000 lignes brutes :
| Destination des lignes initiales | Nombre | Sens du contrôle |
|---|---|---|
| Lignes supplémentaires absorbées dans des fusions | 1 000 | Relations reprises vers les fiches conservées |
| Lignes exclues selon une règle validée | 500 | Motif d’exclusion documenté |
| Lignes ambiguës mises en quarantaine | 800 | Décision humaine encore nécessaire |
| Fiches chargées dans la cible | 7 700 | Contrôle de qualité et de relations |
| Total rapproché | 10 000 | Aucune ligne source inexpliquée |
Ces catégories décrivent ici le devenir des lignes sources, pas le nombre de personnes réellement distinctes avant traitement. Le bilan prouve une réconciliation comptable des lignes. Il ne prouve pas que chaque fusion est correcte : cela demande un contrôle supplémentaire.
La quarantaine est utile. Elle permet de basculer les données sûres tout en conservant les cas problématiques avec un responsable et une date de résolution. Forcer les 800 cas ambigus dans cet exemple rendrait le pourcentage importé plus flatteur, sans améliorer le résultat.
Protéger les relations grâce à une table de correspondance
Les identifiants techniques changent souvent entre les outils. Il faut donc conserver une table ancien identifiant / nouvel identifiant, pour chaque objet, avec la version du traitement et son résultat.
Importez dans un ordre compatible avec les dépendances. Les entreprises peuvent précéder les contacts, puis les opportunités et les activités. L’ordre exact dépend du modèle cible et des possibilités de références externes.
Les relations doivent être contrôlées explicitement. Une opportunité sans entreprise, une activité sans dossier ou une pièce jointe non rattachée sont des anomalies distinctes. La base cible peut empêcher certaines incohérences par des contraintes d’unicité ou de référence, mais les règles commerciales exigent aussi des validations spécifiques.
Il est prudent de conserver un identifiant externe de migration lorsque l’outil le permet. Une reprise interrompue peut alors retrouver une fiche déjà créée, au lieu d’en créer une seconde. Le mécanisme doit s’appuyer sur une règle stable et une vérification des champs.
Cette logique rejoint les principes d’automatisation avec gestion des doublons et des reprises. Une réponse perdue pendant l’import ne signifie pas que la création n’a pas eu lieu. Le journal doit permettre de reprendre le lot sans importer deux fois les mêmes objets.
Protégez enfin les fichiers intermédiaires. Ils contiennent souvent plus de données que les utilisateurs n’en voient dans le CRM. Limitez les accès, chiffrez les transferts lorsque nécessaire et définissez une durée de conservation. Une copie sur plusieurs postes personnels n’est pas une stratégie de reprise.
Faire une répétition complète avant le week-end de bascule
Le premier import doit avoir lieu dans un environnement de test approprié, avec un jeu représentatif. Quelques contacts simples ne révèlent pas les problèmes de pièces jointes, de devises, d’accents ou d’activités anciennes.
Effectuez ensuite une répétition du processus complet : extraction, transformation, chargement, contrôles et ouverture des parcours métier. Mesurez le temps de chaque phase. L’import peut être rapide alors que l’export ou la validation demande plusieurs heures.
Les fichiers doivent porter un identifiant de lot et une empreinte permettant de savoir exactement ce qui a été traité. Conservez le script ou la configuration de transformation, pas uniquement le fichier final. Une règle corrigée doit pouvoir être appliquée de manière reproductible.
Le rapprochement porte sur plusieurs dimensions. Comptez les objets par catégorie, les relations, les opportunités par stade et les montants par devise. Une somme globale peut rester identique malgré l’affectation de plusieurs dossiers aux mauvais clients.
Ajoutez un contrôle par échantillon orienté risque : dossiers importants, historiques longs, doublons fusionnés, cas multidevises et comptes aux droits particuliers. Les commerciaux vérifient des situations qu’ils connaissent, avec une grille écrite. Leur accord informel devant un écran ne remplace pas une recette documentée.
Un scénario utile consiste à ouvrir une opportunité, consulter son historique, créer une activité, modifier un champ autorisé et retrouver le dossier dans un rapport. Ce parcours révèle des problèmes que le seul compteur de lignes n’identifie pas.
Choisir une stratégie de bascule et un vrai plan de retour
Deux stratégies fréquentes sont le gel temporaire des modifications et la reprise différentielle. Dans le premier cas, l’ancien outil passe en lecture seule pendant la dernière extraction. Dans le second, une copie initiale est complétée par les changements intervenus ensuite.
La reprise différentielle paraît plus confortable, mais elle exige de savoir détecter les créations, modifications et suppressions. Un simple champ « modifié le » peut être insuffisant si certaines opérations ne le mettent pas à jour ou si des objets supprimés disparaissent de l’export.
Définissez une heure de référence, la source autoritaire et les règles de conflit. Si les équipes modifient simultanément les deux CRM, les divergences deviennent rapidement difficiles à expliquer. Une période de double saisie doit être limitée et contrôlée, avec une finalité précise.
Le plan de retour arrière doit expliquer ce qui se passe après de nouvelles saisies dans le système cible. Revenir à l’ancien outil sans reprendre ces modifications perdrait du travail. La décision de retour doit donc être associée à des critères, un responsable et une procédure de réconciliation.
Avant la bascule, testez les comptes techniques et désactivez les anciens connecteurs au moment prévu. Les formulaires, campagnes et synchronisations peuvent continuer d’écrire même lorsque les utilisateurs ont cessé d’utiliser l’ancien CRM.
Gardez l’ancien système disponible en lecture seule si le contrat et les règles de conservation le permettent. Cette période doit être bornée. Elle sert à résoudre des écarts, pas à maintenir indéfiniment deux références commerciales concurrentes.
Après l’import, mesurer la capacité à travailler
Le contrôle des usages de communication demande une recette séparée. Une adresse présente dans le CRM ne suffit pas à décider qu’elle peut recevoir une campagne. Reprenez les informations utiles sur les oppositions, désabonnements et justificatifs, selon les règles applicables à chaque usage. Les données absentes ou ambiguës ne doivent pas être transformées automatiquement en autorisation.
Vérifiez également la transmission de ces états aux outils connectés. Un contact correctement exclu dans le CRM peut être réactivé par une ancienne synchronisation. La recette doit partir d’un dossier connu, tester son comportement dans chaque outil concerné et conserver le résultat.
Ce contrôle concerne aussi la suppression. Lorsqu’un processus exige le retrait d’une donnée, il faut comprendre quelles copies et archives sont concernées et comment l’action se propage. Une migration ajoute temporairement des fichiers intermédiaires ; leur propriétaire doit être identifié pour que la clôture du projet inclue leur traitement.
Les premiers jours nécessitent une équipe de résolution identifiée. Classez les problèmes : donnée manquante, correspondance incorrecte, droit insuffisant, automatisation absente ou difficulté d’usage. Mélanger ces catégories donne de mauvais diagnostics.
Suivez les anomalies bloquantes, leur délai de traitement et leur réapparition. Une correction de donnée peut être écrasée par un connecteur encore actif. Le traitement doit donc rechercher la cause, pas uniquement modifier la fiche concernée.
Contrôlez les accès selon les rôles : commercial, manager, support et administration. La migration peut modifier des règles de visibilité. Un utilisateur qui retrouve tous les dossiers n’est pas forcément la preuve d’une reprise réussie ; il peut être la preuve d’un droit trop large.
Revoyez ensuite les rapports. Comparez les définitions et les périmètres, pas seulement les totaux. Si le nouveau CRM exclut les opportunités abandonnées, une baisse du pipeline peut venir de la règle de calcul plutôt que d’une perte de données.
Le bilan doit réunir les objets repris, les exclusions justifiées, les cas en quarantaine, les relations contrôlées, les incidents ouverts et la décision de fermeture de l’ancien outil. Les fichiers temporaires devenus inutiles doivent suivre la règle de suppression prévue.
La migration est terminée lorsque les équipes disposent de données explicables et de parcours opérationnels, avec des exceptions maîtrisées. Une base neuve ne suffit pas. Ce qui compte, c’est la possibilité de prendre une décision commerciale sans devoir deviner ce que l’import a changé.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
