Pour quitter un logiciel SaaS sans perdre vos données, ne vérifiez pas seulement la présence d’un bouton « Exporter ». Vérifiez que vous pouvez récupérer les informations utiles, leurs pièces jointes et leurs relations, puis les exploiter ailleurs. C’est tout l’enjeu de la réversibilité SaaS.
Imaginez ce scénario fictif : votre PME change de CRM. Les contacts arrivent dans le nouvel outil, mais pas les échanges commerciaux. Les devis sont disponibles, mais plus rattachés aux bons clients. Vous avez déménagé les cartons, pas les étiquettes.
Voici sept pièges à tester avant de choisir un logiciel, de renouveler un abonnement ou de préparer un départ. Avec une règle simple : demandez une démonstration de sortie aussi concrète que la démonstration d’entrée.
Qu’est-ce que la réversibilité d’un logiciel SaaS ?
La réversibilité d’un logiciel SaaS désigne la possibilité de quitter le service en récupérant les données et les éléments nécessaires à leur reprise ailleurs. Pour votre entreprise, l’objectif pratique est de poursuivre l’activité sans rester dépendante de l’ancien outil.
Cette sortie se prépare aussi dans le contrat. La CNIL recommande notamment de préciser les conditions de restitution et de destruction des données en fin de contrat.
Pour cadrer votre besoin, distinguez trois résultats :
| Résultat attendu | Question à poser | Preuve à demander |
|---|---|---|
| Consulter les anciennes informations | Pourrons-nous relire un dossier après la fermeture du compte ? | Une archive consultable sans connexion au service |
| Réutiliser les données | Pourrons-nous importer les informations dans un autre logiciel ? | Des fichiers structurés et une description des champs |
| Reprendre le fonctionnement métier | Pourrons-nous continuer à traiter les dossiers en cours ? | Un test de reprise avec relations, documents et règles nécessaires |
Décidez lesquels de ces résultats sont indispensables pour chaque catégorie de données. Un ancien compte rendu peut rester dans une archive ; une commande en cours doit pouvoir continuer son parcours.
Les 7 pièges à vérifier avant de quitter votre logiciel
1. Le bouton « Exporter » ne sort que ce que vous voyez
Premier contrôle : demandez si l’export porte sur une vue filtrée, une catégorie d’informations ou l’ensemble du périmètre prévu.
Chez HubSpot, par exemple, l’export standard inclut par défaut les propriétés et associations présentes dans la vue. L’éditeur distingue également l’export des fiches de celui des activités, comme les appels et les notes, dans sa documentation sur l’export des données CRM.
Le test : choisissez un dossier représentatif et faites l’inventaire de son contenu avant l’export : coordonnées, champs personnalisés, notes, tâches, documents, historique. Comparez ensuite chaque élément avec ce qui a réellement été récupéré.
Notez les absences dans un tableau : élément attendu, présent ou absent, autre procédure nécessaire. Ne validez pas une sortie complète sur la seule base du nombre de contacts récupérés.
2. Les données sont là, mais leurs liens ont disparu
Prenez ce cas fictif : une entreprise cliente possède plusieurs établissements, chacun avec ses contacts et ses contrats. Votre objectif n’est pas seulement d’obtenir trois listes. Vous voulez pouvoir retrouver quel contrat appartient à quel établissement.
Exigez donc un exemple d’export qui conserve les identifiants et les associations nécessaires. HubSpot permet notamment de choisir les propriétés et associations exportées, ainsi que l’inclusion de leurs identifiants, comme le précise la documentation citée précédemment.
Le test : sélectionnez une entreprise ayant plusieurs contacts et plusieurs dossiers. Demandez à une personne qui ne connaît pas le logiciel de reconstituer les relations à partir des fichiers et de leur documentation.
Si cette personne doit deviner à partir des noms, demandez un export mieux documenté. Inscrivez explicitement ces relations dans le périmètre de reprise de votre ERP ou CRM, au même titre que les données elles-mêmes.
3. Les pièces jointes ne sont pas vraiment dans les cartons
Pour les documents, vérifiez séparément les noms, les références et les fichiers effectivement récupérés.
La procédure d’export Salesforce prévoit, par exemple, des options spécifiques pour inclure les images, documents, pièces jointes et fichiers. Ces éléments doivent être sélectionnés dans les conditions décrites par la documentation officielle d’export Salesforce.
Le test : ouvrez les documents exportés depuis un environnement sans session active dans l’ancien logiciel. Vérifiez aussi leur rattachement au dossier d’origine.
- Le devis signé correspond-il au bon client ?
- La photo d’intervention correspond-elle au bon équipement ?
- Le nom du fichier permet-il de distinguer les versions ?
- Une personne autorisée peut-elle retrouver le document sans connaître son ancien emplacement ?
Pour un dossier litigieux ou une intervention encore ouverte, fixez des critères plus exigeants que pour une documentation générale.
4. Vous récupérez le contenu, pas le fonctionnement
Un export de contenu ne constitue pas nécessairement une reconstruction de l’outil. Notion le précise explicitement : réimporter le contenu exporté ne permet pas de recréer instantanément l’espace de travail, selon sa documentation sur la sauvegarde et l’export.
Appliquez cette distinction à votre projet. Listez séparément les données et les mécanismes à reproduire : étapes de validation, calculs, notifications, modèles de documents, règles d’affectation.
Le test : décrivez un parcours métier complet sans citer les boutons de l’ancien outil. Par exemple : « une demande supérieure au seuil interne doit être approuvée avant l’envoi du bon de commande ».
Demandez ensuite comment ce parcours sera repris. Photographier les écrans ne suffit pas comme spécification : notez la condition, l’action, le responsable et les exceptions.
5. L’export dépend d’une personne ou d’un accès mal identifié
Qui peut déclencher l’export ? Avec quel compte ? Qui récupère le résultat ? Faites répondre votre équipe à ces questions avant d’annoncer une résiliation.
Les permissions méritent un contrôle spécifique : Notion indique notamment que les pages auxquelles la personne réalisant l’export n’a pas accès peuvent être exclues de l’archive, dans la documentation citée plus haut.
Le test : faites exécuter la procédure par le responsable désigné, avec ses propres accès. Évitez de considérer comme acquise une opération réalisée uniquement lors d’une démonstration par l’éditeur.
Documentez également la personne de remplacement, l’emplacement sécurisé du résultat et la méthode de transmission au futur outil. La CNIL recommande d’ailleurs de définir contractuellement la répartition des responsabilités et les contraintes d’authentification avec les sous-traitants.
6. « Nous avons une API » remplace une vraie preuve de sortie
Une API, l’interface qui permet à deux logiciels d’échanger, doit être testée sur le périmètre réel de votre reprise. Demandez quels éléments sont accessibles et comment l’extraction complète sera contrôlée.
La documentation technique doit notamment permettre de comprendre la récupération des résultats successifs. À titre d’exemple, l’interface de lecture des objets HubSpot décrit un mécanisme de pagination et des paramètres pour les propriétés, associations et éléments archivés.
Le test : demandez une extraction sur un volume représentatif, accompagnée d’un compte rendu : périmètre demandé, éléments récupérés, erreurs et exclusions.
Faites préciser la durée mesurée et la procédure de reprise après interruption. Une démonstration sur quelques fiches ne doit pas servir seule à valider l’extraction de toute votre base.
7. Personne n’a prévu les modifications de dernière minute
Pour éviter les ambiguïtés pendant la bascule, définissez quel outil fait foi et à partir de quel moment.
Dans un scénario fictif de migration commerciale, un premier export est réalisé le lundi. Jusqu’au vendredi, les commerciaux continuent à modifier leurs dossiers. Votre plan doit préciser comment ces changements rejoindront la nouvelle application.
Le test : créez puis modifiez un dossier pendant une répétition de migration. Vérifiez que la version finale apparaît une seule fois, au bon endroit, avec le bon statut.
Prévoyez les consignes aux équipes, le traitement des demandes reçues pendant la bascule et les conditions d’un éventuel retour arrière. Intégrez ces vérifications à la recette de l’application, c’est-à-dire à sa validation avant utilisation.
Que change le Data Act pour la réversibilité SaaS ?
Le Data Act encadre le changement de fournisseur pour les services de traitement de données entrant dans son champ d’application. Il ne faut pas en déduire qu’un changement de logiciel devient une migration automatique ou sans travail interne.
Applicable depuis le 12 septembre 2025, le règlement prévoit notamment, pour les fournisseurs de plateformes et de logiciels en tant que service concernés, des interfaces ouvertes et l’export des données dans un format couramment utilisé et lisible par machine. La Commission européenne explique ces dispositions relatives au changement de fournisseur.
Au 16 octobre 2026, un autre jalon est à anticiper : la suppression des frais de changement de fournisseur, y compris les frais de sortie des données, est prévue à compter du 12 janvier 2027, selon cette même source.
Pour préparer votre budget, séparez ces frais des travaux nécessaires dans votre entreprise : nettoyage, paramétrage du nouvel outil, tests et formation. Faites vérifier l’application du règlement à votre service et à votre contrat si l’enjeu est important.
Combien coûte réellement la sortie d’un SaaS ?
Pour estimer une sortie de SaaS, additionnez l’extraction, la transformation des données, la reprise dans le nouvel outil et la transition opérationnelle. Évitez de chercher un tarif universel : construisez le budget à partir d’un export testé et d’un périmètre défini.
Utilisez cette grille pour obtenir des estimations comparables :
| Poste à chiffrer | Travail à préciser | Base d’estimation à demander |
|---|---|---|
| Extraction | Exports, documents, éventuel développement d’extraction | Résultat d’un essai et volume restant |
| Transformation | Correspondance des champs, statuts et relations | Liste des transformations à effectuer |
| Reconstruction | Règles métier, modèles et connexions aux autres outils | Inventaire validé par les utilisateurs |
| Transition | Coexistence, vérifications, accompagnement des équipes | Calendrier et responsabilités |
| Archivage | Consultation des anciens dossiers et gestion des accès | Périmètre d’archive retenu |
Pour comparer deux scénarios, utilisez vos propres hypothèses : coût ponctuel du départ, coût de coexistence, coût d’exploitation futur. Ajoutez le temps mobilisé en interne, pas seulement les factures externes.
Une fois la reprise terminée, inscrivez les tests d’export dans votre plan de maintenance et d’évolution du logiciel métier. Définissez leur fréquence selon la criticité de l’outil et les changements apportés à ses données.
Le test de sortie à organiser avant votre prochain renouvellement
Organisez un exercice limité, sans toucher à la production. Le but n’est pas de migrer toute l’entreprise : c’est d’obtenir une première preuve vérifiable.
- Choisissez un dossier complexe : plusieurs interlocuteurs, documents, historique et tâches ouvertes.
- Définissez le résultat attendu : ce qu’un utilisateur doit pouvoir consulter et poursuivre après la reprise.
- Réalisez l’extraction : avec la procédure et les droits réellement disponibles.
- Testez la lecture et l’import : dans un environnement séparé, sans dépendre de l’ancien compte.
- Consignez les écarts : données absentes, associations rompues, règles à reconstruire.
- Attribuez les corrections : un responsable, une action et une date de nouveau contrôle.
Pour chaque écart, décidez s’il bloque le départ ou peut être accepté. Une ancienne mise en page peut être abandonnée ; une commande ouverte sans client associé mérite un traitement prioritaire.
Conservez le résultat de l’exercice avec le contrat et la documentation technique. Lors du renouvellement, demandez une réponse précise aux points encore non résolus.
Questions fréquentes
Le droit à la portabilité du RGPD couvre-t-il toute la base de mon entreprise ?
Non. Le droit à la portabilité concerne, sous ses conditions d’application, les données personnelles relatives à une personne et qu’elle a fournies. La CNIL en précise le périmètre. Ne le confondez pas avec la reprise complète d’un catalogue, de règles métier ou d’une base d’entreprise.
Un logiciel sur mesure évite-t-il automatiquement la dépendance ?
Ne le considérez pas comme une garantie suffisante. Pour un projet sur mesure, demandez aussi une démonstration de reprise : accès nécessaires, documentation, procédure de déploiement, export et restauration. Faites réaliser l’exercice par une personne distincte de celle qui a construit la solution.
Quand demander la suppression des données chez l’ancien fournisseur ?
Planifiez cette étape après validation de la reprise et des archives nécessaires, en cohérence avec vos obligations de conservation. Pour les données personnelles traitées en sous-traitance, l’article 28 du RGPD prévoit, au choix du responsable du traitement, leur suppression ou leur restitution au terme de la prestation, ainsi que la destruction des copies, sauf obligation légale de conservation.
Avant de signer, essayez aussi la porte de sortie
La réversibilité SaaS mérite une preuve, pas une case cochée. Votre prochaine action : choisir un dossier métier, demander son export et tenter de le reprendre ailleurs. Vous saurez alors ce qui est prêt, ce qui manque et ce qu’il faut clarifier avant de vous engager.
