L'essentiel sur l'optimisation des couts infra SaaS
Le FinOps (Financial Operations) est la discipline qui consiste a piloter les couts cloud avec la meme rigueur qu'on pilote le chiffre d'affaires. En pratique, la majorite des SaaS en phase scale n'ont aucune visibilite sur leurs couts cloud par service, par equipe ou par tenant — ils recoivent une facture AWS globale en fin de mois et constatent qu'elle a encore augmente.
Les gaspillages les plus frequents dans une infrastructure SaaS en phase scale sont : le sur-dimensionnement des pods Kubernetes (requests/limits trop eleves par rapport a la consommation reelle), l'absence de Reserved Instances ou de Savings Plans sur les workloads stables, les instances RDS et ElastiCache en On-Demand, les snapshots EBS orphelins, les NAT Gateways sur-dimensionnees et les transferts de donnees inter-regions non optimises.
Cas client SaaS B2B (analytics produit, 500 clients à partir de 8,2 k€/mois de facture AWS) : audit FinOps complet + right-sizing Kubernetes + Reserved Instances + migration staging/preprod vers OVHcloud. Resultat : -52 % de couts cloud en 4 mois (facture mensuelle passee de à partir de 51 k€ a 5711 k€), p99 latency inchange, zero regression de performance.
La migration vers OVHcloud n'est pas systematiquement la bonne reponse — elle n'est pertinente que pour les workloads non critiques et les environnements de preprod. Pour les workloads de production critiques sur AWS, le right-sizing + Reserved Instances offre generalement 25 a 45 % d'economies sans le risque de migration. Les deux approches sont complementaires et c'est precisement leur combinaison qui permet d'atteindre 50 % et plus d'economies.
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 necessaire 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 experience utilisateur.
Adapté à toute taille de structure
La phase de scale d'un SaaS B2B est caracterisee par une acceleration de la croissance du nombre de clients et du volume de donnees traitees — et une acceleration tout aussi rapide des couts d'infrastructure. Ce qui etait une facture AWS de2 12 800 €/mois a la Serie A devient50 15 872 €/mois a la Serie B, puis112 1 792 €/mois deux ans plus tard. Pendant ce temps, l'ARR a peut-etre triple — mais les marges brutes se degradent, et les investisseurs commencent a poser des questions. Le probleme de fond est structural : les equipes engineering en phase de croissance rapide priorisent la livraison de fonctionnalites sur l'optimisation de l'infrastructure. C'est un choix rationnel a 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 allouees), les instances RDS et ElastiCache sont laissees en On-Demand par defaut (un EC2 en Reserved Instance 1 an no-upfront est 30 a 40 % moins cher), les environnements de staging et de preprod utilisent les memes tailles d'instances que la production. Le manque de visibilite est le second probleme majeur. Sans tagging systematique des ressources AWS par service, par equipe et par environnement, il est impossible d'attribuer les couts a des responsables et d'identifier les postes qui derivent. Le Cost Explorer AWS fournit des donnees, mais elles sont inexploitables sans une taxonomie de tags coherente. La majorite 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 categorie 'Untagged' inutilisable pour l'analyse. Le troisieme probleme est le gaspillage sur les environnements non-production. Les environnements de developpement, de staging et de preprod representent en moyenne 25 a 40 % de la facture cloud d'un SaaS en phase scale — selon les donnees Datadog 2024 State of Cloud Costs. La majorite 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 reduire ces couts de 60 % sans impacter la productivite. Le quatrieme probleme est la facture de transfert de donnees (egress costs). Sur AWS, les transferts de donnees 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 donnees par mois entre des services dans des regions differentes, ou vers ses clients via une API haute-frequence, ces couts de transfert peuvent representer 15 a 25 % de la facture totale. Une revue de l'architecture de distribution des donnees (CDN, architecture mono-region, optimisation des requetes) peut reduire ces couts significativement. Enfin, le stockage est systematiquement sous-optimise. S3 sans politique Intelligent-Tiering accumule des donnees en Standard tier dont la majorite n'est pas accedee depuis des mois. Les snapshots EBS orphelins (de volumes supprimes dont les snapshots n'ont pas ete nettoyes) representent des couts invisibles mais persistants. Les bases de donnees RDS sans snapshot lifecycle policy accumulent des snapshots indefiniment.
La methode 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 liberent 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 standardisee : `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 percoivent comme du admin overhead — est le prerequis de toute analyse pertinente. Sans tagging, on ne sait pas ou va l'argent. Avec le tagging, on identifie immediatement les services et les equipes qui derivent. Le right-sizing Kubernetes est systematiquement le poste d'economies le plus important — et le plus sous-exploite. Nehos deploie Goldilocks (outil open-source de Fairwinds) sur le cluster pour analyser la consommation reelle 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 reelle de 50m — soit un facteur 10 de sur-allocation. Ajuster les requests/limits a 120-150 % de la consommation reelle (pour garder une marge de securite) permet souvent de reduire le nombre de nodes Kubernetes de 30 a 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 activees pour les workloads tolerants aux interruptions (jobs batch, workers asynchrones). Les Reserved Instances (ou Savings Plans — plus flexibles) sur AWS sont negociees pour tous les workloads stables en production : instances EC2, RDS, ElastiCache, OpenSearch. Un Savings Plan Compute 1 an no-upfront offre 33 % de reduction vs On-Demand. Un Savings Plan 3 ans full-upfront peut atteindre 62 % de reduction. Pour un SaaS avec une facture EC2+RDS de à partir de 80 k€/mois, passer en Savings Plans 1 an represente une economie 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 necessaire : 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 meme volumes), les bases de donnees de developpement. OVHcloud propose des instances Kubernetes (Managed Kubernetes) et des instances de base de donnees (Managed Databases — compatible Postgres, MySQL, Redis) dont le rapport performance/prix est significativement plus favorable qu'AWS pour les workloads previsibles. La migration est preparee avec Terraform (infrastructure-as-code) et executee avec zero-downtime via un DNS cutover progressif. Le tableau de bord FinOps continu — livre en fin de mission — expose en temps reel les couts par service, par environnement et par tenant, avec des alertes sur les anomalies (pic de couts inhabituel, depassement de budget par service). Il est heberge sur Grafana (avec source de donnees AWS Cost Explorer API) ou sur un outil FinOps specialise (CloudHealth, Apptio Cloudability, ou la plateforme FinOps OVHcloud). Des alertes Slack ou PagerDuty sont configurees pour notifier le CTO et le CFO quand un service depasse son budget mensuel de 20 %.
-52 %
de couts 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 reduction du nombre de nodes Kubernetes observee en moyenne apres right-sizing des requests/limits avec Goldilocks — sans degradation de la p99 latency ni du taux de disponibilite
33 %
de reduction immediate des couts 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 representee par les environnements de staging et de preprod — selon le rapport Datadog State of Cloud Costs 2024
#Le probleme : pourquoi optimisation couts infra saas est un enjeu critique
Situation typique : La phase de scale d'un SaaS B2B est caracterisee par une acceleration de la croissance du nombre de clients et du volume de donnees traitees — et une acceleration tout aussi rapide des couts d'infrastructure. Ce qui etait une facture AWS de2 12 800 €/mois a la Serie A devient50 15 872 €/mois a la Serie B, puis112 1 792 €/mois deux ans plus tard. Pendant ce temps, l'ARR a peut-etre triple — mais les marges brutes se degradent, et les investisseurs commencent a poser des questions.
Le probleme de fond est structural : les equipes engineering en phase de croissance rapide priorisent la livraison de fonctionnalites sur l'optimisation de l'infrastructure. C'est un choix rationnel a 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 allouees), les instances RDS et ElastiCache sont laissees en On-Demand par defaut (un EC2 en Reserved Instance 1 an no-upfront est 30 a 40 % moins cher), les environnements de staging et de preprod utilisent les memes tailles d'instances que la production. (source : Datadog)
Le manque de visibilite est le second probleme majeur. Sans tagging systematique des ressources AWS par service, par equipe et par environnement, il est impossible d'attribuer les couts a des responsables et d'identifier les postes qui derivent. Le Cost Explorer AWS fournit des donnees, mais elles sont inexploitables sans une taxonomie de tags coherente. La majorite 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 categorie 'Untagged' inutilisable pour l'analyse.
Le troisieme probleme est le gaspillage sur les environnements non-production. Les environnements de developpement, de staging et de preprod representent en moyenne 25 a 40 % de la facture cloud d'un SaaS en phase scale — selon les donnees Datadog 2024 State of Cloud Costs. La majorite 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 reduire ces couts de 60 % sans impacter la productivite.
Le quatrieme probleme est la facture de transfert de donnees (egress costs). Sur AWS, les transferts de donnees 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 donnees par mois entre des services dans des regions differentes, ou vers ses clients via une API haute-frequence, ces couts de transfert peuvent representer 15 a 25 % de la facture totale. Une revue de l'architecture de distribution des donnees (CDN, architecture mono-region, optimisation des requetes) peut reduire ces couts significativement.
Enfin, le stockage est systematiquement sous-optimise. S3 sans politique Intelligent-Tiering accumule des donnees en Standard tier dont la majorite n'est pas accedee depuis des mois. Les snapshots EBS orphelins (de volumes supprimes dont les snapshots n'ont pas ete nettoyes) representent des couts invisibles mais persistants. Les bases de donnees RDS sans snapshot lifecycle policy accumulent des snapshots indefiniment.
Pour approfondir ce sujet, consultez notre page audit FinOps et optimisation couts cloud.
#Notre approche en 4 phases
La methode 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 liberent 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 standardisee : 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 evidents : instances non utilisees, snapshots orphelins, NAT Gateways surdimensionnees, S3 lifecycle policies absentes, transferts de donnees 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 reelle (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 cle : 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 cheres), 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 inutilisees. Suppression des EBS snapshots orphelins.
#Phase 4 — Migration workloads eligibles 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 donnees 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 cle : Le right-sizing Kubernetes est systematiquement 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 etape.
#Resultats mesures
Voici ce qu'on a mesure, sans arrondir.
| Indicateur | Resultat | Source |
|---|---|---|
| -52 % | de couts cloud en 4 mois (de à partir 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 reduction du nombre de nodes Kubernetes observee en moyenne apres right-sizing des requests/limits avec Goldilocks... | Benchmarks right-sizing Nehos 2025 (2025) |
| 33 % | de reduction immediate des couts 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 representee par les environnements de staging et de preprod — sel... | Datadog — State of Cloud Costs Report 2024 (2024) |
#Ce que ces chiffres signifient
-52 % — de couts cloud en 4 mois (de à partir 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 reduction du nombre de nodes Kubernetes observee en moyenne apres right-sizing des requests/limits avec Goldilocks — sans degradation de la p99 latency ni du taux de disponibilite. Un indicateur complementaire qui confirme l'impact operationnel. Source : Benchmarks right-sizing Nehos 2025.
33 % — de reduction immediate des couts 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 Serie 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 systematique des ressources. Pas de Reserved Instances. Environnements staging/preprod identiques en taille a la production. Le CEO avait presente les couts cloud aux investisseurs — ils avaient qualifie le ratio cloud costs/ARR de 'preoccupant'.
#Le defi
Reduire la facture cloud d'au moins 40 % en moins de 6 mois sans degradation de la performance (p99 latency inferieure a 200ms) ni du taux de disponibilite (SLA 99,9 %), et sans bloquer les livraisons de fonctionnalites de l'equipe engineering (8 developpeurs backend, 4 frontend).
#Solution deployee
Phase 1 (3 semaines) : audit FinOps — activation Cost Explorer avec tagging systematique, identification des gaspillages (45 % des ressources EKS sous-utilisees, 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 a 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 reel.
#Resultats obtenus
Resultats a 4 mois : facture mensuelle reduite de à partir de 51 k€ a 5711 k€ (-52 %), p99 latency inchangee (185ms vs 183ms avant), taux de disponibilite maintenu a 99,93 %. Economies annualisees : 749 k€. Cout 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 % a 8,6 % — niveau conforme aux benchmarks SaaS B2B du secteur (benchmarks OpenView 2025 : 8-12 % pour les SaaS B2B en phase scale).
Decouvrez aussi notre migration OVHcloud depuis AWS.
#Pourquoi Nehos pour optimisation couts infra saas
Trois choses nous separent du reste du marche :
Expertise sectorielle SaaS / Startup — On connait les contraintes reglementaires, les outils metier, 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 demontrable, on vous le dit. On a deja refuse des projets — et nos clients nous en remercient.
Stack maitrisee — 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 dependance a un outil qu'on decouvre sur votre projet.
Accompagnement apres go-live — TMA, monitoring, evolution. On ne disparait pas apres la mise en production.
#Pour aller plus loin
- simulateur economies FinOps SaaS
- guide FinOps culture pour SaaS B2B
- solutions ingenierie cloud SaaS et startup
Sources citees dans cet article :