Basculer d’un helpdesk à un autre est l’une des migrations les plus sensibles qui soient : chaque minute d’indisponibilité se traduit par des clients sans réponse, des SLA qui s’allongent et des agents désorientés. Passer de Zendesk à Freshdesk, c’est transplanter non seulement des centaines de milliers de tickets, mais aussi l’historique complet de la relation client — conversations, pièces jointes, champs personnalisés, macros et automatisations — sans jamais fermer le canal de support. Voici la méthode pour y parvenir sans impact.

Pourquoi migrer de Zendesk vers Freshdesk ?

Zendesk est une référence incontestée, mais sa grille tarifaire, la séparation de certains modules et le coût des fonctionnalités avancées poussent de nombreuses entreprises à chercher une alternative. Freshdesk, édité par Freshworks, propose un rapport fonctionnalités/prix attractif, une interface jugée plus simple par les équipes support, et une montée en charge progressive du plan gratuit jusqu’à l’édition entreprise avec SLA, champs personnalisés et automatisations. La migration répond donc souvent à une logique d’optimisation budgétaire et d’ergonomie, sans sacrifier le niveau de service.

Ce qui se transporte, ce qui doit être reconstruit

Tout ne migre pas automatiquement. Il faut distinguer deux familles d’objets :

  • Repris automatiquement : tickets, conversations et notes internes, pièces jointes, demandeurs et entreprises, groupes et agents, statuts et priorités, tags.
  • Reconstruit ou configuré à la main : workflows d’automatisation, macros, vues partagées, formulaires de tickets, champs personnalisés, règles de routage, SLA et horaires de service, ainsi que le centre d’aide et ses articles.

Cette distinction est essentielle : une automatisation Zendesk (triggers, automations) n’a pas de traduction directe vers Freshdesk (scenario automations, dispatcher). Elle doit être réécrite en respectant la logique propre de l’outil cible, ce qui exige une vraie analyse métier.

Les étapes de la migration Zendesk → Freshdesk

  1. Audit de l’instance Zendesk : extraire la liste exhaustive des tickets, champs personnalisés, groupes, vues, triggers, automations, macros, SLA et articles du centre d’aide.
  2. Nettoyage préalable : clôturer ou archiver les tickets anciens, fusionner les demandeurs en doublons, supprimer les champs et vues inutilisés.
  3. Cartographie des objets : établir la table de correspondance entre chaque objet Zendesk et son équivalent Freshdesk (statuts, priorités, types de champs, rôles).
  4. Extraction des données : utiliser l’API Zendesk (endpoints d’export incrémental des tickets, api/v2/incremental/tickets/cursor.json) pour récupérer tickets et pièces jointes, en gérant la pagination par curseur et les limites de débit.
  5. Transformation : adapter le format des données (dates, tags, champs) à la structure attendue par l’API Freshdesk, et reconstruire les liens entre conversations et demandeurs.
  6. Import : injecter les données dans Freshdesk via son API (création de tickets, contacts, compagnies), par lots, en surveillant les quotas d’appels.
  7. Reconfiguration : recréer les scénarios d’automatisation, macros, vues, formulaires, SLA et le portail client.
  8. Test et validation : contrôler l’intégrité d’un échantillon de tickets, l’historique des conversations et les pièces jointes, avant la bascule définitive.

Les risques à maîtriser

Le premier risque est la perte d’historique : si les pièces jointes ou les conversations internes ne suivent pas, l’agent perd le contexte de résolution, et la qualité de service chute. Le deuxième est la rupture du canal entrant : adresses e-mail de support, formulaires web, widgets de chat et intégrations (téléphonie, CRM, Slack) doivent être rebranchés simultanément, sinon les demandes se perdent. Le troisième est la dérive des automatisations : une règle mal transcrite peut router les tickets vers le mauvais groupe ou déclencher des réponses erronées.

Bonnes pratiques pour une bascule sans coupure

  • Réaliser une migration pilote sur un sous-ensemble de tickets pour valider le mapping et mesurer les durées d’import.
  • Utiliser la bascule progressive : migrer l’historique complet en amont, puis basculer les canaux entrants au dernier moment, pendant une fenêtre à faible trafic.
  • Maintenir Zendesk en lecture seule pendant la transition pour permettre aux agents de consulter l’ancien historique jusqu’à validation complète.
  • Former les agents à Freshdesk avant la bascule, avec des parcours de prise en main et des scénarios types.
  • Prévoir un plan de repli : tant que les canaux ne sont pas pleinement opérationnels, conserver un mécanisme de réception de secours.

Conduire le changement

Le support est un métier d’habitudes. Changer d’outil perturbe le quotidien des agents ; une adoption réussie passe par des ateliers de formation, un référent par équipe et une documentation des nouveaux workflows. L’objectif est que les agents retrouvent immédiatement leurs réflexes : répondre vite, avec le bon contexte client.

Gérer la reprise des macros, champs et automatisations

Les macros de Zendesk (réponses pré-rédigées appliquées en un clic) n’ont pas d’équivalent identique dans Freshdesk ; elles se recréent sous forme de canned responses ou de scénarios. Leur transcription doit préserver les placeholders (nom du client, nom de l’agent, numéro de ticket) pour rester exploitables. Les champs personnalisés se reprennent par une correspondance de types : champ texte vers champ texte, liste déroulante vers liste, date vers date, en surveillant les valeurs autorisées pour éviter les rejets à l’import.

Les vues partagées de Zendesk (listes filtrées de tickets) se recréent dans Freshdesk avec une logique de filtre proche mais pas identique ; chaque vue doit être reproduite puis vérifiée sur un jeu de tickets réels. Les triggers et automations se réécrivent dans les scénarios Freshdesk, dont le modèle événementiel diffère : il faut tester chaque règle (création de ticket, changement de statut, réponse client) avec des tickets de test avant la mise en production, car une règle mal transcrite peut router les tickets vers le mauvais groupe ou notifier la mauvaise personne.

Un point souvent négligé est la reprise des demandeurs et organisations : un historique de ticket n’a de valeur que si le demandeur est correctement rattaché. La fusion des doublons par adresse e-mail et la conservation des identifiants de demandeur tout au long de la chaîne d’import sont indispensables pour que l’agent retrouve, sur chaque ticket, le bon client et son historique complet.

Tester et mesurer la réussite de la bascule

Une migration de helpdesk ne se valide pas à l’œil : elle se mesure. Avant la bascule, il faut définir des indicateurs de contrôle : nombre de tickets importés par statut, nombre de conversations et de pièces jointes, nombre de demandeurs et d’organisations. Ces compteurs servent de référence pour la réconciliation post-import. Après la bascule, on surveille la continuité des canaux : les e-mails entrants arrivent-ils dans les bonnes files d’attente ? Les formulaires web créent-ils des tickets ? Le chat répond-il ? Enfin, on mesure la satisfaction agent et le temps moyen de réponse pendant les premières semaines pour détecter toute dégradation liée à un workflow mal reconstruit.

Performances Digital accompagne ces migrations d’helpdesk de bout en bout : extraction et transformation des tickets via les API, reprise de l’historique et des pièces jointes, réécriture des automatisations, reconnexion des canaux entrants et formation des équipes support. Nous garantissons une bascule sans perte d’historique et sans rupture de service.

Une migration Zendesk vers Freshdesk réussie est une migration invisible pour vos clients et transparente pour vos agents. Demandez votre devis gratuit : nous auditons votre instance, évaluons vos volumes et vous remettons un plan de migration chiffré, adapté à la taille de votre équipe support.