Reprendre quinze ans de données : ce que ça implique

Ce qui retient vraiment de changer de logiciel

Quand un dirigeant renonce à changer d'outil de gestion, ce n'est presque jamais le prix qui l'arrête. C'est une phrase qu'il se dit à lui-même : je vais perdre mon historique.

La crainte est légitime. Un fichier clients construit sur quinze ans, des tarifs négociés, des devis servant de référence, des campagnes passées auxquelles on compare celle en cours : tout cela ne se retape pas. Et personne ne veut être celui qui aura fait disparaître la mémoire de l'entreprise.

Voici comment une reprise se passe réellement, ce qui se récupère, ce qui ne se récupère jamais, et les questions à poser avant de s'engager.

Trois niveaux de reprise, qu'il faut distinguer

Le mot « reprise » recouvre trois choses très différentes, et le malentendu commence souvent là.

Les deux premiers niveaux sont indispensables : sans eux, le nouvel outil ne peut pas fonctionner. Le troisième est un choix, et c'est celui qui inquiète le plus alors que c'est souvent le moins urgent.

Ce qui se récupère presque toujours

Tout ce qui est structuré dans une base sort d'une manière ou d'une autre. Les fiches clients avec leurs coordonnées et leurs conditions, le catalogue avec ses prix et ses codes-barres, les fournisseurs, les soldes, les en-cours.

La difficulté n'est pas technique, elle est qualitative : ce qu'on reprend, on le reprend avec ses défauts. Doublons, adresses périmées, produits sans code-barres, tiers professionnels sans numéro d'identification. Une base sale importée dans un outil neuf produit un outil neuf qui donne des résultats faux.

D'où la règle que nous appliquons systématiquement : le nettoyage se fait avant l'import, jamais après. Reprendre une base sale revient à déménager en emportant les cartons qu'on avait prévu de jeter. Ce chantier est ingrat mais court, et c'est le meilleur moment de la vie d'une entreprise pour le mener.

Ce qui ne se récupère jamais tel quel

Autant le dire franchement, parce qu'une promesse excessive se paie au moment de la bascule.

• La mise en page de vos anciens documents. Un devis émis il y a huit ans avec l'ancien modèle ne se reconstitue pas au pixel près. On récupère ses données, pas son apparence.
• Les champs bricolés. Toute entreprise a détourné un champ pour y ranger une information que le logiciel ne prévoyait pas. Ces contenus se récupèrent, mais il faut décider où ils vont, et cela suppose une conversation.
• Les paramétrages internes. Règles de remise, automatismes, modèles : ils se reconstruisent, ils ne se transposent pas.
• Ce que l'ancien système ne sait pas exporter. C'est la vraie limite, et elle ne dépend pas du nouvel éditeur.

Cette dernière ligne mérite d'être vérifiée avant de signer avec qui que ce soit, et auprès de l'éditeur que vous quittez. C'est une question désagréable à poser, et c'est précisément pour cela qu'il faut la poser tôt.

La solution simple pour l'historique ancien

Quand un historique profond ne s'importe pas proprement, il existe une réponse que l'on oublie souvent : le conserver consultable à côté.

Plutôt que de forcer dix ans de données dans un modèle qui ne les attendait pas, on garde l'ancien système accessible en lecture, ou l'on conserve un export figé. Vous continuez de pouvoir répondre à une question sur une vente de 2019, sans avoir pollué votre outil neuf avec des données mal converties.

Dans les faits, la fréquence de consultation d'un historique ancien chute très vite après la bascule. Ce qu'on regarde, c'est l'année en cours et la précédente. Le reste sert deux ou trois fois par an, et une consultation à côté suffit largement.

La bascule : une date, pas une période

L'erreur d'organisation la plus coûteuse consiste à faire tourner les deux systèmes en parallèle « le temps de se rassurer ». Au bout de trois semaines, ils divergent, et l'on ne sait plus lequel fait foi.

La bonne méthode tient en quatre points :

• Une date de bascule nette, choisie dans une période calme. Pour un moulin, jamais en novembre ; pour un commerce, jamais en décembre.
• Un inventaire à cette date, qui devient le stock de départ du nouvel outil.
• Les en-cours repris à cette date : ce qui est facturé avant reste dans l'ancien, ce qui est facturé après part dans le nouveau.
• L'ancien système en lecture seule dès le lendemain. Pas de double saisie, pas d'exception.

Cette rigueur paraît brutale. Elle est en réalité la plus confortable, parce qu'elle supprime la question « où dois-je saisir ça ? », qui est la vraie source de fatigue d'une migration.

Les questions à poser avant de vous engager

• Qui réalise la reprise, vous ou l'éditeur, et sur quel périmètre exactement ?
• Y a-t-il une reprise à blanc avant la bascule, permettant de vérifier les données sur un jeu réel ?
• Que devient l'historique qui n'est pas repris : consultable où, et pendant combien de temps ?
• Et si je pars dans cinq ans, que puis-je récupérer, dans quel format ?

La dernière est la plus révélatrice, et la moins posée. Un éditeur qui répond clairement sur les conditions de sortie vous dit beaucoup sur la confiance qu'il place dans son produit.

Ce n'est pas un saut dans le vide

Une migration bien préparée n'est pas une opération risquée, c'est une opération encadrée : on sait ce qu'on reprend, on sait ce qu'on ne reprend pas, on sait quand on bascule, et on garde l'ancien accessible.

Ce qui est réellement risqué, c'est de rester sur un outil qui ne suivra pas la prochaine échéance réglementaire, ou dont l'éditeur n'existe plus. Nous avons vu ce que quatre réformes en vingt ans exigent d'un éditeur : c'est là que se joue la vraie continuité, pas dans la peur de changer.

Si vous vous interrogez sur votre propre reprise, parlons-en avant de décider : nous regarderons ce que votre système actuel sait exporter, ce qui vaut la peine d'être repris, et ce qu'il vaut mieux garder à côté. Voir aussi par où commencer un projet de gestion.