Ce que signifie réellement la portabilité dans le cloud et comment y parvenir

La différence entre le multicloud et la portabilité

À retenir : avoir des charges de travail sur deux clouds, ce n’est pas la même chose que de pouvoir les déplacer librement entre les deux. La portabilité, c’est une question de facilité de déplacement, pas de nombre de fournisseurs utilisés.

La plupart des équipes qui se disent « multicloud » ne sont pas portables. Elles ont des charges de travail cloisonnées chez des fournisseurs distincts, chacun avec sa propre chaîne d’outils, son pipeline de déploiement et ses conventions opérationnelles. Déplacer quoi que ce soit entre ces environnements revient à repartir de zéro.

Ce n’est pas de la portabilité. C’est de la redondance avec une charge opérationnelle supplémentaire.

La véritable portabilité cloud, c’est quand tes applications, tes services et tes données peuvent passer d’un environnement cloud à l’autre sans reconfiguration majeure. Le code reste le même. Le processus de déploiement reste le même. Ce qui change, c’est le fournisseur ou la région sous-jacente, et ce changement doit être un choix délibéré, pas un projet de migration.

Pourquoi la portabilité est plus compliquée qu’il n’y paraît

À retenir : la dépendance vis-à-vis d’un fournisseur n’est généralement pas le fruit d’une seule décision. Elle s’accumule petit à petit. Chaque intégration spécifique à un fournisseur ajoute des obstacles à tout changement futur.

Les obstacles techniques sont bien réels. Les fournisseurs superposent des politiques d’autoscaling propriétaires, des modules complémentaires de mise en réseau et des intégrations d’identité à des technologies ouvertes comme Kubernetes et PostgreSQL, réintroduisant ainsi une dépendance au-delà de la base open source.

Les obstacles organisationnels sont tout aussi importants :

• Les équipes créent des scripts de déploiement, des pipelines d’intégration continue et des configurations de surveillance spécifiques à chaque fournisseur.
• La configuration des applications contient souvent des variables d’environnement, des points de terminaison ou des appels SDK spécifiques à chaque fournisseur.
• Les données stockées dans des formats propriétaires ou sur des services gérés deviennent coûteuses à extraire.
• Les préoccupations liées à la portabilité et à l’interopérabilité des données figurent systématiquement parmi les thèmes les plus discutés par les décideurs informatiques en matière d’enfermement propriétaire.

Une enquête menée en 2026 auprès de 540 professionnels de l’informatique a révélé que 94 % des entreprises s’inquiètent de l’enfermement propriétaire, et que 84 % d’entre elles sont particulièrement préoccupées par la souveraineté des données.

Le fossé entre les préoccupations et l’action persiste, car les outils utilisés par la plupart des organisations intègrent des hypothèses propres au fournisseur au niveau de l’infrastructure. Les fichiers de configuration font référence à des noms de ressources spécifiques à AWS. Les variables d’environnement pointent vers des points de terminaison hébergés sur Azure. Au moment où la portabilité devient urgente, le code a déjà intégré des années de choix spécifiques au fournisseur.

Ce que signifie réellement une infrastructure portable dans le cloud 

À retenir : une infrastructure portable, c’est quand le processus de déploiement décrit les exigences de l’application, et non des commandes spécifiques au fournisseur. Le fournisseur devient un paramètre, pas une dépendance.

La portabilité exige que la configuration de ton infrastructure soit rédigée sous une forme qui accompagne ton code, plutôt que d’être liée au framework, à la console ou à l’interface en ligne de commande (CLI) d’un fournisseur spécifique.

Les exigences pratiques sont les suivantes :

1. Des pipelines de déploiement indépendants du fournisseur. Ton processus de build et de déploiement ne devrait pas avoir besoin de savoir s’il s’exécute sur AWS ou GCP. Il devrait décrire ce dont l’application a besoin, et non où elle se trouve.
2. Une configuration gérée par contrôle de version et portable. Les décisions relatives à l’infrastructure doivent figurer dans des fichiers validés dans ton dépôt Git, et non dans le tableau de bord d’un fournisseur de cloud.
3. Des décisions de placement des charges de travail prises au niveau de la plateforme. La plateforme doit gérer les différences spécifiques à chaque fournisseur, pour que l’équipe n’ait pas besoin de développer une expertise distincte pour chaque cloud.
4. Des contrôles de localisation des données sans fragmentation des processus. Placer des données dans une région spécifique pour des raisons de conformité ne devrait pas nécessiter un processus de déploiement différent pour cette charge de travail.

C’est le modèle qu’utilise Upsun Cloud pour les déploiements multicloud. Les choix d’infrastructure sont gérés via des fichiers YAML portables soumis au contrôle de version au même titre que le code de l’application, et une couche de plateforme cohérente gère les différences spécifiques à chaque fournisseur. Le même processus permet de déployer sur AWS, Azure, Google Cloud, IBM ou OVHCloud, selon la région que tu sélectionnes lors de la création du projet. Choisir le fournisseur de cloud optimal pour chaque projet ne nécessite aucune modification de la façon dont l’application est construite ou exploitée.

Ça veut aussi dire que tes ingénieurs n’ont besoin de maîtriser qu’une seule configuration et une seule interface pour tous les principaux fournisseurs. Ils n’ont pas à gérer de changement de contexte lorsqu’ils passent d’une application à l’autre.  

C’est important, car ça sépare le « où » du « comment ». Les ingénieurs n’ont pas besoin d’apprendre un nouveau modèle de déploiement à chaque fois qu’une charge de travail est déplacée ou s’il est décidé qu’une application doit être hébergée chez un fournisseur de cloud particulier. Ils configurent l’application une seule fois, puis choisissent le fournisseur et la région indépendamment.

Le cas de la conformité et de la résilience

À retenir : la portabilité est la condition préalable à la fois à une véritable souveraineté des données et à une résilience crédible. Sans elle, le multicloud n’est qu’une façade.

Deux contraintes spécifiques font de la portabilité une exigence pratique plutôt qu’une préférence théorique :

1. La résidence des données. Des 
   réglementations comme le RGPD en Europe exigent que certaines catégories de données soient stockées et traitées dans des juridictions bien définies. Une équipe de services financiers peut déployer les données des clients européens chez OVHCloud en Allemagne et celles des clients américains sur AWS en Virginie en utilisant le même pipeline. Sans portabilité, ça ferait deux pipelines, deux jeux de configurations, deux guides d’exploitation. L’exigence de conformité n’a pas changé ; le coût opérationnel a doublé.
2. Planification de la résilience. 
   Répartir les charges de travail entre plusieurs fournisseurs n’est une stratégie de reprise après sinistre pertinente que si ces charges de travail peuvent réellement être déplacées ou basculées. Le modèle de portabilité d’Upsun Cloud permet aux équipes de créer des systèmes de basculement inter-cloud à l’aide de configurations portables et de processus reproductibles. Une organisation qui exécute des charges de travail équivalentes sur Azure et AWS à l’aide d’une plateforme cohérente peut se remettre d’un incident au niveau du fournisseur. Celle qui présente des dépendances profondément ancrées spécifiques à un fournisseur ne le peut pas.

Une équipe dont le pipeline fait référence à des noms de ressources et des points de terminaison spécifiques à AWS ne peut pas basculer vers Azure ; elle peut redéployer, mais il s’agit là d’un projet de migration mené sous pression, pas de résilience. Sans portabilité, le multicloud n’est que de la poudre aux yeux. 

Par où commencer

La portabilité n’est pas une migration ponctuelle. C’est une approche architecturale que les équipes doivent maintenir de manière cohérente. Concrètement, cela signifie :

• Conserver la configuration des applications dans des fichiers YAML sous contrôle de version plutôt que dans les tableaux de bord des fournisseurs.
• Éviter les services gérés sans voie de sortie standard, sauf si le compromis est délibéré et documenté.
• Considérer le choix du fournisseur et de la région comme des décisions opérationnelles, et non architecturales.
• Vérifier que les charges de travail peuvent réellement être déplacées, et ne pas se contenter de supposer qu’elles le peuvent.

L’objectif n’est pas de ne pas s’intégrer du tout aux fournisseurs de cloud. C’est une intégration maîtrisée, où le coût du déplacement est suffisamment bas pour que le choix du fournisseur reste un véritable choix.

Foire aux questions (FAQ)

Quelle est la différence entre la portabilité cloud et le multicloud ?

Le multicloud, c’est exécuter des charges de travail chez plusieurs fournisseurs. La portabilité cloud, c’est la possibilité de déplacer des charges de travail d’un fournisseur à l’autre sans avoir à reconstruire les pipelines ni à réécrire les configurations. Une équipe peut être multicloud tout en étant complètement prisonnière d’un fournisseur. La portabilité, c’est une question de facilité de déplacement, pas de nombre de fournisseurs.

Qu’est-ce qu’une infrastructure portable dans le cloud implique concrètement ?

Quatre conditions doivent être remplies : la configuration de déploiement se trouve dans des fichiers sous contrôle de version plutôt que dans le tableau de bord d’un fournisseur ; ton pipeline décrit ce dont l’application a besoin, pas où elle s’exécute ; la sélection du fournisseur et de la région est gérée au niveau de la plateforme ; et les données sont stockées dans des formats pouvant être migrés sans projet sur mesure.

Comment la portabilité cloud facilite-t-elle la conformité aux règles de résidence des données ?

Sans portabilité, respecter des réglementations comme le RGPD dans différentes régions implique généralement de maintenir des pipelines distincts par zone géographique. Un modèle portable permet aux équipes de déployer chez des fournisseurs spécifiques à une région en utilisant la même configuration et le même processus ; quand la région change, le processus reste le même.

Faut-il créer une plateforme interne pour assurer la portabilité ou en adopter une ?

En la développant toi-même, tu gardes le contrôle, mais ça t’impose une obligation de maintenance permanente. Chaque nouvelle exigence d’un fournisseur devient un projet d’ingénierie, et tes ingénieurs les plus expérimentés finissent par gérer l’infrastructure au lieu de livrer le produit. Une plateforme adoptée absorbe ce coût de par sa conception.