Reprise de données : la méthode pour changer de logiciel sans rien perdre

Une reprise de données réussie suit six étapes : cartographier ce qui existe, décider ce qu'on reprend, nettoyer et dédoublonner, écrire les règles de correspondance, répéter la migration à blanc, puis basculer et contrôler. Le point qui fait échouer la plupart des projets n'est pas technique : c'est de commencer trop tard, quand le nouveau logiciel est prêt et que l'on découvre l'état réel des anciennes données.

Cet article s'adresse au dirigeant ou au chef de projet qui change de logiciel métier, d'ERP ou de CRM, ou qui remplace un outil maison. Il détaille la méthode, les rôles, les contrôles et les pièges, quel que soit le prestataire.

Pourquoi la reprise de données est le chantier sous-estimé

Dans un projet de nouveau logiciel, on parle d'écrans, de fonctions, de délais. La reprise arrive en fin de liste, avec une ligne « import des données » dans le planning. C'est une erreur pour trois raisons :

• les données reflètent des années de pratiques : champs détournés, codes abandonnés, saisies approximatives, règles qui ont changé en cours de route ;
• le nouveau logiciel est plus exigeant : un champ obligatoire, une liste fermée, une relation contrôlée refusent ce que l'ancien acceptait ;
• la confiance se joue au premier jour : si un commercial trouve un client en double ou un tarif faux le lundi de la bascule, il retourne à son tableur, et le projet perd sa crédibilité.

Traitez la reprise comme un projet dans le projet, avec son responsable, son planning et ses critères de réussite, lancé dès le cadrage.

Étape 1 : cartographier les sources

Avant de déplacer quoi que ce soit, dressez la carte de ce qui existe.

• Les systèmes sources : l'ancien logiciel, mais aussi les tableurs satellites, les bases Access, les dossiers partagés, les boîtes e-mail qui servent de registre. Une partie de la vérité vit souvent hors du logiciel officiel.
• Les objets métier : clients, contacts, articles, tarifs, commandes, factures, contrats, interventions, stocks, documents joints.
• Les volumes : nombre d'enregistrements par objet et par année.
• Les propriétaires : pour chaque objet, la personne qui sait dire si la donnée est juste.
• Les formats d'export disponibles : export natif, accès à la base, API, fichiers plats. Vérifiez tôt que vous pouvez réellement extraire vos données, et dans quel délai : c'est parfois une question contractuelle avec l'ancien éditeur, que nous traitons dans notre article sur la réversibilité.

Si l'ancien système est une base Access, notre guide pour migrer Access vers une application web liste les pièges propres à ce cas.

Étape 2 : décider du périmètre

Tout reprendre est rarement la bonne idée. Pour chaque objet, choisissez entre trois sorts :

Deux contraintes cadrent ce choix.

Les obligations de conservation. En France, les livres comptables et les pièces justificatives (dont les factures) se conservent dix ans à partir de la clôture de l'exercice, et les contrats commerciaux cinq ans, selon Service-Public Entreprendre (page vérifiée le 01/07/2024, relevée le 06/11/2026). Ces données n'ont pas besoin d'être reprises dans le nouveau logiciel, mais elles doivent rester accessibles.

Les données personnelles. La CNIL (page du 02/04/2026) rappelle que les données personnelles ne peuvent pas être conservées indéfiniment, et distingue la base active, l'archivage intermédiaire et l'archivage définitif. Une migration est le meilleur moment pour appliquer ces règles plutôt que de transporter des données qui auraient dû disparaître. Notre article sur le RGPD dans une application métier détaille ce qu'il faut prévoir dans le nouvel outil.

Étape 3 : auditer et nettoyer

Une fois le périmètre fixé, mesurez la qualité des données avant de les corriger. Quelques requêtes simples suffisent souvent à révéler l'ampleur du chantier :

• taux de champs vides pour chaque champ que le nouveau logiciel rend obligatoire ;
• valeurs hors liste (codes pays libres, statuts inventés, unités multiples) ;
• formats incohérents (dates en texte, numéros de téléphone sous dix formes, montants avec virgule ou point) ;
• références cassées (une commande qui pointe vers un client supprimé) ;
• enregistrements de test ou de formation jamais effacés.

Ensuite, décidez où corriger. Deux écoles :

1. Corriger dans la source, avant la migration : les utilisateurs nettoient eux-mêmes, dans l'outil qu'ils connaissent. C'est plus lent, mais la correction est validée par ceux qui savent.
2. Corriger pendant la transformation : des règles automatiques normalisent les formats et complètent les valeurs. C'est rapide et reproductible, à condition que chaque règle soit écrite et validée.

Dans la pratique, on combine les deux : règles automatiques pour les formats, correction humaine pour le sens.

Étape 4 : dédoublonner

Le doublon est le défaut le plus visible après une bascule. Un import natif se contente souvent de recopier les lignes, doublons compris.

Une bonne démarche de dédoublonnage :

• définit les critères de rapprochement par objet : SIRET pour une entreprise, adresse e-mail pour un contact, référence fabricant pour un article ;
• sépare les cas sûrs des cas douteux : les cas sûrs fusionnent automatiquement, les cas douteux passent par une liste de validation humaine ;
• choisit l'enregistrement maître et la règle de fusion champ par champ (le plus récent, le plus complet, celui de tel système) ;
• conserve la trace des anciens identifiants, pour retrouver une commande ou une facture qui citait l'ancien numéro.

Ce dernier point est souvent oublié. Gardez une table de correspondance entre anciens et nouveaux identifiants : elle sert pendant des années.

Étape 5 : écrire les règles de correspondance

Le document central de la reprise est la table de correspondance : pour chaque champ cible, d'où vient la donnée, quelle transformation lui est appliquée, quelle valeur par défaut si elle manque.

Chaque règle est validée par le propriétaire métier de la donnée, puis codée dans un script rejouable : on doit pouvoir relancer toute la reprise, depuis zéro, autant de fois que nécessaire. Une reprise faite à la main, par copier-coller, ne se répète pas et ne se contrôle pas.

Étape 6 : répéter, basculer, contrôler

Les migrations à blanc

Une migration à blanc est une répétition générale : copie de l'ancien système, exécution de tous les scripts, chargement dans un environnement de test du nouveau logiciel. Elle sert à trois choses :

• mesurer la durée, pour dimensionner la fenêtre de bascule ;
• compter les rejets, et les corriger à la source ou dans les règles ;
• faire vérifier les utilisateurs sur leurs propres dossiers : leurs dix plus gros clients, leurs commandes en cours, leurs articles les plus vendus.

Prévoyez-en au moins deux. On arrête quand le résultat est stable et que les utilisateurs signent.

La bascule

Deux stratégies existent :

• la bascule en une fois : l'ancien système est figé un vendredi soir, la reprise tourne pendant le week-end, le nouveau démarre le lundi. Simple à comprendre, mais tout le risque est concentré sur un moment ;
• la bascule progressive : par site, par service ou par module, avec parfois une période où les deux systèmes coexistent. Moins risquée, mais il faut gérer la synchronisation entre les deux pendant la transition.

Quel que soit le choix, écrivez un plan de retour arrière : à quel moment, sur quels critères, et comment on revient à l'ancien système si le contrôle échoue.

Le contrôle après bascule

Les contrôles se préparent pendant les essais à blanc et se rejouent le jour J :

• comptages par objet, entre source et cible, rejets expliqués ;
• sommes de contrôle : total des encours clients, valeur du stock, chiffre d'affaires de l'année, identiques au centime près ;
• échantillons vérifiés à la main par les responsables métier ;
• parcours réels : créer une commande pour un client repris, éditer une facture, retrouver un historique.

Le RGPD impose d'ailleurs que les données personnelles soient exactes et tenues à jour (article 5 du règlement) : une reprise contrôlée en fait partie.

Les rôles : qui fait quoi

L'erreur classique est de tout confier au prestataire. Il sait déplacer les données, pas décider si un client inactif depuis 2019 doit être repris.

Les erreurs qui coûtent le plus cher

• Démarrer la reprise quand le logiciel est prêt. Commencez la cartographie dès le cadrage, en parallèle du développement.
• Ne jamais répéter. Une seule migration, le jour J, sans essai à blanc, c'est parier l'activité sur un script jamais exécuté en vrai.
• Oublier les pièces jointes. Contrats scannés, photos, PDF : ils pèsent lourd, ont des chemins fragiles et doivent rester liés au bon dossier.
• Couper l'ancien système trop tôt. Gardez-le en lecture seule le temps de régler les cas oubliés.
• Confondre transfert et validation. « Tout est passé » ne dit pas que tout est juste.

Et quand le nouveau logiciel est développé sur mesure

Dans un projet sur mesure, la reprise a un avantage : le modèle de données du nouvel outil peut être pensé à partir de vos données réelles, et non l'inverse. Les règles de correspondance s'écrivent en même temps que les écrans, et les essais à blanc alimentent les tests. Notre méthode de refonte d'une application métier intègre la reprise dès le premier jour pour cette raison.

C'est aussi pourquoi nous construisons le prototype gratuit, présenté en visio sous 5 jours ouvrés, sur un échantillon de vos vraies données quand c'est possible : vous voyez vos clients et vos commandes dans le futur outil avant de décider, comme nous l'expliquons dans voir son logiciel avant de le payer.