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 n’est pas la même chose que pouvoir les déplacer librement entre eux. La portabilité concerne la facilité de déplacement, pas le nombre de fournisseurs utilisés.

La plupart des équipes qui se qualifient de « 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 son ensemble de 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 signifie que tes applications, services et 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 difficile qu’il n’y paraît

À retenir : la dépendance n’est généralement pas le résultat d’une seule décision. Elle s’accumule progressivement. Chaque intégration spécifique à un fournisseur ajoute des frictions à 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 la 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 au fournisseur.
• Les données stockées dans des formats propriétaires ou 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 en matière d'enfermement propriétaire parmi les décideurs informatiques.

Une enquête menée en 2026 auprès de 540 professionnels de l'informatique a révélé que 94 % des organisations s'inquiètent de l'enfermement propriétaire, 84 % d'entre elles étant 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 les hypothèses des fournisseurs 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 décisions spécifiques au fournisseur.

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

À retenir : une infrastructure portable signifie que 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, et non une dépendance.

La portabilité exige que la configuration de ton infrastructure soit écrite sous une forme qui accompagne ton code plutôt que d'être liée au framework, à la console ou à l'interface 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 sous 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 aux fournisseurs, afin que l'équipe n'ait pas à maintenir une expertise distincte pour chaque cloud.
4. Des contrôles de résidence des données sans fragmentation du 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'Upsun utilise 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 se déploie 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.

Cela signifie également que tes ingénieurs n’ont besoin de comprendre 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 cela 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 certain fournisseur de cloud. Ils configurent l'application une seule fois et choisissent le fournisseur et la région de manière indépendante.

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

Conclusion : 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 telles que le RGPD en Europe exigent que certaines catégories de données soient stockées et traitées dans des juridictions définies. Une équipe de services financiers peut déployer les données des clients européens sur OVHCloud en Allemagne et les données américaines sur AWS en Virginie en utilisant le même pipeline. Sans portabilité, cela impliquerait deux pipelines, deux ensembles de configurations, deux guides opérationnels. L’exigence de conformité n’a pas changé ; le coût opérationnel a doublé.
2. Planification de la résilience.
   La répartition des 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 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. Une organisation qui a 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 d’un projet de migration 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 posture architecturale que les équipes doivent maintenir de manière cohérente. Concrètement, cela signifie :

• Conserver la configuration des applications dans un fichier 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 une intégration zéro avec les fournisseurs de cloud. C'est une intégration contrôlé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 consiste à exécuter des charges de travail chez plusieurs fournisseurs. La portabilité du cloud signifie que les charges de travail peuvent passer 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 verrouillée chez un fournisseur. La portabilité concerne la facilité de déplacement, pas le 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 réside 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, et non 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é en matière 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 ; lorsque la région change, le processus reste le même.

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

La création d’une plateforme interne te donne le contrôle, mais entraîne une obligation de maintenance permanente. Chaque nouvelle exigence des fournisseurs 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.