La Réponse Courte
Le remplacement d'un système CRM par Salesforce n'est pas un simple projet technique de "transfert de données" ; c'est une décision organisationnelle concernant ce qui mérite d'être conservé, ce qui doit être abandonné, et comment maintenir l'activité de l'entreprise pendant la transition. L'échec le plus courant ne réside pas dans l'intégration de Salesforce, mais dans l'hypothèse tacite que tout ce qui existe dans l'ancien système doit être transféré tel quel.
L'approche correcte commence par la modélisation des processus, et non par l'exportation de tableaux. Un nouveau modèle de données est ensuite construit, correspondant à la manière dont l'organisation opère aujourd'hui, et non à une structure établie il y a dix ans dans un autre système. Une période de parallélisme contrôlée, suivie d'une désactivation ordonnée de l'ancien système avec documentation réglementaire, complète le processus.
Les organisations confrontées à ces questions trouveront des informations complémentaires dans Implémentation de Salesforce dans une organisation, qui détaille le processus global de prise de décision pour un projet Salesforce.
Cartographie des processus existants : comprendre, pas exporter
La première étape de toute migration entre systèmes CRM n'est pas de procéder à un "Export", mais de s'asseoir avec les propriétaires de processus pour comprendre ce qui se passe réellement entre l'ouverture d'un prospect et la conclusion d'une affaire, ou entre la réception d'une demande et la clôture d'un dossier de service. Un ancien document de processus, s'il existe, est presque toujours obsolète par rapport à la réalité opérationnelle.
Lors des réunions de cartographie, il est conseillé de documenter non seulement les étapes officielles, mais aussi les "processus de l'ombre" : fichiers Excel parallèles, champs jamais renseignés, validations effectuées via WhatsApp plutôt que dans le système. Ce sont précisément ces points où un nouveau système, même bien construit, échouera en termes d'adoption s'ils ne sont pas pris en compte.
Le résultat de cette cartographie doit inclure un tableau des processus clés, le propriétaire de chaque processus, la fréquence d'utilisation et le degré de dépendance vis-à-vis de l'ancien système. Un processus exécuté une fois par trimestre et générant un rapport critique pour un régulateur nécessite une approche différente d'un processus quotidien à volume élevé. Une telle classification détermine également l'ordre de la migration et le niveau de test requis pour chaque processus.
Ce qu'il ne faut pas transférer : une décision qui réduit de moitié le travail
L'une des décisions les plus importantes dans un projet de migration CRM n'est pas ce qu'il faut transférer, mais ce qu'il ne faut pas transférer. La plupart des systèmes anciens, accumulés au fil des années, contiennent des couches de champs dupliqués, des statuts remplacés et des processus définis pour un projet ponctuel déjà achevé.
Règle pratique : tout objet ou champ qui n'a pas été utilisé au cours des deux dernières années est par défaut placé dans la liste "ne pas transférer", à moins qu'un propriétaire de processus spécifique ne demande une exception justifiée. Cette liste est établie en s'appuyant sur les logs d'utilisation réels de l'ancien système, et non sur la mémoire des utilisateurs, car la mémoire humaine décrit souvent le système tel qu'il était censé fonctionner, et non tel qu'il fonctionne réellement.
Il est crucial de distinguer trois catégories d'informations :
- Informations actives – Doivent être transférées vers le nouveau système en tant qu'enregistrements actifs avec toutes leurs interconnexions.
- Informations historiques pertinentes – Transférées en tant qu'archives consultables, généralement sans besoin d'édition ou d'automatisation.
- Informations obsolètes – Ne sont pas transférées du tout, conservées uniquement dans une sauvegarde externe pour des raisons d'audit éventuelles.
Des précisions sur la gestion des frontières entre la phase de planification et la phase de construction sont fournies dans Le dérapage du périmètre dans Salesforce, car la tendance à ajouter "un peu plus de données anciennes" est l'une des sources les plus courantes de dérapage de périmètre dans ce type de projets.
Modèle de données : ne pas traduire, mais concevoir
Une erreur courante est d'aborder la modélisation des données comme une traduction 1:1 : chaque table de l'ancien système devient un objet Salesforce, chaque colonne un champ. Cette approche perpétue toutes les faiblesses de l'ancien système au sein d'une nouvelle plateforme, et manque l'avantage central de Salesforce : la capacité à créer des relations flexibles entre objets, une automatisation intégrée et une couche de permissions riche.
La comparaison entre les deux approches principales de migration aide à prendre une décision éclairée :
| Aspect | Lift-and-Shift (Transfert tel quel) | Redesign (Refonte) |
|---|---|---|
| Durée du projet | Relativement courte, généralement 6-10 semaines | Plus longue, généralement 3-5 mois |
| Adéquation aux processus métier | Faible — conserve les anciennes limitations | Élevée — construite autour du processus actuel |
| Risque de dette technique | Élevé, se manifeste après un ou deux ans | Plus faible, car la structure est planifiée en amont |
| Coût de maintenance futur | Augmente avec le temps | Relativement stable |
| Convient pour | Organisations sous pression de temps extrême ou périmètre très limité | La plupart des organisations migrant d'un système de plus de trois ans |
| Risque principal | "Nouveau système, problèmes anciens" | Dépassement de calendrier si le périmètre n'est pas bien défini |
En pratique, la plupart des organisations optent pour une approche hybride : une refonte (Redesign) pour le modèle de données central (comptes, contacts, opportunités ou dossiers de service) et un transfert contrôlé (Lift-and-Shift) pour les entités secondaires n'ayant pas d'impact significatif sur les processus. Cette décision doit être prise explicitement lors de la phase de planification, et non se produire de manière accidentelle pendant la construction.
Période de parallélisme : maintenir la continuité des activités
La période de parallélisme est la fenêtre de temps pendant laquelle les deux systèmes fonctionnent simultanément, généralement entre quatre et huit semaines. Son objectif est de révéler les lacunes en temps réel, avant qu'elles ne deviennent des problèmes irréversibles. Une vente conclue, une demande de service ouverte ou un rapport de commission généré — tous ces éléments doivent être vérifiés simultanément dans les deux systèmes et présenter un résultat identique ou justifié.
Une question récurrente dans presque tous les projets : quel système est considéré comme la "source de vérité" pendant cette période ? La réponse doit être unique et prédéfinie, généralement Salesforce dès le premier jour, l'ancien système ne servant alors qu'à la validation et non aux opérations courantes. Un double travail des utilisateurs sur les deux systèmes mène à la fatigue et à l'abandon de facto du nouveau système.
Outils pratiques pour gérer cette période :
- Un rapport de comparaison quotidien ou hebdomadaire des données clés entre les deux systèmes (nombre de leads, montant des transactions, demandes ouvertes).
- Une liste vivante d'exceptions mise à jour dès qu'un écart est détecté, avec un responsable attitré pour le résoudre dans un délai défini.
- Un groupe "d'utilisateurs clés" de chaque département qui signalent quotidiennement les problèmes d'utilisation, et non seulement les problèmes techniques.
Bon nombre des enseignements recueillis durant cette période sont également pertinents pour le processus de test formel, détaillé dans le Guide UAT pour Salesforce, et pour la période post-lancement, décrite dans le Plan Hypercare pour Salesforce.
Déconnexion de l'ancien système : une séquence de décisions, pas un événement unique
La déconnexion de l'ancien système s'effectue par étapes, et non par un simple clic le jour du basculement (Cutover). La règle directrice : le système est déconnecté des opérations courantes dès le Go-Live, mais reste accessible en lecture seule pendant une courte période de grâce, généralement 30 à 60 jours, au cas où une donnée manquante ou une question de l'équipe financière surgirait.
Liste de contrôle pour la décision de basculement (Cutover)
Avant d'envoyer l'annonce officielle de la déconnexion de l'ancien système, il est conseillé de vérifier :
- ☐ Que chaque rapport régulièrement généré par l'ancien système a été reproduit avec succès depuis Salesforce ou l'archive.
- ☐ Qu'un cycle commercial complet (par exemple, un mois de clôture complet) a été achevé entièrement au sein du nouveau système.
- ☐ Que les écarts de données entre les systèmes sont tombés en dessous d'un seuil prédéfini (par exemple, moins de 1% des enregistrements).
- ☐ Qu'une confirmation écrite du service juridique ou financier atteste que l'archive répond aux exigences de conservation.
- ☐ Qui est responsable de l'accès en lecture pendant la période de grâce et quand celle-ci sera définitivement fermée.
- ☐ Qu'une sauvegarde complète et vérifiée de toutes les données de l'ancien système a été effectuée avant l'annulation de la licence.
- ☐ Qu'une notification a été envoyée à tous les propriétaires de processus concernant la date de déconnexion finale et la procédure d'accès à l'archive.
Omettre l'un de ces points est la raison la plus fréquente pour laquelle, des mois après le projet, il est découvert qu'il n'y a pas d'accès à des informations soudainement requises pour un audit fiscal ou un litige juridique.
Archive et Réglementation : ce qu'il faut conserver et pour combien de temps
Les exigences de conservation des données varient d'un secteur à l'autre, mais il est presque toujours obligatoire de conserver les données financières, contractuelles, ou celles liées aux plaintes clients, pendant une période de sept ans, voire plus. L'erreur fréquente est de tenter de "pousser" tout cet historique dans Salesforce comme enregistrements actifs, ce qui alourdit les performances et déroute les utilisateurs qui voient des transactions datant d'une décennie dans leurs listes quotidiennes.
La solution courante est la séparation en deux couches :
| Couche | Contenu | Emplacement | Accessibilité |
|---|---|---|---|
| Informations opérationnelles actives | Les 24-36 derniers mois | Salesforce | Complète, y compris édition et automatisation |
| Archive réglementaire | Historique complet requis par la loi | Data warehouse externe ou Salesforce Archive | Lecture seule, avec capacité de recherche |
Il est crucial de documenter par écrit la politique d'archivage et d'obtenir l'approbation du service juridique avant de couper l'accès à l'ancien système. En effet, une fois la licence annulée, il n'y a pas de retour en arrière possible si une donnée manquante est découverte.
Cas d'étude d'une organisation
Une société de services financiers est passée d'un système CRM local de 12 ans à Salesforce. L'équipe a identifié, lors de la phase de cartographie, qu'environ 40% des champs existants n'avaient pas été utilisés depuis deux ans ou plus, et a décidé de les exclure de la migration. Cela a permis d'économiser environ un mois de travail en construction et en tests.
Pendant la période de parallélisme, qui a duré six semaines, un écart dans le calcul des commissions a été découvert, dû à une différence d'arrondi des nombres entre les systèmes. Cette anomalie n'aurait pas été détectée sans un rapport de comparaison quotidien. L'équipe a corrigé la formule avant qu'elle n'affecte un bulletin de salaire réel. L'ancien système a été déconnecté des opérations courantes le jour du Go-Live, mais un accès en lecture seule a été maintenu pendant 45 jours supplémentaires pour la vérification d'un rapport trimestriel déjà en cours.
Le résultat : trois mois après la déconnexion définitive, aucun accès supplémentaire à l'ancien système n'a été nécessaire, et les économies sur les coûts de licence ont couvert une grande partie du coût du projet de migration lui-même.
Risques courants et actions préventives
| Risque | Comment il se manifeste en pratique | Action préventive |
|---|---|---|
| Transfert "de tout" sans filtrage | Le nouveau système est encombré de données obsolètes et ralentit l'adoption | Définir un critère de filtrage basé sur l'utilisation réelle des deux dernières années |
| Modèle de données copié | Les mêmes limitations de l'ancien système réapparaissent dans Salesforce | Concevoir un nouveau modèle basé sur le processus actuel, non sur les anciennes tables |
| Parallélisme sans responsable | Les écarts entre les systèmes sont détectés tardivement ou pas du tout | Rapport de comparaison périodique avec un responsable désigné pour chaque exception |
| Déconnexion trop hâtive | Une donnée manquante est découverte après l'annulation de la licence | Période de grâce avec accès en lecture seule avant la désactivation finale |
| Ignorance des exigences d'archivage | Un audit réglementaire révèle que des informations requises n'ont pas été conservées correctement | Obtenir une approbation juridique écrite de la politique d'archivage avant le Cutover |
Comment mesurer le succès de la transition
| Domaine | Ce qui est mesuré | Fréquence de vérification |
|---|---|---|
| Intégrité des données | Taux d'enregistrements transférés avec succès sans erreur | Avant et après chaque exécution de migration |
| Uniformité entre les systèmes | Écarts dans les rapports clés entre l'ancien et le nouveau | Quotidiennement pendant la période de parallélisme |
| Adoption par les utilisateurs | Taux d'utilisation du nouveau système par rapport au retour à l'ancien | Hebdomadaire pendant le premier mois |
| Coût opérationnel | Économies sur les licences et la maintenance après déconnexion | Mensuel à partir de trois mois après le Go-Live |
Pour le remplacement d'un système CRM par Salesforce, il est recommandé de choisir à l'avance trois à cinq indicateurs clés uniquement, et de les mesurer avant et après le projet. Autrement, il est difficile de prouver que la transition a réellement amélioré un processus plutôt que de simplement le déplacer vers une autre plateforme. La réalisation effective d'un tel processus peut être menée avec le soutien d'un service d'implémentation Salesforce, qui accompagne les organisations de la phase de cartographie jusqu'à la déconnexion de l'ancien système.
Sources Professionnelles
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Implémentation Salesforce — https://hpi.pro/salesforce-implementation
- HPI Pro – Méthodologie de travail — https://hpi.pro/methodology