FinOps sur OVHcloud : modèle tarifaire, egress et leviers concrets d'optimisation

Pourquoi OVHcloud rebat les cartes du FinOps

La plupart des méthodologies FinOps ont été écrites pour AWS, Azure et GCP. Elles optimisent trois choses : les engagements de compute, le tiering du stockage, et les frais de sortie réseau. Sur OVHcloud, le troisième pilier disparaît en grande partie — et cette différence structurelle réordonne toute la liste des priorités d'optimisation.

Le positionnement commercial d'OVHcloud est de longue date celui de la bande passante incluse : sur les instances Public Cloud en régions européennes et nord-américaines, le trafic sortant public n'est pas facturé au gigaoctet. Vous payez une capacité de bande passante garantie liée au gabarit de l'instance, pas le volume que vous poussez. Conséquence directe : des architectures financièrement punies chez un hyperscaler — streaming, diffusion de médias, distribution de gros jeux de données, réplication inter-régions bavarde, exports vers des partenaires — redeviennent économiquement tenables sans contorsions.

Cela ne veut pas dire que le FinOps sur OVHcloud est trivial. Cela veut dire que les leviers sont ailleurs : stockage bloc facturé au provisionné et non au consommé, instances oubliées allumées, node pools Kubernetes surdimensionnés, snapshots orphelins, et l'éternel arbitrage bare metal contre Public Cloud. Cet article détaille le modèle tarifaire, ce qui est réellement inclus côté egress, et les actions concrètes qui font bouger la facture.

Le modèle tarifaire OVHcloud en cinq dimensions

Une facture Public Cloud se décompose en un petit nombre de lignes. Savoir lesquelles sont élastiques et lesquelles sont structurelles est la première étape.

Deux points méritent d'être soulignés. D'abord, le plan de contrôle du Managed Kubernetes est fourni sans surcoût : vous payez les nœuds workers, leurs volumes, les load balancers et le stockage. Ensuite, le stockage bloc est facturé sur ce que vous provisionnez, pas sur ce que le système de fichiers utilise réellement. Un volume de 500 Go qui contient 40 Go coûte le prix de 500 Go, tous les mois, indéfiniment. C'est de loin la source de gaspillage silencieux la plus fréquente dans nos audits.

Egress : ce qui est réellement inclus, et les exceptions

Le discours « pas de frais de sortie » est globalement exact sur le Public Cloud OVHcloud, mais un praticien FinOps doit en connaître les bornes :

• Instances en régions européennes et nord-américaines : le trafic sortant public n'est pas compté. La contrainte est la capacité de bande passante (débits garanti et en burst selon le gabarit), pas le volume.
• Régions Asie-Pacifique : historiquement traitées différemment, avec un trafic sortant facturé. Si vous exploitez une empreinte multi-régions, vérifiez la grille en vigueur région par région avant de supposer une parité.
• Stockage objet : la politique dépend de la classe. Les classes standard sont positionnées avec le trafic inclus, tandis que les tiers froids/archive portent des coûts de restitution volontairement asymétriques — peu cher à stocker, cher à relire. Traitez le froid comme une assurance, jamais comme un jeu de données actif.
• Réseau privé vRack : le trafic entre vos propres ressources sur le backbone privé n'est pas facturé, ce qui rend les architectures hybrides (bare metal + Public Cloud + bases dédiées sur le même vRack) financièrement très propres.

Stratégiquement, l'enjeu dépasse la facture. Le Data Act européen supprime progressivement les frais de transfert et de changement de fournisseur, poussant les hyperscalers vers le modèle qu'OVHcloud applique déjà. Pour une organisation qui construit une stratégie de réversibilité ou une posture multi-cloud, un fournisseur dont la tarification ne pénalise pas la sortie des données retire un argument structurel de verrouillage.

Observer avant d'optimiser : l'API de consommation

On n'optimise pas une facture qu'on ne voit qu'une fois par mois en PDF. OVHcloud expose la consommation via son API publique, avec des vues courante, historique et prévisionnelle par projet Public Cloud. Branchez cela sur votre stack d'observabilité plutôt que de dépendre du manager.

# Consommation du mois en cours pour un projet
GET /cloud/project/{serviceName}/usage/current

# Historique (tendance et saisonnalité)
GET /cloud/project/{serviceName}/usage/history?from=2025-01-01&to=2025-06-30

# Prévision pour le mois en cours
GET /cloud/project/{serviceName}/usage/forecast

La réponse détaille par type de ressource (instance, volume, snapshot, stockage objet, bande passante le cas échéant) avec les identifiants de chaque ressource. Déversez cela quotidiennement dans un entrepôt colonne ou un exporter Prometheus, et vous obtenez un showback sans acheter de plateforme tierce. La décision de conception en amont est déterminante : utilisez les projets Public Cloud comme frontière d'allocation des coûts. Un projet par couple équipe/environnement est infiniment plus exploitable qu'un projet géant partagé par cinquante personnes, parce que le projet est l'unité naturelle d'agrégation de la facture.

Compute : le mode de facturation est un levier, pas un détail

OVHcloud propose la facturation horaire, la facturation mensuelle et des savings plans avec engagement. L'arbitrage est mécanique :

• Horaire pour tout ce qui est éphémère : runners CI, environnements de preview, jobs batch, flottes de tests de charge. À combiner avec Terraform pour que les environnements soient réellement détruits, pas seulement arrêtés : une instance éteinte continue de facturer ses volumes attachés.
• Mensuel pour tout ce qui tourne en continu — le prix unitaire est nettement inférieur et le coût opérationnel du basculement est quasi nul.
• Savings plans pour le socle stable sur lequel vous êtes confiant à un ou trois ans. Dimensionnez l'engagement sur votre plancher, pas sur votre moyenne ; couvrez les pics en horaire.

Sur le choix des gabarits, ne partez pas par défaut sur du généraliste. Les gammes OVHcloud sont différenciées pour de bonnes raisons : instances discovery pour le dev et les tests, généralistes pour les tiers web, CPU-optimisées pour les services calculatoires, RAM-optimisées pour les caches et l'analytique en mémoire, GPU pour l'inférence et l'entraînement. Choisir un gabarit RAM-optimisé pour une API stateless avec 2 Go de working set est une erreur aussi récurrente que coûteuse.

Kubernetes managé : les pièges spécifiques

Un plan de contrôle gratuit est attrayant, mais la réalité du coût se joue dans les node pools. Trois schémas dominent nos constats :

1. Des node pools qui ne redescendent jamais. Activez l'autoscaling avec un minimum réaliste et laissez le cluster autoscaler faire son travail. Des PodDisruptionBudgets trop stricts ou des DaemonSets sans tolérations adéquates bloquent silencieusement le scale-down.

resource "ovh_cloud_project_kube_nodepool" "workers" {
  service_name  = var.project_id
  kube_id       = ovh_cloud_project_kube.cluster.id
  name          = "workers-b3"
  flavor_name   = "b3-8"
  autoscale     = true
  desired_nodes = 3
  min_nodes     = 2
  max_nodes     = 10

  template {
    metadata { labels = { "workload" = "general" } }
    spec     { unschedulable = false }
  }
}

2. Des requests très au-dessus de l'usage réel. L'autoscaler planifie sur les requests, pas sur la consommation. Si chaque équipe demande 2 CPU « pour être tranquille » sur des charges qui consomment 150m, vous payez environ treize fois le compute nécessaire. Déployez un VPA en mode recommandation, ou faites tourner OpenCost dans le cluster pour produire un showback par namespace et confronter les équipes à leurs propres chiffres.

3. Un load balancer par service. Chaque LB public et chaque IP publique additionnelle est une ligne facturée. Consolidez derrière un ingress controller unique et routez par nom d'hôte.

Stockage : cycle de vie et chasse aux orphelins

Le stockage objet OVHcloud est compatible S3 : l'outillage et la sémantique de cycle de vie standard s'appliquent. Deux règles se remboursent immédiatement : expirer ou transitionner les objets anciens, et avorter les uploads multipart incomplets — ces fragments d'uploads échoués sont invisibles dans la plupart des consoles mais intégralement facturés.

<LifecycleConfiguration>
  <Rule>
    <ID>abort-incomplete-mpu</ID>
    <Status>Enabled</Status>
    <Filter><Prefix></Prefix></Filter>
    <AbortIncompleteMultipartUpload>
      <DaysAfterInitiation>7</DaysAfterInitiation>
    </AbortIncompleteMultipartUpload>
  </Rule>
  <Rule>
    <ID>expire-build-artifacts</ID>
    <Status>Enabled</Status>
    <Filter><Prefix>ci/artifacts/</Prefix></Filter>
    <Expiration><Days>30</Days></Expiration>
  </Rule>
</LifecycleConfiguration>

Côté stockage bloc, instaurez une réconciliation mensuelle : lister les volumes sans attachement, lister les snapshots au-delà de la rétention définie, et comparer la taille provisionnée à l'usage réel du système de fichiers. Un script court contre l'API OpenStack, planifié dans votre CI, transforme cette bonne intention en contrôle.

Bare metal contre Public Cloud : l'arbitrage qu'on évite de faire

C'est ici qu'OVHcloud diffère le plus d'une stratégie purement hyperscaler. Pour des charges à socle stable et prévisible — une base de production, un cluster Kafka, un data plane Kubernetes auto-géré, un back end de stockage — les serveurs dédiés offrent généralement un coût par cœur et par gigaoctet de RAM bien plus favorable que des instances virtualisées équivalentes, avec du NVMe local inclus plutôt que facturé en stockage réseau.

L'architecture pragmatique est hybride : du dédié pour le socle stable, du Public Cloud pour l'élasticité et tout ce qui doit scaler en minutes, les deux réunis sur le même vRack pour que le trafic inter-composants reste privé et non facturé. Le compromis est réel : vous reprenez la responsabilité opérationnelle de la couche bare metal, le provisioning se compte en minutes plutôt qu'en secondes, et il faut une stratégie crédible de domaines de panne. Prenez cette décision explicitement, chiffres à l'appui, plutôt que par défaut.

Une routine FinOps mensuelle qui tient dans la durée

Un outillage sans cadence produit des dashboards que personne n'ouvre. Un rythme soutenable :

• Hebdomadaire, automatisé : détection des orphelins (volumes détachés, IP flottantes inutilisées, LB inactifs, snapshots hors rétention) avec un rapport poussé dans le canal de l'équipe propriétaire.
• Mensuel, humain : revue des dix premières lignes de coût par projet, comparaison au mois précédent, et explication exigée pour tout écart au-delà d'un seuil convenu.
• Trimestriel, stratégique : réexamen de la couverture d'engagement face au plancher réel, réévaluation de l'arbitrage bare metal / Public Cloud sur les deux ou trois charges les plus lourdes, et vérification que la répartition des classes de stockage correspond toujours aux usages.

Ce qu'il faut retenir

Le FinOps sur OVHcloud n'est pas du FinOps hyperscaler à prix différents. Parce que l'egress public est inclus sur les principales régions européennes, l'énergie d'optimisation qui part ailleurs en gymnastique de transfert de données peut être redirigée là où l'argent se trouve vraiment : right-sizing du compute, mode de facturation, stockage bloc provisionné, requests Kubernetes et arbitrage bare metal. Construisez l'allocation par projet dès le premier jour, automatisez l'API de consommation dans votre observabilité, et traitez les ressources orphelines comme un contrôle et non comme une corvée de nettoyage. Les gains sont peu spectaculaires, reproductibles et substantiels.