Well-Architected chez OVHcloud : adapter les six piliers à un cloud européen

Pourquoi un Well-Architected « version OVHcloud » ?

Le Well-Architected Framework a été popularisé par AWS, puis décliné par Azure et Google. Mais les piliers — excellence opérationnelle, sécurité, fiabilité, performance, optimisation des coûts, durabilité — n'appartiennent à personne. Ce sont une grille de lecture. Ce qui change d'un fournisseur à l'autre, ce sont les briques disponibles et l'endroit exact où passe la frontière de responsabilité partagée.

Chez OVHcloud, deux différences structurent toute la démarche. D'abord, le catalogue managé est volontairement plus resserré que celui d'un hyperscaler : pas de WAF managé greffé sur chaque load balancer, pas de suite d'observabilité à vingt services, pas de bus d'événements clé en main. Une plus grande part de la plateforme est à construire et à exploiter — ce qui donne mécaniquement plus de poids aux piliers excellence opérationnelle et fiabilité. Ensuite, le modèle économique et la posture de souveraineté sont réellement différents : le trafic sortant est inclus dans la plupart des régions, le vRack relie datacentres et régions en réseau privé, et un périmètre qualifié SecNumCloud existe pour les charges qui l'exigent. Des choix d'architecture financièrement douloureux ailleurs — réplication inter-région, topologies hybrides bavardes, seconde copie de la donnée sur un autre site — deviennent ici naturels.

Une revue Well-Architected sur OVHcloud n'est donc pas un copier-coller du questionnaire AWS. Ce sont les mêmes questions, répondues avec une carte différente.

Excellence opérationnelle : tout par l'API, rien par le manager

L'espace client OVHcloud est très bien pour explorer, et catastrophique pour la reproductibilité. Le socle minimal d'une plateforme sérieuse, c'est Terraform avec deux providers côte à côte : le provider ovh pour les ressources de niveau compte et services managés (projets Public Cloud, Managed Kubernetes, bases managées, politiques IAM, Private Registry) et le provider openstack pour les primitives bas niveau exposées par Public Cloud (instances, volumes, security groups, load balancers Octavia).

Un détail pratique qui bloque beaucoup d'équipes : il n'existe pas d'équivalent DynamoDB pour le verrouillage du state. Terraform supportant désormais le lock natif par fichier sur S3, vous pouvez héberger le state dans l'Object Storage OVHcloud (compatible S3) et obtenir le verrouillage sans composant externe :

terraform {
  backend "s3" {
    bucket   = "tfstate-platform-prod"
    key      = "platform/terraform.tfstate"
    region   = "gra"
    endpoints = { s3 = "https://s3.gra.io.cloud.ovh.net" }

    use_lockfile                = true
    skip_credentials_validation = true
    skip_requesting_account_id  = true
    skip_region_validation      = true
    skip_s3_checksum            = true
  }
}

Les autres leviers d'excellence opérationnelle à auditer :

• Un projet Public Cloud par environnement. Le projet est une frontière d'isolation forte (tenant Keystone distinct, quotas distincts, ligne de facturation distincte). C'est un bien meilleur contrôle de rayon d'impact que n'importe quelle policy que vous écrirez.
• Politique de mise à jour MKS assumée. Managed Kubernetes expose une stratégie de mise à jour par cluster : choisissez-la explicitement et documentez-la, plutôt que de découvrir une montée de version du control plane un vendredi soir. Idem pour les node pools : rolling update avec nœud supplémentaire plutôt que redémarrage en place.
• GitOps pour tout ce qui vit au-dessus du cluster. Argo CD ou Flux sur MKS, images dans le Managed Private Registry (Harbor) pour que le scan de vulnérabilités et les politiques de rétention vivent au même endroit que la supply chain.
• Les quotas sont un sujet d'architecture. Les quotas Public Cloud (instances, vCPU, volumes, IP flottantes, load balancers) sont par projet et par région, et bas par défaut. Une revue doit poser la question : « ce projet peut-il réellement atteindre sa taille cible aujourd'hui ? » La réponse est souvent non, et un relèvement de quota prend du temps.

Sécurité et souveraineté : IAM large, isolation réseau forte

L'IAM OVHcloud a beaucoup progressé — identités, groupes de ressources, policies avec actions et conditions — mais il reste moins granulaire qu'IAM chez AWS. N'architecturez pas en supposant que chaque nuance de moindre privilège s'exprimera dans un document de policy. Architecturez par l'isolation : projets Public Cloud séparés, credentials S3 distincts par bucket et par usage, clés d'application API distinctes par pipeline d'automatisation, restreintes et tournées régulièrement.

Côté réseau, OVHcloud offre plus que ce que la plupart des équipes utilisent. Le vRack est un réseau privé de niveau 2 qui traverse datacentres et régions : c'est la colle des architectures hybrides. Serveurs de base de données ou nœuds GPU en bare metal d'un côté, instances Public Cloud et workers MKS élastiques de l'autre, le tout en adressage privé. Combiné à un réseau privé Public Cloud, une gateway pour le SNAT sortant et des clusters MKS dont les workers n'ont pas d'IP publique, on obtient une topologie où rien n'est exposé sauf les load balancers déclarés explicitement.

Les points qui ressortent de presque toutes les revues : l'anti-DDoS est inclus mais ce n'est pas un WAF — placez un vrai WAF devant le HTTP public (au niveau Ingress ou appliance dédiée) ; le chiffrement au repos doit être explicite (chiffrement des bases managées, clés adossées au KMS, ou Vault opéré sur MKS) ; le MFA doit être imposé sur toutes les identités du manager ; et en secteur régulé, soyez précis sur l'offre qui porte réellement la qualification attendue — SecNumCloud et HDS couvrent des périmètres identifiés, pas l'intégralité du catalogue par défaut.

Fiabilité : savez-vous lesquelles de vos régions sont multi-AZ ?

C'est la plus grosse source de fausses hypothèses sur OVHcloud. La majorité des régions historiques sont mono-datacentre ; la région parisienne a introduit de véritables zones de disponibilité pour Public Cloud. Si votre production tourne dans une région mono-AZ, « haute disponibilité » signifie trois instances dans le même bâtiment, et votre vraie résilience se joue sur une seconde région.

Deux schémas viables, à choisir consciemment :

1. Multi-AZ dans la région 3-AZ. Un node pool par zone, anti-affinité via topology spread constraints, bases managées avec réplicas répartis, load balancers Octavia en frontal. Latence faible, bascule simple.
2. Actif/passif sur deux régions via vRack. Réplication asynchrone de la base, object storage répliqué par un job planifié, infrastructure décrite une fois en Terraform et instanciée deux fois avec une variable de région. RTO plus long, mais survit à la perte d'un site entier — et comme le trafic sortant est inclus, la réplication continue ne détruit pas le budget.

resource "ovh_cloud_project_kube" "prod" {
  service_name = var.project_id
  name         = "prod-par"
  region       = "EU-WEST-PAR"
  version      = "1.31"
}

resource "ovh_cloud_project_kube_nodepool" "workers" {
  for_each = toset(["eu-west-par-a", "eu-west-par-b", "eu-west-par-c"])

  service_name       = var.project_id
  kube_id            = ovh_cloud_project_kube.prod.id
  name               = "workers-${substr(each.key, -1, 1)}"
  flavor_name        = "b3-16"
  availability_zones = [each.key]
  autoscale          = true
  desired_nodes      = 2
  min_nodes          = 2
  max_nodes          = 8
}

Et le rappel éternel : un snapshot de volume stocké dans la même région n'est pas une sauvegarde. Exportez vers l'object storage, idéalement dans une autre région, et planifiez un exercice de restauration. Une revue qui ne demande pas la date de la dernière restauration réussie est un exercice de documentation, pas un audit.

Performance : la bonne forme, pas la plus grosse

Les familles d'instances Public Cloud se mappent proprement aux profils de charge : équilibrée (b3), orientée CPU (c3), orientée mémoire (r3), NVMe local pour les bases gourmandes en IOPS, familles GPU pour l'entraînement et l'inférence. Le stockage bloc propose plusieurs niveaux de performance, et l'object storage distingue un tier haute performance adossé NVMe, un tier standard et un archivage froid. L'essentiel des surcoûts et des plaintes de latence vient de là : une application sur du bloc classique alors qu'elle réclame du NVMe, ou une stack Prometheus/Loki qui écrit dans la mauvaise classe d'object storage.

La carte hybride mérite d'être jouée. Un PostgreSQL à charge stable ou une flotte GPU d'entraînement en permanence occupée sont souvent nettement plus rapides et moins chers sur du bare metal dédié raccordé en vRack, pendant que la couche stateless reste élastique sur MKS. C'est une architecture que les équipes formées chez les hyperscalers n'envisagent presque jamais, et c'est l'une des vraies forces d'OVHcloud.

Pour l'observabilité, le choix est réel : Logs Data Platform (Graylog/OpenSearch managés) et Metrics Data Platform quand vous voulez un stockage managé, souverain, conforme en rétention et sans charge d'exploitation ; ou une stack Prometheus/Mimir/Loki/Grafana auto-hébergée sur MKS avec l'object storage en backend long terme quand vous voulez la flexibilité maximale et la maîtrise du coût. Notre recommandation par défaut : auto-héberger métriques et traces sur MKS avec object storage compatible S3, et réserver la plateforme managée aux logs lorsque la conformité impose une rétention longue et une chaîne de preuve que vous ne voulez pas exploiter vous-même.

Optimisation des coûts : d'autres leviers que chez les hyperscalers

Le tagging étant moins central que chez AWS, le découpage « un projet par application et par environnement » est aussi votre modèle FinOps. Concevez-le ainsi dès le premier jour : rattraper l'allocation des coûts après coup est toujours douloureux.

Durabilité : un pilier où le fournisseur vous aide

Le modèle industriel d'OVHcloud — watercooling conçu en interne, cycles de réemploi matériel longs, récupération de chaleur sur certains sites, datacentres européens raccordés à des réseaux électriques relativement décarbonés — offre un meilleur point de départ que la moyenne. Mais ces gains sont ceux de l'infrastructure : votre score sur ce pilier dépend de ce que vous y faites tourner. Éteignez les environnements hors production la nuit et le week-end, utilisez franchement le cluster autoscaler, dimensionnez sur des métriques réelles et non sur le ticket qui demandait « 8 vCPU par sécurité », et préférez un petit nombre de nœuds bien remplis à une nuée de machines à moitié inactives. Choisissez la région au mix électrique le plus propre quand la latence le permet.

Mener la revue en pratique

Une session Well-Architected utile sur OVHcloud dure une demi-journée par domaine applicatif et produit un backlog priorisé, pas un jeu de slides. Notre checklist de travail : toutes les ressources sont-elles en Terraform avec un state distant verrouillé ? Y a-t-il un projet par environnement ? Les workers MKS sont-ils dépourvus d'IP publique et derrière une gateway ? La région est-elle mono-AZ, et l'équipe le sait-elle ? Quand a eu lieu la dernière restauration testée ? Les quotas sont-ils dimensionnés pour les douze prochains mois ? Les clés API sont-elles cloisonnées et tournées ? Quelle offre porte réellement la qualification que le contrat suppose ? Quelles charges tournent 24/7 sans engagement ? Quel est le coût par environnement — et savez-vous seulement répondre aujourd'hui ?

Neuf constats sur dix tombent dans trois catégories : une résilience supposée mais jamais testée, une isolation supposée mais implémentée dans un unique projet partagé, et des coûts supposés optimisés parce que le fournisseur est réputé peu cher. La valeur du framework n'est pas dans ses piliers : elle est dans la discipline de poser les questions gênantes avant que l'incident ne les pose à votre place.