Reprise de données et intégration

Ce qui fait échouer les changements d'outil

Un nouveau logiciel qui démarre vide n'est pas utilisable : personne ne retrouve l'historique d'un client, et l'ancien outil reste ouvert « juste pour consulter » — puis pour saisir, et le projet est mort. Un logiciel qui démarre avec des données fausses est pire encore, parce que la confiance perdue au premier mois ne revient pas.

La reprise de données n'est donc pas une formalité de fin de projet. C'est souvent la partie qui décide de l'adoption, et c'est presque toujours celle qu'on sous-estime.

D'où l'on part, en général

Des classeurs Excel

Le cas le plus fréquent, et le plus trompeur. Un tableur accepte tout : des lignes de total au milieu des données, des dates en trois formats, une colonne « commentaire » qui contient en réalité trois informations différentes, des doublons créés par des copies successives. Tout cela se reprend, mais il faut le voir avant de s'engager sur un délai.

Une base Access ou un logiciel ancien

Souvent développé sur mesure il y a quinze ou vingt ans, parfois par quelqu'un qui n'est plus là. La structure est généralement plus saine qu'un tableur, mais la documentation manque et certaines règles ne vivent que dans le code.

Un progiciel du marché

Il faut examiner ce que l'éditeur permet d'exporter. Un export CSV existe presque toujours ; l'accès direct à la base dépend du contrat. C'est un point à vérifier tôt, parce qu'il conditionne le calendrier.

Du papier

Cela arrive encore, notamment pour les historiques anciens. La question à trancher est alors : qu'est-ce qui mérite vraiment d'être ressaisi ? Souvent, une fraction seulement.

Comment se déroule une reprise

1. Audit des sources

On regarde les fichiers réels, pas leur description. On compte les enregistrements, on relève les doublons, les valeurs manquantes, les incohérences de format. Cette étape produit un état des lieux chiffré : c'est lui qui permet d'estimer honnêtement la charge.

2. Décision sur le périmètre

Tout ne mérite pas d'être repris. Les clients inactifs depuis dix ans, les devis jamais transformés, les références abandonnées : les reprendre coûte cher et encombre le nouvel outil. On décide ensemble de ce qui entre, de ce qui part dans une archive consultable, et de ce qui reste dans l'ancien système.

3. Nettoyage et transformation

Normalisation des formats, dédoublonnage sur des règles explicites — jamais automatiquement, une fusion à tort est difficile à défaire —, mise en correspondance des codes, contrôle des références croisées.

4. Reprises à blanc

La migration est rejouée plusieurs fois sur une copie, avec un rapport de contrôle à chaque passage : totaux comparés, échantillons vérifiés, écarts expliqués. On ne bascule que lorsque le rapport ne comporte plus d'anomalie inexpliquée.

5. Bascule

Reprise finale sur des données figées, contrôle, puis ouverture du nouvel outil. L'ancien système reste consultable en lecture pendant une période convenue — c'est peu coûteux et cela évite bien des angoisses.

Faire communiquer vos applications

Changer d'outil ne veut pas dire tout remplacer. La plupart des entreprises gardent leur comptabilité, leur caisse, leur site marchand ou leur logiciel métier, et le sujet devient : comment éviter que la même donnée soit saisie deux fois ?

Par API

Quand les deux logiciels exposent une interface programmable, l'échange est direct et immédiat. C'est le cas le plus confortable.

Par échange de fichiers

Quand il n'y a pas d'API, un export programmé la nuit et une reprise automatique côté destinataire règlent la plupart des besoins. Moins élégant, parfaitement fiable, et cela fonctionne avec des logiciels très anciens.

Par la base de données

Possible lorsque l'éditeur l'autorise. À manier avec prudence : écrire directement dans la base d'un progiciel tiers peut rompre la garantie ou casser des règles internes. En lecture seule, c'est en revanche souvent la voie la plus simple.

Ces raccordements servent aussi bien un ERP sur mesure qu'un CRM, ou deux logiciels du marché qui s'ignoraient jusque-là.

Questions fréquentes

Mes données sont dans des fichiers Excel en désordre, est-ce récupérable ?

Presque toujours. Ce qui ne se récupère pas, c'est une information qui n'a jamais été saisie — et l'audit préalable sert justement à le savoir avant de s'engager.

L'éditeur de mon logiciel refuse de me donner mes données. Que faire ?

Vos données vous appartiennent, et le RGPD comme le droit des contrats vous donnent des arguments. En pratique, il existe presque toujours une voie technique : fonction d'export, accès à la base, ou extraction depuis les états imprimables.

Combien de temps prend une reprise ?

Cela dépend beaucoup moins du volume que de la qualité. Cent mille lignes propres se reprennent plus vite que deux mille lignes saisies pendant quinze ans par cinq personnes avec des conventions différentes.

Peut-on faire communiquer deux logiciels qui n'ont pas été prévus pour ?

Souvent oui, par API, par échange de fichiers programmé, ou par la base lorsque c'est autorisé. La solution dépend surtout de ce que l'éditeur permet contractuellement.

Peut-on revenir en arrière si la bascule se passe mal ?

Oui, et c'est prévu : les données de départ sont conservées intactes, la bascule est répétée à blanc avant d'être faite pour de bon, et l'ancien système reste consultable pendant une période convenue.

Un projet de migration ?

L'audit des sources est la première étape, et elle vaut d'être faite même si vous n'allez pas plus loin : elle vous dit ce que contiennent réellement vos fichiers.

Formulaire de contact · apoulitcreations@gmail.com · 07 61 57 60 62

Voir aussi : ERP sur mesure et CRM sur mesure.