Salesforce
Migrer de TeamLeader vers Salesforce sans perdre dix ans d'historique : la méthode qu'on applique
par Paul Mantez, Co-fondateur & Développeur
TeamLeader est un bon CRM de démarrage. Beaucoup de PME y ont mis dix ans de relation client : comptes, contacts, devis, notes de rendez-vous. Le jour où l'entreprise vend dans plusieurs pays, où les remises doivent être validées par paliers, où le parc installé chez les clients devient un actif à suivre, l'outil atteint sa limite. Et la question qui arrive tout de suite après « on passe sur Salesforce ? », c'est : « et notre historique, on le perd ? »
Non. Mais la façon de le reprendre décide de tout ce qui suit. Cet article décrit la méthode qu'on applique, telle qu'on l'a déroulée pour un fabricant d'instruments scientifiques présent dans huit pays, avec une trentaine de commerciaux et une direction qui voulait que le CRM devienne la source de vérité de l'entreprise.
Pourquoi l'export Excel est le mauvais point de départ
La tentation est forte : TeamLeader exporte des fichiers, Salesforce importe des fichiers, il suffirait de faire correspondre les colonnes. Ça marche pour une liste de contacts. Ça casse dès qu'on a plusieurs objets liés entre eux.
Un export à plat perd trois choses. Les liens d'abord : quelle affaire appartient à quel compte, quel contact a signé quel devis. On peut les reconstruire par le nom de la société, mais deux comptes homonymes, une raison sociale saisie avec ou sans « SAS », et l'affaire atterrit au mauvais endroit. Les identifiants ensuite : sans clé stable, chaque relance de l'import recrée tout, et on se retrouve avec des doublons à nettoyer à la main. L'historique enfin : notes, e-mails liés, dates de création réelles, tout ce qui n'a pas sa colonne dans l'export.
TeamLeader expose une API officielle. On l'interroge en lecture seule, objet par objet, avec pagination, et chaque enregistrement arrive avec son identifiant TeamLeader et les identifiants de ce à quoi il est rattaché. C'est ce graphe-là qu'on transporte, pas des feuilles de calcul.
La clé de voûte : un External ID sur chaque objet
Dans Salesforce, on crée sur chaque objet cible (Account, Contact, Opportunity, Quote, et les objets métier ajoutés) un champ marqué External ID, qui reçoit l'identifiant TeamLeader. L'import se fait alors en upsert : Salesforce cherche l'enregistrement par cet identifiant, le met à jour s'il existe, le crée sinon.
Ça change la nature de la migration. Elle n'est plus un acte unique et anxiogène, c'est un traitement rejouable. On lance un premier import complet dans la sandbox pour la recette. On corrige le mapping, on relance : pas de doublon. On importe en production deux semaines avant le go-live pour que les commerciaux se forment sur leurs vraies données. La veille de la bascule, on passe un delta : seulement ce qui a changé dans TeamLeader depuis le dernier passage. Personne ne travaille un week-end pour « faire la migration ».
Les liens entre objets se posent de la même façon : pour rattacher une affaire à son compte, on ne cherche pas le compte par son nom, on le référence par son External ID. Salesforce résout la relation lui-même.
Décider ce qu'on reprend : compter avant de trancher
Chaque migration a son débat : « on reprend les affaires perdues de 2017 ? », « les contacts qui n'ont pas bougé depuis cinq ans ? ». Ces débats durent des heures quand ils sont menés de mémoire. Ils durent dix minutes quand ils sont menés sur des chiffres.
On extrait donc d'abord, on compte ensuite, on décide enfin. Combien d'affaires par statut et par année. Combien de contacts sans aucune activité depuis trois ans. Combien de comptes probablement en double (même SIREN, même domaine e-mail, même adresse). Combien de devis rattachés à une affaire encore ouverte. Chaque arbitrage de mapping est chiffré depuis les données avant d'être discuté.
La règle qui en sort est souvent la même : tout ce qui sert au reporting (le chiffre d'affaires par compte, le taux de conversion par zone) ou à la relation (les notes, les interlocuteurs) est repris. Le reste est archivé hors CRM, dans un export daté qu'on sait retrouver. Un CRM neuf n'a pas besoin de porter des données que personne ne consultera.
Ce qu'il faut concevoir avant de migrer, pas après
La migration n'est jamais la première étape. Sur le projet cité plus haut, elle est venue après sept ateliers de cadrage, un par domaine : pipeline commercial, leads et attribution par zone, devis et catalogue, support, portail distributeurs, marketing, ERP. Chaque atelier produit un compte-rendu, des décisions tracées, et des feuilles de validation par objet que le client relit avant qu'on configure quoi que ce soit.
Trois sujets en particulier doivent être tranchés avant d'importer la première ligne, parce qu'ils changent la structure des données.
Le multi-devises. C'était la raison numéro un de quitter TeamLeader : impossible de faire un devis depuis l'Inde, taxes locales non gérées. Dans Salesforce, l'activation du multi-devises est définitive et modifie tous les champs de montant. On l'active avant la migration, avec des taux datés, sinon on migre deux fois.
La hiérarchie des comptes. Un groupe, ses filiales, ses sites : TeamLeader les voit à plat, Salesforce sait les emboîter. Décider du modèle (qui est le parent, où se consolide le chiffre) avant d'importer évite de tout re-rattacher.
Ce qui devient un objet. Un parc d'instruments noté en texte libre dans TeamLeader devient un objet Asset dans Salesforce, un par machine installée, avec sa date, son modèle, son site. Les demandes produit que les commerciaux remontaient par e-mail deviennent un objet Wishlist lu par la R&D. Ce sont ces objets qui justifient le changement d'outil ; ils se dessinent en atelier, et la migration les alimente.
Et une recommandation qu'on répète à chaque projet : configurer sobre. Deux profils clonés et six permission sets plutôt qu'une usine à profils, des raisons de perte obligatoires, des approbations de remise par paliers, et pas de personnalisation lourde du processus de vente. L'adoption se joue là.
Le calendrier réel d'un projet
Pour donner un ordre de grandeur, voilà comment les semaines se répartissent sur une migration de cette taille, PME avec quelques milliers de comptes et une équipe commerciale répartie.
| Phase | Durée indicative | Ce qui s'y passe |
|---|---|---|
| Cadrage | 4 à 6 semaines | Ateliers par domaine, décisions tracées, feuilles de validation par objet |
| Configuration | 4 à 6 semaines | Modèle de données, profils et permissions, automatisations, devis |
| Migration en sandbox | 1 à 2 semaines | Extraction API, comptages, mapping, premier import complet, recette |
| Formation sur vraies données | 2 semaines | Import en production, les commerciaux s'entraînent sur leurs comptes |
| Go-live | 1 jour | Delta de la veille, bascule, TeamLeader passe en lecture seule |
La migration technique est la phase la plus courte. C'est aussi celle qui fait le plus peur, et c'est précisément pour ça qu'on la rend rejouable : la peur vient de l'acte unique, pas du volume.
Et l'ERP, dans tout ça ?
Une migration CRM déterre presque toujours la question de l'ERP, même quand elle n'était pas au contrat. Le catalogue produits, les tarifs, les commandes : si le CRM devient la source de vérité pour la vente, il doit parler à l'outil de gestion.
Sur le projet cité, l'ERP était Infor. Plutôt que des développements coûteux côté ERP, on a cadré cinq flux (produits et tarifs, comptes d'achat, commandes, parc installé, clients) et choisi un échange par fichiers plats déposés sur SFTP, Salesforce restant le référentiel maître. C'est le même modèle que la passerelle entre Sage X3 et Salesforce qu'on décrit dans un autre article : partir de ce que l'ERP sait produire, et faire le travail d'intégration à côté.
Le point à retenir : anticipez l'ERP dès le cadrage, même si l'intégration se fait dans un second temps. Le modèle de données du CRM doit prévoir la place du catalogue et des commandes, sinon on refait le modèle six mois plus tard.
Questions fréquentes
Peut-on migrer de TeamLeader vers Salesforce sans perdre son historique ?
Oui, à condition d'extraire les données par l'API de TeamLeader et non par export Excel. Chaque compte, contact, affaire, devis ou note arrive alors avec son identifiant TeamLeader, ce qui permet de reconstruire les liens entre objets dans Salesforce et de rejouer l'import sans créer de doublon.
Combien de temps prend une migration TeamLeader vers Salesforce ?
Pour une PME avec quelques milliers de comptes, comptez trois à quatre mois entre le premier atelier et le go-live, dont la moitié pour le cadrage et la configuration. La migration technique elle-même se joue en quelques jours, mais elle est rejouée plusieurs fois : un premier import complet pour la recette, puis un delta la veille du go-live.
Faut-il reprendre toutes les affaires perdues et les vieux contacts ?
Pas forcément, mais décidez-le sur des chiffres, pas de mémoire. On compte d'abord ce qu'il y a dans TeamLeader (affaires par statut et par année, contacts sans activité depuis trois ans, doublons probables) et on tranche objet par objet. Une règle simple : tout ce qui sert au reporting ou à la relation client est repris, le reste est archivé hors CRM.
Qu'est-ce qu'un External ID et pourquoi c'est indispensable pour migrer ?
C'est un champ Salesforce marqué comme identifiant externe, dans lequel on stocke l'identifiant TeamLeader de chaque enregistrement. L'import se fait alors en upsert sur ce champ : si l'enregistrement existe, il est mis à jour ; sinon, il est créé. C'est ce qui rend la migration rejouable et permet un delta juste avant le go-live.
TeamLeader gère les devis et les factures, Salesforce aussi ?
Salesforce gère les devis en standard (objet Quote) et, pour aller plus loin, avec Revenue Cloud. Pour les factures, la réponse dépend de votre outil comptable ou de votre ERP : en général on garde la facturation dans l'outil de gestion et on synchronise les commandes depuis Salesforce. Le sujet se règle en atelier, pas après la migration.
Que faire du multi-devises et des taxes locales quand on vend dans plusieurs pays ?
C'est souvent la raison de quitter TeamLeader. Salesforce gère le multi-devises nativement, avec des taux datés, et les devis se font dans la devise du client. Il faut l'activer avant la migration, car l'activation est définitive et change la structure des montants sur tous les objets.
Quitter TeamLeader pour Salesforce, ce n'est pas un déménagement de données, c'est une conception de CRM dont la migration est la dernière étape. Lue par l'API, portée par des External ID, rejouée jusqu'à être ennuyeuse, elle ne perd rien. Ce qui compte, c'est ce qu'on a décidé avant.
Vous êtes sur TeamLeader et vous sentez la limite ? On cadre la migration avec vous, données comprises →