Le 13 janvier 2026, la CNIL a prononcé deux sanctions à l'encontre de Free Mobile et de Free, pour un total de 42 millions d'euros. La sécurité était en cause, mais c'est un troisième manquement qui devrait intéresser tous les dirigeants qui changent de logiciel : la société n'avait mis en place aucune mesure pour trier les données de ses anciens abonnés. Des millions d'enregistrements conservés sans justification, pendant une durée excessive, parce que personne n'avait jamais décidé de les supprimer (CNIL, sanctions du 13 janvier 2026).
Ce n'est pas une histoire d'opérateur télécoms. C'est exactement ce que je retrouve dans presque chaque base de données qu'on me demande de récupérer quand une PME change d'outil. On accumule pendant douze ans, on ne trie jamais, et le jour du déménagement on découvre le volume.
En bref. La reprise de données est le poste qui fait le plus souvent dérailler un changement de logiciel métier. La bonne question n'est pas de savoir comment tout transférer, mais ce que vous êtes obligé de conserver, et où. Conserver et migrer sont deux opérations distinctes : les séparer allège le projet et règle votre conformité au passage.
Ce qu'on appelle une reprise de données
La reprise de données, ou migration de données, désigne l'opération qui consiste à récupérer les informations stockées dans votre ancien système pour les injecter dans le nouveau. Fichier clients, fournisseurs, catalogue, historique des commandes, factures, stocks, interventions, dossiers en cours : tout ce que votre entreprise a produit et qui doit continuer à servir demain matin.
Le mot « système » est volontairement large. Dans une PME, la source n'est presque jamais un logiciel unique. C'est un vieil outil métier, plus trois classeurs de tableurs, plus une boîte mail, plus un fichier que la comptable maintient de son côté depuis 2018. Cette dispersion est la vraie caractéristique du sujet en PME, et elle change complètement la méthode par rapport aux guides écrits pour des projets de grands comptes.
Pourquoi la reprise de données fait dérailler les projets
Parce que c'est le seul poste dont les erreurs ne se rattrapent pas vite. Un intégrateur le formule bien : corriger une erreur de paramétrage prend quelques heures, corriger une erreur de programmation prend quelques jours ou quelques semaines, mais corriger des données de base erronées peut prendre des mois, voire des années (Hargos).
L'autre raison est budgétaire. Quand un projet de logiciel est chiffré, la reprise est souvent traitée comme une ligne annexe, estimée sans que personne n'ait ouvert les fichiers sources. Le prestataire découvre la réalité au moment de l'extraction, et c'est là que le calendrier glisse. Je le dis sans détour parce que nous y sommes passés aussi : tant qu'on n'a pas regardé les données, on ne chiffre pas une reprise, on devine.
Enfin, une reprise ratée ne se voit pas tout de suite. Elle se manifeste trois mois après la mise en production, quand une équipe découvre que les commandes antérieures à une certaine date sont incomplètes, ou que le même client existe en quatre exemplaires. À ce moment-là, le nouveau logiciel a déjà perdu la confiance des utilisateurs, et c'est lui qu'on accuse.
Conserver et migrer ne sont pas la même chose
Voici le point que je n'ai vu traité nulle part, et qui change pourtant l'économie entière du projet. La plupart des dirigeants abordent la reprise avec une contrainte en tête : « je dois garder dix ans d'historique, donc je dois tout migrer ». La première partie de la phrase est exacte. La seconde ne l'est pas.
Votre obligation légale porte sur votre capacité à produire un document en cas de contrôle. Elle ne porte pas sur la présence de ce document dans votre outil de gestion quotidienne. Une facture de 2017 doit être retrouvable. Elle n'a aucune raison d'encombrer l'écran de votre commercial en 2026.
Ce que la loi vous oblige à conserver
Les durées sont publiques et faciles à vérifier. Les livres, registres comptables et pièces justificatives se conservent dix ans. Les documents fiscaux se conservent six ans au titre de l'article L102 B du Livre des procédures fiscales. Les contrats commerciaux, documents bancaires et pièces de transport se conservent cinq ans, comme la plupart des documents liés à la gestion du personnel (economie.gouv.fr). La même source rappelle que détruire des documents fiscaux avant le terme expose à une amende de 10 000 euros au titre de l'article 1734 du Code général des impôts.
Ces délais sont des planchers, pas des recommandations. Mais ils ne disent rien du support. Un export figé, complet, horodaté et consultable satisfait l'obligation aussi bien qu'une base active.
Ce que le RGPD vous oblige à supprimer
C'est le versant que presque personne n'anticipe. La CNIL décompose le cycle de vie d'une donnée personnelle en trois phases : la base active, utilisée au quotidien par les équipes ; l'archivage intermédiaire, réservé aux données dont la conservation répond à une obligation légale ou à un intérêt en cas de contentieux ; l'archivage définitif, réservé à ce qui présente un intérêt historique. Le passage en archivage intermédiaire suppose une séparation, physique ou logique, avec la base active, et un accès restreint aux seules personnes qui en ont besoin.
La phrase à retenir figure noir sur blanc dans la doctrine de la CNIL : « Il ne s'agit pas de conserver l'intégralité des données mais seulement celles qui sont indispensables ou requises par l'obligation légale » (CNIL). Autrement dit, reprendre en bloc dix ans de fiches clients dans votre nouveau logiciel ne vous met pas en conformité. Cela transfère votre dette de conformité dans un outil neuf, avec des sauvegardes toutes fraîches.
Une PME ne risque évidemment pas 27 millions d'euros. Mais le raisonnement appliqué à Free Mobile est le même à toutes les échelles : l'absence de tri est en soi le manquement. Et une migration est le seul moment où ce tri ne coûte presque rien, puisque vous êtes déjà en train de manipuler l'ensemble.
Chaque donnée mérite l'une des trois destinations
Voilà la méthode que j'applique désormais avant d'écrire la moindre ligne de script d'import. On ne se demande pas « est-ce que je reprends ceci », question à laquelle la réponse est toujours oui par prudence. On attribue à chaque ensemble une destination parmi trois.
La première, c'est la migration : les données nécessaires au fonctionnement de l'activité demain. Clients actifs, fournisseurs, catalogue à jour, encours, stocks, dossiers ouverts. La deuxième, c'est l'archivage séparé : ce que la loi impose de conserver mais que personne n'ouvrira, exporté dans un format lisible et rangé hors de l'outil de production. La troisième, c'est la suppression : les données dont la durée est échue et qu'aucun texte ne vous oblige à garder.
Ce simple découpage réduit souvent le volume à migrer dans des proportions que les dirigeants n'imaginent pas. Et il transforme une question technique pénible en décision de gestion, ce qu'elle a toujours été.
Les trois familles de données, et l'ordre dans lequel les traiter
L'ordre n'est pas indifférent, parce que les familles dépendent les unes des autres. Les données de structure viennent en premier : plan comptable, familles de produits, axes analytiques, numérotations. Le volume est faible, la saisie manuelle est souvent plus rapide qu'un import.
Viennent ensuite les référentiels : clients, fournisseurs, contacts, catalogue. C'est là que se concentrent les défauts de qualité, parce que ces fiches ont été alimentées pendant des années par plusieurs personnes, avec plusieurs conventions.
Les données de gestion arrivent en dernier : factures, commandes en cours, mouvements de stock, historique. C'est l'étape la plus complexe, et celle où la question du périmètre se pose vraiment (Akuiteo). Prendre les familles dans le désordre, c'est importer des factures rattachées à des clients qui n'existent pas encore.
Quatre stratégies de reprise selon votre situation
| Votre situation | Ce que vous migrez | Ce que vous faites du reste | Le risque à surveiller |
|---|---|---|---|
| Vous partez de tableurs et de fichiers dispersés | Les référentiels nettoyés et l'encours du moment | Vous figez les fichiers en lecture seule dans un dossier daté | Recopier le désordre existant dans un outil neuf |
| Vous quittez un logiciel du marché avec de vrais exports | Référentiels, encours et deux à trois ans d'historique utile | Export complet conservé hors production pour la durée légale | Croire que l'export standard contient tout, y compris les champs personnalisés |
| Vous quittez un logiciel spécifique dont vous n'avez pas la main | Ce que l'accès à la base permet d'extraire, en priorisant | Sauvegarde intégrale de la base avant toute résiliation | Perdre l'accès avant d'avoir extrait, faute d'avoir anticipé |
| Vous fusionnez plusieurs outils qui décrivent les mêmes clients | Une source déclarée maîtresse par type de donnée | Les autres sources en archive, jamais en base active | Fusionner sans arbitrage et fabriquer des doublons durables |
Le vrai blocage n'est pas le nouveau logiciel, c'est l'ancien
Les guides détaillent longuement l'import et passent vite sur l'extraction. C'est pourtant là que les projets se bloquent. Si votre logiciel actuel a fait l'objet d'un développement spécifique, il arrive que seul son concepteur sache en sortir les données proprement, et l'opération devient délicate si la relation s'est tendue ou si la personne qui maîtrisait l'outil a quitté l'entreprise.
D'où une règle simple, et elle est chronologique : on extrait avant de résilier. Jamais l'inverse. Tant que votre contrat court, vous êtes un client, et un client obtient une extraction. Une fois la résiliation notifiée, vous devenez un dossier clos.
Concrètement, réclamez trois choses par écrit avant toute bascule : un export complet de vos données dans un format ouvert et documenté, une copie de la base si l'hébergement vous appartient, et la liste des champs personnalisés qui n'apparaissent pas dans l'export standard. Si ces points n'ont jamais été prévus au contrat, c'est le moment de comprendre à quel point la propriété de vos données conditionne votre liberté de partir. J'ai développé ce sujet dans l'article consacré à la reprise d'un logiciel développé par un autre prestataire, et il vaut aussi pour les données que pour le code.
La source fantôme et le doublon que personne ne tranchera à votre place
Deux écueils reviennent systématiquement, et aucun outil ne les résout.
Le premier est la source fantôme : ce fichier qu'un service maintient dans son coin, invisible du chef de projet, et qui contient pourtant une information dont personne d'autre ne dispose. Les données clients qui vivent dans la base de la comptabilité pendant que le commerce travaille sur son propre tableur, c'est le cas d'école. La seule parade consiste à faire le tour des services et à demander, service par service, quels fichiers ils ouvrent réellement dans la semaine.
Le second est l'arbitrage des doublons. Quand une même donnée existe dans deux sources, il faut choisir : fusionner champ par champ, ce qui donne le meilleur résultat mais prend un temps considérable, ou désigner une source maîtresse et assumer de perdre le reste. Aucun prestataire ne peut trancher à votre place, parce que lui ne sait pas si « Dupont et Fils » et « SARL Dupont » sont le même client. Vous, si.
Ce que nos propres migrations nous ont appris
Nous éditons plusieurs logiciels métier, Simply Spa, Simply Resa, Geko et Postwa, et chacun de leurs déploiements passe par une reprise. C'est la partie du travail que j'ai le plus sous-estimée pendant longtemps.
Deux leçons en sont sorties. La première est qu'un import réussi du premier coup n'existe pas : formats de dates hétérogènes, espaces parasites, codes postaux devenus des nombres, séparateurs qui se baladent. Nous prévoyons désormais systématiquement plusieurs passes sur un environnement de test avant de toucher la production.
La seconde est plus inconfortable. Il nous est arrivé de reprendre trop, par excès de zèle, et de livrer un outil neuf déjà encombré de fiches périmées. Automatiser un désordre ne produit qu'un désordre plus rapide. Depuis, la question du tri se pose au cadrage, en même temps que le cahier des charges de l'application, et non trois jours avant la bascule. C'est aussi pour cette raison que nous préférons construire des logiciels sur mesure dont nos clients gardent l'accès complet aux données : la prochaine migration, un jour, sera la leur.
Comment savoir que la reprise a réussi
Le contrôle est l'étape la plus souvent sacrifiée, parce qu'elle intervient au moment où tout le monde veut en finir. Elle se prépare pourtant en quelques points.
Recoupez d'abord des totaux : nombre de clients actifs, encours global, valeur de stock. Si les deux systèmes ne donnent pas le même chiffre, il faut comprendre pourquoi avant d'aller plus loin. Faites ensuite des recherches identiques dans l'ancien et le nouvel outil sur une dizaine de dossiers pris au hasard, dont deux ou trois compliqués. Enfin, gardez l'ancien système accessible en lecture seule pendant quelques semaines après la bascule. Ce filet de sécurité coûte peu et évite les décisions prises dans l'urgence.
Un dernier conseil, valable même si votre projet paraît simple : si vous prévoyez de faire dialoguer votre nouveau logiciel avec d'autres outils, réglez la reprise d'abord. Brancher des connexions entre logiciels sur des données non fiabilisées revient à propager les erreurs plus vite et plus loin.
Mon verdict
La reprise de données n'est pas un sujet technique, c'est un sujet de décision. Le prestataire sait extraire, transformer et importer ; il ne sait pas quels dossiers comptent pour votre activité, ni quelle source fait foi quand deux fichiers se contredisent. Ces arbitrages vous appartiennent, et c'est le temps que vous y consacrez qui détermine le résultat.
Si je devais retenir une seule règle, ce serait celle-ci : n'emportez dans votre nouvel outil que ce qui sert à travailler demain, archivez à part ce que la loi impose de garder, supprimez le reste. Vous obtiendrez un logiciel plus rapide, des équipes qui lui font confiance, et une conformité que vous n'aurez pas à traiter deux fois. Le même raisonnement s'applique d'ailleurs si vous partez de tableurs, sujet que j'ai traité dans l'article sur le fait de remplacer Excel par un logiciel métier.
Si vous préparez un changement d'outil et que la question des données vous inquiète, parlons-en avant que vous ne résiliez quoi que ce soit. C'est le moment où l'on peut encore tout récupérer.
Questions fréquentes
Faut-il reprendre tout l'historique dans un nouveau logiciel métier ? Non, et c'est même rarement souhaitable. Votre obligation légale porte sur votre capacité à produire un document en cas de contrôle, pas sur sa présence dans votre outil de gestion courante. Reprenez ce qui sert à travailler, archivez le reste dans un export figé et lisible, conservé pour la durée exigée. Vous obtenez un logiciel plus léger et vous restez en règle.
Combien de temps faut-il prévoir pour une reprise de données ? Cela dépend beaucoup moins du volume que de l'état des sources et de la vitesse à laquelle vous tranchez. Une base propre issue d'un logiciel qui exporte correctement se traite vite. Des fichiers dispersés entre plusieurs services, avec des doublons à arbitrer, demandent surtout du temps de décision de votre côté. Personne ne peut chiffrer sérieusement une reprise sans avoir ouvert les fichiers au préalable.
Que faire si mon ancien prestataire refuse de me livrer mes données ? Agissez tant que le contrat court, car votre position est bien plus solide avant la résiliation qu'après. Demandez par écrit un export complet dans un format ouvert, en visant vos conditions contractuelles. Si l'hébergement est chez vous, faites une sauvegarde intégrale de la base avant toute échéance. Un prestataire qui n'a prévu aucune modalité de sortie dans son contrat est en soi un signal sur la suite.
Faut-il supprimer des données au moment de la migration ? Oui, quand leur durée de conservation est échue. La CNIL rappelle qu'il ne s'agit pas de conserver l'intégralité des données mais seulement celles qui sont indispensables ou requises par une obligation légale. Une migration est le moment le plus économique pour faire ce tri, puisque vous manipulez déjà l'ensemble. Documentez vos règles de durée par catégorie, elles vous serviront ensuite chaque année.
Photo : Jan Antonin Kolar sur Unsplash
