Aller au contenu principal
Quel Support Client

Migrations

Basculer sans coupure de service

Pour qui : Équipe en production qui ne peut pas arrêter de répondre pendant le changement d'outil.

Aides Help Scout, Gorgias, Intercom et Zendesk lues par extraction automatique le 3 novembre 2026. Méthode non exécutée.

Notre avis

Basculez un canal à la fois, en commençant par celui où une erreur coûte le moins, avec un critère d'arrêt écrit à l'avance. C'est notre méthode, et aucun éditeur que nous avons lu ne la documente. Help Scout demande même l'inverse : basculer les sources avant l'import complet et cesser le travail dans l'ancien outil au lancement. Lisez donc la consigne de votre outil d'arrivée avant de suivre la nôtre. Si vous êtes trois personnes sur un seul canal, basculez d'un coup un lundi.

Dans l’ordre

  1. Canal le moins risqué d'abord
  2. Critère d'arrêt écrit
  3. Bascule directe pour une petite équipe ou un seul canal

Pourquoi

  • Une erreur sur un canal se répare sans toucher les autres
  • Une date écrite empêche de rester à deux endroits

Ce qui change le choix

Toute petite équipe ou import prescrivant l'arrêt de l'ancien outil : une bascule directe, bien préparée, est plus sûre.

Ce que prescrivent les éditeurs

D'après les aides lues. Aucun ne décrit une bascule par canal ou par file.
OutilPrescriptionCe que cela implique
Help ScoutBasculer redirection et sources avant l'import complet, arrêter l'ancien outil au lancementUn arrêt net, à préparer
GorgiasSynchronisation toutes les 5 minutes, sans les statuts ; mettre en pause les conversations en cours pendant l'historiqueLe double travail fausse les statuts
IntercomInstantané sans synchronisation ultérieureTout ce qui arrive après reste dans l'ancien
Help Desk MigrationDéclare qu'on peut continuer dans l'ancien outil ; delta en PremiumDéclaration d'un tiers

Notre méthode, si plusieurs canaux coexistent

  1. Choisissez l'ordre. Du canal le moins risqué au plus risqué. Souvent le formulaire, puis l'e-mail, puis le chat. Une règle en amont : personne ne répond à deux endroits.
  2. Écrivez le critère d'arrêt. Exemple : une demande perdue, ou un retard de plus de X heures sur un motif grave. Le choix du X vous appartient et s'écrit avant.
  3. Basculez à une date calme. Hors pic, et hors fin de mois si vos clients y écrivent davantage. Prévoyez une personne en renfort.
  4. Fixez une date de fin. Une bascule qui dure devient une double exploitation : deux outils, deux sources de chiffres, deux factures.

Le piège : les réponses aux anciens tickets

Un client qui répond à un e-mail reçu avant la bascule répond à un fil de l'ancien outil. Aucun éditeur lu ne décrit ce qui se passe alors. Un outil tiers et un fil de forum évoquent un risque de nouveau ticket ou de non-transfert. Prévoyez donc le pire : testez ce scénario vous-même avec un message de test, et gardez l'ancienne adresse redirigée. Ne supposez pas que les identifiants suivront.

DNS : un changement de domaine personnalisé prend quelques heures à un jour selon le TTL chez Zendesk. Baissez-le quelques jours avant.

Limites

Méthode propre, sans appui éditeur et sans exécution de notre part. Comportement d'une réponse à un ancien ticket non documenté par les éditeurs lus. Remappage d'identifiants non établi.

Prochaine action

Lisez la consigne de votre outil d'arrivée, écrivez votre ordre et votre critère d'arrêt, puis testez une réponse à un ancien ticket.

Preuves et sources

Ce qui relève d’un fait lu, d’une déclaration, de notre calcul, de notre méthode ou de notre avis. Notre méthode