Gfacility

Mise en production & adoption

Migration et nettoyage des données

Quel historique part vers Gfacility, que jetez-vous, qu'archivez-vous, et comment validez-vous que tout arrive correctement ? Sautez le nettoyage et vous emportez l'ancien désordre dans la nouvelle maison.

Mis à jour le 18 mai 2026

Go-live · 5.1

Pourquoi en premier

Migration et nettoyage sont inséparables. “Tout migrer” semble sûr, jusqu’à ce que vous démarriez Gfacility avec 14 000 tickets de 2017 dont plus personne ne comprend le statut. Importer de mauvaises données rend tous les rapports peu fiables et toutes les suggestions IA inutiles. Nettoyez d’abord, migrez ensuite.

Que livrez-vous ?

Matrice de migration

Par entité source : entité cible, règles de transformation, date de référence, périmètre.

Liste d'actions de nettoyage

Doublons, enregistrements obsolètes, références cassées, qui nettoie quoi avant migration ?

Stratégie d'archivage

Ce que vous ne migrez pas, et comment cela reste accessible selon les obligations de rétention.

Rapport de dry-run

Résultat d'au moins deux exécutions de dry-run : volumes, écarts, durée.

Les cinq familles d’entités

La migration suit toujours les mêmes étapes, quel que soit le système source :

Données de référence

Utilisateurs, organisations, lieux, centres de coûts. En premier, car toutes les autres entités s'y réfèrent.

Configuration

Classifications, champs personnalisés, groupes de travail, workflows. Manuel ou via export, généralement peu de volume.

Données transactionnelles

Tickets ouverts, réservations en cours, tâches planifiées. Volume bas, valeur haute, embarquez tout.

Historique

Tickets clos, anciennes réservations. Décidez la période (12 ou 24 mois) et comment vous préservez la continuité du reporting.

Base de connaissances

Articles, FAQ, modèles. Souvent une occasion de nettoyer et restructurer dans la foulée.

Pièces jointes

Photos, PDF, documents liés aux tickets et aux assets. Généralement le plus lourd en volume.

Questions clés

  1. 1Quels systèmes sources contiennent des données à pousser vers Gfacility, TOPdesk, ServiceNow, listes Excel, outils maison, ressources Outlook ?
  2. 2Limites de périmètre par entité, uniquement enregistrements actifs, seulement 24 derniers mois, seulement certains départements ?
  3. 3Nettoyage avant migration, qui supprime les doublons, désactive les comptes dormants, clôture les tickets orphelins ?
  4. 4Règles de transformation, comment mapper les anciennes catégories vers les nouvelles classifications ? Que fait "inconnu" ?
  5. 5Stratégie pièces jointes, migrer avec, stockage séparé, ou récupérer à la demande depuis l'archive ?
  6. 6Date de référence et gel, quand la source est-elle "gelée" (plus de changements) et que faites-vous des nouveaux enregistrements arrivant entre-temps ?
  7. 7Validation, quels contrôles faites-vous après migration (totaux, échantillons, enregistrements clés revus à la main) ?
  8. 8Solution d'archive, pour les données non migrées, l'ancien outil reste-t-il en lecture seule ? Avec quelle durée de rétention, responsable et modèle d'accès ?
  9. 9Reproductibilité, pouvez-vous rejouer la migration au moins deux fois avant le vrai cutover ? Idempotente (rejouer ne change rien) ?
  10. 10Impact RGPD, transportez-vous des données personnelles dont la durée de conservation est dépassée ? Le DPO vérifie avant migration.

Modèle, matrice de migration par entité

Entité Source Volume Périmètre Action de nettoyage Responsable Validation
UtilisateursEntra ID~2 400Actifs (login 90 j)Désactiver dormantsIT-IdentityTotal +/- 1 %
LieuxExcel + M365 Rooms~180Tous réservablesRe-validation capacitéFMContrôle manuel 100 %
Tickets ouvertsTOPdesk~340Tous ouvertsClôturer > 6 mService ManagerÉchantillon de 50
Tickets closTOPdesk~14 20024 derniers moisAnonymisation PII > 12 mService Manager + DPOTotaux mensuels
Historique réservationsM365~85 00012 derniers moisAucun, lecture seuleWorkplace leadAgrégats
Articles KBWiki SharePoint~220Top 150 les plus lusRéécriture + tagsService ManagerRevue de contenu

Étapes

  1. 1Inventoriez les systèmes sources et assignez un responsable par entité.
  2. 2Lancez des sprints de nettoyage, doublons, comptes dormants, plus vieux que la rétention. Mieux dans la source qu'à la migration.
  3. 3Écrivez le mapping de transformation : champ source → champ Gfacility, avec règles explicites pour "inconnu" et "vide".
  4. 4Premier dry run sur l'environnement de recette, avec volume attendu, uniquement pour mesurer volumes, durée et erreurs.
  5. 5Corrigez les erreurs, durcissez le mapping, et renvoyez les actions de nettoyage à la source.
  6. 6Deuxième dry run avec un état de nettoyage représentatif, les utilisateurs finaux vérifient un échantillon.
  7. 7Accordez la stratégie d'archive, source en lecture seule 12 mois, puis export en cold storage.
  8. 8Livrez un rapport go/no-go au comité de pilotage : volumes correspondent, erreurs < X, validation par les propriétaires d'entités.