Historique des tickets et conservation des données : que garder quand vous changez d’outil

Toute migration de helpdesk impose une question que la plupart des équipes repoussent depuis des années : à quoi sert vraiment tout cet historique ? Dix ans de tickets ressemblent à un actif — jusqu’au jour où il faut les déplacer. Ils deviennent alors une facture : heures d’export, temps d’import, stockage et bruit dans la recherche. La réponse honnête : cet historique remplit trois rôles, chacun avec sa durée de vie propre, et une fois ces rôles nommés, l’arbitrage conserver-ou-archiver se fait presque tout seul.

Les trois rôles de vos anciens tickets

Rôle 1 : le contexte agent. « Ce client nous a-t-il déjà écrit ? Que lui avons-nous promis ? » C’est l’usage quotidien, et il penche massivement vers le récent. Avant de croire la règle empirique de qui que ce soit, regardez vos propres données : quand un agent a-t-il ouvert pour la dernière fois un ticket de plus d’un an ? Dans la plupart des équipes, les consultations se concentrent sur les six à douze derniers mois, avec une traîne ténue pour les grands comptes actifs et les litiges en cours.

Rôle 2 : le reporting et les tendances. Courbes de volume, répartition des sujets, saisonnalité. Les rapports ont besoin d’agrégats, pas de conversations brutes — et un agrégat se calcule une fois, s’exporte en chiffres et se conserve indéfiniment pour un coût négligeable. Dix ans de tickets bruts ne sont pas nécessaires pour se souvenir que janvier est votre pic.

Rôle 3 : l’ancrage de l’IA. Le plus récent des trois, et le plus mal compris — il mérite sa propre section.

Remarquez ce qui manque : rien n’exige dix ans d’historique brut dans votre outil de travail. Le rôle 1 réclame de la fraîcheur, le rôle 2 des chiffres, et le rôle 3 — on va le voir — de la curation. L’instinct de tout migrer vient de l’aversion à la perte, pas d’un rôle que ces données rempliraient réellement.

Ce dont votre IA a réellement besoin (moins que vous ne le croyez)

Une intuition tentante souffle : plus d’historique, IA plus intelligente. Le fonctionnement de l’IA de support moderne dit l’inverse.

Les agents IA répondent à partir de votre base de connaissances — des articles à jour, tenus à la main — et non en fouillant des années de conversations brutes. Quand d’anciens tickets aident, ce sont les récents et bien résolus : ils montrent comment votre équipe formule les choses aujourd’hui, pour le produit que vous vendez aujourd’hui. Les vieux tickets décrivent des produits modifiés depuis, des politiques remplacées et des contournements déjà corrigés. Les injecter n’ajoute pas de sagesse : cela ajoute de la contradiction, et les contradictions ressortent en réponses fausses assénées avec aplomb.

Un effet de second ordre échappe à la plupart des équipes : un historique périmé pollue aussi la recherche côté agents. Quand un agent cherche « politique de remboursement » et récolte trois générations de politiques, le brouillon que l’IA rédige à partir de cette recherche hérite de la confusion. Un corpus élagué et récent n’est pas un compromis sur la qualité de l’IA — il est la qualité de l’IA. C’est pourquoi une migration est, discrètement, la meilleure préparation à l’IA qu’une équipe support puisse s’offrir : elle force le nettoyage du corpus que personne ne planifie jamais.

Le cadre conserver / archiver / supprimer

Trois catégories, tranchées par classe de données plutôt que ticket par ticket :

• Conserver (migrer en actif) : les 12 à 24 derniers mois de conversations, tous les contacts avec leurs champs personnalisés, toute la base de connaissances, et les litiges ouverts ou récemment clos quel que soit leur âge. Cela couvre la quasi-totalité des consultations réelles et tout ce dont l’IA tire profit.
• Archiver (exporter, stocker, ne pas importer) : tout le reste, en export lecture seule dans un format structuré — un JSON avec index vaut mieux qu’un CSV dès que vous pourriez avoir à y chercher — plus les pièces jointes, sur un stockage que vous contrôlez. L’archive sert aux rares audits, litiges ou accès de nostalgie ; elle n’a pas sa place dans l’index de recherche de votre outil de travail.
• Supprimer : les tickets fermés comme spam, les échanges d’un mot, les débris d’e-mails rejetés et les tickets de test. Ce n’est pas du minimalisme risqué, c’est du retrait de bruit. Personne n’a jamais eu besoin de l’archive des réponses automatiques.

Ce cadre a un effet secondaire agréable : votre nouveau helpdesk démarre vite et le reste, son index de recherche portant du signal plutôt que du sédiment.

Vos obligations de conservation, en clair

C’est le point où les équipes promettent trop ou se figent — alors restons simples et honnêtes. Les règles de conservation existent bel et bien, elles varient — et cet article est fourni à titre informatif et ne constitue pas un conseil juridique.

Quelques grands principes valent d’être connus :

• Certains documents sont soumis à une durée de conservation minimale imposée, selon les secteurs et les juridictions — typiquement la correspondance liée à la facturation, les réclamations en industrie régulée ou les pièces attachées à un contrat. L’obligation porte en général sur le type de document, pas sur le helpdesk dans son ensemble.
• Les régimes de protection des données personnelles, RGPD en tête, poussent dans le sens inverse : le principe de minimisation attend que vous ne gardiez les données personnelles que le temps nécessaire à une finalité déclarée. « On a tout gardé pour toujours parce que c’était plus simple à migrer » n’est pas une finalité.
• L’archivage n’exonère de rien au regard de la protection des données personnelles. Un ticket en stockage froid reste une donnée personnelle : demandes de suppression, demandes d’accès et obligations en cas de violation l’atteignent aussi là.

Le geste pratique : avant la migration, demandez au juridique ou à la conformité d’écrire noir sur blanc les durées de conservation par classe de données (tickets, contacts, pièces jointes, CSAT), même si la réponse tient en trois lignes. La migration se contente ensuite d’appliquer le tableau. Toute la relation tient là : le juriste décide, la migration exécute.

Les données personnelles dans l’archive

Si vous suivez ce cadre, c’est dans l’archive que se concentrent les anciennes données personnelles. Traitez-la donc en conscience :

• Restreignez les accès. Le helpdesk en production applique des droits par rôle ; votre archive aussi. Un stockage ouvert à tous contenant dix ans de conversations clients est un passif, pas une sauvegarde.
• Tenez un manifeste : ce que contient l’archive, les plages de dates, le format, et qui a validé sa durée de conservation. Le vous de demain, face à une demande de suppression, interrogera le manifeste plutôt que le dépôt brut.
• Concevez l’archive pour la suppression. Stockez les données par client, de façon à retirer les enregistrements d’une seule personne sans tout déballer. Une archive dans laquelle vous ne pouvez pas supprimer est une obligation que vous ne pouvez pas tenir.
• Fixez une échéance. Décidez quand l’archive elle-même sera réexaminée ou détruite, et posez-le dans l’agenda. Une conservation sans date de fin n’est que de l’accumulation avec un document de politique.

Ce que cela change pour votre plan de migration

La décision de conservation redessine la migration elle-même, et dans le bon sens : l’import en actif se réduit à une fraction du plan naïf « on déplace tout », d’où des fenêtres d’import plus courtes, une recherche propre dès le premier jour et un corpus IA net plutôt que trouble. Les équipes qui retiennent 12 à 24 mois plus les litiges voient couramment leur import se terminer en heures au lieu de jours.

La migration MoveDesk vous laisse choisir la profondeur d’historique au moment de l’import — et comme elle est gratuite et accompagnée, avec les deux outils en parallèle, vous pouvez commencer par 12 mois, vivre avec pendant un mois, puis importer plus profond si la réalité le demande un jour. D’expérience, elle le demande rarement.

Écrivez le tableau des trois catégories cette semaine — conserver, archiver, supprimer, avec une durée de conservation par classe. Cela tient sur une page, cela allège la migration, et cela améliore votre maîtrise des données au passage.