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 depense en moyenne 40 a 60 % de plus que nécessaire sur son infrastructure cloud. Right-sizing Kubernetes, Reserved Instances, migration selective vers OVHcloud : Nehos audite, priorise et execute les optimisations — sans degrader 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 de 12 800 €/mois a la Série A devient 15 872 €/mois a la Série B, puis 17 920 €/mois 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 frequent de trouver des pods qui consomment 10 % des resources 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 30 a 40 % 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. La majorité des SaaS en phase scale ont moins de 30 % de leurs ressources correctement taguees — ce qui signifie que 70 % de la facture est 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 en moyenne 25 a 40 % de la facture cloud d'un SaaS en phase scale — selon les données Datadog 2024 State of Cloud Costs. 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 ces coûts de 60 % 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 facturas — souvent a 0,08 a 0,09 $/GB. 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 15 a 25 % 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 20 a 30 % d'economies en 4 a 6 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. Sur les SaaS que nous auditons, il est courant de trouver des pods avec des requests CPU de 500m pour une consommation réelle de 50m — soit un facteur 10 de sur-allocation. Ajuster les requests/limits a 120-150 % de la consommation réelle (pour garder une marge de sécurité) permet souvent de réduire le nombre de nodes Kubernetes de 30 à 50 % — 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 1 an no-upfront offre 33 % de réduction vs On-Demand. Un Savings Plan 3 ans full-upfront peut atteindre 62 % de réduction. Pour un SaaS avec une facture EC2+RDS de 80 k€/mois, passer en Savings Plans 1 an represente une économie de 612 k€/mois — pour un investissement de zero (no-upfront).
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 3 a 5 fois moins cher que S3 pour les même volumes), 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 %.
-52 %
de coûts cloud en 4 mois (de 1 à partir de 5 k€/mois a 57,6 k€/mois) sur un SaaS B2B analytics produit — right-sizing Kubernetes + Reserved Instances + migration staging OVHcloud
30-50 %
de réduction du nombre de nodes Kubernetes observée en moyenne après right-sizing des requests/limits avec Goldilocks — sans degradation de la p99 latency ni du taux de disponibilité
33 %
de réduction immediate des coûts EC2 en passant de On-Demand a Savings Plans Compute 1 an no-upfront sur AWS — sans engagement upfront ni changement architectural
25-40 %
de la facture cloud totale d'un SaaS en phase scale représentée par les environnements de staging et de preprod — selon le rapport Datadog State of Cloud Costs 2024
#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 de 12 800 €/mois a la Série A devient 15 872 €/mois a la Série B, puis 17 920 €/mois 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 frequent de trouver des pods qui consomment 10 % des resources 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 30 a 40 % moins cher), les environnements de staging et de preprod utilisent les mêmes tailles d'instances que la production. (source : Datadog)
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. La majorité des SaaS en phase scale ont moins de 30 % de leurs ressources correctement taguees — ce qui signifie que 70 % de la facture est 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 en moyenne 25 a 40 % de la facture cloud d'un SaaS en phase scale — selon les données Datadog 2024 State of Cloud Costs. 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 ces coûts de 60 % 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 facturas — souvent a 0,08 a 0,09 $/GB. 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 15 a 25 % 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 20 a 30 % d'economies en 4 a 6 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 (20-40 % 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.
#Résultats mesures
Voici ce qu'on a mesure, sans arrondir.
| Indicateur | Résultat | Source |
|---|---|---|
| -52 % | de coûts cloud en 4 mois (de 51 k€/mois a 5711 k€/mois) sur un SaaS B2B analytics produit — right-sizing Kubernetes ... | Mesures FinOps Nehos 2025 — SaaS B2B client (2025) |
| 30-50 % | de réduction du nombre de nodes Kubernetes observée en moyenne après right-sizing des requests/limits avec Goldilocks... | Benchmarks right-sizing Nehos 2025 (2025) |
| 33 % | de réduction immediate des coûts EC2 en passant de On-Demand a Savings Plans Compute 1 an no-upfront sur AWS — sans e... | AWS Pricing — Savings Plans Compute 2025 (2025) |
| 25-40 % | de la facture cloud totale d'un SaaS en phase scale représentée par les environnements de staging et de preprod — sel... | Datadog — State of Cloud Costs Report 2024 (2024) |
#Ce que ces chiffres signifient
-52 % — de coûts cloud en 4 mois (de 51 k€/mois a 5711 k€/mois) sur un SaaS B2B analytics produit — right-sizing Kubernetes + Reserved Instances + migration staging OVHcloud. C'est le chiffre principal, celui qui justifie l'investissement. Source : Mesures FinOps Nehos 2025 — SaaS B2B client.
30-50 % — de réduction du nombre de nodes Kubernetes observée en moyenne après right-sizing des requests/limits avec Goldilocks — sans degradation de la p99 latency ni du taux de disponibilité. Un indicateur complémentaire qui confirme l'impact opérationnel. Source : Benchmarks right-sizing Nehos 2025.
33 % — de réduction immediate des coûts EC2 en passant de On-Demand a Savings Plans Compute 1 an no-upfront sur AWS — sans engagement upfront ni changement architectural. Source : AWS Pricing — Savings Plans Compute 2025.
#Cas client : SaaS B2B d'analytics produit (product analytics pour equi...
Un cas concret vaut mieux qu'un argumentaire.
#Contexte
SaaS B2B d'analytics produit (product analytics pour equipes marketing et produit), 500 clients PME, 18 mois post Série B (levee de 1501 k€). Facture AWS mensuelle : à partir de 51 k€ en croissance de 15 % par mois. Cluster EKS avec 45 nodes m5.2xlarge. RDS Postgres Multi-AZ en On-Demand. Aucun tagging systématique des ressources. Pas de Reserved Instances. Environnements staging/preprod identiques en taille a la production. Le CEO avait presente les coûts cloud aux investisseurs — ils avaient qualifie le ratio cloud costs/ARR de 'préoccupant'.
#Le défi
Réduire la facture cloud d'au moins 40 % en moins de 6 mois sans degradation de la performance (p99 latency inférieure a 200ms) ni du taux de disponibilité (SLA 99,9 %), et sans bloquer les livraisons de fonctionnalités de l'equipe engineering (8 développeurs backend, 4 frontend).
#Solution déployée
Phase 1 (3 semaines) : audit FinOps — activation Cost Explorer avec tagging systématique, identification des gaspillages (45 % des ressources EKS sous-utilisées, 0 Reserved Instances, staging/preprod en On-Demand 24h/24). Phase 2 (4 semaines) : right-sizing Kubernetes avec Goldilocks — ajustement des requests/limits, reduction de 45 à 26 nodes EKS, activation Karpenter + Spot Instances pour les workers Kafka. Phase 3 (3 semaines) : achat de Savings Plans Compute 1 an pour EC2 + Reserved Instances pour RDS et ElastiCache. Shutdown automatique des environnements staging/preprod la nuit et le week-end. Phase 4 (4 semaines) : migration staging/preprod vers OVHcloud Managed Kubernetes + Object Storage (vs S3). Tableau de bord FinOps Grafana en temps réel.
#Résultats obtenus
Résultats a 4 mois : facture mensuelle réduite de 51 k€ a 5711 k€ (-52 %), p99 latency inchangée (185ms vs 183ms avant), taux de disponibilité maintenu a 99,93 %. Economies annualisees : 749 k€. Coût de la mission Nehos : à partir de 67 k€ HT. ROI de la mission : 11x sur 12 mois. Le ratio cloud costs/ARR est passe de 18 % à 8,6 % — niveau conforme aux benchmarks SaaS B2B du secteur (benchmarks OpenView 2025 : 8-12 % pour les SaaS B2B en phase scale).
Découvrez aussi notre migration OVHcloud depuis AWS.
#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 ROI n'est pas démontrable, on vous le dit. On a déjà refuse des projets — et nos clients nous en remercient.
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 :
- Datadog — State of Cloud Costs 2024 — benchmarks coûts infra SaaS et gaspillages identifies
- AWS — Savings Plans Compute — tarifs et economies vs On-Demand
- OpenView Partners — SaaS Benchmarks 2025 — ratios cloud costs / ARR par stade de croissance
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 (3 a 5 fois moins cher que S3 pour les même 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. Sur les SaaS que nous auditons, il est courant de trouver des pods avec des requests de 500m CPU pour une consommation réelle de 50m — ce qui signifie que 10 nodes sont en train de faire le travail de 1. 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. Sur notre cas client, le cluster est passe de 45 à 26 nodes — une réduction directe de 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, vous pouvez revendre vos Savings Plans non utilises sur le AWS Marketplace a 85-90 % de leur valeur. Pour les SaaS avec une croissance ARR supérieure a 40 %/an, 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 (jusqu'à 62 %).
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. Certains de nos clients SaaS ont instauré 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.
Sur les SaaS en phase scale que nous auditons, les economies identifiées se situent typiquement entre 30 et 60 % de la facture cloud initiale. Le coût de l'audit et de l'implémentation varie de 40 k€ a à partir de 51 k€ HT selon la taille de l'infrastructure et le périmètre de migration. Sur notre cas client de référence (facture à partir de 51 k€/mois), le ROI de la mission était de 11x sur 12 mois (749 k€ d'economies annualisees vs à partir de 67 k€ de coût de mission). Pour les SaaS avec une facture cloud inférieure a à partir de 48 k€/mois, le ROI d'un audit complet est moins immédiat — dans ce cas, nous recommandons de commencer par un audit FinOps accelere de 5 jours qui identifie les quick wins sans l'accompagnement implementation. Le simulateur sur notre site permet d'estimer les economies réalisables selon votre facture actuelle et votre architecture.