Oui, vos données existantes peuvent être récupérées dans une nouvelle application métier : fichiers Excel, exports d’un ancien logiciel, base Access, voire documents papier. C’est ce qu’on appelle la reprise de données, et elle fait partie intégrante d’un projet d’application sur mesure. Concrètement, l’agence extrait vos données, les nettoie, les transforme pour qu’elles correspondent à la structure de la nouvelle application, puis les importe et les fait valider par vos équipes avant la mise en service.
Ce travail est rarement le plus visible du projet, mais il conditionne la confiance de vos collaborateurs dès le premier jour : un historique client incomplet ou des stocks erronés suffisent à discréditer un outil pourtant bien conçu. Voici comment une reprise de données se déroule, ce qu’elle coûte en temps et en attention, et les décisions qui vous reviennent en tant que dirigeant.
Reprise de données : de quoi parle-t-on exactement ?
La reprise de données désigne le transfert de l’information que votre entreprise a accumulée dans ses outils actuels vers la nouvelle application. Elle se distingue de l’interconnexion entre logiciels, qui consiste à faire dialoguer en continu deux systèmes qui restent tous les deux en service. Ici, l’ancien outil est destiné à disparaître ou à être relégué en consultation.
Dans une PME, les sources sont souvent hétérogènes : un classeur Excel par commercial, un logiciel de gestion vieillissant, une boîte mail qui sert d’archive, parfois des cahiers d’atelier. Si vous êtes dans la situation décrite dans notre article sur les signes qu’il est temps de remplacer Excel par une application métier, la reprise de données sera l’un des premiers chantiers à cadrer.
Quelles données reprendre, et lesquelles laisser derrière vous ?
La tentation est de tout migrer. C’est en général une erreur : reprendre vingt ans d’historique multiplie le travail de nettoyage, alourdit l’application et transporte des données dont plus personne ne se sert. Mieux vaut distinguer plusieurs familles.
- Les référentiels : clients, fournisseurs, articles, sites, équipements, salariés. Ils sont indispensables et doivent être repris de manière exhaustive et propre.
- Les données vivantes : commandes en cours, interventions planifiées, devis non signés, stocks actuels. Elles sont reprises au plus près de la bascule pour refléter la réalité du jour J.
- L’historique utile : les deux ou trois dernières années de factures ou d’interventions, parce qu’on y fait régulièrement référence et qu’elles alimentent les statistiques.
- L’historique profond : tout ce qui est plus ancien. On le conserve souvent sous forme d’archive consultable (un export figé, l’ancien outil en lecture seule) plutôt que de l’intégrer à la nouvelle application.
Cette sélection a aussi une dimension réglementaire. Le RGPD impose de ne pas conserver indéfiniment des données personnelles sans justification ; une migration est le moment idéal pour purger les contacts inactifs depuis longtemps ou les candidatures oubliées. Notre article sur le RGPD dans une application métier détaille ce qu’il faut prévoir dès la conception. Cet article ne remplace toutefois pas l’avis d’un professionnel du droit pour votre situation précise.
Les étapes d’une reprise de données réussie
1. Inventaire des sources
L’agence recense avec vous chaque emplacement où vit une donnée utile : fichiers, logiciels, bases, documents. Pour chacun, on note le format, le volume, le propriétaire métier et la fréquence de mise à jour. Cet inventaire révèle presque toujours des sources oubliées.
2. Extraction
Les fichiers bureautiques s’extraient facilement. Les anciens logiciels sont plus délicats : certains proposent un export complet, d’autres seulement des exports partiels écran par écran, et certains stockent les données dans un format fermé. Dans ce dernier cas, il faut parfois demander une extraction à l’éditeur, ce qui peut avoir un coût et un délai à anticiper dans le planning.
3. Nettoyage et dédoublonnage
C’est l’étape la plus longue et la plus sous-estimée. Un même client apparaît sous trois orthographes, des adresses sont incomplètes, des champs libres contiennent des informations qui devraient être structurées (« à rappeler le mardi » dans le champ téléphone). Les règles de nettoyage sont définies avec vous, puis appliquées par des scripts pour être reproductibles.
4. Transformation vers la nouvelle structure
La nouvelle application a son propre modèle de données, souvent plus structuré que l’ancien. Une colonne « Statut » avec des valeurs saisies à la main devient une liste fermée ; une adresse en un seul bloc est découpée en rue, code postal et ville. L’agence rédige une table de correspondance (le « mapping ») qui documente, champ par champ, d’où vient chaque information et comment elle est convertie.
5. Import à blanc et validation métier
Avant la bascule réelle, une ou plusieurs migrations à blanc sont réalisées dans un environnement de test. Vos équipes vérifient par sondage que les fiches sont complètes, que les totaux correspondent et que les cas particuliers ont été traités. Les écarts constatés font corriger les scripts, puis on recommence jusqu’à obtenir un résultat satisfaisant.
6. Bascule
Le jour de la mise en service, on gèle les saisies dans l’ancien outil, on lance la migration finale sur des données fraîches, on contrôle les chiffres clés et on ouvre l’accès aux utilisateurs, généralement sur un week-end ou une période creuse.
Combien de temps et d’efforts cela représente-t-il ?
Il n’existe pas de réponse universelle, car tout dépend de l’état de vos données et du nombre de sources. Trois facteurs pèsent particulièrement.
| Facteur | Situation simple | Situation complexe |
|---|---|---|
| Nombre de sources | Un ou deux fichiers maîtres | Plusieurs logiciels et fichiers qui se recoupent |
| Qualité des données | Saisie encadrée, peu de doublons | Champs libres, doublons, données manquantes |
| Accessibilité | Export complet disponible | Format fermé, éditeur injoignable |
Une part importante de l’effort repose sur vos équipes : ce sont elles qui savent quel client est le « vrai » parmi les doublons ou quel code article est obsolète. Prévoyez du temps pour ces arbitrages, idéalement une personne référente par domaine. Si vous souhaitez situer cette phase dans l’ensemble du projet, consultez notre article sur le déroulement d’un projet de webapp avec une agence.
Les pièges les plus fréquents
- Découvrir la reprise de données en fin de projet. Elle doit être cadrée dès le cahier des charges, parce qu’elle influence la structure de l’application et le planning de mise en service.
- Nettoyer à la main dans Excel. Le travail n’est pas reproductible : à la migration finale, il faudra tout refaire sur des données qui ont évolué entre-temps. Les scripts, eux, se rejouent en quelques minutes.
- Négliger la traçabilité. Conserver l’identifiant d’origine de chaque enregistrement permet, des mois plus tard, de retrouver la source d’une donnée douteuse.
- Oublier les pièces jointes. Devis en PDF, photos d’intervention, contrats signés : ces fichiers accompagnent souvent les données et doivent être rattachés aux bonnes fiches.
- Couper l’ancien outil trop vite. Gardez-le accessible en lecture seule pendant quelques mois, le temps de vérifier qu’aucune information n’a été perdue.
Et si vous changez d’application plutôt que de fichiers ?
Lorsque l’ancien outil est lui-même une application développée sur mesure, la question prend une autre forme : faut-il la reprendre, la refondre ou migrer ? Les principes de reprise de données restent les mêmes, mais l’accès à la base est souvent plus direct, ce qui simplifie l’extraction. Notre article reprendre une application existante : audit, refonte ou migration traite spécifiquement de ce cas.
À l’inverse, certains outils doivent rester en service après la mise en ligne, typiquement le logiciel de comptabilité. On ne parle alors plus de reprise mais de connexion entre les deux systèmes.
Questions fréquentes
Peut-on démarrer la nouvelle application sans reprise de données ?
C’est possible pour certaines activités, par exemple un outil de suivi des interventions où l’on repart des chantiers à venir. Mais il faut au minimum reprendre les référentiels (clients, sites, équipements), sinon les utilisateurs devront tout ressaisir et rejetteront l’outil.
Qui est responsable de la qualité des données migrées ?
L’agence est responsable de la fidélité de la transformation : ce qui entre doit ressortir conformément au mapping validé. La qualité intrinsèque des données d’origine, elle, relève de l’entreprise, d’où l’importance des arbitrages métier pendant le nettoyage.
En résumé
La reprise de données n’est ni un détail technique ni une formalité : c’est le moment où votre nouvelle application hérite de la mémoire de l’entreprise. Bien menée, elle offre une occasion rare de remettre vos référentiels au propre et de démarrer sur des bases fiables. Chez Symbiose, nous la traitons comme un lot à part entière du projet, avec son inventaire, ses migrations à blanc et sa validation par vos équipes. Si vous envisagez de quitter vos fichiers ou un logiciel vieillissant, parlons de vos données avant de parler d’écrans.