8 étapes pour reprendre la main sur une facture cloud qui a triplé — avant même de parler de réservations

La conversation commence presque toujours de la même façon. La facture a doublé ou triplé en douze mois, le trafic n’a pas bougé dans les mêmes proportions, et quelqu’un a lu quelque part que les instances réservées permettent d’économiser 40 %. La tentation est alors de signer un engagement de trois ans pour faire baisser la ligne du mois prochain.

C’est exactement ce qu’il ne faut pas faire en premier. Un engagement pluriannuel posé sur une consommation gaspilleuse ne supprime pas le gaspillage : il le fige au tarif remisé, et vous retire la liberté de supprimer les ressources concernées. La méthode ci-dessous suit donc un ordre strict, où la négociation tarifaire n’intervient qu’à la huitième et dernière étape.

Étape 1 — Rendre la facture lisible avant de la juger

Personne ne peut optimiser ce qu’il ne comprend pas. Commencez par activer l’export détaillé de facturation de votre fournisseur, avec la granularité la plus fine disponible, et chargez-le dans un outil où vous pouvez faire des regroupements — un tableur suffit au démarrage si votre facture tient en quelques milliers de lignes.

L’objectif de cette étape n’est pas d’économiser un euro. Il est de pouvoir répondre à trois questions : quels sont les dix postes les plus coûteux, comment chacun a évolué sur six mois, et lequel a augmenté le plus vite en relatif. Ce troisième point est celui qui révèle les surprises — un poste qui pèse 3 % de la facture mais qui a été multiplié par huit mérite votre attention avant celui qui pèse 30 % et qui est stable.

Étape 2 — Attribuer chaque euro à un responsable identifié

Une facture cloud non attribuée est une facture que personne ne défend. Mettez en place une politique d’étiquetage minimale : équipe propriétaire, environnement, et application. Trois étiquettes suffisent au début ; une taxonomie à douze dimensions ne sera jamais appliquée correctement.

Le point critique est le taux de couverture. Tant qu’une part significative de vos ressources n’est pas étiquetée, vos analyses porteront sur la partie visible et rateront précisément là où se cache le gaspillage. Rendez l’étiquetage obligatoire à la création, via votre outil d’infrastructure déclarative, plutôt que de courir après les ressources existantes à la main.

Étape 3 — Éteindre ce qui ne sert à personne

C’est l’étape au meilleur rapport gain/risque, et pourtant celle qu’on repousse par crainte de casser quelque chose. Les suspects habituels sont toujours les mêmes : disques persistants détachés de toute machine, adresses IP réservées et non utilisées, instantanés de sauvegarde accumulés depuis des années, répartiteurs de charge sans cible active, bases de données de test créées pour une démonstration, et clusters laissés en place après une migration.

La méthode qui évite l’accident : au lieu de supprimer directement, isolez d’abord. Coupez le trafic, renommez avec un préfixe explicite et une date, attendez deux semaines. Si personne ne s’est manifesté, supprimez. Ce délai de grâce transforme une décision anxiogène en procédure routinière, et c’est ce qui fait qu’elle sera réellement appliquée.

Étape 4 — Redimensionner sur des mesures, pas sur des impressions

Le surdimensionnement est structurel : au moment de créer une ressource, personne ne connaît la charge réelle, donc on prend de la marge — et cette marge n’est jamais réexaminée. Récupérez les mesures d’utilisation processeur et mémoire sur une fenêtre d’au moins trente jours, en regardant les percentiles hauts plutôt que la moyenne.

La moyenne est trompeuse : une machine à 8 % d’utilisation moyenne peut saturer chaque lundi matin. Le percentile 95 sur trente jours donne une image bien plus fidèle du besoin réel. Descendez d’un cran de gamme à la fois, en surveillant les latences applicatives, plutôt que de viser directement la taille théoriquement optimale.

Attention à un piège fréquent : sur beaucoup de services managés, la mémoire et le processeur ne se dimensionnent pas indépendamment, et une charge limitée par la mémoire vous oblige à payer du processeur inutile. C’est souvent le signal qu’un changement de famille d’instances, plus que de taille, est la bonne réponse.

Étape 5 — Traiter le stockage et ses classes

Le stockage a une propriété désagréable : il ne fait jamais de bruit. Une base de données qui ralentit provoque des tickets ; un compartiment de stockage qui gonfle de 2 % par semaine ne provoque rien du tout, jusqu’au jour où il représente le deuxième poste de la facture.

Trois leviers, par ordre d’efficacité. D’abord, les règles de cycle de vie : basculer automatiquement vers une classe moins chère les objets non consultés depuis un seuil donné, et supprimer ceux dont la conservation n’a plus de justification. Ensuite, les versions d’objets : quand le versionnement est actif, chaque écrasement conserve l’ancienne version, et la facture peut être plusieurs fois supérieure à la taille apparente des données. Enfin, les instantanés de sauvegarde, dont la politique de rétention est très souvent restée sur les valeurs par défaut.

Sur ce dernier point, tranchez la question avec les personnes qui portent le risque, pas seulement avec l’équipe technique : la durée de conservation est une décision de continuité d’activité et parfois de conformité. Nos confrères de WebGuard Agency documentent régulièrement les obligations qui s’appliquent selon les secteurs, et elles fixent souvent un plancher que l’optimisation ne doit pas franchir.

Étape 6 — Traquer les transferts de données

C’est le poste le plus mal compris, parce qu’il est invisible dans l’architecture. Les données qui entrent sont généralement gratuites ; celles qui sortent vers Internet sont facturées, et celles qui circulent entre zones ou régions le sont également, souvent à un tarif que personne n’avait anticipé.

Les causes classiques d’une facture de transfert anormale : des services très bavards répartis sur plusieurs zones de disponibilité sans nécessité, des sauvegardes répliquées vers une autre région à une fréquence excessive, un stockage d’objets servi directement aux utilisateurs sans réseau de diffusion en amont, et des journaux applicatifs expédiés vers un service tiers hébergé chez un autre fournisseur.

Le réflexe utile est de dessiner les flux de données réels — pas ceux du schéma d’architecture d’origine, ceux que montre la facture. L’écart entre les deux est régulièrement la découverte la plus rentable de tout l’exercice.

Étape 7 — Planifier les environnements hors production

Les environnements de développement, de recette et de démonstration tournent presque toujours vingt-quatre heures sur vingt-quatre, alors qu’ils ne servent que pendant les heures ouvrées. Une extinction automatique le soir et le week-end supprime mécaniquement une part importante de leur coût, sans aucune négociation ni changement d’architecture.

Deux conditions pour que ça tienne dans la durée. D’une part, l’extinction doit être réversible en une commande ou un clic, faute de quoi elle sera désactivée à la première urgence. D’autre part, prévenez explicitement les équipes distantes ou les prestataires qui travaillent sur d’autres fuseaux horaires — c’est la cause numéro un d’abandon de cette mesure après trois semaines.

Pour les projets où les environnements se multiplient naturellement — plateformes multi-clients, places de marché avec espaces de recette dédiés —, cette étape devient structurante dès la conception. Nous l’abordons sous cet angle dans notre guide créer une marketplace, où le coût des environnements croît avec le nombre de clients si rien n’est planifié.

Étape 8 — Souscrire les engagements, enfin

Vous avez maintenant une consommation nettoyée, dimensionnée et attribuée. C’est seulement à ce stade qu’un engagement pluriannuel devient un bon investissement, parce qu’il porte sur une base dont vous êtes raisonnablement certain qu’elle existera encore dans deux ans.

Deux principes de prudence. Premièrement, ne couvrez jamais 100 % de votre consommation par des engagements : visez le socle stable, celui que vous consommez même au creux de l’année, et laissez le reste à la demande. Deuxièmement, privilégiez au démarrage les formules les plus souples, même si la remise affichée est inférieure — la valeur de la flexibilité se révèle le jour où votre architecture change, et elle change toujours.

Un dernier point souvent ignoré : la charge d’inférence des composants d’IA, quand elle existe, obéit à une logique de coût différente du reste et se prête mal aux engagements classiques. Les confrères de Plug-Tech détaillent régulièrement pourquoi ces charges méritent leur propre suivi plutôt que d’être noyées dans la ligne « calcul ».

Récapitulatif : le premier mois

Semaine 1, faites les étapes 1 et 2 : export de facturation exploitable et politique d’étiquetage appliquée à la création. Semaine 2, l’étape 3, avec le délai de grâce de deux semaines qui court en parallèle. Semaines 3 et 4, les étapes 4 à 6, qui demandent des mesures et donc du temps d’observation. L’étape 7 s’installe dès qu’une personne peut écrire le planificateur. L’étape 8 attend le mois suivant, quand la consommation s’est stabilisée à son nouveau niveau.

Ce séquencement paraît lent comparé à la promesse d’une remise immédiate. Il produit pourtant des économies qui tiennent, parce qu’elles reposent sur la suppression d’un besoin plutôt que sur la négociation de son prix.

Questions fréquentes

Pourquoi ne pas commencer par les instances réservées ?

Parce qu’un engagement pluriannuel sur une consommation gaspilleuse fige le gaspillage au tarif remisé. Une remise de 40 % sur des machines surdimensionnées de 300 % reste une mauvaise affaire, et vous perdez la liberté de les supprimer. Engagez-vous uniquement sur la consommation résiduelle, après nettoyage et redimensionnement.

Combien peut-on espérer économiser réellement ?

Sur une infrastructure jamais optimisée, 25 à 40 % sans dégrader le service est un objectif réaliste, dont une bonne moitié provient de la suppression de ressources orphelines et du redimensionnement. Sur une infrastructure déjà travaillée, les marges tombent à quelques pourcents et l’effort se déplace vers l’architecture applicative.

Faut-il un outil FinOps payant ?

Pas pour commencer. Les consoles natives permettent déjà l’export détaillé, le regroupement par étiquette et la détection des ressources inutilisées. Un outil tiers devient pertinent avec plusieurs comptes ou plusieurs fournisseurs, et pour automatiser la refacturation interne. Sans politique d’étiquetage propre, vous paierez surtout pour visualiser du désordre.

Qui doit porter le sujet dans une équipe de quinze personnes ?

Une personne identifiée à temps très partiel, plutôt qu’un comité. Le rôle : publier chaque mois la répartition des coûts par équipe et animer une revue de trente minutes qui produit au moins une action datée. Le bon profil est un ingénieur qui comprend la facture, avec un relais explicite côté finance.