Trente jours pour changer d'outil sans fermer boutique

Changer de logiciel de courtage en six mois : pourquoi ça échoue

Plus une migration dure, plus elle coûte — moins en prestation qu'en énergie. La double saisie s'installe « en attendant », l'ancien outil survit parce que « tout n'est pas encore repris », et au bout de trois mois l'équipe a un avis définitif : c'était mieux avant. L'enthousiasme du choix initial ne survit pas à un chantier sans date de fin.

Le plan court force les arbitrages salutaires : on ne migre pas tout l'historique, on ne forme pas tout le monde à tout, on vise d'abord le quotidien opérationnel. Trente jours, c'est assez pour basculer proprement un cabinet de taille courante — et assez court pour que personne n'ait le temps de retourner à ses vieilles habitudes.

Le cadre : un cabinet de six personnes

Posons le décor : un cabinet de six personnes — un dirigeant, quatre conseillers dont un dédié à la santé-prévoyance, une assistante. L'existant : un CRM vieillissant, trois tableurs de suivi, une signature électronique à part et des documents réglementaires produits sous traitement de texte.

Deux rôles à nommer avant le jour 1 : un pilote de bascule — le dirigeant ou un associé, seul habilité à trancher les arbitrages — et un référent outil qui centralise les questions de l'équipe. L'éditeur vient en appui ; le pilotage reste au cabinet. Dernier prérequis : choisir un mois sans pic d'activité, loin des échéances de fin d'année.

Jours 1 à 7 : l'audit de l'existant

La première semaine ne touche à aucune donnée. Elle inventorie : les processus hebdomadaires du cabinet (lead entrant, devis, souscription, signature, relance, réclamation), les endroits où vivent les données, les outils satellites et leurs abonnements, les habitudes officieuses — le tableur personnel d'un conseiller compte autant que le CRM officiel.

L'audit débouche sur trois livrables courts : la liste des données à reprendre (vivantes et historique utile, le résidu part en archive), la carte des droits d'accès par personne, et la grille de paramétrage du nouvel outil — étapes de pipeline, familles de produits, modèles de documents. Si le choix de la cible n'est pas encore arrêté, reprenez d'abord notre guide pour choisir le logiciel de son cabinet de courtage : on ne migre bien que vers un outil choisi sur ses processus.

Jours 8 à 14 : la reprise des données

La deuxième semaine applique la méthode détaillée dans notre guide pour migrer d'Excel vers un logiciel métier : nettoyage des fichiers sources, dédoublonnage selon une règle écrite, cartographie des colonnes vers les champs cibles. C'est le gros œuvre — comptez quatre jours pleins sur les six.

Jour 12 : import d'un échantillon d'une cinquantaine de dossiers, vérifié ligne à ligne avec l'éditeur — rattachements contacts-contrats, échéances, montants. Jour 13 : corrections de cartographie. Jour 14 : import complet, puis contrôle par sondage sur vingt dossiers tirés au hasard. Le gel de saisie ne dure que ces deux derniers jours, posés en fin de semaine pour amortir l'impact.

Jours 15 à 21 : le double-run, court et cadré

Règle unique, affichée dès le jour 15 : le nouvel outil fait foi. Tout nouveau dossier, toute mise à jour s'y saisit ; l'ancien système ne sert plus qu'en consultation. Le double-run ne signifie pas double saisie — jamais — mais vérification en conditions réelles : un devis complet, une séquence de relance, une signature, un document réglementaire généré de bout en bout.

Chaque matin, dix minutes de point : blocages, contournements repérés, questions. Chaque blocage reçoit un propriétaire et une échéance. Les critères de sortie sont écrits d'avance — par exemple : dix dossiers traités de bout en bout sans retour à l'ancien outil, zéro saisie hors système depuis trois jours. Sans critères, le double-run devient l'organisation permanente du cabinet.

Former par rôle, pas par module

La formation « générale » d'une journée produit des équipes qui savent où sont les menus et pas comment faire leur travail. Formez par parcours : le conseiller sur lead-devis-signature, l'assistante sur documents et relances, le dirigeant sur le reporting et les droits. Deux heures ciblées par rôle valent mieux qu'un tour complet du produit.

Les questions réelles des jours 15 à 21 constituent le meilleur support de formation : le référent les consigne, l'éditeur y répond, et le tout devient l'aide-mémoire interne du cabinet. C'est aussi le moment de vérifier que chacun ne voit que ce que son profil autorise — la formation sert de test grandeur nature aux droits d'accès.

Jours 22 à 30 : bascule, arrêt de l'ancien, preuve de vie

Jour 22 : l'ancien outil passe en lecture seule — pas « bientôt », ce jour-là. Avant la résiliation, exportez et archivez l'intégralité des données de l'ancien système, même celles que vous n'avez pas reprises : l'archive coûte quelques gigaoctets, la donnée perdue coûte un contentieux. La résiliation, elle, se cale sur l'échéance contractuelle.

Jours 25 à 30 : la preuve, pas le sentiment. Comparez une semaine d'activité aux semaines normales — dossiers créés, relances parties, signatures réalisées, documents générés. Si les volumes tiennent, la migration est finie ; sinon, les écarts désignent précisément ce qui reste à régler. Les vérifications de sécurité et de réversibilité, elles, ont eu lieu avant le jour 1 : au jour 30, il ne devrait rester aucune question contractuelle ouverte.

Les cinq pièges classiques

Ils se ressemblent d'un cabinet à l'autre, et ils se préviennent tous dès le jour 1 :

Un dernier mot sur la cible : le paramétrage pèse d'autant moins que l'outil parle déjà le métier. Un généraliste à configurer entièrement allonge chaque étape du plan ; la comparaison entre Lizzee et un CRM classique montre ce que « prêt pour le courtage » change concrètement dans un calendrier de trente jours.

• Migrer 100 % de l'historique « au cas où » : le résidu ralentit tout — archivez-le hors outil ;
• Prolonger le double-run « encore une semaine » : sans date de fin, il devient l'organisation ;
• Former tout le monde à tout : chacun n'a besoin que de son parcours ;
• Ne pas nommer de pilote : un blocage sans propriétaire devient un retour à l'ancien outil ;
• Basculer pendant un pic d'activité : choisissez le mois le plus calme du cabinet.

FAQ

Trente jours, est-ce réaliste pour tous les cabinets ?

Pour une structure jusqu'à une dizaine de personnes avec des données raisonnablement tenues, oui. Ce qui allonge le calendrier, ce n'est presque jamais la technique : c'est l'état des données sources et la disponibilité du pilote. Si vos fichiers exigent trois semaines de nettoyage, prenez-les — mais gardez les autres phases courtes : audit resserré, double-run de sept jours, bascule datée.

Faut-il ralentir la prospection pendant la bascule ?

Non, le plan est construit pour l'éviter. L'activité continue pendant l'audit et la préparation des données ; seul l'import final impose un gel de saisie d'un à deux jours, placé en fin de semaine. À partir du jour 15, les nouveaux dossiers se créent directement dans le nouvel outil — la prospection sert alors de test en conditions réelles.

Que faire si une partie de l'équipe résiste au changement ?

Impliquez les sceptiques dès l'audit : ce sont souvent eux qui connaissent le mieux les défauts de l'existant. Formez par rôle pour que chacun voie vite son gain quotidien — la ressaisie qui disparaît parle plus qu'un argumentaire. Et tenez la règle du référentiel unique : quand l'ancien outil est en lecture seule, la résistance perd son terrain naturel.

Quand résilier l'abonnement de l'ancien logiciel ?

Après trois étapes, jamais avant : export complet archivé de l'ancien système, fin du double-run avec critères de sortie atteints, et semaine de preuve concluante. Ensuite, calez la résiliation sur l'échéance contractuelle en conservant si possible un accès en lecture seule jusque-là. Résilier trop tôt pour économiser un mois d'abonnement se paie très cher si une donnée manque.

Le double-run signifie-t-il saisir deux fois chaque dossier ?

Non, et c'est le point qui décide du succès. Le double-run consiste à faire fonctionner les processus réels dans le nouvel outil pendant que l'ancien reste consultable, sans jamais alimenter les deux. La double saisie épuise les équipes, crée des écarts entre les bases et prolonge indéfiniment la cohabitation. Un seul référentiel fait foi dès le premier jour de la phase.