Migrer proprement hors d'un SaaS tient en cinq mouvements : vérifier ce que l'export donne vraiment, reconstruire le modèle de données cible avant de copier quoi que ce soit, faire tourner l'ancien et le nouveau système en parallèle le temps de vérifier, basculer un jour calme, et avoir négocié la réversibilité du prochain outil avant même de signer son contrat. Aucun logiciel ne fait ce travail à votre place. La méthode, si.
Que donne vraiment un export, au-delà de la promesse marketing ?
La plupart des éditeurs SaaS affichent un bouton « exporter mes données » bien visible. Ce que ce bouton produit réellement mérite d'être vérifié avant de fonder une décision de migration dessus, pas après.
Les formats, d'abord. Un export CSV ou Excel aplatit des relations qui existaient entre vos tables — un client lié à plusieurs commandes, une commande liée à plusieurs lignes — en une suite de colonnes qu'il faudra reconstituer à la main. Un export JSON ou XML conserve davantage de structure, mais suppose ensuite un travail de correspondance vers votre nouveau modèle. Un export PDF, fréquent pour les factures, n'est tout simplement pas une donnée réutilisable : c'est une image de la donnée.
La complétude, ensuite. Certains champs personnalisés, certaines notes internes, certains statuts de workflow n'apparaissent tout simplement pas dans l'export standard — l'éditeur ne les a pas prévus, ou les réserve à une offre supérieure. Les pièces jointes suivent rarement le mouvement principal : factures scannées, contrats, images produits demandent souvent un export séparé, parfois manuel, fichier par fichier.
L'historique et les métadonnées, enfin, sont les grands oubliés. La date de création réelle d'un enregistrement, son auteur, les modifications successives, les commentaires échangés autour d'un dossier : cette couche-là disparaît le plus souvent, alors qu'elle porte une partie de la valeur de vos données. Le seul moyen de savoir ce que vous perdrez est de lancer un export test, tôt, et de l'ouvrir champ par champ à côté de l'outil encore actif.
Reconstruire le modèle de données cible avant de copier quoi que ce soit
Une migration ratée commence presque toujours par le même réflexe : copier tel quel l'ancien modèle dans le nouvel outil. Le résultat reproduit fidèlement les approximations accumulées pendant des années — des champs devenus obsolètes, des doublons jamais nettoyés, des catégories qui n'ont plus de sens.
Le bon ordre inverse la logique. D'abord, décider ce dont l'entreprise a réellement besoin dans le nouvel outil : quels champs, quelles catégories, quels identifiants font foi. Ensuite seulement, faire correspondre chaque champ source à sa destination, un par un, en assumant d'abandonner ce qui ne sert plus. C'est un travail de conception, pas de copier-coller, et c'est très exactement le type de chantier qu'une solution sur-mesure permet de cadrer proprement, avec un modèle de données pensé pour l'entreprise plutôt qu'hérité d'un outil générique.
Pourquoi la double tenue n'est pas une option de confort
Faire tourner l'ancien et le nouveau système en parallèle pendant une période définie n'est pas une précaution superflue : c'est ce qui permet de détecter les écarts avant qu'ils ne deviennent votre nouvelle réalité. Un client saisi deux fois, un montant qui ne correspond plus, un statut qui ne se met à jour que d'un côté — ce sont ces détails-là que la double tenue révèle, pendant qu'il est encore facile de les corriger.
La règle qui évite l'enlisement est simple à énoncer, plus difficile à tenir : fixer une date de fin à la double tenue avant de la commencer, et couvrir au moins un cycle complet de l'activité concernée — un mois de facturation, un trimestre de reporting, selon ce qui est migré. Sans date de fin annoncée, la double saisie s'installe, fatigue les équipes, et personne n'ose plus trancher.
Choisir le bon jour pour basculer
La bascule elle-même mérite d'être traitée comme un projet, pas comme un interrupteur qu'on actionne un vendredi soir en espérant que ça passe. Le meilleur jour est un jour calme : ni une clôture comptable, ni une campagne commerciale, ni une période de forte activité client. Prévenez l'équipe à l'avance, gelez les modifications dans l'ancien système quelques heures avant le basculement, et prévoyez un créneau pour la vérification finale plutôt que de découvrir les problèmes en production.
Gardez surtout l'ancien système accessible, au moins en lecture, pendant quelques semaines après la bascule. La tentation de tout résilier le jour même est compréhensible ; elle prive aussi l'équipe du seul filet de sécurité qui reste si un écart apparaît une fois le nouvel outil réellement mis à l'épreuve.
La clause de réversibilité : elle se négocie avant de signer, pas après
Voici le point le plus mal anticipé de tout le processus. La réversibilité, c'est la capacité contractuelle à récupérer l'intégralité de vos données, dans un format exploitable, dans un délai défini — et elle se négocie au moment de signer le contrat du prochain outil, jamais après, quand le rapport de force s'est déjà inversé en faveur de l'éditeur.
Une clause de réversibilité qui mérite ce nom précise plusieurs points :
- le format de l'export garanti — structuré et documenté, pas un PDF ;
- le délai de mise à disposition après une demande ;
- le coût de l'opération, gratuit ou plafonné, mais connu à l'avance ;
- la durée pendant laquelle les données restent accessibles après la fin du contrat ;
- le sort des pièces jointes et de l'historique, explicitement inclus ou explicitement exclus.
Aucun de ces points n'est garanti par défaut. Un éditeur qui refuse de les préciser par écrit avant la signature donne une indication assez nette de ce qu'il proposera le jour où vous voudrez partir.
Cette clause touche en réalité une question plus large : celle de savoir à qui appartiennent, une fois le contrat signé, votre outil, votre code et vos données. Je l'ai traitée pour elle-même dans À qui appartiennent votre outil, votre code, vos données ? Elle rejoint aussi, souvent, une question d'hébergement : changer d'outil s'accompagne fréquemment d'un changement de lieu d'hébergement, et j'ai détaillé ce que cela change réellement dans Héberger en Suisse : ce que ça change vraiment
Le mythe de l'outil miracle
Aucun logiciel de migration, aussi vanté soit-il, ne fait ce travail à votre place. Les outils de synchronisation automatique gèrent la mécanique du transfert, pas les décisions de fond : quel champ garder, quelle donnée fusionner, quel jour basculer. Ce sont des décisions humaines, documentées, prises dans l'ordre — et c'est bien pour cela qu'une migration se prépare comme un petit projet, avec un responsable identifié, plutôt que comme une tâche qu'on délègue à un bouton « importer ».
Avant même d'en arriver là, encore faut-il savoir ce que vous détenez et où : l'inventaire que je décris dans nLPD : où dorment réellement les données de votre PME ? est le point de départ naturel de toute migration sérieuse. Et parce que la question dépasse la seule mécanique technique, je la resitue dans le cadre plus large de Que doit faire une PME suisse face à l'IA en 2026 ?, où l'arbitrage entre garder, migrer et reconstruire en solution sur-mesure se pose fonction par fonction.
FiscalDoc, l'application locale que j'ai construite pour ma propre fiscalité, illustre la meilleure migration qui soit : celle qu'on ne refait jamais, parce que les données n'ont jamais quitté la machine. Ce n'est pas la solution à tout, mais ça vaut la peine de se demander, avant de migrer une énième fois vers un énième SaaS, si l'outil possédé ne réglerait pas la question une fois pour toutes — je l'ai documenté dans FiscalDoc : remplacer 1'400 CHF/an de SaaS par une IA locale
Ce qu'il faut retenir
— Vérifiez ce qu'un export donne vraiment — formats, complétude, pièces jointes, historique — avant de fonder une décision de migration dessus. — Une double tenue avec date de fin annoncée, et une bascule un jour calme, évitent l'essentiel des incidents de migration. — Négociez la clause de réversibilité au moment de signer le prochain contrat, jamais après : format garanti, délai, coût et durée d'accès doivent être écrits noir sur blanc.
FAQ
Existe-t-il un outil qui migre automatiquement toutes mes données, sans y toucher ? Non, pas pour des données métier structurées avec leur historique et leurs relations. Les outils de synchronisation déplacent des fichiers ; ils ne décident pas quel champ garder, quelle donnée fusionner ou quel doublon supprimer. Ce travail de décision reste humain, même quand la mécanique du transfert est automatisée.
Combien de temps faut-il prévoir pour la double tenue ? Assez longtemps pour couvrir au moins un cycle complet de l'activité migrée — un mois de facturation, un trimestre de reporting, selon le cas. Fixez la date de fin avant de commencer plutôt que d'attendre que la double saisie s'arrête d'elle-même : elle ne s'arrête jamais toute seule.
Que faire si le fournisseur ne propose pas d'export complet ? Considérez-le comme un signal, pas seulement comme un obstacle technique. Un éditeur qui limite l'export limite votre liberté de partir, et c'est une information à connaître avant de renouveler, pas après. Insistez par écrit, et si rien ne bouge, intégrez ce point aux critères de choix de votre prochain outil.
Faut-il migrer toutes les données, y compris les vieilles archives ? Pas nécessairement. Une partie des données anciennes peut rester consultable en lecture seule dans l'ancien système, ou dans un export archivé, sans être réinjectée dans le nouvel outil. Migrer sélectivement ce qui sert encore évite d'alourdir le nouveau système avec le poids de l'ancien.
Je n'ai pas négocié de clause de réversibilité à la signature : est-il trop tard ? Non, mais le rapport de force est moins favorable une fois le contrat signé. Le bon moment pour la reposer est le renouvellement — c'est le seul moment où l'éditeur risque réellement de vous perdre s'il refuse. Entre-temps, demandez au moins un export test pour savoir où vous en êtes réellement.
Un changement d'outil approche et vous redoutez d'y perdre des données ? Le Diagnostic d'Usage IA : soixante minutes pour poser vos flux réels, identifier ce qui mérite du sur-mesure, ce qui reste en SaaS, et ce qui n'a pas besoin d'IA du tout. Réserver un diagnostic
Jérôme Deshaie est CEO et fondateur de MCVA Consulting SA, agence augmentée basée en Valais. Quinze ans au service de grandes marques internationales, désormais en direct pour les PME suisses. Parcours.