Reprendre ses données quand on change de logiciel
La migration est le moment de vérité : on découvre alors ce que valait vraiment la promesse de propriété des données.
Le jour où il faut sortir les données
Un commerçant utilise le même logiciel de caisse ou de gestion depuis trois ans. Il décide d'en changer parce que l'outil ne suit plus, ou parce qu'un logiciel sur mesure répond mieux à son activité. Il demande l'export de ses données clients, de son historique de ventes, de son catalogue produits. Réponse : un fichier PDF, un tableau figé, ou un export CSV avec des colonnes sans nom compréhensible. Personne ne lui avait dit que "vos données vous appartiennent" voulait dire ça.
Ce scénario revient souvent. Le contrat mentionnait bien la propriété des données. Il ne précisait rien sur le format, la structure, ni le délai de restitution. C'est exactement là que ça coince.
Ce que "propriété des données" veut vraiment dire
Une clause de propriété sans obligation de format exploitable ne sert à rien. Avoir le droit de récupérer ses données ne veut rien dire si elles arrivent sous une forme inutilisable : capture d'écran, PDF non structuré, export partiel qui exclut l'historique ou les champs personnalisés.
La vraie question à poser avant de signer n'est pas "puis-je récupérer mes données", mais "sous quelle forme, avec quelle structure, et en combien de temps". Un éditeur sérieux répond à ces trois questions sans détour. Un éditeur qui esquive prépare déjà le verrouillage.
Ce qu'il faut exiger avant de signer
Avant toute signature d'un contrat de logiciel de gestion, CRM ou ERP, quatre ou cinq points doivent être actés noir sur blanc, pas promis à l'oral :
- Le format d'export : un format structuré et standard (CSV avec en-têtes clairs, JSON, ou accès direct à une base de données), jamais un export propriétaire fermé ou un PDF.
- Un jeu d'essai avant signature : demander un export test sur un petit échantillon de données pour vérifier que ce qui sort correspond à ce qui a été saisi, avant de s'engager sur douze ou trente-six mois.
- Une table de correspondance des champs : un document qui explique à quoi correspond chaque colonne exportée, pour éviter de deviner ou de perdre du sens en cours de reprise.
- Une période de double saisie prévue au contrat : le temps de faire tourner l'ancien et le nouveau système en parallèle, sans surcoût imprévu ni coupure d'activité.
- Un délai de restitution écrit : combien de jours l'éditeur a pour fournir l'export complet en cas de résiliation, et sous quelle forme.
Ces points se négocient avant la signature, jamais après. Une fois le contrat signé et les données saisies pendant deux ans, le rapport de force change complètement.
Les pièges classiques et leur coût réel en jours
Certains pièges reviennent sans cesse, et ils se traduisent directement en jours de travail perdus au moment de la migration.
L'export en PDF ou en impression papier est le plus fréquent. Les données existent, mais pas sous une forme réutilisable. Il faut alors ressaisir à la main, ou payer un prestataire pour extraire l'information d'un document non structuré. Sur une base de quelques centaines de fiches clients, cela peut représenter plusieurs jours de saisie.
L'absence de table de correspondance est presque aussi coûteuse. Un export CSV avec des colonnes nommées "champ12" ou "val_x" oblige à deviner, tester, corriger. Le temps perdu à reconstituer le sens des données dépasse souvent celui de la saisie elle-même.
L'historique tronqué est plus discret mais tout aussi gênant. Certains exports ne couvrent que les douze derniers mois, ou excluent les données archivées. On découvre le trou une fois la migration terminée, quand un client demande un historique de commande qui n'existe plus nulle part.
Enfin, l'absence de période de double saisie force à basculer d'un coup. Le jour du changement, l'équipe travaille sur deux systèmes non synchronisés, avec un risque réel d'erreurs de facturation ou de perte de commandes en cours.
Chacun de ces pièges se traduit en jours perdus, en heures de reprise, ou en erreurs à corriger après coup. Aucun n'est une fatalité : tous se négocient en amont.
Ce que ça change pour la suite
La tendance va vers des formats d'export plus standardisés, portés en partie par les obligations de facturation électronique et par l'interopérabilité croissante entre logiciels de gestion. Mais cette évolution ne dispense pas de vérifier, contrat par contrat, ce qui est réellement prévu. Un format standard sur le papier ne garantit pas un export complet et exploitable en pratique.
La vigilance reste la même qu'il y a cinq ans : demander avant de signer, tester avant de s'engager, et ne jamais confondre une promesse contractuelle avec une donnée qu'on peut effectivement récupérer.
Conclusion
La reprise de données ne se négocie pas le jour où on change de logiciel. Elle se négocie avant de signer le premier, avec un format, un jeu d'essai et une table de correspondance écrits noir sur blanc.
Vérifier la portabilité de vos données avant de changer de logiciel
ArkonLabs conçoit des logiciels de gestion sur mesure avec un plan de reprise de données défini dès le cadrage : format d'export, table de correspondance, période de double saisie. Pour discuter de votre situation actuelle, rendez-vous sur www.arkon-labs.com.