Demandez à dix équipes infra si elles ont une stratégie de sortie cloud, neuf répondront oui. Demandez en quoi elle consiste, et vous obtiendrez généralement une page wiki écrite pendant une revue fournisseur, listant les services propriétaires et ceux qui sont portables. C'est un inventaire, pas une stratégie. Le vrai test est moins confortable : si votre fournisseur doublait ses prix, changeait de juridiction, ou suspendait votre compte un mardi matin, combien de semaines avant de servir du trafic ailleurs - et qui, dans votre équipe, peut répondre à ça sans ouvrir un tableur ?
La pression réglementaire ici est réelle, mais ce n'est pas la partie intéressante. Le Data Act supprime les frais de changement de fournisseur, ce qui retire au service financier son excuse. Schrems II et le CLOUD Act ont retiré l'excuse juridique il y a des années. Ce qui reste, c'est la réalité technique, et aucune directive ne la corrige. Un régulateur peut rendre le départ moins cher sur le papier ; il ne peut pas faire fonctionner votre pipeline de déploiement, votre modèle d'identité, vos enregistrements DNS et votre procédure de restauration chez un second fournisseur. Ce travail est le vôtre, et c'est là tout le coût.
Ce qu'est vraiment une stratégie de sortie cloud
Une stratégie de sortie est une propriété mesurable de votre architecture, pas un document. La mesure est brutale : quelle part de votre parc en production pourriez-vous redéployer chez un autre fournisseur, avec l'outillage que vous exploitez déjà, sans écrire une ligne de code ? Pour la plupart des équipes, la réponse honnête se situe entre quarante et soixante-dix pour cent, et l'écart n'est jamais là où on l'attendait. Ce n'est presque jamais l'application. C'est la base de données gérée, la file de messages, la sémantique du stockage objet, et les onze petites habitudes opérationnelles que personne n'a jamais écrites.
L'erreur, c'est de croire qu'avoir deux fournisseurs prouve quoi que ce soit. Beaucoup d'entreprises font tourner leur production chez un hyperscaler et un projet de test oublié ailleurs, puis appellent ça du multi-cloud. L'optionalité, ce n'est pas la présence d'un second compte ; c'est la capacité à l'exercer. Tant qu'un vrai workload - avec monitoring, sauvegardes, un roulement d'astreinte et une restauration réellement effectuée - ne tourne pas ailleurs que chez votre fournisseur principal, vous avez une deuxième facture, pas une deuxième option.
Les trois choses qui rendent le départ difficile
D'abord, la gravité des données, ennuyeuse et décisive. Copier des octets ne coûte rien ; les déplacer de façon cohérente pendant qu'un système tourne en production coûte cher. Dès que vos données résident dans un service géré propriétaire, la sortie cesse d'être une copie et devient une réécriture de tout ce qui lui parle. C'est pourquoi les équipes qui conservent leur état dans quelque chose qu'elles pourraient exploiter elles-mêmes - même si elles choisissent de ne pas le faire aujourd'hui - préservent des options que les équipes sur des stacks entièrement managés perdent discrètement en quelques années.
Ensuite, la mémoire musculaire opérationnelle. Votre équipe connaît le modèle d'identité d'un fournisseur, une abstraction de firewall, une façon de nommer les réseaux, une disposition de console à trois heures du matin. Passez à un second fournisseur, et chacun de ces repères devient étranger sous pression. Le coût, ce n'est pas le week-end de migration ; ce sont les six mois suivants d'incidents gérés un peu plus lentement par des gens qui tâtonnent. Personne ne met ça dans une estimation de migration, et c'est pourtant généralement la plus grosse ligne du budget.
Enfin, l'attribution des coûts. La plupart des équipes ne peuvent pas dire ce que coûte un seul workload aujourd'hui, ce qui rend la comparaison des fournisseurs impossible en principe. Si votre facture est un seul chiffre par fournisseur et que votre architecture compte quarante services, la conversation sur la sortie dégénère en impressions vagues. Avant de pouvoir chiffrer une sortie, il vous faut des dépenses détaillées par service, projet et environnement, sur chaque fournisseur que vous utilisez, y compris les petits que vous avez oubliés. C'est un travail de fond peu glamour, et c'est un prérequis pour toutes les autres décisions ici.
Comment éviter le vendor lock-in cloud dans l'UE
Si vous voulez éviter le vendor lock-in cloud, le marché européen est en meilleure forme que la plupart des équipes ne l'imaginent. Le rapport prix-performance de Hetzner fait ressembler les factures des hyperscalers à une erreur d'arrondi dans le mauvais sens. OVHcloud exploite ses propres data centers et sa propre fibre à travers l'Europe. Scaleway propose une expérience développeur vraiment moderne, depuis la France. UpCloud livre du compute fiable depuis la Finlande. Aucun d'eux ne remplace tous les services d'un hyperscaler - mais pour le compute, le stockage bloc et le réseau, là où va réellement la majeure partie du budget infrastructure, ils sont crédibles et ne répondent qu'au droit de l'UE.
La limite honnête, ce sont les services managés. Si votre produit repose sur une base de données serverless propriétaire, un event bus spécifique, ou une plateforme de machine learning sans équivalent ailleurs, aucun enthousiasme européen ne changera ça en un trimestre. Le mouvement utile n'est pas une migration héroïque du tout-ou-rien. C'est de savoir précisément quels workloads sont portables aujourd'hui, d'en faire tourner certains là où la juridiction et le prix vous conviennent, et de traiter le reste comme une décision délibérée et documentée plutôt qu'un accident de l'histoire.
Ce qu'implique vraiment un exercice de sortie
Traitez ça comme un exercice de restauration, parce que c'est exactement ça. Choisissez un vrai workload - pas le site marketing, quelque chose avec un état et un runbook. Déployez-le chez un second fournisseur. Dirigez-y une fraction du trafic réel. Cassez-le délibérément et vérifiez si votre monitoring, votre modèle d'accès et votre roulement d'astreinte fonctionnent là aussi. Puis notez le temps réel écoulé et tout ce qui vous a surpris. Un exercice qui ne produit aucune surprise signifie généralement que vous avez choisi quelque chose de trop facile.
Si la plupart des équipes ne s'exercent jamais, ce n'est pas de la paresse, c'est l'outillage. Chaque fournisseur supplémentaire, c'est une autre console, un autre modèle d'identifiants, un autre export de facturation, un autre lot de bizarreries à apprendre - et une petite équipe plateforme ne peut pas absorber ça une fois par cloud. C'est la taxe opérationnelle qui transforme discrètement une conversation sur la souveraineté en problème de l'année prochaine, chaque année. Et c'est précisément le problème qu'un plan de contrôle est censé retirer de votre bureau.
C'est ce que nous avons construit avec Sencai. Un seul plan de contrôle sur onze fournisseurs - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode d'Akamai et Oracle Cloud - plus vos propres serveurs via un agent hôte. Les réseaux, firewalls et DNS sont gérés là où ils vivent réellement, chez le fournisseur, si bien qu'un second fournisseur devient une tuile dans la même interface plutôt qu'une seconde équipe plateforme. Les dépenses sont suivies par organisation avec des plafonds, si bien que la conversation sur la sortie s'appuie sur des chiffres.
Vous pouvez faire tourner ça sur vos propres comptes fournisseurs, ou acheter la capacité via nous et garder une seule facture - les deux sont pris en charge, et le choix vous appartient et reste modifiable plus tard. Dans les deux cas, le livrable est le même, et c'est le seul chiffre qui mérite d'être remonté à la direction : combien de temps il vous faudrait pour tourner ailleurs. Mesurez-le une fois, et ça cesse d'être une peur. Mesurez-le chaque trimestre, et ça devient un levier - dans une négociation, dans une revue d'achats, et le jour où quelque chose impose la question.