Remplacer son outil de ticketing : ce qui casse vraiment
Ces migrations échouent rarement sur la technique. Elles échouent sur l'historique, les contournements informels des équipes, et le périmètre qui grossit en route.
Le remplacement d’un outil de gestion des demandes est le projet le plus sous-estimé du portefeuille d’une DSI d’ETI. Il paraît circonscrit, il est vendu comme rapide, et il déborde presque systématiquement. Ce qui suit porte sur les causes réelles de ce débordement.
Le périmètre est toujours plus grand que prévu
Le projet démarre sur le support informatique. Il finit rarement là.
Dès que l’outil est en place, les services généraux découvrent qu’ils pourraient tracer leurs interventions. Les ressources humaines voient une réponse à leurs demandes d’onboarding qui arrivent aujourd’hui par messagerie. La direction qualité veut y mettre ses non-conformités. Chacune de ces demandes est légitime, et leur somme transforme un projet de trois mois en programme de dix-huit.
Cette dérive n’est pas un accident : c’est le signe que l’outil répond à un besoin réel non couvert. La question n’est donc pas de l’empêcher, mais de la séquencer.
Décidez avant le choix de l’outil si le périmètre est informatique seul ou multi-métiers. Ce choix détermine l’outil, le budget et la gouvernance, et il ne se rattrape pas en cours de route.
Un outil choisi pour le support informatique seul se révèle souvent coûteux à étendre, parce que la facturation est établie par intervenant et que chaque domaine métier arrive comme un module additionnel. Un outil choisi d’emblée pour plusieurs métiers coûte plus cher au démarrage mais absorbe l’extension sans renégociation.
L’historique : la question qu’on repousse et qui bloque
C’est le point qui fait le plus déraper les plannings, parce qu’il est traité en fin de projet alors qu’il est structurant.
La demande initiale est presque toujours de tout reprendre. Elle ne résiste pas à l’examen. Reprendre dix ans de tickets suppose de faire correspondre des catégories qui ont changé trois fois, des utilisateurs partis, des champs personnalisés supprimés, des pièces jointes stockées hors base. Le coût est considérable et l’usage quasi nul : au-delà de deux ans, la consultation d’un ticket clos relève de l’exception.
La position qui tient en pratique : migrer l’intégralité des tickets ouverts, une profondeur limitée d’historique clos, et conserver le reste en export consultable. Cet arbitrage doit être écrit et validé par le responsable du support avant le début des travaux, sans quoi il ressurgira à trois semaines de la bascule.
Les contournements que personne ne documente
Dans toute équipe de support installée depuis plusieurs années, il existe des pratiques qui ne figurent dans aucune procédure et sans lesquelles rien ne fonctionne.
Un champ commentaire détourné pour stocker un numéro de série. Une catégorie qui ne veut pas dire ce que son intitulé indique. Un ticket ouvert systématiquement sur un utilisateur fictif pour les interventions de nuit. Une convention de nommage qui permet de retrouver les demandes d’un site donné parce que le champ site n’a jamais été fiable.
Ces contournements sont invisibles dans une spécification et se découvrent le jour de la bascule, quand l’équipe constate qu’elle ne sait plus faire son travail. La seule méthode efficace consiste à passer une demi-journée à côté de deux techniciens, à les regarder travailler, avant d’écrire quoi que ce soit. Ce que vous verrez ne correspondra pas à ce que la documentation décrit, et c’est cet écart qui est l’information utile.
Ce qui compte réellement au moment de choisir
Une fois le périmètre arbitré, les critères qui font la différence à l’usage sont moins nombreux qu’il n’y paraît.
Le modèle de facturation. Par intervenant, par salarié, par module. C’est le critère qui détermine le coût à trois ans, bien plus que le prix affiché la première année. Un outil facturé par intervenant devient coûteux dès que vous ouvrez le périmètre à d’autres métiers, puisque chaque nouvel intervenant métier se paie au tarif d’un technicien informatique.
La capacité de paramétrage sans prestataire. Formulaires, catégories, workflows simples. Si chaque modification suppose un bon de commande, l’outil se fige en dix-huit mois et vous vous retrouvez avec le problème que vous cherchiez à résoudre.
La localisation des données et l’hébergement, selon votre exposition réglementaire. Le sujet est devenu discriminant pour les organisations entrant dans le champ de NIS2, et il conditionne parfois des clauses contractuelles avec vos propres clients.
La réversibilité. La capacité d’exporter vos données dans un format exploitable, sans intervention de l’éditeur. Vérifiez-la pendant l’évaluation, pas au moment de partir.
Sur le marché francophone, les options couramment évaluées par une ETI vont des solutions open source comme GLPI ou iTop, qui n’ont pas de coût de licence mais un coût d’exploitation réel, aux plateformes internationales comme Freshservice, Jira Service Management ou ManageEngine, facturées par intervenant, jusqu’aux éditeurs français comme EasyVista ou Keolux One. Ce dernier facture au salarié plutôt qu’à l’intervenant, entre 1,00 et 1,50 euro hors taxes par salarié et par mois selon l’effectif, tous domaines inclus, ce qui change le calcul dès lors que le périmètre dépasse l’informatique. Aucun de ces outils n’est un bon choix dans l’absolu : le modèle de facturation doit correspondre à la forme de votre périmètre.
La bascule
Deux principes réduisent nettement le risque du jour J.
Ne pas faire fonctionner deux outils en parallèle plus de quelques jours. La double saisie est refusée par les équipes en moins d’une semaine, et vous vous retrouvez avec deux référentiels incomplets. Une bascule franche, un vendredi soir, avec l’ancien outil en lecture seule, produit de meilleurs résultats qu’une transition douce théorique.
Prévoir une présence physique renforcée la première semaine. Pas une formation en amont, dont il ne restera rien : quelqu’un à côté des techniciens pendant qu’ils travaillent réellement. C’est le poste de dépense le plus rentable de tout le projet, et le premier à sauter quand le budget se tend.
Ce qu’on ne récupère jamais
Une dernière chose, rarement dite. Une migration d’outil ne corrige pas un problème d’organisation du support. Si les demandes arrivent aujourd’hui par téléphone, par messagerie et dans les couloirs, elles continueront après. L’outil change le lieu de l’enregistrement, pas les habitudes de sollicitation.
Ce chantier existe, il est utile, mais c’est un chantier distinct. Le mener en même temps que la migration technique est la manière la plus sûre de rater les deux.
Questions fréquentes
- Faut-il migrer l'historique des tickets ?
- Rarement en totalité. Migrer les tickets ouverts et une profondeur d'historique limitée, souvent douze à vingt-quatre mois, couvre l'usage réel. Le reste se conserve en export consultable hors de l'outil. La migration intégrale coûte cher, retarde la mise en service, et sert des consultations qui n'ont presque jamais lieu.
- Combien de temps prend le remplacement d'un outil de ticketing ?
- Pour un périmètre informatique seul, dans une ETI, comptez de six semaines à trois mois entre la décision et l'usage réel, dont l'essentiel n'est pas du paramétrage mais de la reprise de processus et de la conduite du changement. Les délais annoncés par les éditeurs décrivent la mise à disposition de la plateforme, pas l'adoption.
- Faut-il reprendre les processus existants ou repartir de zéro ?
- Ni l'un ni l'autre intégralement. Reprendre à l'identique reproduit les contournements accumulés. Repartir de zéro impose une conduite du changement que l'équipe ne supportera pas en même temps que l'outil. Reprendre le processus tel qu'il est réellement pratiqué, puis corriger deux ou trois points, est le compromis qui tient.