Votre facture cloud augmente plus vite que votre ARR — c'est le signe qu'il faut agir
Un SaaS en phase scale qui ne pratique pas le FinOps dépense souvent plus que nécessaire sur son infrastructure cloud. Right-sizing Kubernetes, Reserved Instances, migration sélective vers OVHcloud : Nehos audite, priorise et exécute les optimisations — sans dégrader vos SLA ni votre expérience utilisateur.
Nos clients types
La phase de scale d'un SaaS B2B est caractérisée par une acceleration de la croissance du nombre de clients et du volume de données traitées — et une acceleration tout aussi rapide des coûts d'infrastructure. Ce qui était une facture AWS raisonnable à la Série A devient bien plus lourde à la Série B, puis encore davantage deux ans plus tard. Pendant ce temps, l'ARR a peut-être triple — mais les marges brutes se dégradent, et les investisseurs commencent à poser des questions. Le problème de fond est structural : les equipes engineering en phase de croissance rapide priorisent la livraison de fonctionnalités sur l'optimisation de l'infrastructure. C'est un choix rationnel à court terme. Mais ses consequences s'accumulent : les requests et limits Kubernetes sont fixes une fois en debut de projet et ne sont jamais revus (il est fréquent de trouver des pods qui consomment une petite part des ressources qui leur sont allouées), les instances RDS et ElastiCache sont laissées en On-Demand par défaut (un EC2 en Reserved Instance 1 an no-upfront est moins cher), les environnements de staging et de preprod utilisent les mêmes tailles d'instances que la production. Le manque de visibilité est le second problème majeur. Sans tagging systématique des ressources AWS par service, par equipe et par environnement, il est impossible d'attribuer les coûts a des responsables et d'identifier les postes qui dérivent. Le Cost Explorer AWS fournit des données, mais elles sont inexploitables sans une taxonomie de tags cohérente. Beaucoup de SaaS en phase scale ont une grande partie de leurs ressources mal taguées — ce qui range une part importante de la facture dans une catégorie 'Untagged' inutilisable pour l'analyse. Le troisième problème est le gaspillage sur les environnements non-production. Les environnements de développement, de staging et de preprod représentent une part importante de la facture cloud d'un SaaS en phase scale. La majorité de ces environnements tournent 24h/24, 7j/7, alors qu'ils ne sont utilises que pendant les heures de travail. Des politiques de shutdown automatique la nuit et le week-end (Lambda Scheduler, Kubernetes CronJob de scale-down) peuvent réduire fortement ces coûts sans impacter la productivité. Le quatrième problème est la facture de transfert de données (egress costs). Sur AWS, les transferts de données sortants (vers Internet ou vers d'autres regions) sont facturés au Go, selon la grille tarifaire d'AWS. Pour un SaaS qui transfere plusieurs TB de données par mois entre des services dans des régions différentes, ou vers ses clients via une API haute-fréquence, ces coûts de transfert peuvent représenter une part significative de la facture totale. Une revue de l'architecture de distribution des données (CDN, architecture mono-region, optimisation des requêtes) peut réduire ces coûts significativement. Enfin, le stockage est systématiquement sous-optimise. S3 sans politique Intelligent-Tiering accumule des données en Standard tier dont la majorité n'est pas accedee depuis des mois. Les snapshots EBS orphelins (de volumes supprimes dont les snapshots n'ont pas été nettoyés) représentent des coûts invisibles mais persistants. Les bases de données RDS sans snapshot lifecycle policy accumulent des snapshots indéfiniment.
La méthode FinOps Nehos pour les SaaS en phase scale suit un principe simple : auditer d'abord, optimiser ensuite, dans l'ordre de l'impact rapide. Les quick wins qui libèrent des économies en quelques semaines financent le reste du programme.
L'audit commence par l'activation et la configuration du Cost Explorer AWS (ou GCP Billing Analysis, selon le cloud utilisé) avec une taxonomie de tags standardisée : service, environment (production/staging/dev), team, tenant_id (pour le billing par tenant). Ce travail de tagging — souvent resiste par les equipes engineering qui le perçoivent comme du admin overhead — est le prérequis de toute analyse pertinente. Sans tagging, on ne sait pas ou va l'argent. Avec le tagging, on identifie immédiatement les services et les equipes qui dérivent.
Le right-sizing Kubernetes est systématiquement le poste d'economies le plus important — et le plus sous-exploite. Nehos déploie Goldilocks (outil open-source de Fairwinds) sur le cluster pour analyser la consommation réelle de CPU et memory de chaque pod vs les requests/limits configures. Il est courant de trouver des pods dont les requests CPU sont très supérieures à la consommation réelle — une sur-allocation importante. Ajuster les requests/limits a 120-150 % de la consommation réelle (pour garder une marge de sécurité) permet souvent de réduire sensiblement le nombre de nodes Kubernetes — ce qui se traduit directement sur la facture EC2. Karpenter (AWS) ou le Cluster Autoscaler est configure pour le scaling dynamique, et les Spot Instances sont activées pour les workloads tolérants aux interruptions (jobs batch, workers asynchrones).
Les Reserved Instances (ou Savings Plans — plus flexibles) sur AWS sont négociées pour tous les workloads stables en production : instances EC2, RDS, ElastiCache, OpenSearch. Un Savings Plan Compute offre une réduction significative par rapport à l'On-Demand, d'autant plus forte que l'engagement est long (voir la grille tarifaire officielle d'AWS). Passer en Savings Plans 1 an no-upfront représente une économie récurrente sans investissement initial.
La migration selective vers OVHcloud adresse les workloads pour lesquels AWS est structurellement plus cher que nécessaire : les environnements de staging et de preprod, les workloads batch intensifs, le stockage objet (Object Storage OVHcloud est généralement moins cher que S3 pour les mêmes volumes, à vérifier sur les grilles tarifaires), les bases de données de développement. OVHcloud propose des instances Kubernetes (Managed Kubernetes) et des instances de base de données (Managed Databases — compatible Postgres, MySQL, Redis) dont le rapport performance/prix est significativement plus favorable qu'AWS pour les workloads prévisibles. La migration est préparée avec Terraform (infrastructure-as-code) et exécutée avec zero-downtime via un DNS cutover progressif.
Le tableau de bord FinOps continu — livre en fin de mission — expose en temps réel les coûts par service, par environnement et par tenant, avec des alertes sur les anomalies (pic de coûts inhabituel, dépassement de budget par service). Il est heberge sur Grafana (avec source de données AWS Cost Explorer API) ou sur un outil FinOps specialise (CloudHealth, Apptio Cloudability, ou la plateforme FinOps OVHcloud). Des alertes Slack ou PagerDuty sont configurées pour notifier le CTO et le CFO quand un service depasse son budget mensuel de 20 %.
À mesurer
évolution de la facture cloud mensuelle sur quelques mois, avec right-sizing Kubernetes, Reserved Instances et migration des environnements non critiques
À mesurer
réduction du nombre de nodes Kubernetes après right-sizing des requests/limits (Goldilocks), sans dégradation de la latence p99 ni du taux de disponibilité
À mesurer
réduction des coûts EC2 en passant d'On-Demand à des Savings Plans Compute, sans changement architectural
À mesurer
part de la facture cloud représentée par les environnements de staging et de preprod, avant et après les politiques de shutdown automatique
#Le problème : pourquoi optimisation coûts infra saas est un enjeu critique
Situation typique : La phase de scale d'un SaaS B2B est caractérisée par une acceleration de la croissance du nombre de clients et du volume de données traitées — et une acceleration tout aussi rapide des coûts d'infrastructure. Ce qui était une facture AWS raisonnable à la Série A devient bien plus lourde à la Série B, puis encore davantage deux ans plus tard.
Pendant ce temps, l'ARR a peut-être triple — mais les marges brutes se dégradent, et les investisseurs commencent à poser des questions.
Le problème de fond est structural : les equipes engineering en phase de croissance rapide priorisent la livraison de fonctionnalités sur l'optimisation de l'infrastructure. C'est un choix rationnel à court terme. Mais ses consequences s'accumulent : les requests et limits Kubernetes sont fixes une fois en debut de projet et ne sont jamais revus (il est fréquent de trouver des pods qui consomment une petite part des ressources qui leur sont allouées), les instances RDS et ElastiCache sont laissées en On-Demand par défaut (un EC2 en Reserved Instance 1 an no-upfront est moins cher), les environnements de staging et de preprod utilisent les mêmes tailles d'instances que la production.
Le manque de visibilité est le second problème majeur. Sans tagging systématique des ressources AWS par service, par equipe et par environnement, il est impossible d'attribuer les coûts a des responsables et d'identifier les postes qui dérivent. Le Cost Explorer AWS fournit des données, mais elles sont inexploitables sans une taxonomie de tags cohérente.
Beaucoup de SaaS en phase scale ont une grande partie de leurs ressources mal taguées — ce qui range une part importante de la facture dans une catégorie 'Untagged' inutilisable pour l'analyse.
Le troisième problème est le gaspillage sur les environnements non-production. Les environnements de développement, de staging et de preprod représentent une part importante de la facture cloud d'un SaaS en phase scale. La majorité de ces environnements tournent 24h/24, 7j/7, alors qu'ils ne sont utilises que pendant les heures de travail.
Des politiques de shutdown automatique la nuit et le week-end (Lambda Scheduler, Kubernetes CronJob de scale-down) peuvent réduire fortement ces coûts sans impacter la productivité.
Le quatrième problème est la facture de transfert de données (egress costs). Sur AWS, les transferts de données sortants (vers Internet ou vers d'autres regions) sont facturés au Go, selon la grille tarifaire d'AWS. Pour un SaaS qui transfere plusieurs TB de données par mois entre des services dans des régions différentes, ou vers ses clients via une API haute-fréquence, ces coûts de transfert peuvent représenter une part significative de la facture totale.
Une revue de l'architecture de distribution des données (CDN, architecture mono-region, optimisation des requêtes) peut réduire ces coûts significativement.
Enfin, le stockage est systématiquement sous-optimise. S3 sans politique Intelligent-Tiering accumule des données en Standard tier dont la majorité n'est pas accedee depuis des mois. Les snapshots EBS orphelins (de volumes supprimes dont les snapshots n'ont pas été nettoyés) représentent des coûts invisibles mais persistants. Les bases de données RDS sans snapshot lifecycle policy accumulent des snapshots indéfiniment.
Pour approfondir ce sujet, consultez notre page audit FinOps et optimisation coûts cloud.
#Notre approche en 4 phases
La méthode FinOps Nehos pour les SaaS en phase scale suit un principe simple : auditer d'abord, optimiser ensuite, dans l'ordre de l'impact rapide. Les quick wins qui libèrent des économies en quelques semaines financent le reste du programme. L'audit commence par l'activation et la configuration du Cost Explorer AWS (ou GCP Billing Analysis, selon le cloud utilisé) avec une taxonomie de tags standardisée : service, environment (production/staging/dev), team, tenant_id (pour le billing par tenant).
#Phase 1 — Audit FinOps et cartographie des depenses cloud (semaines 1-3)
Activation du Cost Explorer AWS (ou GCP Cost Analysis / Azure Cost Management). Tagging exhaustif des ressources par service, environnement et equipe. Identification des gaspillages évidents : instances non utilisées, snapshots orphelins, NAT Gateways surdimensionnees, S3 lifecycle policies absentes, transferts de données inter-regions. Rapport d'audit avec classement des economies potentielles par effort/gain.
#Phase 2 — Right-sizing Kubernetes et compute (semaines 4-8)
Analyse des requests/limits Kubernetes actuels vs consommation réelle (Kubernetes VPA en mode recommendation, Goldilocks). Ajustement des requests CPU/memory sur tous les workloads. Identification des namespaces sur-alloues. Activation du Cluster Autoscaler et de Karpenter pour le scaling dynamique des nodes. Remplacement des instances EC2 On-Demand par des Spot Instances + Reserved Instances (1 an, no upfront) sur les workloads stables.
Point clé : Sans tagging, on ne sait pas ou va l'argent.
#Phase 3 — Optimisation des services managés et stockage (semaines 9-12)
RDS : migration vers instances graviton2 (moins chères), activation des Reserved Instances DB, audit des Multi-AZ inutiles sur les environnements non-production. ElastiCache : right-sizing des clusters Redis. S3 : activation des Intelligent-Tiering policies et des lifecycle rules pour l'archivage vers Glacier. CloudFront : audit des distributions et des origines inutilisées. Suppression des EBS snapshots orphelins.
#Phase 4 — Migration workloads éligibles vers OVHcloud (mois 3-4)
Identification des workloads candidats a la migration OVHcloud : environnements de staging/preprod, workloads batch non critiques, stockage objet (Object Storage OVHcloud vs S3), bases de données non-production. Migration progressive avec tests de performance. Mise en place d'une architecture multi-cloud avec DNS failover. Tableau de bord FinOps unifie AWS + OVHcloud.
Point clé : Le right-sizing Kubernetes est systématiquement le poste d'economies le plus important — et le plus sous-exploite.
On s'appuie sur notre Kubernetes right-sizing et cluster autoscaling pour cadrer chaque étape.
#Ce qu'on mesure
Nous ne publions pas de chiffres de résultats pour ce type de projet : chaque contexte est différent. Voici les indicateurs qu'on met en place dès le pilote pour décider, chiffres réels à l'appui, d'aller plus loin ou non.
| Indicateur | Ce qu'on regarde |
|---|---|
| Coûts cloud | évolution de la facture cloud mensuelle sur quelques mois, avec right-sizing Kubernetes, Reserved Instances et migration des environnements non critiques |
| Nodes Kubernetes | réduction du nombre de nodes Kubernetes après right-sizing des requests/limits (Goldilocks), sans dégradation de la latence p99 ni du taux de disponibilité |
| Savings Plans | réduction des coûts EC2 en passant d'On-Demand à des Savings Plans Compute, sans changement architectural |
| Environnements hors production | part de la facture cloud représentée par les environnements de staging et de preprod, avant et après les politiques de shutdown automatique |
#Exemple de situation : SaaS B2B d'analytics produit
Ce n'est pas une référence client : c'est une situation type, telle que nous la rencontrons dans ce secteur.
#Contexte
Un SaaS B2B d'analytics produit (product analytics pour équipes marketing et produit), avec plusieurs centaines de clients PME, quelque temps après sa Série B. La facture AWS mensuelle est élevée et en forte croissance. Le cluster EKS est dimensionné largement, RDS Postgres Multi-AZ est en On-Demand, aucun tagging systématique des ressources, pas de Reserved Instances, et les environnements staging/preprod sont aussi gros que la production. Le CEO a présenté les coûts cloud aux investisseurs, qui ont qualifié le ratio cloud costs/ARR de préoccupant.
#Le défi
Réduire significativement la facture cloud en moins de six mois, sans dégradation de la performance (latence p99) ni du taux de disponibilité (SLA 99,9 %), et sans bloquer les livraisons de fonctionnalités de l'équipe engineering.
#Solution envisagée
Phase 1 : audit FinOps — activation de Cost Explorer avec un tagging systématique, identification des gaspillages (ressources EKS sous-utilisées, absence de Reserved Instances, staging/preprod en On-Demand 24h/24). Phase 2 : right-sizing Kubernetes avec Goldilocks (ajustement des requests/limits, réduction du nombre de nodes EKS, Karpenter et Spot Instances pour les workers Kafka).
Phase 3 : Savings Plans Compute pour EC2 et Reserved Instances pour RDS et ElastiCache, shutdown automatique des environnements staging/preprod la nuit et le week-end. Phase 4 : migration de staging/preprod vers OVHcloud Managed Kubernetes et Object Storage.
#Ce qu'on mesure
On ne promet pas de chiffre. On suit la facture cloud mensuelle, la latence p99, le taux de disponibilité, le nombre de nodes et le ratio cloud costs/ARR avant et après chaque phase. La comparaison avec la situation de départ permet de décider de la phase suivante, et de vérifier que les économies ne dégradent ni la performance ni la disponibilité.
#Pourquoi Nehos pour optimisation coûts infra saas
Trois choses nous séparent du reste du marche :
Expertise sectorielle SaaS / Startup — On connaît les contraintes réglementaires, les outils métier, les workflows terrain. Chokri Siala (CTO) pilote ce type de projet personnellement.
Approche ROI-First — On chiffre le retour avant de coder. Si le retour attendu n'est pas démontrable, on vous le dit avant de démarrer.
Stack maîtrisée — EKS, Karpenter, Goldilocks, Spot Instances, Savings Plans Compute, RDS Aurora, ElastiCache Redis, S3 Intelligent-Tiering, OVHcloud Managed Kubernetes, Object Storage OVHcloud, Terraform, Grafana, Cost Explorer API. Pas de dépendance a un outil qu'on découvre sur votre projet.
Accompagnement après go-live — TMA, monitoring, evolution. On ne disparaît pas après la mise en production.
#Pour aller plus loin
- simulateur economies FinOps SaaS
- guide FinOps culture pour SaaS B2B
- solutions ingénierie cloud SaaS et startup
Sources citées dans cet article :
Questions & réponses
Questions frequentes sur l'optimisation des coûts infra SaaS
Le FinOps est la discipline de pilotage financier du cloud — visibilité, optimisation continue, culture de la responsabilité des coûts dans les equipes. Le right-sizing est une action spécifique d'optimisation : ajuster les ressources allouées (taille des instances, requests/limits Kubernetes) a la consommation réelle. La migration cloud (AWS vers OVHcloud par exemple) est une action structurelle : déplacer des workloads vers un cloud ou le rapport performance/prix est plus favorable. Ces trois leviers sont complémentaires : le FinOps vous dit ou sont les gaspillages, le right-sizing elimine les sur-allocations, et la migration deplace les workloads vers les fournisseurs les mieux positionnes. Les meilleurs résultats sont obtenus quand les trois sont combines — c'est la méthode Nehos.
Pas systématiquement — et ce serait une erreur de le faire sans analyse préalable. AWS reste supérieur pour les workloads qui bénéficient de son écosystème de services managés (SageMaker pour le ML, Kinesis pour les streams, Lambda pour le serverless event-driven), sa couverture globale de régions, et sa fiabilité opérationnelle. OVHcloud est plus compétitif sur le compute brut (instances vCPU/RAM a meme prix), le stockage objet (généralement moins cher que S3 pour les mêmes volumes), et les bases de données managees pour les workloads prévisibles. La migration est pertinente pour les workloads non critiques (staging, preprod, batch, stockage froid) mais rarement pour les workloads de production critiques a forte dépendance sur les services managés AWS. Notre audit identifie systématiquement le bon mix selon votre architecture.
Le right-sizing Kubernetes consiste a ajuster les requests et limits CPU et memory de chaque pod (conteneur) a sa consommation réelle — plutôt que de laisser des valeurs surdimensionnees qui font tourner plus de nodes que nécessaire. Il est courant de trouver des pods avec des requests CPU très supérieures à la consommation réelle — ce qui signifie que plusieurs nodes font le travail d'un seul. Goldilocks (open-source, Fairwinds) déployé sur le cluster analyse la consommation historique de chaque pod (via Kubernetes Metrics Server) et recommande des requests/limits optimaux. Ces recommandations sont appliquées progressivement, pod par pod, avec monitoring de la p99 latency après chaque ajustement. Le nombre de nodes diminue directement, et avec lui la facture EC2.
Le risque existe si vous vous engagez sur des volumes de compute que vous n'utiliserez pas — mais il est très manageable avec les bons choix. Les Savings Plans Compute 1 an no-upfront sont la solution la plus flexible : aucun engagement upfront, engagement de depense horaire (pas sur un type d'instance spécifique), applicable sur EC2, Lambda et Fargate. Si votre croissance ralentit, le risque est de payer un engagement non utilisé : on dimensionne donc l'engagement sur le compute réellement stable. Pour les SaaS en forte croissance, les Savings Plans 1 an représentent un engagement conservateur — vous aurez presque certainement utilise plus de compute l'année prochaine. Les 3 ans full-upfront sont reserves aux workloads très stables (database de référence, infrastructure de base) et maximisent les economies.
Le pilotage FinOps continu requiert trois elements : la visibilité (un tableau de bord de coûts par service, par team et par environnement, accessible a tous — pas juste au CTO), la responsabilité (chaque squad est responsable de son budget cloud, avec des alertes automatiques quand elle depasse de 20 %) et la culture (les coûts cloud sont discutes dans les sprint reviews au même titre que les métriques produit). Techniquement, Grafana avec source AWS Cost Explorer API ou un outil specialise (Apptio Cloudability, CloudHealth, ou le dashboard FinOps OVHcloud) exposent les coûts en temps réel. Les alertes sont configurées dans Slack ou PagerDuty. Une pratique courante est d'instaurer un 'FinOps champion' dans chaque squad — un développeur refèrent qui suit les coûts et identifie les optimisations dans son domaine. Voir notre guide FinOps culture pour SaaS B2B.
Le retour d'un audit FinOps dépend de la taille de l'infrastructure et du périmètre de migration : les économies identifiées se chiffrent pendant l'audit, sur votre facture réelle. Pour cadrer, l'audit ROI de 5 jours coûte 2 125 € HT. L'implémentation est ensuite chiffrée sur devis, remis en 48 h après un premier échange. Pour une facture cloud modeste, le retour d'un audit complet est moins immédiat — dans ce cas, nous recommandons de commencer par cet audit de 5 jours, qui identifie les quick wins sans l'accompagnement à l'implémentation.