La plupart des migrations CRM sont gérées comme une liste de tâches. Mapper les données, construire les workflows, planifier les formations, choisir une date de launch. La liste passe au vert, quelqu’un déclare le projet terminé, et le matin du go-live l’équipe au contact des clients se connecte à un système que personne n’a réellement utilisé de bout en bout. C’est à ce moment que les failles apparaissent, en production, avec de vrais clients dans les enregistrements.
Le problème, c’est qu’une liste de tâches confirme que le travail est fait. Elle ne confirme pas que le flux fonctionne. Un workflow peut être construit et se déclencher quand même sur le mauvais trigger. Une property peut être mappée et atterrir quand même dans une view que le rep n’ouvre jamais. Une pipeline peut être configurée et n’avoir quand même aucun chemin de la stage où un lead entre jusqu’à la stage où un deal se gagne. Rien de cela n’apparaît dans un status sheet. Cela apparaît la première fois qu’un vrai enregistrement tente de parcourir tout le journey, et si cette première fois est votre go-live, vous débuguez l’infrastructure de revenu pendant que vos gens essaient de vendre dessus.
Il y avait autrefois de la marge dans le système pour absorber un launch chaotique. Quelques personnes éteignaient les workflows cassés pendant une semaine, l’admin corrigeait en direct, et l’équipe rejoignait l’adoption tant bien que mal. Ce coussin a largement disparu. L’analyse GTM 2026 de SaaStr montre que l’entreprise médiane prévoit zéro pour cent de croissance de headcount RevOps cette année, avec des orgs GTM 20 à 30 pour cent plus allégées et bien plus plates qu’avant. Les gens qui absorbaient un cutover raté n’existent plus sur l’organigramme.
L’enjeu de l’autre côté est plus élevé aussi. Vous n’avez pas beaucoup d’essais. Comme le formule SaaStr dans son article 2026 sur le lock-in CRM, la migration est en général « trop douloureuse pour être justifiée » une deuxième fois, et à mesure que vous branchez des agents et des automatisations sur le CRM, le changement passe de pénible à « pratiquement impossible ». Le CRM go-live est presque une porte à sens unique. Le dry run, c’est la façon de s’assurer qu’elle ouvre sur la bonne pièce.
Voici la distinction que je graverais dans tout plan de migration. Il y a deux types de confirmation, et les équipes collectent systématiquement le premier et sautent le second.
Le premier est la confirmation des tâches : les données sont mappées, les workflows construits, les views configurées, le deck de formation rédigé. C’est nécessaire et c’est ce que suit votre plan de projet. Le second est la confirmation du flux : un vrai enregistrement, partant de là où un vrai client partirait, va jusqu’au deal gagné, et chaque stage, property, workflow et view qu’il touche en chemin fait ce qu’il doit faire. Presque personne ne réserve de temps pour le second. C’est l’assurance la moins chère que vous puissiez acheter avant un CRM go-live, et c’est l’étape qu’on coupe quand la date de launch se resserre.
Un dry run n’est pas une démo et ce n’est pas un UAT dans une sandbox où l’admin clique sur les happy paths. C’est une répétition chronométrée et de bout en bout de tout le customer journey dans le système que vous allez lancer, exécutée par les personnes qui possèdent chaque partie, à la recherche précise de ce qui casse.
Ce que je recommande : bloquez deux heures, mettez un enregistrement à l’écran, et faites-le passer du premier contact au deal gagné devant toute l’équipe. Un lead entre. Atterrit-il dans la bonne pipeline ? Le workflow qui doit se déclencher se déclenche-t-il vraiment ? Quand le rep ouvre le contact, voit-il la même view que son collègue, ou y a-t-il cinq layouts différents si bien que personne ne regarde les mêmes données ? Quand le deal change de stage, la prochaine action est-elle créée ? Quand il se gagne, le handoff vers l’onboarding ou le service se déclenche-t-il ? Vous ne testez pas si les pièces existent. Vous testez si les pièces se connectent.
La raison de le faire en direct, ensemble et à voix haute, c’est que les failles vivent dans les coutures entre le travail des uns et des autres. La personne qui a construit le workflow de lead-routing et celle qui a construit les deal stages ont chacune testé sa propre pièce en isolation, et chaque pièce a passé. Le journey traverse les deux, et la cassure est presque toujours à la jointure. Vous ne voyez la jointure que lorsqu’un enregistrement parcourt l’ensemble en une seule séance.
Nous avons récemment travaillé avec une entreprise B2B SaaS en Series B dans la région DACH qui migrait de Salesforce vers HubSpot, avec une date de go-live ferme et une équipe au contact des clients qui n’avait jamais touché le nouveau setup. Le plan de projet était en bon état : mapping des données scopé, workflows construits, formation planifiée.
Deux choses sont sorties du fait d’insister sur un dry run avant le cutover. Premièrement, en faisant passer un enregistrement dans le journey, plusieurs workflows avaient été construits correctement en isolation mais n’étaient jamais branchés au trigger que le vrai customer journey produit, si bien qu’un contact pouvait entrer et rester là, sans étape suivante. Un status sheet aurait montré ces workflows comme « faits ». Le dry run les a montrés comme des impasses. Deuxièmement, l’équipe n’avait pas prévu de migrer les notes et l’activité historiques de l’ancien système, seulement les enregistrements ouverts. Cela paraît raisonnable jusqu’à ce qu’on réalise qu’au jour un un rep reprend un compte actif, ne voit aucun historique, et ouvre discrètement l’ancien CRM dans un autre onglet pour le retrouver. Au moment où vos gens gardent l’ancien système ouvert, l’adoption est déjà perdue, et vous payez deux CRM pour en faire tourner un. Nous avons attrapé les deux avant le launch parce que nous avons joué le journey, pas la checklist.
- Réservez le dry run comme un événement à part, avant le go-live. Deux heures, toute l’équipe, calé dans l’agenda comme une working session, pas un status call. S’il n’est pas dans l’agenda avec un owner clair, il sera écrasé par la date de launch. Traitez-le comme un gate que le go-live doit passer, pas comme un nice-to-have.
- Faites passer un vrai enregistrement du premier contact au deal gagné. Choisissez un scénario représentatif et suivez-le jusqu’au bout : création du lead, routing, qualification, chaque stage, la conclusion, et le handoff après la conclusion. Ne sautez pas à la partie intéressante. C’est dans les transitions ennuyeuses que se cachent les impasses.
- Testez les coutures, pas les pièces. À chaque handoff, demandez si la chose suivante se déclenche : le workflow, la tâche, la notification, le changement de view, l’attribution. Les objets individuels ont déjà été testés par celui qui les a construits. Votre travail dans le dry run, ce sont les connexions entre eux.
- Migrez l’historique, pas seulement les enregistrements ouverts. Décidez explicitement quel historique client passe : notes, activité passée, contexte antérieur. Si les reps ne peuvent pas voir ce qui s’est passé avant le go-live, ils garderont l’ancien système ouvert, et c’est le moyen le plus rapide de perdre l’adoption. Si vous ne pouvez pas tout amener, amenez assez pour qu’aucun rep n’ait de raison de rouvrir l’ancien CRM.
- Standardisez les views avant le launch, pas après. Une view commune et adaptée au rôle, pour que tout le monde voie les mêmes données quand on partage un enregistrement. Ma règle : changez la view selon où l’enregistrement se situe dans son lifecycle, pas selon qui le regarde. Un contact avant d’être client devrait avoir une autre allure qu’un contact qui est client. Cinq layouts personnels au jour un, ce sont cinq personnes qui se parlent à côté en semaine un.
- Rédigez la documentation à partir de la version qui marche. Enregistrez le dry run, puis construisez le guide utilisateur à partir du flux que vous venez de confirmer, avec des captures d’écran des vraies étapes. Une documentation écrite avant que le système soit confirmé documente un système qui n’existe pas encore.
- Placez le dry run tôt dans la journée, et réservez le temps de correction après. Partez du principe que le dry run trouvera des failles, car il en trouvera, et que certaines exigeront de nouveaux workflows. Faites-le le matin pour que la personne qui doit corriger ait encore l’après-midi. Un dry run sans temps de correction réservé après n’est qu’une liste de problèmes que vous connaissez désormais et ne pouvez pas résoudre avant le launch.
Vous n’avez pas besoin d’un programme formel pour ça. Vous avez besoin de deux heures, d’un enregistrement, des bonnes personnes dans la pièce, et de la discipline de suivre tout le journey plutôt que les parties dont vous êtes sûr. Le dry run, c’est la différence entre trouver vos failles dans une working session calée une semaine avant le launch et les trouver en production avec un client au bout du fil. L’un est bon marché. L’autre vous coûte le go-live et une partie de votre adoption.
Si vous préparez un CRM go-live et voulez un partenaire qui mène le dry run avant le cutover, c’est exactement le type de travail que nous faisons : scoper la migration, brancher les workflows, et répéter tout le customer journey avant que quiconque ait à vendre dessus. Lisez l’article compagnon sur l’écart d’adoption CRM qui s’ouvre après le launch, ou voyez comment nous abordons les revenue operations de bout en bout.
- SaaStr. « The Modern GTM Org in 2026: Leaner, Flatter, and More Revenue Per Rep. » SaaStr, janvier 2026. saastr.com
- SaaStr. « Which CRM Should You Use in 2026/2027? Follow the Agents. » SaaStr, février 2026. saastr.com
Carolina Decastri