Migration sans interruption : deux helpdesks en parallèle

Certaines équipes peuvent profiter d’un week-end calme et changer de helpdesk d’un seul geste. D’autres ne le peuvent pas : le support tourne 24 h/24, le volume ne retombe jamais, ou un lundi chaotique coûterait tout simplement trop cher. Pour celles-là, il existe un autre schéma — le fonctionnement en parallèle. La migration cesse d’être un événement de bascule pour devenir un curseur : deux helpdesks vivent en même temps, le trafic passe de l’ancien au nouveau canal par canal, et l’ancien outil ne s’éteint que le jour où les chiffres disent qu’on peut le faire sans risque.

Bien mené, ce schéma ne se voit pas côté client et n’expose jamais les agents à un saut dans le vide. Mené à la légère, il produit les deux ratés classiques : le client reçoit deux réponses de deux personnes différentes, ou n’en reçoit aucune parce que chaque outil supposait que l’autre s’en occupait. Entre les deux, il n’y a qu’une poignée de règles.

Le principe : router le neuf, vider l’ancien

Une seule règle porte tout le dispositif : les nouvelles conversations démarrent dans le nouvel outil ; celles qui sont en cours se terminent là où elles ont commencé.

Rien ne déménage en cours de fil. Un client qui a écrit mardi dans l’ancien système reçoit sa réponse du jeudi depuis l’ancien système, d’un agent qui a tout l’échange sous les yeux. Un client qui écrit pour la première fois après la bascule arrive dans la nouvelle boîte de réception. Chaque conversation a un domicile et un seul, déterminé par son point de départ — à tout instant, les deux équipes et les deux outils savent donc sans ambiguïté à qui appartient quoi.

L’ancien helpdesk cesse d’être votre système de support pour devenir une file en cours de vidange : plus aucune entrée, un arriéré qui fond, et une ligne d’arrivée visible.

Basculez les canaux un par un

Le fonctionnement en parallèle marche parce que vous ne misez jamais tous les canaux d’un coup. Un ordre classique, du risque le plus faible au plus élevé :

1. Le chat du site. Un snippet à remplacer, réversible en un instant, et des conversations courtes — la vidange des échanges en cours prend des heures, pas des semaines. C’est votre répétition générale à faible enjeu.
2. Un alias e-mail secondaire — l’adresse à faible volume, pas la vitrine. Observez une semaine entière de trafic de bout en bout : routage, attribution, escalades, CSAT.
3. L’e-mail de support principal. À ce stade, le processus a fait ses preuves ; seul le volume change.
4. Les messageries instantanées et les réseaux sociaux — leur reconnexion dépend souvent d’étapes côté plateforme : planifiez ce rebranchement au lieu de le tenir pour acquis.

Accordez à chaque canal une période de recouvrement — quelques jours pendant lesquels il tourne sur le nouvel outil pendant que vous vérifiez qu’il ne fuit nulle part — avant de passer au suivant. L’échelle complète s’étale en général sur deux à quatre semaines. Plus lent, c’est très bien ; sauter des barreaux, c’est ainsi que les surprises s’accumulent.

Garder des données cohérentes entre deux outils

L’architecture tentante, c’est une synchronisation bidirectionnelle en temps réel entre les deux systèmes. Résistez. Une synchro bidirectionnelle entre helpdesks est une tuyauterie fragile qui casse en silence, et elle prétend résoudre un problème que la règle de routage a déjà réglé — personne n’a besoin que les deux outils contiennent chaque conversation pendant la période de parallèle ; ce qu’il faut, c’est que chaque conversation ait un domicile unique maintenant, et que le nouvel outil détienne l’archive complète à la fin.

Le schéma qui fonctionne est bien plus simple :

• Un import en masse avant le début du parallèle : historique, contacts, base de connaissances et macros arrivent dans le nouvel outil pour que les agents aient le contexte dès le premier jour.
• Un import différentiel à la fin : une fois la file de l’ancien outil vidée, un dernier passage récupère tout ce qui y a été créé pendant le recouvrement. L’archive est complète au moment précis où l’ancien outil part à la retraite.
• Les contacts convergent sur l’e-mail comme clé de déduplication : un client apparu dans les deux outils pendant le recouvrement fusionne en une seule fiche au lieu de devenir des jumeaux.

Qui répond où : organiser l’équipe sans dédoublement

Répartissez l’équipe par canal, pas par ancienneté : ceux qui tiennent le chat passent sur le nouvel outil le jour où le chat bascule ; l’équipe e-mail suit quand l’e-mail bascule. Chaque agent traverse en même temps que son canal, donc personne ne travaille sur deux files à la fois — et c’est précisément cette double saisie qui fabrique la double réponse.

Deux règles d’appui :

• Les ambassadeurs traversent en premier. Les agents qui apprennent le plus vite prennent le premier canal : quand l’e-mail principal bascule, le nouvel outil a déjà ses experts maison sur chaque créneau.
• L’ancien outil reçoit une date de fin, inscrite dans l’agenda et visible de tous. Un parallèle sans échéance encourage le campement dans la file familière — les agents s’attardent dans l’outil qu’ils connaissent — et vous finissez par payer deux systèmes par pure inertie.

Les indicateurs pendant la période double

Pendant un recouvrement, les chiffres agrégés mentent : la file de l’ancien outil rétrécit par construction, celle du nouveau grossit par construction, et toute moyenne combinée mesure surtout le dosage entre les deux, pas la qualité du service. À la place :

• Suivez le délai de première réponse et le délai de résolution outil par outil, et comparez les chiffres du nouvel outil à la référence d’avant migration de l’ancien — c’est la seule comparaison honnête, à périmètre égal.
• Surveillez la courbe d’arriéré de l’ancien outil. Elle doit décroître sans jamais remonter ; un plateau signifie que quelque chose y achemine encore des demandes entrantes, et trouver cette fuite devient la tâche la plus importante de la journée.
• Attendez-vous à ce que les chiffres du nouvel outil démarrent légèrement en dessous, puis repassent au-dessus de la référence en une à deux semaines par canal, le temps que les habitudes se prennent.

Critères de sortie : quand éteindre l’ancien outil

Écrivez-les avant que le parallèle ne commence, pour que la décision soit une checklist et non un débat :

• Tous les canaux routés vers le nouvel outil, chacun ayant achevé sa période de recouvrement.
• La file en cours de l’ancien outil descendue sous un seuil convenu, avec les retardataires explicitement réattribués.
• L’import différentiel exécuté, et des vérifications par sondage qui confirment que l’archive est complète.
• Les indicateurs du nouvel outil, canal par canal, au niveau de la référence d’avant migration ou au-dessus.
• Intégrations, webhooks et automatisations vérifiés : ils pointent uniquement vers le nouvel outil.
• La validation de l’équipe — les responsables de créneau confirment que plus rien ne dépend de l’ancien système.

Ensuite : ancien outil en lecture seule jusqu’à la fin du cycle de facturation (assurance bon marché et référence honnête), résiliation confirmée par écrit, et export d’archive rangé quelque part que vous maîtrisez.

Les défaillances à neutraliser dès la conception

• La double réponse — toujours le symptôme d’un agent qui tient les deux files, ou d’un canal routé vers les deux outils. La règle de routage et la répartition par canal l’empêchent structurellement.
• Les alias orphelins — l’adresse de redirection oubliée qui alimente encore l’ancien outil alors que « tout » a basculé. Le plateau de l’arriéré la démasque.
• Les intégrations qui écrivent dans la dépouille — un webhook ou un script qui crée encore des tickets dans l’ancien système. Ce n’est pas par hasard qu’elles figurent dans les critères de sortie.
• Le parallèle éternel — six mois à payer deux outils parce que personne n’était responsable de la date de fin. Fixez-la dès le premier jour.

Ce que MoveDesk apporte

MoveDesk est pensé pour le fonctionnement en parallèle : la migration accompagnée, gratuite, comprend à la fois l’import en masse initial et le passage différentiel final ; le nombre illimité d’utilisateurs permet à toute l’équipe de vivre dans les deux outils pendant le recouvrement, sans arithmétique de licences ; et l’essai de 14 jours couvre confortablement les premiers barreaux de l’échelle des canaux. Si vous vous demandez à quoi ressemble l’autre rive du recouvrement, la comparaison avec Intercom détaille le chemin de migration.

Choisissez votre premier canal — le chat, sans doute — et fixez dès aujourd’hui la date de fin de l’ancien outil. Une migration en parallèle sans date de fin n’est pas une migration ; c’est un second abonnement.