Une organisation décide de migrer vers le cloud. Le discours est rodé : élasticité, vitesse de déploiement, fin des investissements matériels, accès à des services managés qu’aucune équipe interne ne saurait reproduire. La migration se fait, les bénéfices arrivent — réels. Puis, trois ou quatre ans plus tard, une autre conversation s’ouvre en comité : « Combien nous coûterait-il de partir ? » Et la réponse, presque toujours, tombe comme un couperet : beaucoup trop pour l’envisager.

Ce moment est révélateur. Il ne dit pas que le cloud était un mauvais choix — il l’était rarement. Il dit que la décision a été prise sur un seul axe, le bénéfice, sans jamais instruire l’autre : la réversibilité. L’organisation n’a pas choisi le cloud ; elle s’y est enfermée. Et cet enfermement n’est pas une fatalité technique : c’est le résultat d’une série de choix d’architecture, faits ou évités, souvent sans en mesurer la portée.

Cet article défend une thèse simple : le vrai risque du cloud n’est pas le cloud, c’est l’irréversibilité. La dépendance à un fournisseur — le fameux vendor lock-in — n’est pas un accident, c’est une propriété de conception. Elle se dose, se négocie, s’arbitre. À condition de la traiter comme ce qu’elle est : une décision d’architecture, prise en amont, au même titre que la performance ou le coût.

Le faux débat : « cloud ou pas cloud »

Le premier réflexe, face au risque d’enfermement, est de reposer la question en termes binaires. Faut-il aller dans le cloud ou rester on-premise ? Faut-il tout migrer ou tout rapatrier ? Ce cadrage est stérile, parce qu’il oppose deux caricatures.

D’un côté, le mythe du cloud comme solution universelle : tout y migrer, le plus vite possible, sans distinguer les charges de travail. De l’autre, la nostalgie du datacenter maîtrisé, qui ignore pourquoi l’organisation a voulu en sortir. La réalité utile se situe entre les deux, et elle n’est pas une position mais une trajectoire : quelles charges vont où, sous quelle forme, avec quelle capacité de retour.

Le signe que le débat a mal été posé, c’est la surprise. Une organisation surprise par sa facture cloud, surprise par le coût de sortie, surprise par une contrainte réglementaire découverte après coup, est une organisation qui a décidé sans instruire la trajectoire. Le mouvement de rapatriement de certaines charges — que l’on observe depuis quelques années, à mesure que des entreprises ramènent des workloads prévisibles vers une infrastructure dédiée — n’est pas un rejet du cloud. C’est la correction, coûteuse, de migrations faites sans discernement. On ne rapatrie pas ce qu’on a placé au bon endroit ; on rapatrie ce qu’on y a mis par défaut.

Anatomie de l’enfermement

Le verrouillage n’est pas un phénomène unique. C’est un empilement de dépendances qui se cumulent, chacune augmentant le coût de sortie. Les nommer, c’est déjà pouvoir les arbitrer.

La gravité des données. C’est la couche la plus lourde, au sens propre. Plus une masse de données grossit dans un environnement, plus les traitements, les applications et les autres données viennent s’y agréger — parce qu’il est plus simple de rapprocher le calcul de la donnée que l’inverse. À mesure que cette gravité s’installe, déplacer l’ensemble devient une opération de plus en plus dissuasive. Le coût de transfert sortant — l’egress — n’en est que la traduction financière la plus visible ; le vrai poids est architectural.

Les services managés propriétaires. C’est le paradoxe central du cloud. Ce qui fait sa valeur — des services haut niveau, intégrés, qui dispensent l’équipe de réinventer une base de données distribuée, une file de messages ou un moteur d’événements — est aussi ce qui enferme le plus. Une application bâtie sur des primitives standard (une base relationnelle classique, des conteneurs, des protocoles ouverts) se déplace. Une application tissée autour des services spécifiques d’un fournisseur — ses fonctions serverless, ses API propriétaires, son modèle d’identité — ne se déplace pas : elle se réécrit.

Les compétences. Une dépendance qu’on oublie de compter. Quand les équipes ne maîtrisent plus que les outils d’un seul fournisseur, l’organisation perd la capacité même d’imaginer une alternative. Le verrouillage devient culturel avant d’être technique : ce n’est pas seulement que partir coûterait cher, c’est que plus personne ne saurait par où commencer.

Le contrat et l’économie. Engagements pluriannuels, remises conditionnées au volume, tarification de l’egress : l’architecture commerciale renforce l’architecture technique. Une remise attractive obtenue contre un engagement de consommation est un verrou qui ne dit pas son nom.

Ces quatre couches ne se valent pas et ne se traitent pas de la même manière. Mais elles ont un point commun : aucune n’apparaît le jour de la migration. Elles s’installent silencieusement, décision après décision, jusqu’à ce que leur somme rende la sortie impensable.

Réversibilité n’est pas portabilité

Deux mots sont souvent confondus, et cette confusion coûte cher.

La portabilité est une propriété technique : la capacité à exécuter la même charge de travail ailleurs, idéalement sans la modifier. C’est l’idéal du conteneur qui tourne partout, du standard ouvert, de l’infrastructure décrite en code. La portabilité est nécessaire, mais elle ne suffit pas.

La réversibilité est une propriété organisationnelle et contractuelle plus large : la capacité effective à quitter un fournisseur dans un délai et à un coût maîtrisés, sans perte de données, de fonction ni de conformité. Une charge peut être techniquement portable et pratiquement irréversible — parce que récupérer les données prendrait des mois, parce que le contrat l’interdit, parce que personne n’a jamais testé la manœuvre.

La distinction est décisive parce qu’elle déplace la question. La portabilité se conçoit dans le code ; la réversibilité se conçoit dans la stratégie de sortie. Et une stratégie de sortie n’existe que si elle est écrite, chiffrée, et — c’est le test ultime — répétée. Une réversibilité qu’on n’a jamais exercée est une hypothèse, pas une garantie. La question à poser en revue d’architecture n’est pas « pourrions-nous partir ? » mais « avons-nous déjà démontré que nous le pouvons, et à quel coût ? ».

La souveraineté : trois couches à ne pas confondre

À la réversibilité se superpose une seconde préoccupation, montée en puissance ces dernières années : la souveraineté. Là encore, le mot recouvre des réalités distinctes qu’il faut séparer pour décider juste.

La souveraineté des données est la plus connue : où résident physiquement les données, sous quelle juridiction, avec quelles garanties de localisation. C’est la couche que la plupart des organisations croient traiter en cochant la case « région locale ».

La souveraineté opérationnelle va plus loin : qui, concrètement, peut accéder aux données et aux systèmes, administrer les clés de chiffrement, opérer les infrastructures ? Des données stockées localement mais administrables depuis l’étranger par le personnel du fournisseur ne sont souveraines qu’en apparence.

La souveraineté juridictionnelle est la plus subtile et la plus souvent négligée : à quelle loi le fournisseur est-il soumis, indépendamment de l’endroit où sont les données ? Un fournisseur relevant d’une législation extraterritoriale peut être contraint, par sa propre juridiction, de communiquer des données hébergées ailleurs. La localisation physique ne protège pas de l’exposition juridique. C’est précisément le point que des cadres comme le CLOUD Act américain rendent tangible, et que les débats européens sur le cloud de confiance cherchent à adresser.

Ces trois couches appellent des réponses différentes. Localiser les données répond à la première, pas aux deux autres. Chiffrer avec des clés que l’on maîtrise soi-même répond en partie à la deuxième. La troisième, la plus difficile, ne se résout souvent qu’au niveau du choix même du fournisseur et de son statut juridique — d’où l’émergence d’offres de cloud souverain et de partenariats visant à découpler l’exploitation technique de la juridiction du fournisseur.

Le contexte réglementaire : ce qui a changé, et pourquoi c’est le bon moment

Deux évolutions récentes rebattent les cartes et rendent la question plus actionnable qu’elle ne l’était.

Le cadre européen a musclé le droit à la réversibilité. Le Data Act européen, applicable depuis septembre 2025, impose aux fournisseurs de services cloud des obligations concrètes de changement de prestataire : délais de migration encadrés, clauses contractuelles standard facilitant la sortie, et surtout suppression progressive des frais de changement — les frais d’egress facturés pour partir doivent être éliminés à l’horizon janvier 2027. Ce que le marché laissait à la négociation devient un droit. C’est un basculement : la réversibilité n’est plus seulement une bonne pratique d’architecture, c’est une exigence que le cadre juridique commence à garantir.

Les fournisseurs ont commencé à lever les barrières de sortie. Sous cette pression réglementaire et concurrentielle, les grands fournisseurs ont, dès 2024, annoncé la gratuité des transferts de données sortants pour les clients qui quittent leur plateforme. Le verrou financier le plus visible de l’enfermement — payer pour récupérer ses propres données — recule. Il ne disparaît pas : la gratuité est souvent conditionnée à un départ complet, et ne touche ni la gravité des données, ni la dépendance aux services propriétaires. Mais la direction est claire.

Pour une DSI, la conséquence pratique est double. D’abord, la fenêtre est favorable : le rapport de force se rééquilibre, et négocier des clauses de réversibilité n’a jamais été aussi légitime. Ensuite, il ne faut pas confondre le recul d’un verrou avec la disparition de tous les autres. La suppression de l’egress facturé règle la couche la moins profonde ; les trois autres — gravité, services propriétaires, compétences — restent entières et continuent de relever de l’architecture, pas du droit.

Le contexte marocain et africain

Pour les organisations basées à Casablanca, Abidjan ou Dakar, ces questions ne sont pas une transposition abstraite du débat européen. Elles ont leur propre grammaire.

La protection des données personnelles est encadrée — au Maroc, par la loi 09-08 et l’autorité qui en assure le contrôle — et impose des exigences de localisation et de consentement qui pèsent directement sur les choix d’hébergement. Les régulateurs financiers, Bank Al-Maghrib au premier rang, encadrent étroitement l’externalisation vers le cloud des établissements de crédit : maîtrise du risque, réversibilité, droit d’audit, notification. Une architecture cloud pour une banque de la région n’est pas seulement un choix technique, c’est un dossier à défendre devant un régulateur présent et exigeant.

À cela s’ajoute une réalité d’infrastructure : la disponibilité de régions cloud locales reste plus limitée qu’en Europe ou en Amérique du Nord, ce qui pose concrètement la question de la latence, de la résidence et de la continuité. La conséquence n’est pas de renoncer au cloud, mais de concevoir des trajectoires hybrides assumées, où la localisation des charges sensibles et la capacité de repli ne sont pas des options ajoutées après coup, mais des contraintes de conception dès le premier schéma.

Cadrer la trajectoire : une décision par charge de travail

La bonne unité de décision n’est ni « l’organisation », ni « le cloud », mais la charge de travail. Chaque application, chaque flux de données mérite d’être placé sur une trajectoire explicite, en fonction de quelques critères qui, croisés, dictent le bon niveau d’engagement et le bon niveau de réversibilité à préserver.

La criticité et la sensibilité. Une charge portant des données réglementées ou stratégiques n’appelle pas le même arbitrage qu’un environnement de test. Plus la sensibilité est haute, plus la réversibilité et la souveraineté doivent être instruites — quitte à accepter un cloud moins optimisé mais plus maîtrisable, ou une trajectoire hybride.

Le profil de charge. Une charge élastique, imprévisible, à pics marqués tire un bénéfice maximal de l’élasticité du cloud. Une charge stable, prévisible, tournant en continu tire un bénéfice bien plus faible — et c’est précisément le type de charge que le mouvement de rapatriement ramène vers des infrastructures dédiées, pour des raisons de coût et de prévisibilité.

L’intensité de couplage. Une charge qui, pour fonctionner, doit s’appuyer massivement sur des services propriétaires haut niveau accepte de fait un verrouillage fort. Ce n’est pas interdit — c’est souvent ce couplage qui crée la valeur — mais cela doit être un choix conscient, dont on connaît le prix de sortie, pas une dérive.

La gravité prévisible. Où va s’accumuler la donnée, et à quel rythme ? Anticiper la gravité, c’est décider tôt d’une stratégie de données — formats ouverts, points d’export, éventuelle réplication — avant que la masse ne rende toute manœuvre prohibitive.

Croiser ces critères ne donne pas une réponse unique ; il donne une carte. Certaines charges iront pleinement dans le cloud et y assumeront un couplage fort, parce que la valeur le justifie et que leur criticité l’autorise. D’autres resteront volontairement portables, sur des primitives standard. D’autres encore ne migreront pas, ou reviendront. L’important n’est pas la destination, c’est que chaque destination soit choisie, et que le chemin du retour soit connu.

Garder la porte de sortie ouverte

Préserver la réversibilité ne veut pas dire renoncer aux services managés ni se condamner au plus petit dénominateur commun — ce serait payer le cloud sans en tirer la valeur. Cela veut dire construire, dès le départ, quelques garde-fous d’architecture qui maintiennent le coût de sortie sous contrôle.

Isoler le propriétaire derrière des frontières nettes. Là où l’on choisit un service spécifique à un fournisseur, on l’encapsule derrière une interface interne, de sorte que le reste du système ignore le détail. Le couplage existe, mais il est confiné à une zone identifiée — celle qu’il faudra réécrire en cas de sortie, et pas davantage.

Maîtriser ses données et ses formats. Garder ses données dans des formats ouverts et documentés, disposer d’un chemin d’export testé, connaître le volume et le temps de récupération : c’est la couche la plus lourde de l’enfermement, et donc celle qui mérite le plus d’attention en amont.

Décrire l’infrastructure en code. Une infrastructure reproductible, décrite de manière déclarative, transforme une reconstruction ailleurs d’un projet en un exercice. C’est le socle technique de toute réversibilité crédible.

Écrire — et exercer — la stratégie de sortie. Le plan de réversibilité n’a de valeur que testé. Restaurer un environnement chez un autre fournisseur, ne serait-ce que partiellement, une fois par an, transforme une clause contractuelle en capacité réelle. C’est aussi le seul moyen d’en connaître le vrai coût avant d’en avoir besoin.

Négocier la réversibilité dans le contrat. Le cadre réglementaire fournit désormais un point d’appui : droit de sortie, portabilité des données, encadrement des frais. Il faut s’en saisir au moment où le rapport de force est le plus favorable — la signature — et pas au moment où l’on veut partir, où il ne l’est plus.

Conclusion

Le cloud n’est pas un piège, et la souveraineté n’est pas un slogan. Ce sont deux dimensions d’une même décision d’architecture, trop souvent réduite à un arbitrage de coût ou à une question d’infrastructure. Le fournisseur que l’on choisit, les services sur lesquels on s’appuie, l’endroit où l’on laisse la donnée s’accumuler, la clause que l’on néglige à la signature : chacun de ces choix ajoute ou retire un degré de liberté futur.

La bonne question n’a jamais été « faut-il aller dans le cloud ? ». C’est « quelle charge, où, sous quelle forme, et avec quelle capacité de retour ? ». Une organisation qui sait répondre à cela pour chacun de ses systèmes n’est pas enfermée — même si elle est massivement dans le cloud. Une organisation qui l’ignore est déjà prisonnière — même si elle croit encore avoir le choix. La différence ne se joue pas au moment de partir. Elle se joue au moment de concevoir.