Comment changer de CRM sans perdre de données?
Exportez tout avant de vous engager à quoi que ce soit, confirmez que vous pouvez vraiment lire l’exportation, et faites fonctionner les deux systèmes en parallèle jusqu’à ce que le nouveau ait fait ses preuves. Les données que les gens oublient sont celles qui comptent en cas de litige : notes, pièces jointes, historique des courriels et horodatages.
Les exportations standards couvrent généralement les contacts et les occasions d’affaires, et omettent discrètement l’historique des activités. Vérifiez précisément ce point avant de signer avec le nouveau fournisseur, parce que c’est souvent la partie la plus difficile à reconstituer. Les notes, les journaux d’appels, les fils de courriels, les pièces jointes et les horodatages de tout ça sont la mémoire institutionnelle de chaque relation — et en cas de litige, la trace de qui a dit quoi et quand est celle qui compte. Certaines plateformes ne donnent accès à l’historique complet que par leur API, pas par le bouton d’exportation; découvrez à quel type vous avez affaire pendant que vous avez encore un rapport de force, pas après avoir donné votre avis de résiliation.
Le cœur technique d’une migration, c’est de préserver les liens entre les fiches. Un CRM, ce n’est pas des tables de contacts et d’occasions d’affaires; ce sont les liens entre elles — cette note appartient à cette occasion, qui appartient à cette entreprise, qui compte ces trois contacts. Les exportations aplatissent ces liens en identifiants internes, et l’importation doit les reconstruire en conservant l’ancien identifiant sur chaque fiche dans un champ de référence. Les migrations faites en importations déconnectées produisent une base de données où tous les contacts existent et où aucun historique n’est rattaché à quoi que ce soit — techniquement complète, pratiquement inutile.
Attendez-vous à ce que l’étape de correspondance des champs soit aussi un projet de nettoyage de données. Les listes de choix de l’ancien CRM ne concorderont pas avec celles du nouveau, la moitié des étapes du pipeline de ventes n’auront pas d’équivalent, du texte libre se trouve là où le nouveau système veut de la structure, et des années de doublons attendent d’être transférés fidèlement. Décidez champ par champ : faire correspondre, transformer ou archiver. Deux détails qui se perdent facilement méritent des vérifications explicites, parce que les paramètres par défaut les effacent en silence : le propriétaire des fiches (tout importer au nom de l’administrateur détruit la responsabilisation) et les dates (les importations qui marquent chaque fiche « créée aujourd’hui » détruisent la chronologie).
Migrez par étapes et gardez une copie en lecture seule de l’ancien système pendant un an. Ce coût est dérisoire comparé à la découverte d’un trou après la fermeture du compte. Faites fonctionner les deux systèmes en parallèle pendant une période limitée, avec des critères de bascule explicites — nombre de fiches rapproché, vérifications ponctuelles réussies sur de vrais comptes, équipe qui accomplit son travail quotidien dans le nouveau système sans se tourner vers l’ancien. Ensuite, figez l’ancien système en lecture seule plutôt que de le garder à moitié en vie; une période en parallèle sans date de fin donne deux CRM à moitié fiables, ce qui est pire que chacun seul.
Planifiez le volet humain avec le même sérieux. Les réflexes de l’équipe vivent dans l’ancien outil, et les deux premières semaines dans le nouveau sont le moment où la qualité des données s’installe ou s’effondre — ce qui plaide pour migrer une équipe au complet plutôt que tout le monde en même temps, et pour confier la migration de bout en bout à une seule personne. Une migration de CRM est un projet d’ingénierie de données déguisé en abonnement logiciel; les équipes qui la traitent comme un simple « changement d’application » sont celles qui découvrent le trou un an plus tard.
Dernière révision le 28 août 2026