Réversibilité du cloud : à partir du 12 janvier 2027, c'est un droit

La réversibilité est, depuis vingt ans, le chapitre le plus consensuel et le moins appliqué des contrats cloud. Le règlement européen sur les données (Data Act, règlement (UE) 2023/2854) la sort du registre des bonnes intentions : à partir du 12 janvier 2027, les frais de changement de fournisseur — y compris les frais de transfert de données liés à la sortie — sont interdits pour les services de traitement de données, IaaS, PaaS et SaaS confondus.

Ce qui est déjà en vigueur, et ce qui arrive

Le chapitre du règlement consacré au changement de service s'applique depuis le 12 septembre 2025. Jusqu'au 12 janvier 2027, les fournisseurs peuvent facturer des frais de changement à condition qu'ils se limitent à la couverture des coûts réellement supportés ; au-delà de cette date, ils ne peuvent plus rien facturer à ce titre. L'obligation vise tout fournisseur servant des clients établis dans l'Union, quelle que soit sa propre implantation.

Le règlement encadre aussi le déroulement : un préavis maximal de deux mois pour demander le changement, une période de transition plafonnée à trente jours calendaires, et la possibilité de récupérer ses données pendant au moins trente jours après. Ces durées sont des maximums contractuels — rien n'oblige un client à s'y prendre au dernier moment.

Le périmètre exact, qui est souvent mal lu

L'interdiction porte sur les frais liés au changement : ce que vous payez pour partir. Le trafic sortant du quotidien — servir des contenus à vos utilisateurs, répliquer entre régions, alimenter un partenaire — reste facturable, et il n'y a aucune raison qu'il en aille autrement. Lire le texte comme la fin de la facturation du trafic sortant conduirait à des architectures mal dimensionnées.

Un droit ne rend pas une migration possible

C'est le point qui intéresse l'architecte. La facture de sortie n'a presque jamais été le vrai obstacle : elle est douloureuse, mais elle se paie une fois. Ce qui empêche réellement de partir est ailleurs, et le règlement n'y change rien.

• Les services managés propriétaires. Une base de données managée, une file d'attente, un moteur d'identité ou un service d'inférence exposent des API qui n'existent nulle part ailleurs. Le coût de sortie est un coût de réécriture, pas un coût de transfert.
• La gravité des données. Plusieurs centaines de téraoctets ne se déplacent pas en trente jours sans préparation, même gratuitement.
• Les dépendances d'exploitation. Les rôles, les politiques d'accès, les secrets, les pipelines de déploiement et l'observabilité sont souvent plus couplés au fournisseur que l'application elle-même.
• Le savoir-faire. Une équipe qui n'a jamais exploité ailleurs ne le fera pas en un trimestre, quelles que soient les clauses.

Ce qu'un architecte doit en faire

La bonne réponse n'est pas de tout rendre portable : une architecture qui refuse tout service managé paie une complexité permanente pour une option qu'elle n'exercera peut-être jamais. La réponse est de décider explicitement, composant par composant, à quel niveau de verrouillage on consent.

Trois niveaux suffisent à cadrer la discussion : portable (standard ouvert, remplaçable en quelques jours), remplaçable (propriétaire mais avec un équivalent et un chemin de migration connu), verrouillé (pas d'équivalent, sortie = réécriture). Un composant verrouillé n'est pas une faute ; un composant verrouillé par défaut, sans que personne ne l'ait décidé, en est une. C'est exactement le type d'arbitrage qui mérite une décision d'architecture écrite et datée, comme nous l'expliquons à propos d'une architecture qui n'a pas à être refaite.

Le plan de sortie se teste, ou il n'existe pas

Une clause de réversibilité non éprouvée a la même valeur qu'une sauvegarde jamais restaurée. L'exercice utile tient en une journée par an : prendre le composant le plus critique, exporter ses données vers un environnement neutre, et vérifier qu'on sait le relire. Ce que l'exercice révèle n'est presque jamais le volume — c'est la dépendance oubliée, le format non documenté, le secret que personne ne sait regénérer. Ce sont les mêmes réflexes que ceux de l'exploitation et de l'observabilité : on ne découvre pas ses angles morts le jour de l'incident.

Et pour l'IA

La question se pose désormais aussi sur la couche de modèles. Un agent écrit directement contre l'API d'un fournisseur, avec ses outils maison et son format de mémoire, est un composant verrouillé — y compris quand le fournisseur est excellent. Les standards d'interopérabilité que nous décrivions à propos de MCP et A2A ne suppriment pas ce verrouillage, mais ils en déplacent la frontière, et c'est ce qui les rend utiles dans une décision d'architecture.

• À partir du 12 janvier 2027, les frais de changement et de sortie sont interdits pour les services de traitement de données dans l'UE.
• Le trafic sortant courant reste facturable : l'interdiction vise la sortie, pas l'exploitation.
• Le vrai verrouillage est architectural — services managés, gravité des données, dépendances d'exploitation — et le règlement n'y touche pas.
• Classer chaque composant en portable / remplaçable / verrouillé, et écrire la décision.
• Un plan de sortie non testé ne compte pas.

Sources

• Règlement (UE) 2023/2854 — Data Act (EUR-Lex)
• Cloud Magazin — Quand les frais de changement disparaissent
• ePrecisio — Chapitre VI du Data Act : le changement de fournisseur