Changer d’outil métier : tester ses exports avant de migrer
Votre outil de suivi client devient difficile à adapter. Une autre plateforme semble mieux convenir, et l’éditeur actuel propose un bouton « Exporter ». Avant de fixer la date du changement, vérifiez ce que vous pourrez réellement reconstruire avec les fichiers obtenus.
Une migration doit permettre à l’équipe de poursuivre son travail : retrouver le bon dossier, consulter son historique, ouvrir ses documents et déclencher la bonne action. Voici comment tester cette continuité avant d’engager le transfert complet.
Prenons un exemple entièrement fictif. Une PME de maintenance souhaite remplacer son outil de suivi des interventions. Elle y conserve des clients, des sites, des dossiers, des comptes rendus et des relances automatiques. Ce cas sert uniquement à illustrer la démarche.
Définir ce qui doit rester utilisable
Commencez par décrire les opérations que l’équipe devra pouvoir réaliser dans le nouvel outil. Dans notre PME fictive, un responsable doit retrouver les interventions d’un site, identifier celle qui reste ouverte et consulter le dernier compte rendu. Cette description devient le premier critère de réussite.
Classez ensuite les éléments à reprendre : données courantes, documents, historique, relations entre fiches et règles de fonctionnement. Pour chacun, précisez s’il doit être utilisable dans le nouvel outil ou conservé dans une archive consultable. Faites valider cette distinction par la personne qui utilise les dossiers.
La présence d’un export ne garantit pas une reconstruction immédiate. Notion précise, par exemple, que réimporter le contenu exporté d’un espace ne permet pas de recréer instantanément cet espace. Cette limite concerne le fonctionnement documenté de Notion ; vérifiez séparément celui de votre plateforme. Source : sauvegarde et export des données, Notion.
Demandez une démonstration du parcours de reprise avec vos catégories de données. Un fichier qui s’ouvre est un premier résultat ; le test doit aller jusqu’à l’usage attendu.
Vérifier le périmètre exact de l’export
Effectuez un premier export avec la personne qui administrera la migration. Notez la date, les filtres appliqués, les catégories choisies et les options activées. Conservez ces réglages avec les fichiers pour pouvoir reproduire l’opération.
Dans HubSpot, l’export de fiches récupère leurs propriétés actuelles et leurs associations. Les propriétés et associations présentes dans la vue sont sélectionnées par défaut, avec des options pour élargir le contenu. La documentation prévoit d’autres méthodes pour exporter certaines activités, comme les appels et les notes. Source : export des fiches, HubSpot.
Pour notre entreprise fictive, la revue porterait donc sur plusieurs éléments distincts : clients actifs, sites, interventions ouvertes, interventions terminées et comptes rendus. Chaque catégorie aurait son nombre attendu et sa méthode de récupération.
Comparez les fichiers obtenus au périmètre convenu. Un filtre oublié peut expliquer un écart, mais cette explication doit être vérifiée. Consignez aussi les éléments volontairement exclus, afin de distinguer une décision d’archivage d’une donnée manquante.
Récupérer les pièces jointes et vérifier leur ouverture
Inspectez les colonnes qui représentent des documents. Contiennent-elles le fichier lui-même, son nom, un identifiant ou une adresse de téléchargement ? Ces éléments demandent des traitements différents.
Airtable indique que les liens de téléchargement des pièces jointes expirent et recommande de récupérer les fichiers depuis les liens présents dans l’export CSV avant leur expiration. Conserver uniquement le tableau contenant ces adresses laisse donc une étape à effectuer. Source : comportement des URL de pièces jointes, Airtable.
Dans notre exemple fictif, nous préparerions un dossier de fichiers accompagné d’un inventaire : identifiant de l’intervention, nom du document et emplacement de la copie. Deux comptes rendus peuvent porter le même nom ; le rangement doit préserver leur rattachement au bon dossier.
Ouvrez ensuite des documents depuis cette copie, avec les accès prévus pour l’équipe. Vérifiez les fichiers absents, illisibles ou associés au mauvais dossier. Conservez les exports dans un emplacement contrôlé et limitez leur accès aux personnes chargées de la reprise.
Préserver les liens entre les fiches
Une liste de clients et une liste d’interventions ne suffisent pas à expliquer quel dossier appartient à quel site. Conservez les identifiants d’origine et préparez la correspondance avec ceux créés dans le nouvel outil.
La documentation d’import de HubSpot illustre ce besoin : elle décrit l’utilisation d’identifiants uniques pour mettre à jour les fiches et associer des enregistrements. Les règles exactes dépendent de l’objet importé et de l’opération choisie. Source : préparation des fichiers d’import, HubSpot.
Dans une migration vers une autre plateforme, l’ancien identifiant peut être conservé dans un champ dédié si l’outil le permet. Il ne doit pas être utilisé comme nouvel identifiant interne sans vérifier le fonctionnement de la destination.
Pour notre PME fictive, le test inclurait un client possédant plusieurs sites, chacun avec plusieurs interventions. Après import, un utilisateur devrait retrouver cette structure. Évitez de reconstruire les relations uniquement à partir des noms : deux sites peuvent partager le même intitulé, et un client peut avoir changé de raison sociale.
Faire rejouer un parcours complet par l’équipe
Préparez un lot d’essai qui couvre les variantes utiles : dossier ouvert, dossier terminé, plusieurs pièces jointes, information manquante et changement de responsable. Faites l’import dans un environnement de test, avec les envois externes et les actions automatiques désactivés.
Voici la grille que nous proposerions à notre entreprise fictive :
Vérification | Résultat attendu dans l’essai |
|---|---|
Rechercher un client et ses sites | Les fiches prévues sont présentes et correctement reliées. |
Ouvrir une intervention en cours | Son statut, son responsable et sa prochaine échéance sont compréhensibles. |
Consulter un compte rendu | Le fichier s’ouvre et correspond à l’intervention choisie. |
Rechercher une intervention terminée | L’historique retenu reste accessible à l’emplacement convenu. |
Corriger puis réimporter une fiche | Le comportement correspond à la règle prévue, sans doublon involontaire. |
Comparez les volumes attendus et importés, puis contrôlez des dossiers complets. Un total identique peut masquer des relations incorrectes. Gardez également la liste des lignes rejetées et la cause de chaque rejet.
Confiez cette revue à un utilisateur métier. Son rôle consiste à vérifier qu’il peut reprendre une intervention sans demander au concepteur de la migration où se trouve chaque information.
Préparer la bascule des automatisations
Recensez les processus reliés à l’ancien outil : formulaire du site, création de tâches, notifications, synchronisation documentaire et tableaux de bord. Pour chaque connexion, identifiez le déclencheur, les données échangées et la personne responsable.
Décrivez ensuite le passage d’un système à l’autre. À quel moment l’ancien outil cesse-t-il de recevoir des modifications ? Comment les changements intervenus depuis le premier export sont-ils repris ? Quand les nouvelles automatisations sont-elles activées ?
Dans notre cas fictif, une relance d’intervention ne devrait partir que depuis le système désigné pour cette étape. La procédure préciserait comment suspendre l’ancien scénario, contrôler la reprise des échéances, puis activer le nouveau sur des cas vérifiés.
Prévoyez également les conditions d’un retour temporaire à l’ancien outil, avec le traitement des modifications déjà saisies dans le nouveau. Ce point mérite d’être testé avant la bascule. Notre comparatif n8n, Make et Zapier donne des critères utiles pour examiner la maintenance et les responsabilités des connexions concernées.
Décider avec un coût de reprise connu
À l’issue de l’essai, rassemblez les éléments récupérés, ceux qui demandent une transformation et ceux qui devront être reconstruits. Chiffrez le travail correspondant, les tests, la formation et l’éventuelle période de coexistence des outils.
Ce raisonnement rejoint notre guide des indicateurs de ROI d’un projet IA : le coût du contrôle et du changement fait partie de la décision. Appliquez ici cette logique au projet de migration, avec vos propres mesures.
La direction peut alors approuver le transfert, réduire son périmètre ou demander un nouvel essai sur un point précis. Conservez les fichiers de test, les correspondances et les résultats : ils serviront de référence pour préparer l’opération finale.
Vous envisagez de remplacer un outil relié à vos processus métier ? Présentez votre situation à Studio UNIQ pour définir les données à reprendre, les dépendances à vérifier et un premier test de migration.