Un client nous a récemment contactés avec un problème que la plupart des entreprises de services en pleine croissance connaissent bien. Son activité était répartie entre ClickUp et Freshservice. Il souhaitait une gestion plus fine des autorisations pour ses relations clients hautement réglementées, ainsi que la marge d'automatisation nécessaire pour assurer un service client homogène à grande échelle. Son choix s'est porté sur HaloPSA, convaincu que cette solution pourrait remplacer les deux outils existants. Cependant, un obstacle se dressait : il était impératif de conserver des années de données historiques, essentielles à la continuité de service pour ses propres clients. Autrement dit, le principal frein à la migration vers un nouvel outil serait une tâche que personne n'apprécie : la migration des données.
La solution technologique est généralement évidente lorsqu'on fait appel à nous : une plateforme cible plus adaptée existe. Le problème n'est pas le choix de l'outil, mais la crainte d'une migration lente, coûteuse et imprévisible. Des tickets seront perdus, les rapports dysfonctionneront, les équipes se rebelleront, les organismes de réglementation ou les clients pourraient s'y opposer, et les coûts exploseront.
Mais rien de tout cela n'est inévitable. Bien menée, la migration de données ne doit pas empêcher votre entreprise d'utiliser les outils adéquats. La consolidation peut – et doit – être une opportunité d'améliorer le fonctionnement de l'entreprise, et non un simple transfert de données. Voici notre approche.
Les deux moitiés de la consolidation
Un projet de consolidation comporte deux moitiés faciles à confondre mais de nature très différente.
La première étape consiste à migrer les données : transférer les tickets, commentaires, pièces jointes, utilisateurs, champs personnalisés et historiques des plateformes sources vers la plateforme cible. Il s'agit d'un travail véritablement technique. Pour les cas un peu complexes, on utilise des API, souvent en suivant un ordre précis, car les pièces jointes dépendent des tickets, les commentaires des utilisateurs, les champs personnalisés des schémas, etc. L'importation de fichiers plats permet d'avancer, mais ne suffit pas. C'est précisément le type de tâche pour lequel des outils spécialisés, comme Help Desk Migration , existent.
La seconde étape consiste à repenser le modèle opérationnel : définir comment la nouvelle plateforme doit concrètement fonctionner pour l’entreprise. Quels types de tâches y transitent ? À quoi ressemble un reporting efficace ? Qui est responsable de quelles files d’attente ? Quelles nouvelles fonctionnalités sont désormais disponibles (facturation, libre-service client, gestion intégrée des changements) et lesquelles sont prioritaires à activer immédiatement ?
Ces deux aspects sont indissociables. Se concentrer sur le premier ne fait que reproduire le désordre existant dans un nouveau système. Se concentrer uniquement sur le second vous laisse bloqué, car les données historiques ne seront pas disponibles.
La plupart des projets de consolidation échouent car ils sont souvent perçus comme une simple migration de données. Les gains les plus importants – et les risques les plus élevés – résident dans le modèle opérationnel.
Pourquoi la consolidation est plus difficile qu'il n'y paraît
Une partie de la complexité est d'ordre technique, une autre d'ordre organisationnel. Voici les pièges les plus fréquents :
1. Le mappage des données est chaotique. Les différents outils structurent les mêmes concepts différemment. Noms de statut, niveaux de priorité, types de tickets, champs personnalisés, catégories, types de demandes : la correspondance est rarement directe. La difficulté ne réside pas dans la création du mappage, mais dans la définition de ce mappage, ce qui impose des choix de modèle opérationnel prématurés.
2. Le modèle agent/utilisateur/client varie selon les outils. Certaines plateformes distinguent les agents internes, les utilisateurs externes et les clients externes en trois entités distinctes. D'autres les fusionnent. Certaines permettent aux agents d'être des partenaires externes, d'autres non. La Freshservice modélisation des utilisateurs diffère entre Halo , Jira Service Management . Migrer des utilisateurs est rarement un simple copier-coller ; c'est une adaptation, et les choix effectués à cette étape influencent les permissions, les rapports et les licences pour les années à venir.
3. Les champs personnalisés et les types de tickets s'accumulent. La plupart des systèmes sources accumulent des années de personnalisation, dont certaines sont utiles, mais la plupart sont oubliées. Migrer l'ensemble du système recrée le même problème de maintenance dans un nouvel outil. Migrer uniquement ce qui est nécessaire oblige à des discussions franches avec les personnes qui ont créé ces champs.
4. La gestion des permissions se complexifie. Une plateforme consolidée est généralement utilisée par plus d'équipes que n'importe quelle source individuelle. Cela implique de nouveaux modèles de permissions, de nouvelles règles de visibilité et une exigence accrue de perfectionnement, car les erreurs sont plus visibles.
5. Les erreurs apparaissent en premier lieu au niveau des rapports. Les systèmes sources comportent souvent des rapports qui dépendent de structures de champs, de statuts ou de conventions de nommage spécifiques. Lorsque ces éléments changent dans la cible, les rapports deviennent inopérants et les parties prenantes le remarquent immédiatement. Les exigences en matière de reporting doivent être intégrées à la conception de la migration, et non ajoutées a posteriori.
6. Une migration de test complète est généralement nécessaire. Pas un échantillon, pas une migration partielle : une migration complète de test d'acceptation utilisateur (UAT) avec des données réelles, par rapport à la cible configurée, effectuée par les utilisateurs finaux du nouveau système. C'est là que les véritables surprises surviennent : des structures de données inattendues, des choix de mappage erronés, des intégrations à ajuster. Prévoyez le temps et le budget nécessaires. Tenter de sauter cette étape est le raccourci le plus coûteux en matière de consolidation.
7. Les exigences réglementaires et clients dictent souvent les éléments à préserver. Il arrive qu'un client souhaite « abandonner l'ancien système et repartir à zéro », mais ses propres clients ou les organismes de réglementation exigent la conservation de l'historique des tickets, commentaires et pièces jointes à des fins d'audit. Cela modifie complètement le périmètre de la migration, car l'historique des commentaires et des pièces jointes est la partie qui nécessite le plus de travail sur les API et une planification rigoureuse. Nous avons eu des projets où l'exigence de conservation des données était la seule raison de la complexification de la conception de la migration. Renseignez-vous au plus tôt.
Une approche pratique
Chaque consolidation que nous avons réalisée a suivi plus ou moins le même schéma. L'ordre importe moins que les intitulés.
1. Comprendre l'utilisation réelle. Avant toute cartographie, il est essentiel de comprendre comment les systèmes sources sont réellement utilisés aujourd'hui, et non selon leur usage prévu ou la documentation. Consultez les rapports d'utilisation. Échangez avec les utilisateurs. Vous constaterez généralement qu'une part importante des personnalisations du système source est inactive ou obsolète. Ce n'est pas un problème, mais une opportunité de simplifier la cible.
2. Définir le modèle opérationnel cible. C'est la question fondamentale : qu'attendez-vous de la nouvelle plateforme, par rapport aux anciennes ? Un meilleur reporting des SLA ? Une facturation intégrée ? Des portails de demandes en libre-service ? Une gestion des changements liée à une CMDB ? Chacune de ces fonctionnalités oriente la configuration dans une direction particulière. Déterminez vos objectifs d'optimisation avant de commencer la cartographie des données.
3. Concevoir la cartographie des données en fonction du nouveau modèle, et non de l'ancien. L'erreur la plus fréquente consiste à transposer directement la structure des données sources dans la cible. L'approche idéale consiste à cartographier les données sources à travers le modèle opérationnel cible : quels champs sont pertinents, lesquels sont archivés, lesquels sont supprimés et lesquels sont consolidés ? C'est à ce stade que convergent les décisions relatives au modèle opérationnel et la migration technique.
4. Effectuez des migrations tests ciblées. Avant la répétition générale, (les tickets d'une seule équipe, un workflow personnalisé ou un groupe d'utilisateurs) afin de valider le bon fonctionnement de la logique de mappage et du séquencement des API de bout en bout. Ces essais courts permettent de détecter les problèmes à un stade où leur correction est peu coûteuse.
5. Effectuez une migration complète en conditions d'acceptation utilisateur (UAT). La répétition générale. Données complètes, configuration complète, utilisateurs réels testant des scénarios réels. Prévoyez le temps nécessaire. Cette étape est déterminante pour le bon déroulement de la migration.
6. Effectuez la migration avec un plan, pas au hasard. Communication, critères de retour en arrière, couverture du support, répartition des responsabilités pendant la période de transition. La migration elle-même est généralement moins spectaculaire si les tests d'acceptation utilisateur (UAT) ont été approfondis.
7. Accompagnez efficacement l'adoption. Un nouvel outil parfaitement fonctionnel mais inutilisé est un projet voué à l'échec. Son adoption nécessite des ambassadeurs internes, une documentation claire, une formation adaptée aux méthodes de travail réelles et un soutien manifeste de la direction. C'est cet aspect que les projets de migration purement techniques négligent systématiquement.
Un exemple récent
La migration a dû gérer trois formats de données différents :
- Documents provenant de ClickUp, dont la structure était de type wiki et liée aux projets
- Tâches issues de ClickUp, où le modèle était imbriqué et prenait en compte les dépendances
- Les tickets de Freshservice, où le modèle était un schéma de ticket classique avec des commentaires, des pièces jointes et des relations avec le demandeur
Chacun de ces éléments a dû être cartographié , non pas à l'identique de leur structure source, mais selon le modèle opérationnel conçu pour la cible. Les documents ont été intégrés d'un côté, les tâches de l'autre, les tickets d'un troisième, et dans certains cas, des références croisées ont été nécessaires car une même activité était représentée dans plusieurs systèmes.
Il existe une solution alternative pour ce type de travail : écrire des scripts de migration directement sur les API source et cible. Nous l'avons déjà utilisée sur des projets antérieurs, et les outils d'IA permettent d'accélérer le processus. Cependant, pour les projets où les structures de données sont variées, la configuration de destination complexe et les délais critiques, l'utilisation des outils spécialisés de Help Desk Migrationréduit considérablement les risques liés à la migration des données et raccourcit les délais. Cela nous a permis de nous concentrer sur l'essentiel pour lequel le client nous avait sollicités : la configuration, la conception de l'automatisation et le modèle de permissions.
Ce qui importait au client, ce n'était pas simplement que « les données aient été transférées avec succès ». C'était que la nouvelle plateforme lui offre les contrôles et les automatisations nécessaires à son activité, sans pour autant perdre l'historique des données sur lequel s'appuyaient ses propres clients. Voilà la différence entre un projet de migration et un projet de consolidation de données.
On observe des dynamiques similaires lorsque la destination est une plateforme PSA : la facturation, le suivi de la rentabilité des projets et le suivi du temps sont intégrés aux tâches opérationnelles. Pour un exemple concret de consolidation vers HaloPSA, consultez notre récente étude de cas sur bdq.cloud.
Où Help Desk Migration s'intègre
Nous ne prétendons pas être une entreprise spécialisée dans les outils de migration de données. Le travail technique consistant à créer et à exécuter des scripts de migration sur de multiples API de plateformes, dans le bon ordre, en gérant les cas particuliers liés aux pièces jointes, aux commentaires et aux correspondances d'utilisateurs, est un savoir-faire pointu, et Help Desk Migration excelle dans ce domaine.
De même, et c'est tout aussi important, l'utilisation d'outils spécialisés permet de maîtriser les coûts et les délais de la migration des données. Les dépenses liées à cette migration doivent constituer un poste budgétaire précis, et non un risque imprévu ; or, lorsqu'elles sont connues, l'analyse de rentabilité de la consolidation globale est grandement facilitée.
Le point sur lequel nous revenons sans cesse
La migration des données ne devrait pas vous empêcher d'utiliser les outils adéquats pour votre entreprise. Elle peut s'avérer coûteuse, chronophage et risquée, mais avec les bons partenaires et la bonne approche, ce n'est pas une raison pour rester sur une plateforme obsolète.
Les organisations qui tirent le meilleur parti de la consolidation sont celles qui la perçoivent comme une opportunité d'améliorer leur modèle opérationnel, et non comme un simple transfert de données. La valeur ajoutée pour l'entreprise ne réside pas dans les aspects techniques du scripting API et du mappage des champs. Elle se trouve plutôt dans des rapports plus performants, des processus optimisés, une meilleure automatisation et des équipes capables de se concentrer sur les tâches essentielles.
Si vous envisagez une consolidation, la question à se poser en premier lieu n'est pas « comment transférer les données ? » mais « à quoi cela devrait-il ressembler une fois terminé ? » La gestion des données suivra.
À propos de BDQ
BDQ Cloud est une société de conseil informatique basée à Londres, spécialisée dans la migration, la consolidation et la modernisation des plateformes de gestion des services. Nous travaillons avec HaloITSM, Atlassian, Freshworks, Asana et d'autres outils modernes, et nous collaborons avec Help Desk Migration pour la migration technique des données, élément essentiel de nos projets de consolidation. Si vous souhaitez discuter d'un défi de consolidation spécifique, nous proposons une évaluation de migration de 30 minutes, axée sur le modèle opérationnel et les résultats attendus, et pas seulement sur les données.
