Data Act : rendre votre SaaS portable sans tout recoder

Beaucoup de PME découvrent le Data Act européen au mauvais moment : au moment de vouloir changer de solution SaaS, de récupérer leurs données ou de fusionner deux outils métier. Ce règlement, dont les obligations principales sont entrées en application en 2025, impose aux fournisseurs de services cloud et SaaS de faciliter la portabilité des données et la fin du verrouillage technique. Pour un éditeur de logiciel ou une entreprise qui exploite son propre SaaS, ce n'est plus seulement un sujet juridique : c'est un chantier d'architecture.

Ce que le Data Act change concrètement pour un éditeur SaaS

Le texte vise à limiter le vendor lock-in : un client doit pouvoir quitter un service cloud ou SaaS, récupérer ses données dans un format exploitable, et migrer vers un autre prestataire sans blocage technique ni contractuel excessif. Concrètement, cela se traduit par plusieurs obligations qui touchent directement le code et l'architecture d'une plateforme :

• mettre à disposition une fonction d'export des données structurées, idéalement via une API documentée plutôt qu'un export manuel ;
• utiliser des formats ouverts ou interopérables quand c'est possible, pour éviter que l'export ne soit qu'un geste symbolique ;
• documenter clairement les modalités de résiliation, de récupération des données et les délais associés ;
• revoir les clauses contractuelles qui créeraient artificiellement une dépendance technique.

Pour une entreprise qui a développé son propre logiciel SaaS, cela veut dire anticiper l'export dès la conception du modèle de données, et pas le bricoler a posteriori sous la pression d'un client qui veut partir.

Portabilité des données et architecture multi-tenant : le vrai défi technique

Dans une architecture multi-tenant, les données de plusieurs clients cohabitent dans les mêmes tables ou les mêmes index, avec des mécanismes d'isolation logique. Construire un export conforme suppose de pouvoir extraire proprement les données d'un seul tenant, sans fuite croisée et sans compromettre la performance des autres clients pendant l'opération. Il faut aussi penser aux données liées : pièces jointes, historiques, paramétrages métier, droits d'accès. Un export « table par table » sans cohérence relationnelle n'a aucune valeur réelle pour le client qui cherche à migrer.

C'est un sujet qui doit être traité au niveau de la conception du produit, au même titre que la sécurité ou la gestion des abonnements, et non comme une fonctionnalité annexe ajoutée en fin de projet.

Automatiser l'export plutôt que le traiter au cas par cas

Traiter chaque demande de portabilité manuellement devient vite intenable dès que la base clients grossit. La bonne pratique consiste à construire un processus reproductible : génération automatique d'un paquet de données à la demande, notification par webhook une fois l'export prêt, purge programmée après le délai légal de conservation. C'est typiquement le genre de flux que couvre l'automatisation des tâches : scripts planifiés, files d'attente de traitement, intégrations avec le système de facturation pour déclencher l'export au moment de la résiliation.

Et si vous êtes utilisateur d'un SaaS, pas éditeur ?

La portabilité ne concerne pas que les éditeurs. Si votre PME dépend d'un ERP, d'un CRM ou d'un outil métier en mode SaaS, c'est le bon moment pour vérifier deux choses : la solution propose-t-elle un export complet et exploitable de vos données, et le contrat prévoit-il des frais ou des délais excessifs en cas de départ ? Si la réponse est non sur l'un des deux points, vous êtes probablement en situation de dépendance plus forte que nécessaire vis-à-vis d'un seul fournisseur.

C'est aussi un argument pour les entreprises qui envisagent un développement web sur mesure plutôt qu'une solution fermée : garder la main sur le format et l'accès à ses propres données plutôt que de dépendre entièrement de la politique d'export d'un éditeur tiers.

Comment aborder ce chantier sans tout reconstruire

Il n'est pas nécessaire de refondre toute une plateforme pour se mettre en ordre de marche. L'approche la plus réaliste consiste à :

• cartographier les données réellement nécessaires à une migration (et exclure le superflu) ;
• exposer un ou deux formats d'export standards (CSV structuré, JSON, ou connecteur API) plutôt que de viser l'exhaustivité immédiate ;
• documenter la procédure côté client, pour que l'export ne dépende pas d'une intervention manuelle du support ;
• tester l'export sur un tenant réel pour vérifier qu'il est réellement réutilisable, pas seulement techniquement présent.

Pour les éditeurs qui combinent SaaS et briques d'intelligence artificielle (scoring, recommandations, assistants), la question se pose aussi pour les données d'entraînement ou d'usage générées par l'intelligence artificielle intégrée au produit : elles font souvent partie de ce que le client considère, à juste titre, comme ses propres données.

En résumé

La portabilité des données n'est plus une option différenciante, c'est en train de devenir une exigence structurelle pour tout logiciel SaaS. Mieux vaut l'intégrer dès la conception ou lors d'une refonte d'architecture que de la découvrir sous la pression d'un client ou d'un contrôle. Si vous développez ou faites évoluer un SaaS et que vous voulez savoir où en est votre produit sur ce point, contactez-nous pour en discuter.

Questions fréquentes