Migrer son historique de tickets sans le perdre : journal d'une migration réelle
Une migration se joue deux fois. La première sert à produire la liste de ce qui va casser.
Changer d'outil de support est surtout un problème de données. Le nouveau produit se choisit en une semaine ; l'historique, lui, contient des années de conversations que vos agents citent, que votre juridique peut réclamer, et dont la perte ne se remarque que six mois plus tard.
Ce texte est écrit du point de vue de celui qui a écrit l'importeur. Les difficultés décrites ne sont pas des hypothèses : ce sont les endroits où le code a des cas particuliers.
Le compte à rebours des pièces jointes
C'est la contrainte la plus urgente et la moins connue. Dans les exports des outils du marché, une pièce jointe n'est pas un fichier : c'est une URL. Et cette URL est authentifiée, temporaire, et liée à votre compte source.
Conséquence directe : le jour où vous résiliez, ces URL cessent de fonctionner. Un export réalisé proprement six mois plus tôt, conservé dans un coin, contient donc des milliers de liens morts — et personne ne le sait avant d'aller chercher une capture d'écran dans un vieux ticket.
Les statuts et priorités sans équivalent
Chaque produit a son vocabulaire, et les correspondances ne sont ni évidentes ni sans perte. Quelques cas réels :
| Cas rencontré | La question | Ce qu'il faut décider |
|---|---|---|
| Un statut « en attente » qui couvre deux réalités | Attente du client ou attente d'un tiers ? | Deux statuts distincts, ou un seul et l'information perdue |
| Cinq niveaux de priorité contre quatre | Lequel fusionne avec lequel ? | Fusionner vers le haut ou vers le bas — cela change vos statistiques historiques |
| Des statuts personnalisés créés par l'équipe | Les recréer ou les projeter ? | Les recréer conserve l'histoire, les projeter simplifie l'avenir |
| Un ticket « résolu » puis « clos » 30 jours après | Deux dates ou une ? | La date de résolution est celle qui compte pour vos SLA historiques |
Il n'y a pas de bonne réponse universelle. Il y a une table de correspondance écrite, décidée avant de lancer, et conservée : le jour où un chiffre historique paraît étrange, c'est le premier document à relire.
Les anomalies que la répétition à blanc révèle
Une migration se joue deux fois. La première — la répétition à blanc — n'écrit rien : elle lit l'export, applique les correspondances, et produit la liste de ce qui ne passe pas. Voici les familles qui reviennent :
- Des utilisateurs sans adresse email. Ils existent : créés par une intégration, importés d'un ancien système, ou anonymisés par une demande d'effacement. Un contact sans email n'a pas d'identité pour le nouvel outil, et il faut choisir — un identifiant de repli, ou l'auteur du message devient anonyme.
- Des messages sans auteur. L'agent qui les a écrits a été supprimé du compte source, et l'export ne conserve qu'un identifiant qui ne résout plus.
- Des tickets dont le demandeur est un agent, parce que quelqu'un a créé un ticket au nom d'un client. Le nouvel outil doit décider si c'est un ticket interne ou un ticket client.
- Des dates impossibles : une réponse antérieure à la création, une résolution postérieure à la clôture. Elles viennent de fuseaux horaires appliqués deux fois quelque part dans l'histoire du système source.
- Des pièces jointes déjà mortes, dont l'URL a expiré avant même la migration.
Aucune de ces anomalies ne doit interrompre la migration : chacune doit produire une ligne dans un rapport et une décision par défaut. Un importeur qui s'arrête à la première donnée bizarre ne finira jamais sur des données réelles.
La vérification : compter, pas croire
« La migration a réussi » est une phrase sans contenu. Ce qu'il faut, ce sont des nombres comparés de part et d'autre, et la comparaison doit être faite par quelqu'un qui n'a pas écrit la migration.
- 1Compter les tickets, dans les deux systèmes, sur la même période. Un écart de trois est plus inquiétant qu'un écart de trois mille : trois, c'est un cas particulier silencieux ; trois mille, c'est un filtre oublié qu'on trouve tout de suite.
- 2Compter les messages, pas seulement les tickets. Un ticket peut arriver avec un seul message sur les quinze qu'il portait.
- 3Compter les pièces jointes, et leur poids total. Le poids est le seul contrôle qui détecte les fichiers rapatriés vides.
- 4Ouvrir les dix tickets les plus longs et lire le fil. Les cas limites sont dans les fils longs, pas dans la moyenne.
- 5Vérifier les extrêmes de dates : le plus vieux ticket et le plus récent. Un décalage de fuseau se voit là avant de se voir ailleurs.
La bascule des emails, le jour J
C'est le moment où l'on perd des demandes si l'ordre est mauvais. La séquence qui marche :
- 1Migrer l'historique avant de basculer la réception. L'ancien outil continue de recevoir pendant ce temps.
- 2Rejouer une migration incrémentale sur la période entre l'export et la bascule. C'est pour cette raison qu'un importeur doit être idempotent : rejouer ne doit rien dupliquer.
- 3Basculer les MX vers le nouvel outil, et garder l'ancien accessible en lecture au moins un mois.
- 4Surveiller les deux réceptions pendant quarante-huit heures. Un email en route au moment de la bascule arrive quelque part, et il vaut mieux savoir où.
Le piège de cette étape est celui décrit dans l'article sur la réception d'emails : une route qui n'existe pas pour le domaine exact accepte les messages et ne les transmet jamais, sans erreur. Le jour de la bascule est exactement celui où l'on ne veut pas de défaillance silencieuse.
Où nous en sommes
Notre importeur est écrit avec un adaptateur par produit source : chaque export est traduit vers une forme commune, et la partie coûteuse — celle qui écrit dans la base, gère l'idempotence et produit le rapport — est écrite une seule fois.
Aujourd'hui un seul adaptateur existe, pour Zendesk. Le suivant est Freshdesk, et il n'est pas écrit : nous préférons le dire ici plutôt que de laisser une page de migration le suggérer. Si vous venez d'un autre produit, l'import passe par un export tabulaire et une correspondance manuelle — c'est faisable et c'est plus de travail.
Une migration réussie ne se reconnaît pas à l'absence d'erreurs, mais à l'existence d'une liste écrite de ce qu'on a décidé de perdre.
Le code de l'importeur, ses correspondances et son rapport d'anomalies sont lisibles sous licence AGPL-3.0 — page open source. Et le coût de sortie d'un outil est la ligne qu'il faut négocier à l'entrée, quand on a encore le choix.
Nous ne publions pas d'article sans un chiffre mesuré chez nous, du code qu'on peut aller lire, ou une limite avouée. C'est la seule façon d'écrire sur ce métier sans répéter ce que tout le monde écrit déjà.