Prévision des coûts cloud : construire un forecast fiable

Quels facteurs font varier les coûts cloud d’un mois à l’autre ?

Avant de prévoir quoi que ce soit, il faut savoir ce qu’on prévoit. Et la plupart des équipes qu’on rencontre confondent deux choses : le montant de la facture, et les leviers qui la font varier. C’est une nuance qui paraît anodine, mais elle change tout dans la façon de construire un forecast.

Une facture cloud, décomposée honnêtement, c’est un empilement de drivers hétérogènes. Il y a le socle, l’infrastructure qui tourne en permanence, prévisible, presque plate d’un mois à l’autre : bases de données de production, environnements toujours-on, réseau. Il y a la couche qui suit l’usage : le trafic, le nombre d’utilisateurs actifs, le volume de données traitées. Et il y a la couche qui suit les décisions produit : une nouvelle fonctionnalité gourmande en calcul, une migration, un nouveau service tiers activé sans qu’on s’en rende vraiment compte (le fameux « on a juste testé Bedrock deux semaines » qui finit par apparaître en ligne récurrente sur la facture).

Le problème, c’est que la majorité des forecasts qu’on audite mélangent ces trois couches dans un seul chiffre global, en se contentant de dire « le mois dernier on était à X, on va mettre X + une marge ». Ça marche tant que rien ne change. Et dans le cloud, quelque chose change tout le temps. Identifier ses drivers, ça veut dire répondre concrètement à une question toute simple : si mon activité doublait demain, quelle part de ma facture doublerait avec elle, et quelle part resterait stable ? Une fois qu’on a cette cartographie même approximative au début, le forecast cesse d’être une boule de cristal pour devenir un calcul.

Une prévision fiable distingue donc cinq composantes : le socle de dépenses récurrentes, les variations d’usage, la saisonnalité, les nouveaux projets et les éventuelles dérives. Ces éléments doivent être estimés séparément avant d’être consolidés dans le forecast global.

Comment intégrer les pics saisonniers dans sa prévision de coûts cloud ?

Il y a quelque chose d’assez ironique dans le fait que la saisonnalité soit à la fois le driver le plus prévisible et celui qui surprend le plus d’entreprises. Un e-commerçant qui découvre en novembre que son infra n’a pas été dimensionnée (ni budgétée) pour le Black Friday, une plateforme SaaS B2B dont l’usage chute chaque été parce que ses clients sont en vacances, une fintech dont les pics de charge suivent le calendrier fiscal : ce sont des patterns connus, documentés, qui reviennent chaque année. Et pourtant, on continue à les traiter comme des surprises.

La raison est presque toujours la même : le forecast est construit sur une base linéaire (le run-rate du mois précédent projeté sur douze mois) sans jamais réintégrer l’historique des années passées. C’est là qu’on insiste beaucoup, en atelier avec nos clients : deux ou trois ans d’historique de facturation cloud, ça vaut de l’or, à condition de le lire correctement. Pas juste « combien on a dépensé en décembre l’an dernier », mais « quel a été le facteur multiplicateur entre le mois calme et le pic, et est-ce que ce facteur est resté stable d’une année sur l’autre ». Un pic saisonnier structurel se répète avec une régularité presque embarrassante une fois qu’on prend la peine de le mesurer.

Ce qui est un peu plus délicat, c’est de distinguer la saisonnalité « métier » (Black Friday, rentrée scolaire, clôture fiscale) de la saisonnalité « technique » des jobs batch mensuels, des traitements de fin de trimestre, des sauvegardes qui montent en volume. Ces deux logiques ne se recoupent pas forcément, et un bon forecast doit les traiter séparément avant de les recombiner. On simplifie souvent trop vite en ne gardant qu’une courbe unique.

Comment estimer le coût cloud d’un nouveau projet avant sa mise en production ?

Voilà le point de friction numéro un entre les équipes techniques et la finance, et honnêtement, on ne va pas se mentir : c’est souvent là que le forecast part complètement en vrille. Un projet est décidé, priorisé, développé et personne n’a formalisé son impact budgétaire avant le jour où il atterrit sur la facture. Ce n’est pas de la mauvaise volonté. C’est juste que l’estimation du coût cloud d’un nouveau projet est rarement intégrée au rituel de cadrage, alors qu’elle devrait l’être au même titre qu’une estimation de charge de développement.

Ce qu’on recommande, très concrètement, c’est d’exiger une fourchette de coût cloud dès la phase de design d’un projet un peu conséquent, pas un chiffre précis à l’euro près, personne n’a cette précision-là avant d’avoir codé quoi que ce soit, mais un ordre de grandeur documenté et une hypothèse de scaling.

Trois questions suffisent en général à dégrossir le sujet : quel est le service cloud principal utilisé et son mode de facturation, quel volume est attendu à trois mois et à un an, et quel est le scénario si l’adoption dépasse largement les attentes (parce que oui, un succès inattendu coûte cher aussi, et c’est un problème qu’on préfère largement à l’inverse).

L’autre réflexe à installer, c’est de traiter les projets comme une ligne à part dans le forecast, distincte du run-rate. Ça permet de visualiser clairement ce qui relève de la continuité d’activité et ce qui relève d’un choix d’investissement et ça évite l’effet loupe où un dérapage de projet vient contaminer la lecture de toute l’infrastructure existante.

Écart de budget cloud : anomalie ponctuelle ou dérive structurelle ?

C’est la question qu’on nous pose le plus souvent en debrief mensuel : « on a dépassé le budget de 12%, c’est grave ? » Et la réponse honnête, c’est : ça dépend entièrement de la nature de l’écart, pas de son ampleur. Un dépassement de 12% causé par un bug d’auto-scaling qui a tourné en boucle pendant trois jours, ce n’est pas la même histoire qu’un dépassement de 12% qui progresse chaque mois depuis un trimestre sans incident identifiable.

Une anomalie, par définition, est ponctuelle et corrigible : une ressource oubliée après un test, une boucle infinie dans du code qui appelle une API facturée à la requête, un environnement de staging qu’on a oublié d’éteindre le week-end. Une fois identifiée, elle se corrige et disparaît du forecast suivant sans laisser de trace durable. Une dérive structurelle, elle, raconte autre chose : une croissance d’usage réelle, une architecture qui devient mécaniquement plus coûteuse à mesure qu’elle grossit, une dette technique qui empile les couches sans jamais être nettoyée. Et celle-là, il faut l’intégrer au forecast, pas la traiter comme un incident à corriger.

Le piège classique, c’est de traiter systématiquement les écarts comme des anomalies parce que psychologiquement, c’est plus confortable de dire « on va corriger ça » que « notre trajectoire de coût a changé et il faut revoir le budget ». On voit régulièrement des entreprises qui accumulent, mois après mois, des « anomalies » qui sont en réalité la même dérive qui continue tranquillement son chemin. La discipline à avoir, c’est de se poser systématiquement la question à J+30 : est-ce que cette anomalie est vraiment repartie à zéro, ou est-ce qu’elle a juste changé de nom ?

Pourquoi adopter un rolling forecast pour piloter son budget cloud ?

Parce qu’un budget annuel construit une fois par an et jamais retouché, dans un environnement aussi mouvant que le cloud, c’est une photo qu’on continue à regarder alors que le paysage a complètement changé. On le dit sans détour : le forecast annuel figé est un exercice largement dépassé pour le cloud, et s’accrocher à ce format, c’est se condamner à des écarts qui grandissent mécaniquement à mesure que l’année avance.

L’alternative, c’est le rolling forecast, une prévision glissante, révisée à intervalle régulier (mensuel dans la grande majorité des cas qu’on accompagne), qui réintègre à chaque cycle les nouvelles données réelles et repousse l’horizon de prévision d’autant. Concrètement : plutôt que de prévoir « 2026 » en décembre 2025 et de vivre avec ce chiffre toute l’année, on prévoit en continu les douze prochains mois glissants, en ajustant chaque mois avec ce qu’on vient d’observer. Ça demande un peu plus de rigueur opérationnelle, on ne va pas le nier, il faut un rituel, un propriétaire du processus, une donnée fiable et à jour. Mais le gain en précision est sans commune mesure, et surtout, ça change complètement la nature de la conversation avec la direction financière : on ne discute plus d’un chiffre qu’on défend becs et ongles parce qu’on l’a voté en janvier, on discute d’une trajectoire qu’on ajuste ensemble.

Ce qu’on observe chez les entreprises qui font cette bascule, c’est un effet secondaire intéressant : les tensions entre finance et tech diminuent nettement. Pas parce que les écarts disparaissent, ils existent toujours mais parce qu’ils sont détectés plus tôt, discutés plus souvent, et donc moins dramatisés. Un écart découvert en semaine 3 se corrige. Un écart découvert en décembre se subit.

Qui doit être responsable de la prévision du budget cloud ?

Et voilà la question qui fâche, celle qu’on pose systématiquement en début de mission parce que la réponse conditionne tout le reste de la démarche FinOps. La réponse courte : ni l’une, ni l’autre, seule. La réponse un peu plus longue, et un peu plus inconfortable pour certaines organisations : la responsabilité du forecast doit être distribuée jusqu’aux équipes qui prennent les décisions techniques qui font varier la facture, pas centralisée entre les mains de la finance, qui n’a ni la visibilité ni le levier pour agir dessus.

On le formule souvent ainsi en atelier : la finance sait compter, mais elle ne sait pas toujours pourquoi ça compte. Les équipes produit et techniques savent pourquoi ça coûte, mais elles n’ont historiquement jamais eu à en rendre compte. Ce découplage est la cause racine de la plupart des dérapages budgétaires qu’on constate. Tant qu’un tech lead ne voit pas l’impact financier de ses choix d’architecture avant de les déployer, et tant qu’un CFO ne comprend pas ce qui, techniquement, fait bouger la ligne « cloud » de son P&L, le forecast restera un exercice de devinette entre deux mondes qui ne se parlent pas.

La bonne pratique, et c’est probablement le point le plus structurant de tout cet article, c’est d’installer une forme de responsabilité produit sur le budget : chaque équipe, ou chaque owner de service, porte son propre bout de forecast, avec une visibilité directe sur son coût et sur ses écarts. La finance garde la vue consolidée et l’arbitrage, mais elle cesse d’être la seule à porter le sujet et surtout, elle cesse d’être perçue comme celle qui vient « punir » les dépassements après coup. Ce changement de posture, à lui seul, transforme souvent plus la culture budgétaire d’une entreprise que n’importe quel outil de tagging ou de dashboard.