Réduire les coûts cloud sans commencer par un chantier FinOps
Un réflexe de diagnostic pour repérer ce qui étonne dans une facture cloud, notamment les ressources qui tournent en continu pour un usage réel intermittent.
Quand une facture cloud monte, on peut vite partir vers un chantier FinOps.
On peut regarder les réservations, changer des tailles d’instances, ajouter des tableaux de bord, chercher une optimisation plus propre, plus technique, plus complète.
Parfois, c’est nécessaire.
Mais avant d’ouvrir ce chantier, on peut regarder d’abord ce qui tourne en continu sans vraie raison.
Dans un cas récent, le sujet n’arrivait même pas comme une demande de réduction cloud. Il arrivait par un problème plus large côté dev et infra : l’équipe avait du mal à livrer vite, et la première piste était de revoir toute la trajectoire Docker, du poste développeur jusqu’à la production.
En creusant, une autre question est apparue dans la roadmap : pourquoi certains environnements bêta et préprod restaient-ils allumés en permanence ?
La disponibilité avait une raison
Le point important, c’est que personne n’avait “oublié” ces serveurs.
La personne responsable de l’infrastructure était compétente. Elle avait déjà cherché comment les éteindre proprement, sans trouver de solution satisfaisante à ce moment-là.
Ces environnements restaient disponibles pour une raison compréhensible : des clients devaient pouvoir tester sans faire une demande spéciale, sans attendre quelqu’un, et sans risquer de tomber sur une indisponibilité au mauvais moment.
Commercialement, cela se défendait.
Le problème, c’est que l’usage réel ne ressemblait pas à cette disponibilité permanente. Les environnements servaient quelques heures par jour pendant les périodes de test, puis pouvaient rester inutilisés pendant quatre ou cinq mois.
Le reste du temps, ils faisaient exactement ce qu’on leur demandait : ils tournaient.
Le coût était noyé dans la masse
Une facture AWS ne raconte pas toujours une histoire lisible.
Elle additionne des services, des usages, des habitudes, des environnements, des décisions anciennes et des contraintes commerciales. Un coût récurrent peut rester visible dans la facture, mais invisible dans les décisions.
C’était le cas ici.
Le coût des environnements bêta et préprod n’était pas spectaculaire ligne par ligne. Il était noyé dans la masse des charges AWS. Mais dans un contexte où les frais augmentent et où l’argent rentre moins facilement, une somme à libérer chaque mois commence à compter.
L’économie identifiée était d’environ 1500 euros par mois dans cette configuration précise.
Ce chiffre ne prouve pas qu’une revue infra fera toujours baisser une facture de 10 %, ni qu’il suffit d’éteindre quelques serveurs pour régler un sujet cloud. Il montre autre chose : un coût défendable à un moment peut devenir disproportionné quand l’usage réel change ou devient plus rare qu’on ne le pensait.
Le levier était plus simple
La réponse n’était pas de refaire toute l’infrastructure, c’était simplement de rendre ces environnements activables à la demande, prévoir une extinction automatique, et documenter clairement qui peut les allumer, quand, et avec quelles précautions.
Ce genre de sujet demande quand même du sérieux.
Avant d’éteindre une ressource, il faut comprendre ce qui dépend d’elle, qui sera prévenu, ce qui se passe si un client teste au mauvais moment, et comment revenir en arrière si l’automatisme se trompe.
Ce n’est pas parce qu’une solution est petite qu’elle doit être bricolée.
Mais ce n’est pas non plus parce qu’un sujet touche au cloud qu’il doit devenir un grand programme.
Les questions à poser avant de couper
Avant de proposer une suite, quelques questions simples évitent de décider trop vite.
Qu’est-ce qui tourne tout le temps ?
Qui l’utilise vraiment ?
À quelle fréquence ?
Que se passe-t-il si ce n’est pas disponible immédiatement ?
Qui peut l’allumer ?
Qui sait l’éteindre ?
Quelle erreur serait gênante : client bloqué, oubli d’extinction, perte de contexte, dépendance mal comprise ?
Ces questions évitent deux mauvais réflexes.
Le premier serait de lancer une optimisation cloud trop large alors qu’un levier court existe déjà.
Le deuxième serait de couper trop vite une ressource qui sert à tenir une promesse commerciale ou opérationnelle.
Dans ce cas, le sujet utile était plus simple et plus concret : arrêter de payer en continu pour un usage très intermittent, sans casser l’expérience client.
Ma règle est là : avant de parler FinOps, je cherche tout ce qui m’étonne chez mes clients. Ici, ça m’a étonné de voir que quelque chose tournait en permanence avec un usage très ponctuel, alors j’ai creusé.