Quitter son fournisseur cloud devrait ressembler à un déménagement, pas à une reconstruction. Pourtant, récupérer les données n’est souvent que la première étape : il faut aussi refaire les connexions, remplacer certains services et vérifier que tout fonctionne ailleurs. En ce mois de septembre 2026, le Data Act constitue le nouveau cadre européen pour desserrer cette dépendance. Mais entre un droit de sortie et une migration réussie, l’écart reste considérable. Décryptage à partir du règlement adopté et des mécanismes techniques connus, sans préjuger d’un bilan d’application encore à établir.
Un droit de sortie, pas une migration automatique
Entré en vigueur en janvier 2024, le règlement européen sur les données est applicable depuis le 12 septembre 2025. Son volet consacré aux services de traitement de données vise notamment les obstacles au changement de fournisseur : clauses dissuasives, procédures opaques, difficultés d’exportation ou manque de coopération. Il concerne aussi bien les grands groupes américains opérant sur le marché européen que les fournisseurs établis dans l’Union.
Le texte impose de formaliser les conditions de sortie dans le contrat. Il prévoit notamment un préavis maximal de deux mois pour engager le changement, puis une période transitoire normalement limitée à trente jours. Si ce délai est techniquement irréalisable, le fournisseur doit le justifier et peut proposer une transition prolongée, dans les limites prévues par le règlement. Ce calendrier donne au client un levier, sans garantir que son propre chantier sera terminé aussi vite.
Autre échéance décisive : le 12 janvier 2027. À cette date, les frais de changement de fournisseur doivent disparaître. D’ici là, les frais réduits autorisés ne peuvent pas dépasser les coûts directement liés au changement. Cela ne signifie ni gratuité générale du trafic réseau ni disparition de toutes les sommes dues au titre du contrat. La facture de sortie et le coût réel du déménagement sont deux sujets distincts.
Les fichiers voyagent mieux que les applications
Prenons une enseigne de commerce fictive. Ses photos de produits sont stockées dans des objets, son catalogue dans une base de données gérée, ses commandes transitent par une messagerie et ses promotions déclenchent des fonctions exécutées à la demande. Télécharger les photos paraît simple. Reproduire les garanties de livraison des messages, les droits d’accès et le comportement des fonctions l’est beaucoup moins.
C’est le cœur du verrouillage technique. Une machine virtuelle utilisant un système courant se déplace relativement bien, sous réserve d’adapter son image et son réseau. Une application construite autour d’une base propriétaire, d’un moteur d’analyse ou d’un service d’intelligence artificielle spécifique demande parfois une réécriture. Les interfaces peuvent se ressembler sans offrir les mêmes performances, limites ou garanties.
Le Data Act distingue ces situations. Pour les services d’infrastructure, il prévoit des mesures facilitant une équivalence fonctionnelle à destination, dans les conditions qu’il définit. Pour les autres catégories, les obligations d’interfaces ouvertes et l’encadrement de l’interopérabilité prennent davantage de place. Le règlement n’oblige pas un concurrent à reproduire à l’identique chaque service propriétaire. Il ne transforme donc pas deux catalogues cloud en pièces interchangeables.
Le piège des dépendances invisibles
Les conteneurs et Kubernetes ont popularisé une promesse : emballer une application pour la faire tourner partout. Ils améliorent effectivement la portabilité, mais ne transportent pas toute son infrastructure. Derrière le conteneur restent les certificats, les secrets, les équilibreurs de charge, les sauvegardes et les règles de sécurité. Même les outils qui décrivent l’infrastructure sous forme de code utilisent des composants propres à chaque fournisseur.
Le risque se niche aussi dans l’exploitation quotidienne. Une équipe habituée à une console, à ses alertes et à ses tableaux de bord doit reconstruire ses réflexes. Une migration peut être techniquement achevée tout en dégradant la capacité à diagnostiquer un incident. La documentation et la formation sont donc des éléments de réversibilité, pas des accessoires.
Le contrat peut retenir sans interdire
Le verrouillage n’a pas toujours la forme d’une clause empêchant le départ. Il peut résulter d’une remise obtenue contre un engagement pluriannuel, d’une consommation minimale ou de crédits commerciaux utilisables uniquement dans le même écosystème. Une entreprise conserve alors la possibilité de partir, mais renonce à un avantage ou doit honorer un engagement distinct des frais de migration.
Il faut donc lire plusieurs documents ensemble : contrat principal, annexes de service, conditions tarifaires et accords négociés. Quelles données sont exportables ? Dans quels formats ? Qui fournit l’assistance ? Quand les copies seront-elles supprimées ? Le Data Act encadre la sortie, mais la qualification d’une somme facturée ou le périmètre d’un service peuvent encore nourrir des désaccords.
Le sujet devient plus délicat lorsqu’un intégrateur ou un revendeur intervient. Le client n’a pas nécessairement un interlocuteur unique pour l’hébergement, les licences et l’exploitation. Répartir les responsabilités avant le départ évite de découvrir, pendant la bascule, que personne n’avait prévu de reconstruire les droits d’accès.
La facture dépasse largement les frais de transfert
Les frais de sortie des données, souvent appelés egress, sont devenus le symbole du cloud captif. Leur encadrement compte, surtout pour les volumes importants. Mais leur suppression dans le cadre du changement de fournisseur ne financera ni les développeurs ni les tests. Les coûts les moins visibles risquent ainsi de devenir les plus déterminants.
- Le double fonctionnement : maintenir les deux environnements pendant la copie, la synchronisation et les vérifications.
- L’adaptation : modifier le code, les schémas de données, les politiques de sécurité et les outils d’exploitation.
- La validation : contrôler les performances, l’intégrité des données, les sauvegardes et la reprise après incident.
- Le risque opérationnel : prévoir une bascule progressive et un retour arrière si le service se dégrade.
À cela s’ajoute la gravité des données : plus un ensemble est volumineux et connecté à d’autres systèmes, plus son déplacement exige de coordination. Une base en production continue d’évoluer pendant son transfert. Il faut synchroniser les dernières écritures, éviter les doublons et limiter l’interruption. La bande passante seule ne résout pas ce problème.
La réversibilité se prépare dès l’achat
Pour les entreprises, la réponse raisonnable n’est pas nécessairement le multicloud généralisé. Répartir systématiquement chaque application entre plusieurs fournisseurs peut multiplier les compétences, les contrats et les points de panne. Mieux vaut identifier les services critiques, cartographier leurs dépendances et choisir consciemment celles que l’on accepte.
Un test de sortie limité vaut souvent mieux qu’une promesse commerciale. Exporter une base, restaurer une sauvegarde ailleurs et mesurer le travail nécessaire permettent de confronter le contrat au réel. Les acheteurs peuvent aussi demander des formats documentés, un calendrier d’assistance et une estimation séparant frais du fournisseur et travaux internes.
Et maintenant ? L’échéance de janvier 2027 devrait déplacer le débat : moins vers le prix affiché de la sortie, davantage vers la capacité réelle à fonctionner ailleurs. C’est une perspective, pas encore un résultat acquis. Le succès du Data Act dépendra de son application, mais aussi de choix d’architecture et d’achats moins improvisés. La liberté de changer de cloud se mesurera à une question simple : a-t-on déjà essayé de partir ?
