Faut-il reprendre tout l’historique de l’ancien logiciel ?
Pas nécessairement. Dix années de données peuvent représenter beaucoup de volume alors qu’une grande partie n’est quasiment jamais consultée. Il faut distinguer les données nécessaires aux opérations courantes, celles requises pour la traçabilité ou les obligations de conservation et celles pouvant rester accessibles dans une archive.
Une stratégie fréquente consiste par exemple à reprendre les référentiels complets et les dernières années d’activité utiles, puis à conserver les historiques plus anciens dans un système de consultation en lecture seule. Le choix doit cependant être adapté au métier : comptabilité, qualité, santé ou industrie peuvent imposer des exigences de conservation très différentes.
Cette décision prise avant le développement réduit fortement la quantité de transformations, de contrôles et de tests nécessaires pendant la migration.
Comment faire correspondre les données entre l’ancien et le nouveau logiciel ?
Le mapping de données consiste à définir la correspondance entre les champs du système source et ceux du système cible. Par exemple : `client_name → raison_sociale`, `status = 3 → statut = "validé"`, ou `customer_id → relation avec la nouvelle fiche client`.
Certaines correspondances sont directes ; d’autres nécessitent une transformation. Une ancienne application peut stocker un nom complet dans un seul champ alors que la nouvelle sépare prénom et nom, utiliser d’anciens codes métier ou représenter plusieurs états avec une seule valeur.
Ces règles doivent être documentées avant le chargement. Elles permettent ensuite de développer des scripts reproductibles plutôt que de corriger manuellement les mêmes données après chaque test de migration.
Comment nettoyer et dédupliquer les données avant leur migration ?
Une migration est souvent le meilleur moment pour arrêter de transporter des problèmes historiques. Le nettoyage peut traiter doublons, valeurs manquantes, caractères invalides, formats incohérents, anciennes références, emails incorrects ou relations devenues inutiles.
Le dédoublonnage doit cependant rester prudent. Deux sociétés portant presque le même nom ne sont pas nécessairement le même client. Les règles peuvent donc combiner plusieurs critères, comme le SIRET, l’email, l’identifiant historique et l’adresse, puis réserver les cas ambigus à une validation humaine.
L’objectif n’est pas de rendre artificiellement toutes les données parfaites avant la migration, mais de déterminer quel niveau de qualité est nécessaire pour que le nouveau système puisse fonctionner sans hériter des erreurs les plus coûteuses.
Comment migrer des données depuis Excel, un ERP, un CRM ou un ancien logiciel métier ?
Les fichiers Excel et CSV sont généralement simples à extraire mais peuvent contenir beaucoup de logique implicite : couleurs, formules, onglets, colonnes utilisées différemment selon les équipes. Il faut donc comprendre leur usage avant de considérer chaque colonne comme une donnée propre.
Une migration depuis un ERP ou CRM implique souvent davantage de relations : clients, commandes, factures, lignes de commande, produits, utilisateurs et historiques doivent rester reliés. Selon le produit, l’extraction peut se faire par API, export natif ou accès à la base de données.
Pour un ancien logiciel métier sur mesure, il faut parfois analyser directement son modèle de données. Le but reste le même : extraire proprement → transformer selon des règles connues → charger dans la cible → contrôler le résultat.
Comment tester une reprise de données avant la migration finale ?
Nous privilégions plusieurs migrations à blanc, c’est-à-dire des imports réalisés avant la bascule définitive avec une copie représentative des données. Elles permettent d’identifier les transformations incorrectes, les données rejetées et les temps nécessaires au traitement.
Après chaque chargement, une réconciliation compare la source et la cible : nombre de clients, montants, documents, relations, statuts ou autres indicateurs métier. Le contrôle ne doit pas uniquement vérifier que 50 000 lignes ont été importées ; il doit vérifier que les 50 000 bonnes lignes ont été importées correctement.
Une recette métier complète ensuite les contrôles automatiques : les utilisateurs testent des dossiers réellement connus avant d’autoriser la migration finale. Cette phase évite de découvrir qu’un historique indispensable n’a pas été repris après la mise en production.
Comment migrer les données sans interrompre l’activité ?
La bascule, ou cutover, désigne le moment où l’ancien système cesse d’être la source active et où le nouveau prend le relais. Elle doit être planifiée en fonction du volume de données, de la durée d’import et de la quantité de nouvelles informations susceptibles d’être créées pendant la migration.
Selon le contexte, l’ancien système peut être placé temporairement en lecture seule, une dernière extraction différentielle peut reprendre uniquement les changements récents, puis le nouveau logiciel devient la source de vérité une fois les contrôles terminés.
Un plan de rollback, ou plan de retour arrière, définit ce qui se passe lorsque la migration finale échoue : jusqu’à quel moment peut-on revenir à l’ancien système, quelles données doivent être restaurées et quelles opérations devront être rejouées. Une migration critique ne devrait pas dépendre d’une seule tentative sans scénario de repli.
Comment vérifier qu’aucune donnée n’a été perdue pendant une migration ?
La validation combine des contrôles quantitatifs, relationnels et métier. Comparer uniquement le nombre total de lignes ne suffit pas : il faut également vérifier les montants, les relations entre objets, les pièces jointes, les statuts, les dates et les données jugées critiques par les utilisateurs.
Des scripts peuvent produire automatiquement des rapports d’écarts : nombre d’enregistrements source et cible, éléments rejetés, relations orphelines, sommes de contrôle ou différences sur certains champs sensibles.
La migration n’est considérée comme terminée qu’après validation de critères définis à l’avance. Cette logique de recette et de contrôles est celle que l’on retrouve dans les projets réels de changement de système d’information : extraction, migration pilote, vérification quantitative et qualitative, corrections puis migration finale.
Comment sécuriser les données pendant une reprise ?
Les données de production ne doivent pas circuler librement entre ordinateurs, emails ou environnements de test. Le projet doit définir les personnes autorisées à accéder aux exports, leur stockage, leur chiffrement, leur durée de conservation et leur suppression après migration.
Lorsque les données contiennent des informations personnelles, le RGPD reste applicable pendant la migration : le fait de changer de logiciel n’autorise pas à multiplier les copies ou conserver sans limite des exports intermédiaires.
Les données sensibles peuvent également imposer des contraintes sectorielles supplémentaires. L’architecture de migration doit alors être adaptée au niveau de confidentialité attendu plutôt que de dupliquer automatiquement toute la base de production dans un environnement non maîtrisé.
Combien coûte une reprise ou une migration de données ?
Le coût dépend moins du nombre brut de lignes que de leur hétérogénéité et du nombre de règles nécessaires pour les interpréter. Un million de lignes parfaitement structurées peut parfois être plus simple à migrer que 20 fichiers Excel contenant chacun des règles métier différentes.
Les principaux facteurs sont : nombre de sources, qualité des données, relations à préserver, documents associés, historique repris, transformations nécessaires, contraintes de sécurité et nombre de migrations à blanc.
Chez Koragence, une reprise simple depuis quelques fichiers structurés peut être intégrée à un projet logiciel. Un chantier autonome avec plusieurs systèmes, nettoyage, scripts de transformation, tests et bascule doit être cadré séparément après analyse des données disponibles.
Comment Koragence réalise une reprise de données ?
Nous commençons par inventorier les sources et définir les données réellement nécessaires dans le nouveau système. Le mapping est ensuite validé avec les personnes qui connaissent le métier afin de documenter les transformations et les règles de nettoyage avant le développement des scripts.
Nous réalisons ensuite une ou plusieurs migrations à blanc, produisons les contrôles d’intégrité et corrigeons les écarts. Les utilisateurs peuvent effectuer leur recette sur des données réelles avant la bascule finale.
Le processus suit donc une chaîne vérifiable : inventaire → mapping → nettoyage → transformation → migration test → réconciliation → recette → bascule → contrôle final → archivage de l’ancien système.
Good is Merch
Onctuo
Comment auditer les données avant une migration vers un nouveau logiciel ?
La première étape consiste à savoir précisément ce qui existe : bases de données, fichiers Excel, pièces jointes, référentiels, historiques, utilisateurs et systèmes connexes. Pour chaque source, il faut identifier son propriétaire, son volume, sa qualité et déterminer si elle constitue réellement la source de vérité, c’est-à-dire la référence considérée comme correcte.
L’audit fait également ressortir les anomalies avant qu’elles soient transportées dans le nouveau système : doublons clients, identifiants manquants, formats de dates différents, références obsolètes, informations contradictoires ou relations cassées entre plusieurs tables.
Le résultat doit permettre de classer chaque donnée : à migrer, à nettoyer, à transformer, à archiver ou à abandonner. Migrer toutes les données simplement parce qu’elles existent augmente souvent le coût sans améliorer le futur logiciel.