La souveraineté numérique devient de plus en plus un enjeu vital pour les organisations, notamment lorsque le contexte géopolitique international se tend. Cependant, quand il s’agit d’aborder ce sujet, nous entendons beaucoup d’avis différents sur cette question. Qu’est-ce que vraiment la souveraineté ? C’est consommer local ? Mais si consommer local revient à se locker avec un fournisseur, est-ce que ce principe de souveraineté est toujours appliqué ?
Les enjeux sont grands pour les entreprises et chaque situation nécessite un arbitrage éclairé. Alors comment se prémunir de se retrouver bloqué par un fournisseur, peu importe qu’il soit européen ou pas ? En concevant des architectures dites réversibles.
Pour les CTOs et architectes, la question n’est plus faut-il penser la réversibilité ? mais comment la concevoir au juste coût, sans sacrifier l’innovation ni la vélocité ?
La souveraineté numérique ne se résume pas à choisir un fournisseur européen : choisir un fournisseur local ne suffit pas si l'architecture reste captive. La vraie protection, c'est la réversibilité, la capacité à changer de fournisseur sans douleur excessive.
Trois concepts à distinguer : la portabilité (déplacer les données et applications), la réversibilité (les opérer durablement ailleurs), et l'exit strategy (le plan documenté pour y parvenir).
En pratique : privilégier l'open source, appliquer l'architecture hexagonale aux composants critiques, standardiser sur des formats ouverts, et documenter chaque choix de service propriétaire dans un ADR avec son coût de sortie estimé.
Le lock-in n'est pas toujours un problème : pour un MVP ou un projet à durée de vie limitée, l'accepter en connaissance de cause est rationnel. La différence entre une dette saine et une dette toxique, c'est la visibilité.
Côté réglementaire, le Data Act (sept. 2025), la loi SREN et DORA pour le secteur financier transforment la réversibilité en obligation légale: vos fournisseurs doivent désormais la garantir contractuellement.
1. Qu’est-ce que la réversibilité dans un contexte d’infrastructures Cloud ?
La réversibilité est la capacité à quitter un fournisseur Cloud ou à faire évoluer ses choix techniques sans se retrouver pieds et poings liés avec ledit fournisseur. Elle concerne aussi bien la capacité à transférer les données que la possibilité de sortir de l’usage de certaines fonctionnalités.
Augmentation de coût, retrait d’un service spécifique, cessation d’activité d’un fournisseur, changement de politique d’entreprise ou tout simplement un changement d’architecture logicielle ou d’infrastructure sont des exemples qui peuvent nous pousser à revoir nos choix et nos décisions passés. Dès lors, l’importance stratégique d’intégrer la réversibilité comme principe directeur dès la phase de conception apparaît comme un point crucial et non négociable dans l’intérêt de son entreprise.
2. Réversibilité, portabilité, exit strategy : trois concepts distincts
Les décisions d’architecture ne devant jamais être anodines ou prises au hasard, il est important de bien comprendre la différence entre les 3 concepts suivants pour pouvoir prendre une décision pertinente et effectuer des arbitrages éclairés : portabilité, réversibilité et exit strategy.
2.1 Portabilité
La portabilité est une propriété technique. C’est la capacité de déplacer des données et des applications d’un environnement à un autre. Prenez l’exemple d’une application qui tourne sur un fournisseur cloud A, si on arrive à faire fonctionner l’application sur un fournisseur cloud B, sans devoir ré-architecturer l’application, c’est qu’elle est portable.
2.2 La réversibilité
La réversibilité est plus large : elle englobe la portabilité mais y ajoute la capacité opérationnelle à exploiter durablement les workloads dans le nouvel environnement.
Prenons l’exemple d’un fournisseur de solutions d’infrastructure qui applique des changements tarifaires et met devant le fait accompli ses clients. Cela va pousser la majorité de ces derniers à évaluer des alternatives. Les clients qui auront développé des applications portables s’en sortiront mieux que les autres pour migrer. Cependant, une fois ces applications déplacées, il faut pouvoir être capable de les opérer et de les maintenir en condition opérationnelle en production. C’est là qu’intervient le principe de réversibilité.
D’ailleurs, l’ANSSI mentionne explicitement dans son guide d’hygiène informatique parmi les exigences à imposer contractuellement à tout prestataire : “réversibilité du contrat, réalisation d’audits, sauvegarde et restitution des données dans un format ouvert normalisé, maintien à niveau de la sécurité dans le temps”.
2.3 Exit strategy
Et pour pouvoir garantir la portabilité et la réversibilité, il faut mettre en place une exit strategy. Mais c’est quoi au juste ? L’exit strategy ou stratégie de sortie est le cadre de gouvernance documenté qui rend la réversibilité et la portabilité opérantes. Concrètement, cela passe souvent par de la documentation d’actions à effectuer, des procédures de tests, la définition d’une matrice de risques avec des actions correctives, etc.
3. Actions concrètes pour garantir la réversibilité
L’approche pragmatique consiste à être réversible dans la mesure du possible, en ciblant les efforts là où le risque est le plus élevé. L’objectif n’est pas d’abstraire chaque service cloud derrière une couche d’indirection, mais de préserver la capacité à changer là où ça compte vraiment.
3.1 Privilégier les projets open source
Privilégier les projets open source portés par plusieurs fournisseurs est un levier puissant : un service construit sur PostgreSQL, Kafka ou Kubernetes dispose d’un écosystème entier d’alternatives, là où un service propriétaire n’en offre aucune.
3.2 Se prémunir du vendor lock-in
Le vendor lock-in ou verrouillage fournisseur est une situation de dépendance où un client est contraint de rester avec un fournisseur de services Cloud ou logiciels. Il s’agit là d’un des risques majeurs pour la réversibilité qui, lorsqu’il survient, peut avoir un impact majeur sur une entreprise. Ce risque ne concerne pas uniquement les solutions non souveraines ni n’est propre à un contexte cloud public. Même on-premises, vous pouvez y être confronté. Pour le mitiger, il faut évaluer le risque de dépendance aux services proposés par un fournisseur unique et arbitrer en connaissance de cause.
Il faut faire attention aussi aux détails. Il arrive, par exemple, que l’on utilise l’API d’un service standard (Kubernetes) et que le fournisseur étende cette API avec des fonctionnalités propriétaires, ce qui contraint à réécrire l’application pour pouvoir migrer.
Parfois le problème vient de l’architecture, nous pouvons partir sur une architecture donnée, et nous nous retrouvons dans l’incapacité de migrer. Par exemple, en passant du cloud vers l’on-premises ou de l’on-premises vers le cloud.
D’autres fois, le risque vient de l’expertise qui est concentrée uniquement sur un écosystème donné, réduisant la capacité à mieux anticiper cette problématique.
Et dans certains cas le risque est contractuel. Nous nous retrouvons, par exemple, avec des engagements sur un type de ressources, qui limitent la possibilité d’évolution architecturale sans engendrer de coût important.
Il est important de souligner que le vendor lock-in n’est pas un sujet exclusif aux fournisseurs non européens. La nationalité du fournisseur ne protège pas du lock-in, seule l’architecture le peut.
3.3 L’architecture hexagonale comme bouclier anti-lock-in
Le pattern hexagonal (ports & adapters), proposé par Alistair Cockburn, isole la logique métier des dépendances externes via des ports (interfaces agnostiques) et des adaptateurs (implémentations spécifiques). Appliqué aux services cloud, il permet de remplacer un adaptateur S3 par un adaptateur Azure Blob Storage sans modifier le code métier.
La recommandation pragmatique est d’appliquer l’architecture hexagonale sélectivement aux composants interagissant avec des services managés susceptibles de changer : bases de données, queues de messages, stockage objet. Abstraire l’intégralité de l’infrastructure revient à construire des couches d’abstraction coûteuses pour un bénéfice incertain.
3.4 Conteneurs et Kubernetes : portabilité réelle mais limitée
Kubernetes fournit une abstraction commune pour le compute, le réseau et (partiellement) le stockage. Cependant, si l’effort de migration du code applicatif est moindre, voire nul, la portabilité se brise sur d’autres composants d’architecture : VPC, DNS, load balancers, IAM… Il faut anticiper l’effort de configuration initiale. À cela s’ajoute le sujet des volumes de stockage persistants, spécifiques à chaque fournisseur.
La vraie valeur de Kubernetes en matière de réversibilité n’est pas la portabilité « lift & shift » mais la portabilité des compétences et des concepts : un modèle opérationnel standardisé qui réduit les coûts de formation et donne un véritable levier stratégique à l’entreprise.
3.5 L’infrastructure as Code
Terraform (et son fork open source OpenTofu) offre un workflow unifié pour provisionner des ressources chez plus de 1 000 providers, mais les définitions de ressources restent spécifiques à chaque fournisseur (on ne peut pas écrire une fois et déployer partout). La portabilité via l’infrastructure as Code passe par des modules abstraits avec des implémentations provider-spécifiques, une séparation stricte de l’état par provider, et un stockage des secrets hors du code.
3.6 Le spectre du lock-in par service
Les services créant le plus de lock-in sont les services propriétaires sans équivalent direct. Les services managés construits sur de l’open source (PostgreSQL, Kafka managé) présentent un lock-in moyen : le moteur est portable, mais les fonctionnalités spécifiques ne le sont pas. Le plus faible lock-in se trouve dans les API devenues des standards de facto : l’API S3 est aujourd’hui le protocole universel du stockage objet, supporté par des solutions aussi bien open source que managées.
3.7 Multi-cloud : complexité contre liberté de choix
Le concept de « polycloud » offre une alternative plus pragmatique au multi-cloud générique : utiliser différents providers selon leurs forces respectives (GCP pour le ML, AWS pour l’étendue des services, Azure pour l’écosystème Microsoft) plutôt que de chercher un dénominateur commun qui appauvrit chaque plateforme. Le multi-cloud actif-actif (même workload sur plusieurs clouds) reste quant à lui très rare et très coûteux.
4. Mesurer et piloter la réversibilité
4.1 Cadre d’évaluation
L’évaluation de la réversibilité peut se structurer autour de six axes :
- absence d’engagement obligatoire
- transfert de licences et utilisation de standards ouverts
- portabilité des données
- mobilité des applications
- valeur ajoutée du fournisseur
- caractère raisonnable des coûts de migration
Il faut au minimum évaluer ces six axes pour mesurer son score de réversibilité.
4.2 Estimation du coût de sortie
Le coût d’un cloud exit doit intégrer des éléments souvent sous-estimés : les frais d’egress (plafonnés au coût direct jusqu’au 12 janvier 2027, puis interdits par le Data Act dans le cadre d’un changement de fournisseur), les coûts de ré-architecture des applications dépendant de services PaaS/SaaS propriétaires, le fonctionnement en double pendant la transition, la formation des équipes aux nouvelles plateformes, l’acquisition d’infrastructure (en cas de rapatriement), les cycles de test et de validation, le coût d’opportunité de l’ingénierie mobilisée, et les coûts de re-certification compliance, si cela est applicable.
Cette estimation est importante et nécessaire pour savoir si la sortie d’un fournisseur est économiquement justifiée.
4.3 La gravité des données : premier obstacle à la sortie
En 2010, Dave McCrory a introduit le concept de data gravity, qui explique pourquoi la réversibilité se dégrade avec le temps : à mesure que les données grossissent, elles attirent applications et services comme une masse gravitationnelle. Les stratégies de mitigation incluent la distribution des workloads (cloud spread), le traitement en périphérie (edge computing), la réplication fédérée, l’adoption de formats de données ouverts (Apache Parquet, Iceberg, Delta Lake), et surtout une revue trimestrielle du placement des données et du compute.
5. Le vendor lock-in : une stratégie parfois assumée
Tout ce qui a été dit plus haut pourrait laisser croire que le lock-in est toujours un problème à résoudre. Ce n’est pas le cas. Pour certaines organisations, à certains moments de leur cycle de vie, accepter le lock-in en connaissance de cause est une décision parfaitement rationnelle.
5.1 Le cas des startups et du MVP
Prenons une entreprise qui se lance et veut valider son concept avec un MVP. Elle sait pertinemment qu’elle fera évoluer son architecture applicative et son architecture d’infrastructure. Dans ce contexte, la vélocité de mise sur le marché pèse infiniment plus lourd dans la balance que la portabilité. Utiliser certains services propriétaires permet de livrer plus vite ce qui prendrait plus longtemps à livrer avec une architecture cloud-agnostique, notamment parce que cela demanderait certaines compétences en infrastructure et en administration des systèmes. Le surcoût d’une éventuelle migration future est un risque acceptable face au risque bien plus immédiat de ne jamais trouver son marché.
Ce raisonnement ne s’applique pas qu’aux startups. Une équipe innovation au sein d’un grand groupe, un proof of concept à durée de vie limitée, un projet événementiel avec une date de fin connue, autant de situations où l’arbitrage coût/vélocité penche naturellement vers les services natifs.
5.2 Critères de décision pour un lock-in assumé
Accepter le lock-in ne signifie pas l’ignorer. Un lock-in assumé est un lock-in documenté. Plusieurs critères permettent de structurer cette décision :
- La durée de vie prévisible du workload. Un service temporaire ou exploratoire ne justifie pas le même investissement en portabilité qu’un système cœur de métier à horizon plus long.
- Le différentiel de productivité. Si un service managé propriétaire divise le temps de développement par trois par rapport à une alternative portable, le coût de la portabilité est concret et immédiat, là où le coût du lock-in est hypothétique et futur.
- La criticité métier des données. Les données transactionnelles clients méritent un format portable et des exports réguliers, même si l’application qui les traite est fortement couplée à un fournisseur.
- La probabilité réelle de migration. Certains composants ne migreront jamais. Un système d’authentification construit sur une brique propriétaire restera probablement sur le même provider aussi longtemps que le provider existera. Le coût d’une abstraction n’a pas de retour sur investissement si la migration n’arrive jamais.
- La taille de l’équipe et ses compétences. Une petite équipe maîtrisant parfaitement un fournisseur donné perd en efficacité si elle doit maintenir des abstractions multi-cloud qu’elle ne testera jamais.
5.3 Documenter le choix, planifier la réévaluation
Le piège n’est pas le lock-in lui-même mais le lock-in accidentel, celui qui s’accumule sans que personne n’en ait pris la décision. Chaque choix de service propriétaire devrait être consigné dans un ADR (Architecture Decision Record) qui documente le service retenu, les alternatives évaluées, la raison de l’arbitrage en faveur du service natif, l’estimation du coût de migration si le choix devait être révisé, et le trigger de réévaluation (montée en charge, changement de stratégie, échéance réglementaire ou révision tarifaire significative du fournisseur).
Un ADR ne coûte pas beaucoup à produire et transforme un lock-in subi en lock-in maîtrisé. La réévaluation devrait intervenir à des moments clés : revue d’architecture annuelle, changement significatif de volumétrie, passage d’une phase exploratoire à une phase de scale, ou évolution du contexte réglementaire (entrée en vigueur du Data Act par exemple).
5.4 Le lock-in comme dette technique consciente
En ce sens, le lock-in assumé s’apparente à une dette technique consciente au sens de Martin Fowler : une dette contractée délibérément, avec un plan de remboursement conditionnel. La différence entre une dette saine et une dette toxique, c’est la visibilité. Un lock-in documenté dans un ADR, avec un coût de sortie estimé et un trigger de réévaluation, c’est une dette saine. Un lock-in qui s’accumule service après service sans que personne n’en connaisse le coût total, c’est une dette toxique. Malheureusement, ce dernier cas est le plus fréquent.
6. Bonnes pratiques pour les décideurs
6.1 Le plan de réversibilité : un livrable, pas une option
Un plan de réversibilité structuré couvre la gouvernance, l’évaluation des risques, la définition de la stratégie de sortie et les tests réguliers. Ce cadre se construit en fonction du contexte de l’entreprise. Idéalement, le plan de sortie doit être défini avant le premier déploiement en cloud, pas après.
6.2 Ce que le Data Act change pour les entreprises françaises
Le règlement européen 2023/2854 (Data Act), dont les dispositions cloud sont applicables depuis le 12 septembre 2025, donne à tout client cloud le droit de changer de fournisseur à tout moment. Les frais de sortie sont plafonnés aux coûts directs jusqu’au 12 janvier 2027, puis purement interdits dans le cadre d’un changement de fournisseur. En France, la loi SREN du 21 mai 2024 anticipe ces dispositions avec des amendes pouvant atteindre 3 % du chiffre d’affaires mondial du fournisseur. Concrètement, cela signifie que la réversibilité n’est plus un sujet d’architecture uniquement, c’est un droit que vos fournisseurs ont l’obligation légale de garantir.
Pour les entités du secteur financier, le règlement DORA (UE 2022/2554, applicable depuis janvier 2025) ajoute une couche d’obligations supplémentaires : exit strategies documentées pour tous les prestataires ICT critiques, évaluation obligatoire du risque de concentration sur un fournisseur unique, et exigences contractuelles renforcées incluant les conditions de résiliation et les procédures de migration. DORA transforme la réversibilité en exigence prudentielle au même titre que la continuité d’activité.
6.3 Clauses contractuelles essentielles
Le Data Act et la loi SREN structurent désormais le cadre contractuel minimum. Tout contrat cloud doit inclure : le droit de basculer vers un autre fournisseur, une procédure de migration claire, les catégories de données et actifs numériques portables, l’assistance à la stratégie de sortie, la restitution complète des données dans un format exploitable, et des délais précis de suppression sécurisée après la fin du contrat. La Commission européenne a développé des clauses contractuelles types (non contraignantes) avec deux options : Option A (migration assistée par le fournisseur avec plan de sortie détaillé) et Option B (migration en libre-service avec outils automatisés).
6.4 Gouvernance continue et tests de réversibilité
La réversibilité n’est pas un état binaire mais une capacité qui se dégrade si elle n’est pas entretenue. Les bonnes pratiques incluent la maintenance d’artefacts auditables (résultats de tests de sortie, revues d’accès, traçabilité de la gestion des clés), la standardisation sur des formats ouverts (OpenAPI pour les API HTTP, Apache Parquet/Avro pour les données, OCI pour les images de conteneurs), et des exercices réguliers de sortie. Deux approches de test sont possibles : un test de faisabilité de migration dans des conditions maîtrisées, et un exercice de migration réelle avec maintien de la continuité de service.
7. Rapatriement, souveraineté, et clouds de confiance
7.1 Le rapatriement cloud est réel mais sélectif
Certaines entreprises préfèrent revenir on-premises. Cependant, dans la majorité des cas de retour vers l’on-premises, le consensus est celui d’un rééquilibrage au sein de stratégies hybrides : les workloads prévisibles et data-intensive migrent vers de l’infrastructure propre, les workloads élastiques restent dans le cloud. Grâce aux technologies cloud native, revenir on-premises ne signifie pas renoncer aux pratiques cloud native, c’est passer d’un modèle cloud public à un modèle cloud privé.
7.2 FinOps : le garde-fou avant la sortie
Les programmes FinOps matures traitent la réversibilité comme une propriété système. Le plus souvent, les dépenses inutiles sur le cloud arrivent à cause de ressources surdimensionnées ou d’un mauvais usage. Avant d’envisager un rapatriement, le FinOps doit vérifier si les surcoûts proviennent de lacunes de tagging, de ressources inactives ou d’une mauvaise couverture de remises, problèmes résolvables sans migration.
7.3 Les clouds souverains français et les clouds de confiance
De plus en plus, nous entendons parler du concept de « géopatriation », le mouvement des hyperscalers vers des fournisseurs locaux ou régionaux. C’est dans ce contexte que se multiplient les alliances entre hyperscalers et providers locaux, notamment pour adresser ce marché. En France, nous en parlons sous le nom de “Cloud de confiance”.
D’autres acteurs se lancent dans une offre souveraine avec des capitaux 100 % français (OVHcloud, Numspot, Scaleway, OUTSCALE, etc.).
Selon Gartner (enquête menée de mai à juillet 2025 auprès de 241 décideurs d’Europe de l’Ouest), 53 % estiment que la géopolitique limitera leur usage futur des fournisseurs cloud globaux, et 55 % considèrent que les technologies open source seront importantes dans leurs stratégies cloud futures.
7.4 Et le SecNumCloud dans tout cela ?
Le référentiel SecNumCloud de l’ANSSI comporte plus de 360 exigences dont des dispositions explicites sur la réversibilité. Il impose aux prestataires d’inclure dans la convention de service une clause de réversibilité permettant au client de récupérer l’ensemble de ses données, soit par mise à disposition de fichiers dans un format documenté et exploitable, soit par des interfaces techniques (API) documentées. Le référentiel exige également la suppression sécurisée de toutes les données après la fin du contrat.
Au niveau européen, le schéma EUCS (EU Cloud Services Scheme) reste en discussion, le débat politique sur les exigences de souveraineté n’ayant pas encore abouti à un consensus définitif. La norme ISO/IEC 19941 fournit le cadre conceptuel international pour l’interopérabilité et la portabilité cloud, tandis que le code de conduite CISPE et son Cloud Switching Framework de novembre 2024 rendent opérationnelle la conformité au Data Act pour les fournisseurs IaaS.
Si tous ces référentiels et normes vont dans le bon sens, ils peuvent s’avérer lourds à implémenter par des acteurs locaux et peuvent créer une asymétrie de conformité entre acteurs locaux et hyperscalers, ces derniers disposant de plus de ressources pour y répondre.
Certaines organisations ne choisissent pas leur fournisseur cloud pour son label SecNumCloud mais pour la fiabilité et la richesse fonctionnelle de ses services, le label n’étant qu’un critère parmi d’autres dans la décision.
8. Conclusion : la réversibilité comme discipline d’architecture continue
La réversibilité cloud n’est pas un projet ponctuel mais une discipline continue qui se joue principalement à deux niveaux : architectural (patterns d’abstraction, standards ouverts, IaC multi-cloud), et organisationnel (plans de sortie testés, clauses contractuelles, compétences diversifiées). Le piège le plus fréquent n’est pas l’absence totale de réversibilité mais la dégradation silencieuse de cette capacité au fil des choix techniques quotidiens : un service managé propriétaire ici, une intégration spécifique là, jusqu’à ce que le coût de sortie devienne prohibitif.
La posture optimale, validée tant par les retours d’expérience que par les analystes, est celle du pragmatisme calibré : investir dans la portabilité là où le lock-in est le plus risqué (données cœur, stockage, observabilité), accepter les services natifs là où le gain de productivité justifie le coût de migration potentiel, et maintenir dans tous les cas la capacité organisationnelle à exercer l’option de sortie. La convergence entre pression réglementaire européenne, maturité des outils open source (Kubernetes, OpenTelemetry, Terraform/OpenTofu) et volonté croissante de souveraineté numérique crée un momentum sans précédent pour faire de la réversibilité un critère de design de premier rang.
Vous souhaitez évaluer votre niveau de réversibilité ou construire votre exit strategy ? Contactez-nous.
Sources
- ANSSI — Guide d’hygiène informatique — Recommandations sur la réversibilité des prestataires cloud
- Journal officiel de l’UE — Règlement 2023/2854 (Data Act)
- Légifrance — Loi SREN n° 2024-449 du 21 mai 2024
- Gartner — Geopolitics Will Drive 61% of Western European CIOs to Increase Reliance on Local Cloud Providers — IT Symposium/Xpo Barcelone, novembre 2025
- ISO — ISO/IEC 19941:2017 — Cloud computing — Interoperability and portability
- Journal officiel de l’UE — Règlement DORA 2022/2554
- ANSSI — Référentiel SecNumCloud v3.2
- CISPE — Cloud Switching Framework, novembre 2024
- Dave McCrory — Data Gravity
- Martin Fowler — Technical Debt
- Alistair Cockburn — Hexagonal Architecture