Ressources
Budget cloud d'un SaaS en croissance : prévoir trois scénarios
Un budget cloud SaaS distingue prévision, budget autorisé et facture, bâtit trois scénarios de croissance sans coût linéaire et explique l'écart mensuel.
L'équipe CTN Solutions · publié le · 16 min de lecture
Base d'expérience : Méthode et documentation officielle (AWS, FinOps Foundation) ; tableur de démonstration reproduit en laboratoire local le 8 octobre 2026 sur un exemple fictif, sans référence client ni retour de mission.
Faits vérifiés sur les sources primaires le
Un budget cloud qui reprend la facture du dernier trimestre et la multiplie par un taux de croissance ne dit ni quand la dépense monte, ni ce qui la fait monter. Un nouveau segment de clients, une fonctionnalité qui conserve davantage de données ou l'ouverture d'une région changent la dépense par étapes, à des dates précises. Cet article propose une méthode pour préparer le budget de l'année suivante avec trois scénarios de croissance nommés, construits à partir du plan commercial et du plan produit.
Le lecteur visé est le fondateur, le directeur technique (CTO) et le directeur administratif et financier (DAF) d'un SaaS, c'est-à-dire d'un logiciel fourni en ligne par abonnement, dont les usages ou le périmètre cloud vont changer. La méthode sépare trois nombres, relie le plan aux variables d'usage, ajoute les dates, les engagements et les dépenses ponctuelles, puis organise l'explication mensuelle des écarts. Les chiffres proviennent d'un exemple fictif, construit à partir de prix publics de liste d'Amazon Web Services (AWS). Ils ne prévoient la dépense d'aucun client réel.
Prévision, budget autorisé et facture : trois nombres à distinguer
Trois nombres circulent pour le même mois, et ils ne répondent pas à la même question. La prévision est un modèle de dépense future pour un périmètre donné, qu'il s'agisse d'un système, d'un service ou d'une application [1]. Le budget est le financement approuvé pour les activités technologiques planifiées, piloté principalement par la finance [2]. La facture est ce qui est dû pour une période. Une prévision de facture peut différer de la facture réelle de chaque relevé [3].
Le cadre FinOps place la construction des modèles de prévision surtout entre l'ingénierie et le produit [1]. Les budgets d'un système ou d'une application reposent généralement sur les prévisions que fournissent ces équipes [2]. Le tableau suivant précise qui porte chaque nombre et ce qu'il ne démontre pas.
| Nombre | Question à laquelle il répond | Qui le porte | Ce qu'il ne prouve pas |
|---|---|---|---|
| Prévision | Combien coûtera la dépense future si les hypothèses tiennent ? | Ingénierie et produit, avec la finance | Qu'une hypothèse de croissance se réalisera |
| Budget autorisé | Quel montant l'organisation accepte de financer | DAF | Que la dépense restera conforme au plan |
| Facture ou réalisé comparable | Ce qui a été consommé ou dû, sur une base de coût choisie | Finance, à partir des relevés techniques | Pourquoi la dépense a varié |
Dans un laboratoire local du 8 octobre 2026, nous avons construit un tableur de démonstration, généré avec Python 3.14.6 et openpyxl 3.1.5, dont les formules ont été recalculées par une bibliothèque indépendante, formulas 1.3.4. Il applique les prix publics de liste d'AWS pour la région Paris, en dollars américains (USD) et hors taxes. Pour janvier 2027, le scénario central de cet exemple fictif donne une prévision de 2 259 USD, un budget autorisé de 2 400 USD et un réalisé comparable de 2 308 USD. Le réalisé est lui aussi fictif.
La comparaison n'a de sens que sur une base de coût unique. Le tableur compare toutes ses lignes en coût amorti, c'est-à-dire un paiement initial ou récurrent réparti sur la durée du terme [6]. Le choix entre coût amorti, coût non combiné et montant facturé est traité dans Coût facturé, coût amorti, crédits : réconcilier des montants AWS qui ne tombent jamais juste. Cet article suppose ce choix déjà fait.
Relier le plan SaaS aux variables qui font évoluer les usages
Le plan commercial ne dit pas combien coûte un client. Il dit combien de clients arrivent, dans quel segment, à quelle date, et quelles fonctionnalités ils utilisent. Le modèle traduit chaque hypothèse en unité consommée : nœuds de calcul, gigaoctets (Go) stockés, Go transférés vers Internet, clusters Kubernetes managés. Chaque unité porte une source, une date et un responsable, car une hypothèse sans propriétaire ne se révise pas.
De l'hypothèse commerciale à la prévision mensuelle
Le schéma relie le plan commercial et produit à la prévision mensuelle, puis à la révision des hypothèses après l'écart.
Schéma défilable horizontalement ; sa version textuelle complète suit.
Lire le schéma sous forme textuelle
- Le plan commercial et produit donne les clients par segment, les dates de livraison d'une fonctionnalité et les dates d'ouverture d'une région.
- Ces hypothèses sont converties en unités consommées : nœuds, Go stockés, Go transférés, clusters.
- Des règles de capacité et de paliers transforment les unités en nombre de ressources à facturer.
- Chaque poste est calculé séparément, unité multipliée par tarif, puis les postes disjoints sont additionnés.
- La prévision mensuelle sert de base au budget autorisé, que la finance approuve.
- La facture ou le réalisé comparable est rapproché de la prévision et du budget.
- L'écart absolu et l'écart relatif sont calculés, puis une cause, une action et une date sont attribuées.
- La révision remonte aux hypothèses d'unités, et non seulement au total du mois.
Dans l'exemple fictif, les hypothèses d'usage tiennent dans le tableau suivant. PME désigne les petites et moyennes entreprises, ETI les entreprises de taille intermédiaire.
| Variable | Valeur de l'exemple | Unité | Responsable (fictif) |
|---|---|---|---|
| Charge de calcul par client PME | 0,015 | nœud | CTO |
| Ingestion de données par client PME | 5 | Go par mois | Produit |
| Rétention des données PME | 6 | mois | Produit |
| Transfert sortant par client PME | 20 | Go par mois | CTO |
| Charge de calcul par client ETI | 0,12 | nœud | CTO |
| Ingestion de données par client ETI | 60 | Go par mois | Produit |
| Rétention des données ETI | 12 | mois | Produit |
| Transfert sortant par client ETI | 300 | Go par mois | CTO |
| Taux d'utilisation cible des nœuds | 65 | % | CTO |
| Socle de capacité | 6 | nœuds | CTO |
La règle de calcul du nombre de nœuds est explicite : il vaut le plus grand entre le socle et la charge divisée par le taux d'utilisation cible, arrondie à l'unité supérieure. Après l'ouverture d'une région, trois nœuds s'ajoutent. La facture n'est jamais obtenue en multipliant tout le total par la croissance du nombre de clients. Elle se calcule poste par poste, et les postes sont additionnés sans recouvrement.
Construire trois scénarios sans supposer un coût linéaire
Les trois scénarios sont des hypothèses nommées : ralenti, central et accéléré. Ils ne reçoivent aucune probabilité. Un scénario de forte consommation n'est pas le plus favorable commercialement : il décrit une activité plus forte, qui coûte davantage. Seuls les moteurs changent d'un scénario à l'autre ; les prix et les règles restent identiques.
| Moteur (exemple fictif) | Ralenti | Central | Accéléré |
|---|---|---|---|
| Clients PME au départ, croissance mensuelle | 120, 2 % | 120, 4 % | 120, 7 % |
| Clients ETI au départ, croissance mensuelle | 20, 1,5 % | 20, 3 % | 20, 5 % |
| Fonctionnalité consommatrice livrée (ingestion multipliée par 1,6) | mois 7 | mois 5 | mois 4 |
| Ouverture régionale (3 nœuds et 1 cluster de plus) | aucune dans l'horizon | mois 8 | mois 6 |
Exemple fictif : totaux sur douze mois
Le tableau reprend les totaux du laboratoire du 8 octobre 2026 pour 2027, en consommation amortie hors taxes. Les postes sont arrondis : leur somme peut différer d'une unité du total.
| Poste (USD, sur 12 mois) | Ralenti | Central | Accéléré |
|---|---|---|---|
| Calcul, engagement amorti (5 nœuds) | 6 040 | 6 040 | 6 040 |
| Calcul à la demande | 5 233 | 9 484 | 13 409 |
| Disques EBS (Elastic Block Store, stockage bloc) | 1 708 | 2 190 | 2 636 |
| Stockage objet S3 | 6 425 | 7 313 | 8 298 |
| Transfert sortant | 10 134 | 11 277 | 13 047 |
| Kubernetes managé (EKS) | 876 | 1 241 | 1 387 |
| Ponctuel : migration de données | 8 000 | 8 000 | 8 000 |
| Ponctuel : mise en place de région | 0 | 15 000 | 15 000 |
| Total | 38 415 | 60 545 | 67 816 |
Chiffrage fondé sur vos données
Vérifié le
Dans ce laboratoire, doubler le nombre de clients au premier mois a fait passer la dépense de 2 259 à 4 696 USD, soit davantage que le double (2 x 2 259 = 4 518 USD). Le mécanisme est arithmétique. L'engagement couvre cinq nœuds ; chaque nœud au-delà est facturé à la demande, à un tarif supérieur au tarif engagé. La non-linéarité joue aussi dans l'autre sens : une baisse de la demande ne réduit pas l'engagement, dont le coût amorti reste de 503 USD par mois dans le modèle.
Les marches de capacité se lisent dans le scénario central. À l'ouverture de la région, au mois 8, le modèle ajoute trois nœuds et un cluster Kubernetes, avec une dépense ponctuelle de mise en place de 15 000 USD. Le total mensuel passe de 2 983 USD au mois 7 à 18 662 USD au mois 8. Une progression lissée aurait masqué ce mois-là, qui est précisément celui où il faut décider.
Le transfert sortant suit une tarification par tranches. Dans le scénario central, le volume franchit la tranche de 10 240 Go au mois 7. Au-delà de cette tranche, le Go suivant est facturé 0,085 USD, et non 0,09 USD pour l'ensemble du volume. La tarification ne se lit donc pas comme un prix unitaire constant.
Ajouter les dates, les engagements et les dépenses ponctuelles
Trois types d'éléments ne se déduisent pas des usages : les dates produit, les échéances de version et les engagements. Le calendrier les inscrit mois par mois, avec leur source. Une échéance de version est une date à reporter depuis la documentation du fournisseur. Par exemple, une version Kubernetes qui atteint la fin de son support standard entre en support étendu, à un coût supplémentaire par heure de cluster [7]. Le calcul détaillé de cette exposition est traité dans Support étendu EKS et RDS : calendrier de fin 2026, tarifs et calcul de l'exposition. Dans le calendrier, la date et son origine figurent sur la même ligne que la dépense qu'elle déclenche.
Un engagement de réservation ou de Savings Plans achète un niveau d'usage pour une durée d'un ou trois ans [8]. Trois règles de lecture comptent dans un budget. Un Savings Plan ne peut pas être annulé pendant sa durée [9]. L'engagement se consomme heure par heure, sans report d'une heure à l'autre, et l'usage au-delà est facturé au tarif à la demande [10]. Une réservation d'instance EC2 se facture à chaque heure du terme choisi, que l'instance tourne ou non (en paiement All Upfront, le terme entier est réglé en un paiement à l'achat) [11]. Pour un Savings Plan en paiement sans avance (No Upfront), la part d'engagement est facturée chaque heure ; avec le paiement intégral à l'achat (All Upfront), la ligne de facturation indique la part non utilisée sur la période [12].
Le laboratoire a utilisé une réservation d'instance standard d'un an sur cinq nœuds, faute de tarifs de Savings Plans dans les fichiers d'offre retenus. Les montants ci-dessous valent pour cette option uniquement ; ils ne se transposent pas à un Savings Plan. Les deux modes de paiement sont comparés pour le même engagement, avec les prix publics de liste de la région Paris : 1 208 USD par instance en All Upfront, 0,14774 USD par heure en No Upfront, publiés le 7 octobre 2026 [13].
| Mode de paiement (cinq nœuds) | Coût amorti mensuel de l'engagement | Décaissement de l'engagement au mois 1 | Décaissement de l'engagement sur 12 mois | Total décaissé au mois 1, reste inclus |
|---|---|---|---|---|
| All Upfront, paiement initial intégral | 503 USD | 6 040 USD | 6 040 USD | 7 796 USD |
| No Upfront, sans paiement initial | 539 USD | 539 USD | 6 471 USD | 2 295 USD |
Le coût amorti répartit l'engagement sur la durée et sert à la lecture budgétaire. Le décaissement sert à la trésorerie. Les deux vues ne se cumulent pas : sur l'année, la dépense consommée atteint 60 545 USD avec All Upfront et 60 976 USD avec No Upfront, et c'est le calendrier de paiement qui diffère. Enfin, les dépenses ponctuelles figurent sur une ligne distincte, au mois où elles ont lieu. Dans l'exemple, la migration de données coûte 8 000 USD au mois de livraison de la fonctionnalité, et la mise en place d'une région 15 000 USD au mois d'ouverture. Ces montants sont fictifs et ne figurent pas dans la liste de prix d'AWS.
Expliquer l'écart mensuel et décider qui ajuste
L'écart absolu est le réalisé moins la prévision. L'écart relatif est l'écart absolu divisé par la prévision. Il n'a pas de sens quand la prévision est nulle : la fiche affiche alors « non applicable », et l'écart absolu reste lisible. Une absence de réalisé n'est pas un écart nul : la case reste vide tant que la période n'est pas close.
Chaque organisation fixe sa propre tolérance d'écart entre prévision et réel [1]. Le cadre FinOps cite des repères de variance budgétaire de 20 % au niveau Crawl, 15 % au niveau Walk et 12 % au niveau Run [2]. Ce sont des repères, pas des seuils : l'exemple n'en applique aucun.
Le tableau reprend les trois premiers mois du scénario central, avec un réalisé fictif. Le budget autorisé de l'exemple égale la prévision centrale majorée de 5 %, arrondie à la centaine supérieure ; c'est un choix fictif, et non une règle.
| Mois (2027) | Prévision | Budget autorisé | Réalisé comparable | Écart absolu | Écart relatif |
|---|---|---|---|---|---|
| 01 | 2 259 | 2 400 | 2 308 | +49 | +2,2 % |
| 02 | 2 271 | 2 400 | 3 895 | +1 624 | +71,5 % |
| 03 | 2 494 | 2 700 | 2 707 | +213 | +8,6 % |
Les mois 4 à 12 n'ont pas encore de réalisé : leurs colonnes restent vides. Les écarts relatifs sont calculés sur les montants non arrondis.
Au mois 2, l'écart total de +71,5 % vient presque entièrement d'une ligne ponctuelle sans prévision. Le détail montre comment la revue l'explique et l'affecte.
| Ligne, février 2027 (USD, exemple fictif) | Prévision | Réalisé | Écart absolu | Écart relatif | Cause et action |
|---|---|---|---|---|---|
| Ponctuels : outil de test de charge facturé à l'unité | 0 | 1 500 | +1 500 | non applicable | Dépense non prévue. Créer une ligne au budget ou refuser la dépense (DAF, révision au 5 mars 2027). |
| Transfert sortant | 801 | 897 | +96 | +12,0 % | Pic d'exports en fin de mois. Réviser le transfert par client ETI de 300 à 330 Go par mois si le pic se répète (CTO, révision au 5 mars 2027). |
Une ligne à prévision nulle garde un écart absolu lisible, alors que son écart relatif n'existe pas. Au mois 3, un nœud conservé après un test de charge explique 119 USD d'écart sur le poste calcul, et l'action proposée est de le retirer ou d'avancer la validation du palier.
Qui ajuste quoi ? Le CTO met à jour les hypothèses d'usage : ingestion, transfert, nombre de nœuds. Le DAF décide des lignes ponctuelles et du budget : le cadre FinOps indique que le budget est piloté principalement par la finance [2]. AWS Budgets propose plusieurs types de budgets, dont des budgets de coût et des budgets de Savings Plans ou de réservations [5]. Ses alertes peuvent porter sur le montant réel ou sur la prévision [6] : une alerte sur la prévision prévient avant la facture. La méthode générale de la démarche FinOps, le dimensionnement et les engagements sont traités dans FinOps, c'est quoi ? Définition 2026, méthode et par où commencer.
L'offre Audit FinOps : expliquer la facture rapproche la facturation, les usages, l'étiquetage et les contrats, puis remet une grille de lecture des coûts et des recommandations chiffrées sur les données du client. Elle exclut la mise en œuvre des recommandations et la gouvernance continue des coûts. Elle exclut aussi la renégociation des contrats avec les fournisseurs, qui reste de votre responsabilité.
Sources officielles et limites de lecture
Faits datés
Les pages officielles citées ont été lues le . Les pages FinOps et AWS consultées n'affichent pas toujours de date de mise à jour : elles se relisent avant toute décision budgétaire.
Les limites de l'exemple sont les suivantes. Le laboratoire est un modèle de tableur : aucune ressource cloud n'a été créée et aucune donnée client n'a servi. Les prix sont des prix publics de liste pour la région Paris, en dollars, hors taxes, sans remise négociée, sans crédit et sans quota gratuit de transfert sortant : l'exemple surestime donc légèrement le transfert. Le modèle simplifie les services : une seule famille d'instances, une seule tarification régionale pour la seconde région, pas de base de données managée, de journaux, de sauvegardes ni de support payant. Le changement de tarif du S3 au mois 7 (+10 %) est fictif, sans lien avec une annonce d'AWS. Le classeur a été vérifié par recalcul indépendant de ses formules, sans écart sur 216 valeurs comparées.
Cost Explorer fonde sa prévision sur l'usage passé et affiche un intervalle de prédiction de 80 % : cet intervalle n'est pas une précision garantie. Sans historique suffisant, le service n'affiche pas de prévision [3]. L'estimation du calculateur AWS ne couvre que les informations saisies et exclut les taxes : elle ne constitue pas une facture future [4].
Sources
- FinOps Foundation, capacité Forecasting : https://www.finops.org/framework/capabilities/forecasting/, consulté le 8 octobre 2026.
- FinOps Foundation, capacité Budgeting : https://www.finops.org/framework/capabilities/budgeting/, consulté le 8 octobre 2026.
- AWS, Cost Explorer, prévisions : https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html, consulté le 8 octobre 2026.
- AWS, AWS Pricing Calculator, présentation : https://docs.aws.amazon.com/pricing-calculator/latest/userguide/what-is-pricing-calculator.html, consulté le 8 octobre 2026.
- AWS, types de budgets : https://docs.aws.amazon.com/cost-management/latest/userguide/custom-budgets.html, consulté le 8 octobre 2026.
- AWS, créer un budget de coût, alertes sur le réel ou la prévision, coût amorti : https://docs.aws.amazon.com/cost-management/latest/userguide/create-cost-budget.html, consulté le 8 octobre 2026.
- AWS, Amazon EKS, versions de Kubernetes et support étendu : https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html, consulté le 8 octobre 2026.
- AWS, Savings Plans, fonctionnement : https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html, consulté le 8 octobre 2026.
- AWS, Savings Plans, annulation et réservations : https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-ris.html, consulté le 8 octobre 2026.
- AWS, Savings Plans, application de l'engagement : https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html, consulté le 8 octobre 2026.
- AWS, réservations d'instances EC2, tarifs : https://aws.amazon.com/ec2/pricing/reserved-instances/pricing/, consulté le 8 octobre 2026.
- AWS, Cost and Usage Report, lignes de Savings Plans : https://docs.aws.amazon.com/cur/latest/userguide/cur-sp.html, consulté le 8 octobre 2026.
- AWS, Price List API, index des offres ; le laboratoire a lu les fichiers d'offre de la région eu-west-3 qui y sont listés (EC2 publié le 7 octobre 2026, EKS et S3 le 28 septembre 2026, transfert de données le 16 septembre 2026) : https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/index.json, consulté le 8 octobre 2026.