Sommaire
- Séparer la décision CRM de la décision de migration
- Inventorier ce que les équipes utilisent vraiment
- Décider comment reconnaître un même client
- Écrire un dictionnaire des champs
- Répéter avant de basculer
- Préparer la bascule et les changements tardifs
- Accompagner les premières semaines d’usage
- Exemple de mapping : du tableur au nouveau CRM
- Sources et méthode
Une migration vers un CRM sur mesure est réussie lorsque les équipes retrouvent les bonnes données, les bonnes relations et les prochaines actions au moment de reprendre leur travail. Importer toutes les lignes sans erreur technique ne suffit pas : une occasion commerciale rattachée au mauvais client peut être plus dommageable qu’une ligne refusée et visible dans un journal.
En bref
- Définissez les données à reprendre et la référence de chaque champ.
- Répétez la migration sur une copie et faites valider les parcours par les ventes.
- Préparez la bascule, les changements de dernière minute et le retour arrière.
Séparer la décision CRM de la décision de migration
Le choix de construire, configurer ou intégrer un CRM doit précéder les détails de reprise. Notre guide coûts et architecture CRM traite de cette décision. Une fois le périmètre retenu, la migration devient un chantier à part entière, avec ses responsables, ses essais et ses critères d’acceptation.
N’attendez pas la fin du développement pour examiner les données. Un export réel, anonymisé et représentatif peut révéler des colonnes incohérentes, des identifiants absents ou des relations implicites. Ces découvertes influencent le modèle du nouveau CRM et le temps nécessaire pour mettre les données en ordre.
Inventorier ce que les équipes utilisent vraiment
Listez les comptes, contacts, occasions, activités, documents, consentements et tâches. Ajoutez les champs qui ne sont pas visibles dans le tableau principal mais qui déclenchent une règle : territoire, statut de paiement, catégorie client ou date de prochain suivi. Demandez aux équipes ce qu’elles recherchent pendant un appel réel.
Attribuez à chaque catégorie une destination : migration active, archive consultable ou exclusion justifiée. Garder tous les anciens champs dans la nouvelle interface peut reproduire la confusion. À l’inverse, supprimer un historique sans examiner son usage peut priver un représentant d’une information essentielle.
TableauInventorier ce que les équipes utilisent vraiment · bloc partageable
| Risque de reprise | Contrôle métier | |
|---|---|---|
| Compte client | Doublons et noms proches | Identifiant stable et liste des fusions proposées |
| Contact | Relation perdue avec l’entreprise | Vérification des liens compte-contact |
| Occasion | Étape ou montant modifié | Comparaison par responsable, étape et devise |
| Activité | Auteur ou date mal interprété | Contrôle des fuseaux, des propriétaires et de l’ordre |
| Document | Lien devenu inaccessible | Essai d’ouverture avec le rôle utilisateur prévu |
| Préférences | Valeur ancienne ou ambiguë | Conservation de la provenance et revue par le responsable |
Cette grille est un point de départ. Les règles de conservation, de confidentialité et de consentement doivent être confirmées avec les personnes compétentes de votre organisation; un changement de CRM ne constitue pas, en soi, une autorisation d’élargir les usages des données.
Décider comment reconnaître un même client
Le nom commercial n’est pas toujours une clé fiable. Il peut changer, contenir une faute ou désigner plusieurs établissements. Définissez des identifiants durables et une correspondance entre les anciens et les nouveaux numéros. Conservez cette table pour expliquer une migration et éviter les créations répétées lors d’un second passage.
Microsoft documente, pour les imports Dataverse, la nécessité de définir l’unicité avec des clés et de mapper les données aux champs attendus. Le principe est utile au-delà de cet outil : chaque nouvelle ligne doit pouvoir être associée à une identité et à une règle de mise à jour explicites.
Pour les doublons, séparez les décisions automatiques des cas à examiner. Deux comptes partageant une adresse courriel générique ne sont pas nécessairement identiques. Un rapport de rapprochement doit montrer les valeurs en conflit, la règle proposée et la personne autorisée à confirmer une fusion.
Écrire un dictionnaire des champs
Pour chaque champ, notez sa définition, son type, sa source, sa destination et la règle de transformation. Une date vide peut signifier « inconnue »; la remplacer par la date de migration inventerait une information. Un montant peut être avant taxes, après taxes ou associé à une devise : le nouveau CRM ne doit pas résoudre cette ambiguïté au hasard.
Documentez les valeurs autorisées et leur correspondance. Si les anciennes étapes sont « envoyé », « suivi » et « gagné », expliquez comment elles rejoignent le nouveau pipeline. Vérifiez les dossiers qui ne correspondent à aucune étape. Un import qui classe tout dans « nouveau » paraît propre techniquement, mais détruit le suivi commercial.
Un CRM sur mesure peut refléter vos règles particulières. Cette souplesse demande toutefois de nommer les responsables des données et de garder les règles lisibles, pour que l’équipe comprenne ce qui a été transformé.
Répéter avant de basculer
Exécutez une reprise d’essai sur une copie isolée. Comparez les quantités par catégorie, les relations, les montants et les dossiers incomplets. Les nombres totaux sont nécessaires, mais insuffisants : cent occasions importées peuvent être rattachées à cent mauvais comptes.
Préparez un échantillon représentatif : nouveau client, dossier ancien, occasion active, contact inactif, entreprise avec plusieurs établissements et activité avec document. Faites réaliser aux utilisateurs leurs gestes habituels. Peuvent-ils trouver le dernier échange, le prochain suivi et la bonne personne à contacter?
Illustration fictive : un représentant doit reprendre une occasion avec deux contacts et une proposition jointe. Le test couvre la recherche du client, l’ouverture du document, la lecture de l’historique et la mise à jour de l’étape. Le fait que les quatre enregistrements existent ne prouve pas que ce parcours fonctionne.
Préparer la bascule et les changements tardifs
Définissez la fenêtre de bascule et ce qui demeure permis dans l’ancien outil. Si les ventes continuent d’écrire pendant la migration, il faut reprendre les changements intervenus depuis l’extraction initiale. Nommez le système de référence pour chaque phase, afin de ne pas maintenir deux vérités contradictoires.
Prévoyez les conditions d’arrêt et de retour arrière avant de commencer. Quels échecs empêchent l’ouverture? Qui prend la décision? Où les nouvelles saisies sont-elles conservées si la bascule doit être annulée? Une sauvegarde n’est utile que si la restauration et la reprise du travail ont été vérifiées.
Les autorisations doivent également être testées. Un responsable peut voir plusieurs équipes; un représentant uniquement ses dossiers. OWASP décrit les risques d’autorisation applicative qui rendent ces contrôles indispensables, particulièrement quand le CRM expose des API ou des exports.
Accompagner les premières semaines d’usage
Fournissez une courte procédure pour les tâches fréquentes, un canal de remontée des anomalies et un responsable capable de distinguer donnée incorrecte et nouvelle règle métier. Corriger rapidement une liste de valeurs incomprise peut éviter le retour à des tableurs parallèles.
Suivez les anomalies restantes, les délais de traitement et la qualité des nouvelles saisies. Évaluez l’adoption sur les processus terminés, pas seulement sur les connexions. Une équipe qui ouvre le CRM puis travaille ailleurs n’a pas encore adopté le système.
Exemple de mapping : du tableur au nouveau CRM
Le mapping est le document qui relie l’ancien champ au nouveau, avec une règle de transformation et une règle de rejet. Voici un exemple fictif pour une PME qui reprend ses comptes, contacts et occasions. Les noms de champs sont illustratifs; ils ne décrivent pas un logiciel particulier.
TableauExemple de mapping : du tableur au nouveau CRM · bloc partageable
| Champ cible et transformation | Exception à traiter | |
|---|---|---|
| No client | account.external_id; conserver comme texte | Identifiant manquant ou utilisé par deux comptes |
| Société | account.name; retirer les espaces superflus | Nom absent; ne pas fusionner sur le nom seul |
| Courriel contact | contact.email; espaces retirés | Adresse invalide; conserver le rejet pour correction |
| Responsable vente | opportunity.owner_id via table de correspondance | Ancien employé : attribution approuvée par le directeur |
| Étape | opportunity.stage via liste de valeurs validée | Valeur inconnue; ne pas la convertir automatiquement en gagné |
| Montant CAD | opportunity.amount; interpréter le séparateur décimal | Valeur ambiguë ou devise non précisée |
| Dernier échange | activity.occurred_at avec fuseau connu | Date ambiguë; retour au dossier source |
Une correspondance précise pour l’étape peut être « devis envoyé » vers « proposition », « signé » vers « gagné » et « abandonné » vers « perdu ». Ces règles appartiennent à ce cas fictif et doivent être approuvées par l’équipe commerciale. Une même adresse courriel ne suffit pas à décider que deux sociétés sont identiques. Les regroupements incertains vont dans une file de revue avec les identifiants d’origine.
Liste de réception avant la bascule
- Réconcilier les comptes source : lignes importées, rejetées, fusionnées et exclues avec motif; aucun écart inexpliqué.
- Comparer les occasions ouvertes par étape et les montants dans une même devise; examiner chaque divergence.
- Ouvrir un échantillon de dossiers choisi par les ventes, dont un compte avec plusieurs contacts et un responsable parti.
- Retrouver les activités, leurs dates et les pièces liées; contrôler les permissions avec plusieurs rôles.
- Rejouer un import interrompu; vérifier qu’une reprise ne duplique pas les fiches déjà intégrées.
- Valider une répétition générale chronométrée, la période de gel et les écritures à rapprocher depuis le dernier export.
- Désigner la personne qui accepte chaque écart restant et l’équipe qui traite les anomalies après lancement.
À titre d’illustration, 1 000 lignes peuvent devenir 920 comptes, 50 rejets et 30 lignes fusionnées dans les comptes conservés. Le total se réconcilie, mais cela ne prouve pas à lui seul que les fusions sont correctes. Vérifiez la règle et les dossiers concernés. Une tolérance éventuelle doit être explicite : un montant commercial inexpliqué mérite une autre décision qu’un espace dans un numéro de téléphone.
Le retour à l’ancien CRM exige également un plan pour les nouvelles écritures. Après la bascule, revenir à une sauvegarde ancienne peut perdre les échanges saisis entre-temps. Définissez avant le lancement comment exporter, rapprocher ou ressaisir ces changements. La décision de retour doit tenir compte de cette opération et de son responsable.
Questions fréquentes
Faut-il migrer tout l’historique?+
Pas nécessairement. Définissez ce qui doit rester actif, ce qui peut être archivé et ce qui doit être conservé selon vos obligations. Une archive accessible peut suffire pour certains dossiers anciens, mais la décision doit être validée par les responsables métier et des données.
Peut-on nettoyer les doublons après le lancement?+
Certains cas peuvent être traités ensuite, mais les doublons qui affectent les relations, les montants ou les automatismes doivent être examinés avant. Sinon, le nouveau CRM peut propager la mauvaise information vers d’autres systèmes.
Comment éviter de perdre les changements pendant la migration?+
Définissez une période de gel ou une reprise des modifications depuis l’extraction initiale. Testez cette procédure. Chaque phase doit avoir un système de référence et un responsable, afin que les utilisateurs sachent où saisir l’information.
Comment prouver que la migration est complète?+
Combinez les comptes par catégorie, la vérification des relations, les contrôles des montants et les parcours utilisateurs. Conservez les écarts, les exclusions et les décisions. Le nombre de lignes importées seul ne prouve pas la qualité de la reprise.
Sources et méthode
Microsoft Learn — Import data from Excel and export data to CSV · OWASP — API Security Top 10, édition 2023. Sources consultées le 1er octobre 2026; les grilles et exemples de décision sont une analyse éditoriale de Daillac.
Évaluer votre reprise de données avant la bascule
Partagez la structure de vos données, les systèmes concernés et les processus prioritaires. Nous pourrons cadrer les essais, les contrôles et les responsabilités de migration.
D
Rédigé par
DaillacStratégie numérique et ingénierie logicielle — Saint-Jérôme · Grande région de Montréal
