Multi-cloud : stratégie et architecture pour éviter le vendor lock-in

Le multi-cloud en 2024 : chiffres réels et réalité terrain

Selon l'étude Flexera 2024 State of the Cloud, 87 % des entreprises utilisent plusieurs clouds. Pourtant, seulement 23 % déclarent avoir une stratégie multi-cloud délibérée. Les 64 % restants sont ce qu'on appelle le "multi-cloud accidentel" : des clouds différents dans des silos, sans portabilité réelle, sans gouvernance unifiée, souvent héritage d'acquisitions ou de choix d'équipes autonomes.

Ce guide ne plaide pas pour un multi-cloud systématique. Il vous donne un cadre pour décider quand le multi-cloud est justifié, comment l'architecturer intelligemment, et quel est le vrai coût de cette stratégie.

Comprendre le vrai lock-in : ce n'est pas les conteneurs

La croyance répandue est que Kubernetes élimine le lock-in. C'est partiellement faux. Il existe trois niveaux de portabilité, et les entreprises confondent souvent le premier — le plus facile — avec la portabilité réelle :

Niveau 1 : Portabilité des conteneurs (théorique)

Un workload Kubernetes peut théoriquement migrer d'EKS vers GKE vers AKS sans modifier le code applicatif. En pratique, dès que vous utilisez des services managés cloud-specific (AWS RDS, Google AlloyDB, Azure Cosmos DB), vous créez du lock-in au niveau des données — le plus difficile à défaire.

# Portabilité théorique Kubernetes
# Même manifest, trois clouds différents

# Sur AWS EKS
kubectl apply -f deployment.yaml
# kubectl context: eks-prod-eu-west-1

# Sur GKE
kubectl apply -f deployment.yaml
# kubectl context: gke-prod-europe-west1

# Sur OVH MKS
kubectl apply -f deployment.yaml
# kubectl context: ovh-prod-gra7

# En pratique : ça marche... jusqu'à ce que votre app appelle
# aws dynamodb get-item ou google.cloud.firestore.Client()

Niveau 2 : Abstraction des services managés

Le vrai lock-in vient des dépendances aux APIs propriétaires : DynamoDB, Pub/Sub, Azure Service Bus, Cosmos DB. La solution est de placer une couche d'abstraction entre votre code et ces services :

# Couche d'abstraction pour le stockage objet (Python)
from typing import Protocol, BinaryIO

class ObjectStorage(Protocol):
    def upload(self, bucket: str, key: str, data: bytes) -> None: ...
    def download(self, bucket: str, key: str) -> bytes: ...
    def delete(self, bucket: str, key: str) -> None: ...

# Implémentation AWS S3
class S3Storage:
    def __init__(self, client):
        self._s3 = client

    def upload(self, bucket: str, key: str, data: bytes) -> None:
        self._s3.put_object(Bucket=bucket, Key=key, Body=data)

    def download(self, bucket: str, key: str) -> bytes:
        return self._s3.get_object(Bucket=bucket, Key=key)["Body"].read()

# Implémentation OVH / tout provider S3-compatible
class S3CompatibleStorage(S3Storage):
    # OVH Object Storage, MinIO, Cloudflare R2 — même API boto3
    pass

# Implémentation Google Cloud Storage
class GCSStorage:
    def __init__(self, client):
        self._gcs = client

    def upload(self, bucket: str, key: str, data: bytes) -> None:
        self._gcs.bucket(bucket).blob(key).upload_from_string(data)

# Injection de dépendance — changement de cloud sans modifier le code métier
storage: ObjectStorage = S3Storage(boto3.client("s3"))
# ou
storage: ObjectStorage = GCSStorage(storage.Client())

Niveau 3 : Portabilité des données — le vrai verrou

Les frais d'egress réseau sont le mécanisme de lock-in le plus sous-estimé. AWS facture 0,09 $/GB pour les données sortant vers internet. Pour un dataset de 10 TB, une migration représente 900 $ de frais d'egress seuls, avant même de compter le temps de transfert et la complexité de migration. OVH et Cloudflare ne facturent pas l'egress — c'est un argument de souveraineté et de liberté réel.

Anti-patterns : ce qui crée un lock-in irréversible

• Couplage fort aux APIs propriétaires : utiliser DynamoDB (API propriétaire) directement dans le code métier sans couche d'abstraction — migration vers PostgreSQL = réécriture complète de la couche données
• Lambda functions avec triggers AWS-only : une architecture entièrement construite sur Lambda + SQS + DynamoDB + EventBridge est ultra-efficace mais totalement non-portable
• IAM et networking clouds-spécifiques : les Security Groups AWS, les VPC peering, les IAM roles ne s'exportent pas — toute la couche sécurité est à reconstruire lors d'une migration
• Formats de données propriétaires : Parquet sur S3 est portable ; DynamoDB binary format ne l'est pas

Patterns d'abstraction avec Terraform

Terraform avec ses 200+ providers est l'outil le plus efficace pour une IaC multi-cloud. Le pattern de modules réutilisables permet de créer des abstractions qui fonctionnent sur plusieurs clouds :

# Module Terraform cloud-agnostique pour un cluster Kubernetes
# modules/kubernetes-cluster/main.tf

variable "provider" {
  type    = string
  # "aws", "ovh", "gcp", "azure"
}

variable "region" {
  type = string
}

variable "node_count" {
  type    = number
  default = 3
}

# Ressources conditionnelles par provider
resource "aws_eks_cluster" "this" {
  count = var.provider == "aws" ? 1 : 0
  name  = var.cluster_name
  # ...
}

resource "ovh_cloud_project_kube" "this" {
  count        = var.provider == "ovh" ? 1 : 0
  name         = var.cluster_name
  region       = var.region
  # ...
}

# Output unifié — le kubeconfig quelle que soit l'implémentation
output "kubeconfig" {
  value = var.provider == "aws" ? (
    aws_eks_cluster.this[0].certificate_authority[0].data
  ) : (
    ovh_cloud_project_kube.this[0].kubeconfig
  )
  sensitive = true
}

Crossplane : gestion des ressources cloud depuis Kubernetes

Crossplane est une alternative à Terraform qui gère les ressources cloud depuis Kubernetes via des CRDs. C'est particulièrement adapté aux plateformes multi-cloud où l'équipe plateforme veut exposer des abstractions aux développeurs :

# Composite Resource Definition (XRD) Crossplane
# Abstraction d'un bucket de stockage multi-cloud
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xobjectstorages.platform.example.com
spec:
  group: platform.example.com
  names:
    kind: XObjectStorage
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          properties:
            spec:
              properties:
                provider:
                  type: string
                  enum: ["aws", "gcp", "ovh"]
                region:
                  type: string
---
# Le développeur crée un bucket sans savoir quel cloud est utilisé
apiVersion: platform.example.com/v1alpha1
kind: XObjectStorage
metadata:
  name: my-app-storage
spec:
  provider: aws  # Changeable vers "ovh" sans modifier l'app
  region: eu-west-1

Stratégie de souveraineté des données multi-cloud

Un cas d'usage réel et légitime du multi-cloud : la ségrégation des données par géographie réglementaire. Voici l'architecture que nous déployons pour les clients avec des obligations RGPD et des opérations aux États-Unis :

# Plan de contrôle unifié, deux régions cloud
# terraform/environments/multi-region.tf

# Données UE → OVH Public Cloud (souveraineté européenne)
module "eu_cluster" {
  source     = "./modules/kubernetes-cluster"
  provider   = "ovh"
  region     = "GRA7"
  node_count = 3
}

# Données US → AWS (écosystème, performance)
module "us_cluster" {
  source     = "./modules/kubernetes-cluster"
  provider   = "aws"
  region     = "us-east-1"
  node_count = 3
}

# Même application déployée sur les deux clusters
# via ArgoCD ApplicationSet
module "app_eu" {
  source     = "./modules/helm-release"
  kubeconfig = module.eu_cluster.kubeconfig
  chart      = "./charts/my-app"
  values = {
    database_region = "eu"
    data_residency  = "EU"
  }
}

module "app_us" {
  source     = "./modules/helm-release"
  kubeconfig = module.us_cluster.kubeconfig
  chart      = "./charts/my-app"
  values = {
    database_region = "us"
    data_residency  = "US"
  }
}

Outillage multi-cloud indispensable

• Terraform + Terraform Cloud : IaC multi-provider avec state centralisé, drift detection et politique d'approbation
• Datadog : monitoring unifié pour AWS, GCP, Azure, OVH — une seule console de métriques, logs et traces
• HashiCorp Vault : gestion des secrets cloud-agnostique, compatible avec les providers AWS/GCP/Azure/Kubernetes
• ArgoCD + ApplicationSet : déploiement GitOps sur plusieurs clusters Kubernetes, quel que soit le cloud sous-jacent
• Crossplane : abstraire les ressources cloud derrière des CRDs Kubernetes pour les équipes plateforme

Le vrai coût du multi-cloud : 20-30 % d'overhead opérationnel

Soyons directs : le multi-cloud a un coût réel. D'après notre expérience et les analyses sectorielles, gérer une infrastructure multi-cloud représente 20 à 30 % d'overhead opérationnel supplémentaire par rapport à un single-cloud bien optimisé. Ce coût se répartit entre :

• Formation et maintien des compétences sur plusieurs plateformes
• Complexité de la gestion des identités (IAM AWS + IAM GCP + RBAC Kubernetes + ...)
• Outillage supplémentaire (monitoring unifié, cost management multi-cloud)
• Complexité réseau (inter-cloud latency, VPN/peering, frais de transfert)
• Cycles de revue de sécurité plus longs (deux surfaces d'attaque à auditer)

Cadre de décision : quand choisir le multi-cloud ?

Notre recommandation est claire : single cloud par défaut, multi-cloud uniquement si une raison spécifique le justifie. Les raisons légitimes sont :

• Réglementaire : données UE sur OVH/AWS eu-west, données US sur AWS us-east — obligations légales non-négociables
• Résilience : pour les applications critiques où la défaillance d'un cloud entier est inacceptable (rarissime en pratique — les providers ont un SLA >99,99 %)
• Levier commercial : négociation de tarifs avec des fournisseurs cloud en jouant la concurrence — efficace lors des renouvellements d'Enterprise Agreement
• M&A : acquisition d'une entreprise sur un cloud différent — migration progressive plus rentable que migration brutale

Conclusion

Le multi-cloud n'est pas une fin en soi — c'est un outil stratégique qui a un coût opérationnel réel. La grande majorité des entreprises tirerait plus de valeur d'un single-cloud bien optimisé (Savings Plans, Reserved Instances, architecture bien dimensionnée) que d'une stratégie multi-cloud mal exécutée. Si le multi-cloud s'impose pour des raisons réglementaires ou de résilience, investissez d'abord dans la portabilité de la couche données — c'est elle le vrai verrou. Kubernetes + Terraform + Helm vous donneront ensuite la portabilité applicative à moindre coût.