Migrer ses données vers un nouveau logiciel : la méthode

Migrer ses données vers un nouveau logiciel se joue avant tout sur une décision de périmètre : que reprend-on vraiment, et que laisse-t-on en consultation ailleurs. Le réflexe le plus répandu, tout reprendre par prudence, est aussi le plus coûteux et le moins utile. La méthode qui fonctionne enchaîne des phases précises : arbitrer le périmètre, auditer la donnée source, construire la correspondance de champs, nettoyer, répéter la migration à blanc, basculer, puis vérifier.

Ce n'est presque jamais un problème d'outil. C'est un problème de décisions prises dans le bon ordre, avant que la technique n'entre en jeu. Une migration mal cadrée ne se voit pas le jour de la bascule, elle se voit trois mois plus tard, quand un commercial cherche un historique qui n'a jamais été repris ou qu'un rapport ne recoupe plus les chiffres de l'ancien système.

Cet article détaille chaque phase de cette méthode, où l'IA aide réellement dans ce travail, et à partir de quand l'import natif proposé par l'éditeur du nouveau logiciel ne suffit plus.

Quelles données reprendre : le périmètre, la décision la plus rentable

Avant tout audit et toute technique, une question doit être tranchée en premier : que reprend-on réellement dans le nouveau logiciel ? C'est la décision qui a le plus d'impact sur le coût, la durée et le risque du projet, bien avant le choix de l'outil de migration lui-même.

Arbitrer par usage réel, pas par réflexe

Le réflexe le plus courant consiste à vouloir tout reprendre "au cas où". C'est aussi le choix le plus coûteux et le moins utile en pratique : plus de champs à mapper, plus de données à nettoyer, plus de risques d'erreur, pour un usage réel souvent limité à une poignée de fiches consultées de temps en temps.

La bonne méthode consiste à passer chaque catégorie de données au filtre de trois questions :

• Obligation légale de conservation. Certaines données (factures, contrats, pièces comptables) doivent être conservées pendant une durée réglementaire. Sur ce point, restez prudent : les durées varient selon le type de document et l'évolution des textes, un service juridique ou votre expert-comptable doit valider la durée exacte applicable à votre cas plutôt que de se fier à une règle générale.
• Besoin opérationnel. La donnée est utilisée activement au quotidien : clients actifs, contrats en cours, stock disponible. Elle doit vivre dans le nouveau système, à jour et exploitable.
• Besoin de consultation. La donnée sert occasionnellement de référence (un ancien devis, un historique de commande sur un client inactif) sans nécessiter d'être modifiée ni recherchée au quotidien.

L'option souvent gagnante : l'actif dans le nouveau système, l'historique en consultation

Une fois ce tri fait, une option revient très souvent comme la plus raisonnable : reprendre dans le nouveau logiciel uniquement ce qui correspond à un usage opérationnel actif, et garder le reste, l'historique long, les données à faible fréquence de consultation, dans un entrepôt séparé, accessible en lecture seule.

Cette séparation évite deux écueils à la fois : perdre une information dont on aura besoin un jour, et alourdir le nouveau système avec des années de données qui ne servent plus à rien au quotidien. Notre article sur la reprise de l'historique et des champs libres avec l'IA détaille comment structurer cet entrepôt de consultation et ce qu'on peut en extraire plus tard si le besoin apparaît.

Le cas de l'import natif de l'éditeur : quand il suffit, quand il décroche

La plupart des éditeurs de logiciels de gestion, CRM ou ERP proposent un outil d'import natif. Il suffit dans un cas précis : un volume raisonnable, une structure de données simple, une seule base source propre, et peu ou pas de champs libres à interpréter. Dans ce cas de figure, il fait le travail correctement et rapidement, sans qu'un projet de migration dédié soit justifié.

Il décroche à partir de plusieurs seuils, qui se cumulent souvent :

• Un historique long, accumulé sur plusieurs années avec des évolutions de structure entre-temps (champs ajoutés, renommés, supprimés).
• Des champs libres qui contiennent de l'information utile mais non structurée : un commentaire, une note de suivi, une adresse écrite à la main de dix façons différentes.
• Des données réparties sur plusieurs outils qu'il faut consolider avant même de penser au format cible.
• Des doublons déjà présents dans la base source, qu'un import natif se contente de recopier tels quels, sans les détecter ni les fusionner.

L'import natif applique un mapping générique conçu pour le cas moyen. Il ne prend aucune décision métier et ne détecte rien de ce qui rend votre base particulière. Dès que l'un des quatre points ci-dessus s'applique, un travail de migration dédié devient plus rentable qu'un import qui devra de toute façon être corrigé après coup, souvent avec plus d'efforts qu'un cadrage fait en amont.

Auditer la donnée source avant de promettre une date de bascule

L'audit de la donnée source est l'étape que beaucoup de projets sautent, pressés de commencer le mapping. C'est pourtant ici que se découvrent les mauvaises surprises, et il vaut mieux les découvrir maintenant que trois jours avant la bascule prévue.

Volumétrie et qualité : ce qu'on mesure

L'audit commence par des mesures simples mais rarement faites avant un projet de migration : combien de fiches, combien de lignes par table, combien de champs réellement remplis par rapport aux champs disponibles, quelle est la fraîcheur des données (date de dernière mise à jour). Ces chiffres donnent une estimation de charge réaliste, bien plus fiable qu'une durée fixée avant d'avoir regardé la base.

Doublons, champs vides, champs détournés

Trois anomalies reviennent presque systématiquement dans une base qui tourne depuis plusieurs années :

• Des doublons, exacts ou approximatifs : le même client saisi deux fois avec une orthographe différente, une raison sociale ancienne jamais nettoyée.
• Des champs vides sur une part significative des fiches, alors que le nouveau système peut les considérer comme obligatoires.
• Des champs détournés de leur usage d'origine. Un champ "commentaire" utilisé pendant des années pour stocker une date de relance, un champ "code postal" qui contient parfois un numéro de téléphone saisi par erreur. Ce genre de détournement ne se voit qu'en regardant vraiment le contenu, jamais sur la seule structure de la table.

Ces trois anomalies compliquent particulièrement les champs texte libres, qui accumulent souvent l'information la plus utile et la moins structurée de toute la base. Notre article sur structurer des données non structurées avec l'IA détaille comment extraire cette information avant qu'elle ne soit perdue au moment du transfert.

Les mauvaises surprises qu'on préfère découvrir maintenant

Un audit sérieux révèle presque toujours au moins une surprise : un référentiel client dupliqué entre deux services, un champ de statut qui n'a plus la même signification depuis un changement de process, une table entière que plus personne ne sait vraiment interpréter. Découvrir cela pendant l'audit permet de le traiter calmement. Le découvrir pendant la bascule, avec une date de mise en production déjà annoncée, transforme un ajustement mineur en crise.

La correspondance de champs et les règles de transformation

Une fois le périmètre arbitré et la donnée source auditée, il reste à établir comment chaque champ de l'ancien système se traduit dans le nouveau. C'est un travail plus fin qu'un simple mapping de colonnes.

Construire la table de correspondance

Pour chaque champ retenu dans le périmètre, la table de correspondance précise trois choses : le champ source, le champ cible dans le nouveau logiciel, et la transformation à appliquer entre les deux quand le format diffère. Un statut client codé "1", "2", "3" dans l'ancien système doit être traduit vers les libellés attendus par le nouveau, une unité de mesure doit être convertie, une date au format texte doit devenir une vraie date. Notre article sur la correspondance de champs entre deux logiciels détaille comment construire cette table méthodiquement, y compris quand les deux systèmes ne partagent aucune nomenclature commune au départ.

Les règles de transformation, pas seulement le mapping

Le mapping dit où va chaque champ. Les règles de transformation disent comment il y arrive : quelle valeur par défaut appliquer sur un champ vide obligatoire côté cible, quelle règle de priorité suivre quand deux champs sources doivent fusionner en un seul champ cible, quel format de date ou de numéro de téléphone imposer. Ce sont des décisions métier, posées avant l'écriture du moindre script, jamais improvisées pendant l'exécution.

Quand la base source ne dispose d'aucun identifiant fiable pour rapprocher deux enregistrements entre systèmes, la question du rapprochement se pose dès cette étape. Notre article sur synchroniser deux logiciels sans identifiant commun traite spécifiquement ce cas, qui touche autant une synchronisation continue qu'une migration ponctuelle.

Ce que l'IA peut proposer, ce qu'elle ne décide jamais

Sur un volume de champs important, un modèle de langage peut proposer des correspondances candidates entre les nomenclatures des deux systèmes, en repérant des similarités de nom, de type et d'usage que la lecture manuelle mettrait longtemps à croiser. C'est un gain de temps réel sur le premier jet de la table de correspondance.

Ce que l'IA ne fait jamais : décider quelle donnée prime en cas de conflit, ni valider seule qu'une correspondance proposée est correcte sur le plan métier. Chaque correspondance générée automatiquement doit être relue par une personne qui connaît le métier avant d'être figée dans la table finale.

Nettoyer : ce qu'on corrige avant, pendant, et ce qu'on ne corrigera jamais

Le nettoyage n'est pas une étape unique, c'est un travail réparti sur trois moments distincts du projet, chacun avec une logique différente.

Avant la migration : la base source

Certaines corrections doivent se faire directement dans l'ancien système, avant tout export : fusionner des doublons identifiés pendant l'audit, compléter des champs obligatoires manquants sur les fiches encore actives, corriger des valeurs manifestement fausses (un code postal à trois chiffres, une date de naissance en 1900). Le dédoublonnage en particulier gagne toujours à être fait à ce stade plutôt qu'après l'écriture dans le nouveau système. Notre article sur dédoublonner une base clients avant migration avec l'IA détaille cette méthode, y compris sur les doublons approximatifs qu'une simple règle de correspondance exacte ne détecte jamais.

Pendant : les règles automatiques

D'autres corrections s'appliquent au moment du transfert lui-même, via les règles de transformation définies à l'étape précédente : normalisation d'un format de téléphone, harmonisation d'une casse de texte, application d'une valeur par défaut. Ce sont des règles systématiques, appliquées uniformément à toute la base, jamais des corrections faites au cas par cas pendant l'exécution.

Ce qu'on ne corrigera jamais (et pourquoi c'est un choix, pas un renoncement)

Certaines anomalies ne valent pas le coût de leur correction : une poignée de fiches très anciennes avec des champs incomplets, sans usage opérationnel restant. Décider de ne pas les corriger, en connaissance de cause, fait partie du travail. C'est très différent de laisser passer une anomalie faute de l'avoir vue. La différence entre les deux, c'est l'audit mené en amont.

Les migrations à blanc répétées : pourquoi on ne bascule jamais du premier coup

Personne ne bascule un système de production sur un script de migration jamais testé. Entre la table de correspondance finalisée et la bascule réelle, plusieurs migrations à blanc s'enchaînent, chacune sur une copie de la base, sans jamais toucher le système en production.

Ce qu'on mesure à chaque passage

Chaque migration à blanc sert à vérifier un point précis, dans un ordre qui va du plus grossier au plus fin : la complétude d'abord (est-ce que tout le périmètre retenu est bien transféré, sans fiche perdue en route), puis la conformité des règles de transformation (les valeurs arrivent-elles dans le bon format, avec les bonnes conversions appliquées), puis la performance (combien de temps prend l'exécution complète). Un tableau de contrôle, comparant des totaux et des échantillons entre la base source et la base cible après chaque passage, objective ces trois points plutôt que de se fier à une impression générale.

Pourquoi la dernière doit être rejouable en quelques heures

Le critère qui indique qu'on est prêt pour la bascule réelle n'est pas "la migration a fonctionné une fois". C'est "la migration tourne de bout en bout sans intervention manuelle, dans une durée compatible avec une fenêtre de bascule réelle", en général quelques heures, pas plusieurs jours. Cette contrainte de durée conditionne directement le choix de l'outil qui exécute la migration : un script mal pensé qui demande des corrections manuelles à chaque passage ne sera jamais rejouable à froid le jour J. Notre article sur connecteur standard ou développement sur mesure aide à choisir l'approche technique adaptée à ce niveau d'exigence, selon la complexité réelle du cas.

C'est ce type de projet que nous cadrons dans le cadre de notre offre de migration et reprise de données : arbitrer le périmètre avec vous, auditer la base source, construire la table de correspondance, puis exécuter et vérifier la bascule jusqu'à ce qu'elle soit fiable et rejouable.

La bascule, la vérification et la période de double contrôle

Le jour de la bascule n'est pas le moment de prendre des décisions. Toutes les décisions ont déjà été prises pendant les phases précédentes ; ce jour-là, on exécute un plan écrit à l'avance.

Gel de saisie et ordre de chargement

La bascule commence par un gel de saisie sur l'ancien système : plus aucune modification n'entre pendant la fenêtre de migration, pour garantir que la base exportée correspond exactement à la base transférée. Le chargement dans le nouveau système suit ensuite un ordre précis : les référentiels d'abord (clients, produits, comptes), puis les mouvements qui s'appuient sur eux (commandes, factures, écritures). Charger les mouvements avant les référentiels dont ils dépendent provoque des erreurs de rattachement en cascade, difficiles à corriger une fois la base en production.

Le plan de retour arrière

Un plan de bascule sérieux prévoit toujours la sortie de secours : à partir de quel point de blocage revient-on à l'ancien système, qui décide, et en combien de temps ce retour est-il possible. Ce plan doit exister avant la bascule, jamais s'improviser une fois le problème constaté. Dans la grande majorité des cas il ne sert pas, mais son absence transforme un incident gérable en crise.

Vérifier après bascule : la période de double contrôle

La vérification ne s'arrête pas au chargement réussi. Une période de double contrôle, en général de quelques semaines, permet de comparer les opérations réelles produites par le nouveau système avec ce qu'aurait produit l'ancien sur les mêmes cas : une facture, un rapport de stock, un solde client. L'ancien système reste accessible en lecture seule pendant cette période, sans nouvelle saisie, pour servir de référence de comparaison. Notre article sur vérifier une migration de données avec des contrôles détaille les contrôles à mettre en place pour objectiver cette vérification plutôt que de la faire à l'instinct.

Pendant cette période, il arrive que les équipes continuent temporairement à renseigner certaines informations dans les deux systèmes par prudence. C'est acceptable sur une durée courte et définie à l'avance, mais cela reproduit exactement le problème que nous détaillons dans notre article sur supprimer la double saisie entre deux logiciels : fixez une date de fin claire à cette double saisie temporaire, faute de quoi elle s'installe durablement.

Questions fréquentes sur la migration de données vers un nouveau logiciel

Pour aller plus loin

• Dédoublonner une base clients avant migration avec l'IA : la méthode détaillée pour détecter et fusionner les doublons exacts et approximatifs avant l'écriture dans le nouveau système.
• Vérifier une migration de données avec des contrôles : les contrôles à poser pour objectiver la vérification après bascule plutôt que de la faire à l'instinct.
• Reprendre l'historique et les champs libres avec l'IA : comment structurer l'entrepôt de consultation pour l'historique non repris dans le nouveau système.
• La correspondance de champs entre deux logiciels : la méthode complète pour construire la table de correspondance et les règles de transformation.
• Rendre ses données prêtes pour l'IA en entreprise : pourquoi une migration bien menée conditionne aussi la capacité future à exploiter ces données avec l'IA.