Reprise de données : que vérifier avant de changer de logiciel ?

Une reprise de données lors d’un changement de logiciel n’est pas réussie simplement parce que l’import se termine sans erreur. Une commande doit retrouver son client, ses documents et son statut ; une équipe doit pouvoir reprendre un dossier en cours sans reconstruire son historique.

Pour une PME, le sujet mérite une validation à part entière. Voici comment définir ce qui doit être transféré, demander des preuves utiles et décider de la bascule. Cette méthode concerne le remplacement d’un outil métier, d’un CRM ou d’une application ancienne, vers un logiciel du marché ou une application sur mesure.

Le repère à garder : distinguez trois questions : avons-nous repris le bon périmètre, les informations ont-elles gardé leur sens, et peut-on réellement travailler avec elles ? Un total de lignes identique ne répond qu’à une partie du problème.

Sommaire

• Définir les données à reprendre
• Écrire les règles de correspondance
• Vérifier l’import avec des preuves
• Répéter et organiser la bascule
• Clarifier les responsabilités et le devis
• Questions fréquentes

Définir le périmètre de la reprise de données

Commencez par les objets dont l’entreprise se sert : clients, contacts, commandes, interventions, contrats, articles, documents associés. Pour chacun, identifiez la source qui fait référence et la personne capable de confirmer la signification des champs. Un export disponible n’est pas nécessairement un export complet.

Vérifiez notamment les notes, pièces jointes, historiques de statut, références anciennes et liens entre dossiers. Certaines informations peuvent se trouver dans un répertoire partagé ou un second outil plutôt que dans la base principale. Faites préciser comment elles seront récupérées, puis retrouvées dans la nouvelle application.

Séparer les données actives des archives

Tout reprendre à l’identique n’est pas toujours utile. Vous pouvez distinguer les dossiers nécessaires au travail quotidien, l’historique à consulter et les éléments hors périmètre. Consignez les exclusions et leur justification ; une donnée absente doit être un choix explicable, pas une découverte après le lancement.

Conserver l’ancien outil en lecture seule peut faciliter la consultation, mais vérifiez que cet accès restera possible : licences, postes compatibles, hébergement, sauvegardes et personne responsable. Une archive exportée demande aussi une structure compréhensible et une méthode de recherche. Ni la migration ni l’archivage ne justifient une conservation sans limite : faites valider les règles applicables à vos données avant toute suppression ou prolongation de conservation.

Si vous hésitez encore sur l’intérêt de changer d’outil, commencez par notre guide pour décider quand remplacer Excel par un logiciel métier. Ici, la décision de changement est déjà prise : il s’agit de sécuriser le transfert, pas de choisir une technologie.

Écrire les règles de correspondance avant l’import

Le tableau de correspondance, parfois appelé mapping, indique où va chaque information et comment elle est transformée. Il doit être relu par quelqu’un qui connaît le métier. Un développeur peut convertir une date ; il ne peut pas deviner si elle représente une échéance contractuelle ou un rendez-vous indicatif.

Pour chaque champ important, notez le champ source, sa destination, le format attendu, la transformation autorisée et la conduite à tenir si la valeur est vide ou incohérente. Évitez les valeurs par défaut qui donnent une apparence correcte à une information inconnue. Un statut « à vérifier » peut être plus honnête qu’un dossier déclaré terminé sans preuve.

Préserver les identifiants et les relations

Les numéros techniques peuvent changer dans la nouvelle application. Conservez alors une correspondance entre ancienne et nouvelle référence, avec une règle pour les liens entre objets. Il faut pouvoir expliquer à quel client appartient une commande et à quelle intervention correspond un document.

Exemple fictif : deux établissements portent le même nom commercial mais appartiennent à des sociétés différentes. Fusionner leurs fiches sur le seul nom peut mélanger leurs commandes. Définissez les critères de rapprochement et faites arbitrer les cas ambigus. Une correction de doublons doit laisser une trace de ce qui a été regroupé, conservé ou rejeté.

Contrôler les données transférées à plusieurs niveaux

Demandez un rapport de reprise qui distingue les éléments lus, importés, écartés et en erreur. Les nombres doivent pouvoir se rapprocher selon les règles convenues, en tenant compte des fusions et des transformations. Si le périmètre change entre deux essais, comparez les résultats sur une base équivalente.

Un contrôle automatique peut repérer un champ obligatoire vide ou une relation manquante. Il ne remplace pas la validation du sens des informations. À l’inverse, ouvrir quelques fiches au hasard ne suffit pas à repérer toutes les omissions. Combinez des contrôles exhaustifs sur les règles calculables avec des essais métier ciblés.

Choisir des cas qui mettent les règles à l’épreuve

Construisez votre échantillon avec les utilisateurs : dossier ordinaire, ancien dossier rouvert, commande partiellement livrée, client avec plusieurs contacts, texte accentué, pièce jointe volumineuse, information manquante. Adaptez ces exemples à votre activité. Leur rôle est de couvrir les situations importantes et les exceptions, pas d’atteindre un nombre arbitraire de fiches.

Dans son guide de préparation à la mise en service de Dynamics 365, Microsoft recommande de tester la migration et d’obtenir une validation métier après avoir traité les problèmes identifiés. Ce principe aide à séparer un transfert techniquement exécuté d’une reprise réellement acceptée.

Conservez pour chaque anomalie une référence de test, le résultat attendu, le constat et la décision. Limitez l’accès aux exports et aux environnements d’essai ; utilisez des données anonymisées lorsque cela permet de vérifier le scénario. Un rapport partagé largement ne doit pas devenir une copie supplémentaire de votre fichier clients.

Répéter la migration et décider du moment de bascule

Un petit import réussi ne donne pas la durée du transfert complet. Faites une répétition avec un volume représentatif et mesurez toute la séquence : extraction, transformation, chargement, contrôles et décision. Le temps disponible doit inclure les vérifications et une marge adaptée au projet, pas seulement le chargement des fichiers.

Le guide Microsoft de planification de la bascule distingue le chargement complet des reprises des modifications intervenues ensuite. Il insiste aussi sur la communication et le gel des écritures lors du dernier transfert. Les délais et volumes de ses exemples ne constituent pas un barème pour votre PME.

Ne pas perdre les changements intervenus après l’export

Si votre équipe continue de travailler entre l’extraction et le lancement, prévoyez comment reprendre les créations, modifications et suppressions intervenues pendant cet intervalle. La reprise des seules nouvelles fiches ne suffit pas. Fixez le moment où l’ancien outil cesse d’être modifiable et où le nouveau devient la référence.

La continuité d’activité ne signifie pas nécessairement zéro interruption. Selon les outils et leurs possibilités d’export, une fenêtre de suspension clairement annoncée peut être nécessaire. Précisez les tâches momentanément indisponibles, le contact en cas de difficulté et le moment où les équipes reçoivent l’autorisation de reprendre.

Prévoir un retour arrière qui tient compte des nouvelles saisies

Une sauvegarde conservée ne suffit pas à définir un retour arrière. Désignez qui décide, quels incidents justifient l’arrêt, jusqu’à quand l’ancienne solution reste utilisable et comment seront récupérées les opérations réalisées depuis la bascule. Remettre une copie ancienne en service peut sinon faire disparaître le travail de la journée.

Après ouverture, surveillez les premiers traitements et les échanges avec les autres logiciels. Les synchronisations récurrentes relèvent d’un autre contrôle : notre guide sur l’automatisation des doubles saisies explique notamment comment traiter les doublons et les reprises après interruption. Ne réactivez pas une connexion sans vérifier sur quelle base elle va travailler.

Clarifier les responsabilités et le contenu du devis

La mention « reprise des données incluse » laisse trop de questions ouvertes. Faites préciser les sources concernées, les formats disponibles, les pièces jointes, les transformations prévues, le traitement des anomalies, les répétitions et l’accompagnement de la bascule. Le devis doit distinguer ce qui est confirmé de ce qui reste à examiner sur un export test.

Répartissez aussi le travail : qui fournit l’export, qui corrige les données à la source, qui tranche les doublons et qui valide les résultats ? Le prestataire ne doit pas décider seul du sens métier d’une information ; l’entreprise ne doit pas être seule à détecter les erreurs techniques. Ces responsabilités peuvent compléter votre cahier des charges logiciel.

Avant d’autoriser la bascule : demandez un périmètre daté, des règles de transformation validées, un rapport de rapprochement, des essais métier réussis et une procédure de reprise utilisable. Les écarts restants doivent être nommés et leur impact accepté explicitement.

Questions fréquentes sur la reprise de données

Quelle différence entre migration de logiciel et reprise de données ?

La migration de logiciel concerne le changement d’application, ses fonctions, ses utilisateurs et son exploitation. La reprise de données est le chantier qui sélectionne, transforme, transfère et vérifie les informations existantes. Les deux doivent être coordonnés.

Faut-il reprendre tout l’historique ?

Pas nécessairement. Distinguez les données utiles au travail quotidien, les archives consultables et les exclusions validées. La décision dépend des usages, des possibilités techniques et des règles de conservation applicables à vos données.

Un export Excel ou CSV suffit-il ?

Il peut suffire pour certaines données tabulaires, mais il faut vérifier les champs exportés, les formats, les identifiants et les relations. Les pièces jointes, les historiques et les droits peuvent nécessiter un traitement distinct.

Peut-on changer de logiciel sans interruption ?

Cela dépend des outils et de la méthode retenue. Une reprise progressive peut limiter l’arrêt, mais les dernières modifications et les écritures concurrentes doivent être maîtrisées. Ne promettez pas une absence d’interruption sans répétition et validation technique.

Qui valide que la reprise est correcte ?

Le prestataire vérifie le transfert et les règles techniques ; les responsables métier confirment le sens des données et les parcours de travail. Une personne désignée formalise la décision à partir des résultats, des écarts et de leurs conséquences.

Préparer la reprise avant de reconstruire le logiciel

La qualité d’une migration se juge sur le travail que votre équipe peut reprendre, avec des informations fiables et des écarts connus. Traitez donc les données comme un chantier du projet, avec son périmètre, ses règles et sa validation.

Pixel Info accompagne la migration de logiciels existants vers des applications web. Pour un premier échange, indiquez l’outil utilisé, les types de données, les exports possibles et les opérations qui ne peuvent pas être interrompues. Présentez votre projet de migration sans joindre de données clients confidentielles ; les modalités d’un éventuel échantillon seront définies ensemble.