Les champs (fixes ou persos) sont le cœur du help desk. Ils gèrent la structure des tickets, les flux, les rapports et le succès des équipes. Lors d'un changement de système, le mappage correct des données est tout aussi crucial que le transfert des informations elles-mêmes.
En somme, Help Desk Migration sécurise et facilite le mappage ainsi que le transfert des données — à condition de bien respecter les règles.
Ce guide pratique détaille pour vous tous les principes clés.
Mappage des champs fixes et persos : Help Desk Migration
Chaque help desk repose sur des champs. Certains sont natifs du système ; d’autres sont créés par vous.
Champs par défaut
Par exemple, sur Zendesk : Demandeur, Agent, CC, Sujet, Description, Statut, Type, Priorité, Tags.
Ils constituent la base structurelle de chaque ticket.
Champs personnalisés
ID de commande, Forfait, Type de produit, Niveau SLA, etc.
Ils captent vos données et dopent vos rapports et automates.
Help Desk Migration transfère ces deux types de champs.
Comme ils forment l'ossature de vos données, leur mappage est vital. C'est là que nos clients s'interrogent.
Le mappage : source majeure d'anxiété lors de la migration
Avec Help Desk Migration, les risques majeurs surgissent souvent lors du mappage des champs.
On peut observer :
- Perte de précision (ex: un champ multi-sélection devient mono-sélection et perd des données)
- États de tickets modifiés ou déformés
- Tickets manquants
- Utilisateurs ou organisations en double
- Déclencheurs d'automatisation indésirables
La bonne nouvelle ? Ces risques, liés aux déclencheurs ou à la perte de données, sont maîtrisables via une configuration et une préparation rigoureuses, basées sur les capacités réelles de l'outil.
Débutons par la base. Quels objets Help Desk Migration transfère-t-il ?
Quels objets mapper avec Help Desk Migration ?
Help Desk Migration supporte le transfert des champs fixes et persos des tickets, problèmes, changements, contacts, comptes, articles et tâches PM.
Types de champs supportés par Help Desk Migration
L'outil migre tous les types de champs majeurs :
- Champs à options fixes, incluant listes, cases à cocher et multi-sélections
(ex. Type, Région, SLA). Dans Migration Wizard, ils s'affichent en menu déroulant. - Texte / chaîne. Champs de saisie libre pour textes courts ou longs.
- Numérique. Champs stockant des nombres tels que des identifiants, des quantités ou des références internes.
- Date. Champs qui stockent les dates du calendrier (par exemple, date de renouvellement, début du contrat, échéance personnalisée).
- Champs Regex. Champs validés par une règle basée sur un modèle. Par exemple, un champ qui n'accepte qu'un ID de commande correctement formaté, tel que ORD-12345. Ces champs sont affichés pour le mappage entre les plateformes, mais leurs données ne sont migrées que pour Zendesk et Pylon , où la logique de modèle est entièrement prise en charge.
- Champs Formule. Valeurs calculées via d'autres champs. Ex: Coût Total via Qté x Prix, ou un score de priorité. Sur certains outils, ils sont mappables. Le transfert de la valeur dépend du stockage des données.
La première étape pour bien cartographier ces types de champs de service d'assistance commence par une règle importante.
Règle : mapper champs fixes et persos par type
Une migration fiable exige des types de champs cohérents. Mappez les champs, fixes ou persos, en respectant les types entre source et cible .
- Un champ texte se mappe uniquement vers un champ texte.
- Un champ numérique se mappe vers un champ numérique.
- Un menu déroulant doit pointer vers un menu aux valeurs liées.
- Un champ nombre ou date peut aussi migrer vers un champ texte.
- Et ainsi de suite.
Si les types ne correspondent pas, les données risquent de ne pas migrer correctement ou de perdre leur structure.
Champs de sélection : mappage des listes (sélection unique), choix multiples et cases à cocher
Le mappage des listes dans Help Desk Migration exige d'aligner les valeurs, pas seulement le nom du champ. Cette règle vaut pour tout champ de sélection.
En clair, lier « Type » à « Catégorie » ne suffit pas. Chaque option interne doit pointer vers son équivalent exact (ex. : « Incident » vers « Incident » ou « Problème » vers « Problème »).
Aussi, soyez vigilant avec les champs de Sélection (un seul choix) et Multi-Sélection (choix multiples) dans l'Assistant. Sélection > Sélection ou Multi-Sélection migre bien, mais Multi-Sélection > Sélection ne garde que la première valeur.
Gestion des options non mappées lors de la migration des cases, listes et valeurs à choix multiples
Parfois, les valeurs ne migrent pas, car elles ne concordent pas entre les systèmes source et cible.
Si besoin, notre équipe ajustera la configuration pour que chaque valeur arrive au bon endroit.
Champs qui ne migrent pas
Les champs de liste sans aucune option ne s'affichent pas dans l'interface de mappage, c'est un souci classique.
De plus, les valeurs supprimées n'apparaissent pas. Par exemple, un ticket peut avoir une valeur historique, mais si elle est retirée des options actuelles, elle sera absente du mappage. Dans ce cas, le système lie alors ces dossiers à la valeur par défaut sur la plateforme cible.
Sans valeurs à aligner, le système les exclut automatiquement de l'interface utilisateur de mappage.
Créer des champs personnalisés avant de migrer
Les champs persos doivent exister sur la cible avant d'être mappés.
Si un champ manque sur la cible, rien ne peut y être lié et les données ne migreront pas. Voilà pourquoi préparer ces champs tôt est une étape cruciale de toute migration.
Mais il y a quelques exceptions.
Logique de création de champs selon la plateforme
Souvent, les clients créent les champs avant de migrer, directement sur le help desk cible.
Respectez bien ces règles de mappage par plateforme :
Freshdesk
Les champs de sélection sont créés en tant que custom_dropdown.
Zendesk
Le système vérifie si le champ est un tagger (unique) ou multi-choix, puis le crée.
Intercom
Les champs de sélection sont créés avec le type de champ "liste".
Jira Service Management
Le système définit si le champ est unique ou multiple selon la structure source.
De plus, si une liste contient des milliers d'options, Migration Wizard peut échouer. Parfois, le champ est créé mais pas lié au projet ; un ingénieur doit alors intervenir.
Intercom
L'API limite les listes à 250 valeurs, même si l'interface en accepte davantage.
Limitations importantes pour toute plateforme
On ne peut pas créer de doublons via Migration Wizard ; les listes gardent les options sources.
Limites du mappage des champs Contact et Entreprise
Help Desk Migration gère le transfert des champs persos pour les contacts et entreprises sur certains couples.
Pour vérifier si cette migration est supportée dans votre cas, allez dans Entité → Données.
Si vous voyez « Describe - 1 » près des champs persos contact ou entreprise, la migration automatisée est possible.
Sinon, ces champs ne migreront pas seuls, même s'ils existent déjà sur la cible. Notre équipe gère alors cela.
Côté client, si le transfert n'est pas supporté pour leur duo de plateformes, seuls les champs par défaut (Nom, Email, etc.) seront visibles pour le mappage.
Migration de champs dépendants à plusieurs niveaux
Un champ à plusieurs niveaux (également appelé champ imbriqué ou dépendant) contient plusieurs niveaux d'options. Le choix effectué au premier niveau détermine les options disponibles au niveau suivant.
Un exemple simple est un champ Adresse :
Niveau 1 → Pays
Niveau 2 → Ville (filtrée par pays)
Niveau 3 → Rue (filtrée par ville)
Chaque sélection restreint le nombre de choix suivants.
Pourquoi les champs multiniveaux posent problème
Les champs multiniveaux compliquent souvent la migration si la structure n'est pas identique sur la cible.
Gestion des champs multiniveaux si la cible ne les supporte pas
Si la source possède un champ multiniveau mais que la cible ne gère pas les champs dépendants, des solutions existent.
Option 1 : Diviser un champ à plusieurs niveaux en champs déroulants distincts
Si le système source possède un champ à plusieurs niveaux mais que le système cible n'en possède pas, le client peut créer des champs de liste déroulante distincts dans le système cible — un pour chaque niveau.
Par exemple:
- Pays (menu déroulant)
- Ville (menu déroulant)
- Rue (menu déroulant)
Dans cette configuration, les options d'un même champ source sont mappées sur plusieurs champs cibles, alignées en fonction de leurs niveaux respectifs.
Option 2 : Mapper plusieurs champs vers un champ multiniveau
Si la source a des listes séparées (ex. Pays, Ville, Rue), mais que la cible gère un seul champ multiniveau, le mappage est possible.
Dans ce cas, notre équipe peut configurer le mappage.
Le client doit fournir un fichier de mappage guidant la façon dont les niveaux doivent être combinés.
Les champs multiniveaux exigent une attention accrue car ils stockent des liens structurés. Une bonne préparation garantit que cette structure ne sera pas perdue lors du transfert.
Règles, champs obligatoires et migration de valeurs par défaut
Le mappage ne se limite pas à lier des champs. Il s'agit de contrôler les données sur la cible — de façon cohérente et globale.
Ignorer ce champ
Disponible uniquement pour les champs non obligatoires.
Cette option laisse le champ cible vide dans tous les tickets migrés, quelle que soit la valeur source.
Utilisez l'option « Ignorer ce champ » dans les migrations lorsque :
- Le champ existe dans la cible, mais il n'est plus pertinent.
- Ce champ est facultatif et peut être laissé vide sans risque.
Valeur par défaut
Cette option définit une valeur fixe pour un champ de liste déroulante dans tous les tickets migrés.
Par exemple, si vous définissez Type → Problème, chaque ticket migré aura la valeur « Problème » sélectionnée dans le champ Type, quelle que soit la valeur d'origine.
L'option de valeur de champ par défaut est utile lorsque :
- Normalisation des données historiques.
- Passage à une structure de champs simplifiée.
- Application d'un nouveau modèle de catégorisation.
À utiliser pour les valeurs par défaut ou vides
Disponible uniquement lors du mappage des champs obligatoires.
Cette option remplit par défaut un champ cible obligatoire uniquement si le champ source mappé est vide dans un ticket spécifique.
Cela signifie:
- Si la valeur source existe → elle migre normalement.
- Si la valeur source est vide → la valeur de repli sélectionnée est appliquée.
Cela permet d'éviter les erreurs de migration tout en préservant les données réelles là où elles existent.
Pas besoin de remplir
Disponible pour le mappage de champs facultatifs.
Si des valeurs sources sont choisies, cette option laisse le champ cible vide.
C'est utile quand :
- Certaines valeurs sources ne sont plus pertinentes.
- Vous voulez exclure des catégories de la migration.
- Le champ est optionnel et doit rester vide parfois.
Ces réglages offrent la flexibilité pour épurer vos données lors du transfert.
Erreurs de mappage courantes et comment les régler
La plupart des soucis de mappage ont deux causes : les doublons sur la cible ou des champs requis bloquant les tickets.
Doublon de nom
L'erreur de champ dupliqué apparaît lorsque le système cible contient déjà un champ portant le même nom.
Même si vous ne le voyez pas immédiatement, le champ peut :
- Exister mais être inactif
- Appartenir à un autre projet (dans les systèmes de gestion de projets)
- Être masqué par les paramètres de configuration
Comment y remédier :
- Vérifiez si le champ existe déjà dans la cible.
- Activez ou réutilisez le champ existant au lieu d'en créer un nouveau.
- Sur les plateformes basées sur des projets, assurez-vous que le champ est ajouté au projet approprié.
Obligatoire = Champ manquant
Cette erreur se produit lorsqu'un champ obligatoire du système cible ne reçoit aucune valeur lors de la migration.
Un champ peut être obligatoire :
- Pour la création de billets
- Pour la fermeture des billets
- En raison de règles ou de conditions spécifiques
Par exemple, un système peut bloquer un ticket si un champ requis (ex. Résolution) est vide. Ces règles se règlent dans les paramètres ou via les flux.
Parfois, un champ n'est pas marqué requis car la règle est conditionnelle. Pourtant, lors de la migration, ces règles bloquent les tickets si le champ est vide.
Régler l'erreur de champ requis :
- Vérifiez que tous les champs requis sont mappés.
- Utilisez « Valeur par défaut » pour éviter les champs requis vides.
- Révisez les flux et conditions avant la Migration Finale.
Connaître ces deux types d'erreurs aide à éviter les arrêts et assure une migration fluide du début à la fin.
Démo de migration pour valider (pas en théorie)
Une migration démo montre vos règles de mappage avant la Migration Finale.
Démo gratuite illimitée
La 20 tickets aléatoires avec leurs liens et 20 articles. Un rapport détaille ensuite les succès et échecs de migration des données.
Vous lancez la démo à l'infini jusqu'à ce que tout soit parfait.
Démo personnalisée unique
Plutôt que des données au hasard, la démo perso laisse choisir des tickets. Cela aide à valider les cas limites avant la migration finale.
Liste de contrôle du mappage
Avant de lancer la migration finale, vérifiez ces points :
- Types cohérents (texte → texte, liste → liste, etc.).
- Champs requis mappés ou avec une valeur par défaut.
- Champs persos créés sur la cible (ou via la Migration Wizard).
- Options de listes alignées, sans valeurs non assignées.
- Support des champs persos contacts/comptes (Entité → Données).
- Champs multiniveaux bien structurés ou ajustés.
- Pas de doublons ni de flux bloquants sur la cible.
- Une Démo Gratuite (et Perso) a été lancée et validée.
Le mappage n'est pas qu'une étape technique. Il protège vos automates, vos rapports et vos flux après migration. Une liste rigoureuse évite des corrections coûteuses.
FAQ sur le mappage des champs fixes et personnalisés
Help Desk Migration associe les champs en faisant correspondre les types de champs compatibles entre les systèmes source et cible. Les champs par défaut et personnalisés sont alignés selon leur type (texte, liste déroulante, numérique, date, etc.), et les valeurs des listes déroulantes sont associées option par option. Vous pouvez tout valider grâce à une démonstration gratuite avant de lancer la migration complète.
Oui, souvent les champs persos doivent exister sur la cible avant le mappage. Pourtant, sur plusieurs outils, ces champs peuvent être créés directement via l'Assistant de migration au moment de la configuration de votre transfert.
L'outil gère : texte, nombre, date, liste (choix unique), choix multiples, case à cocher, regex et formules. Des types avancés (regex, formules) peuvent avoir des limites selon les spécificités de chaque plateforme de destination.
Si les types divergent (ex. lier une liste à un champ texte par erreur), les données peuvent mal migrer ou perdre leur structure. Suivre la règle « mapper par type » garantit un transfert de données sûr, précis et totalement fiable.
Chaque option d'une liste, case ou multi-choix doit être liée à son équivalent exact sur la cible. Si un champ multi-choix est mappé vers un champ à choix unique, seule la toute première valeur sélectionnée sera alors transférée.
Ceci apparaît quand des valeurs sources ne trouvent pas d'équivalent sur la cible. Ces valeurs sont surlignées avant la Migration Finale pour vous permettre de corriger le tir et d'éviter ainsi tout manque dans vos données.
Le transfert des champs persos contacts/comptes n'est possible que pour certains duos d'outils. Vérifiez cela dans Entité → Données. Sinon, notre équipe technique peut vous proposer des options de traitement sur mesure pour cela.
Si les deux outils les gèrent, leurs structures doivent être identiques. Si la cible ne supporte pas le multiniveau, les données peuvent être divisées en listes séparées ou configurées via un mappage personnalisé par nos soins.
Les soucis courants sont les doublons de noms sur la cible et les champs requis restés vides. Ils se règlent en réutilisant des champs existants, en mappant tout le requis ou en appliquant des valeurs de secours par défaut.
La Démo valide votre mappage avec de vrais dossiers. Lancez des Démos Gratuites illimitées ou une Démo Perso pour tester des tickets précis. Cela assure que tout votre mappage fonctionne avant le transfert global de vos données.
