Maîtriser les coûts cloud : facturation, rightsizing, engagements et FinOps

Un budget on-premise se décide une fois par an, par des gens dont c'est le métier de décider des budgets. Un budget cloud se décide en continu, par quiconque merge une pull request qui ajoute une politique de rétention, change de famille d'instances ou introduit un appel inter-régions. Le pouvoir de dépenser est passé à l'ingénierie et, dans la plupart des organisations, la responsabilité n'a pas suivi. C'est précisément cet écart que la gestion des coûts vient combler.

Ce guide part de la mécanique pour remonter : comment une facture se construit, ce que chaque compteur facture réellement, comment les engagements et la capacité interruptible changent l'équation, puis les pratiques — rightsizing, politiques de cycle de vie, tagging, budgets et boucle FinOps — qui maintiennent la dépense proportionnelle à la valeur produite. Aucun prix précis n'y figure : les tarifs publics changent et varient selon la région, ce sont les ordres de grandeur et les formes qui restent utiles.

Comment une facture se construit réellement

Une facture cloud est une très longue liste de lignes mesurées, chacune enregistrant un type d'usage, une quantité, un tarif et un identifiant de ressource. Quatre propriétés de cette liste expliquent l'essentiel de la confusion qu'elle suscite.

L'unité de facturation est fine et temporelle. Le calcul est facturé à la seconde ou à l'heure de temps alloué, le stockage au gigaoctet-mois proratisé à l'heure, les requêtes au million, le transfert de données au gigaoctet. Rien n'est facturé par « application » : le lien entre une ligne et une fonction métier n'existe que si vous le créez avec des tags.

Les frais continuent quand une ressource est inactive. Une machine virtuelle arrêtée garde un disque attaché, une adresse IP publique réservée, un snapshot et peut-être un load balancer, et tout cela est facturé. C'est de loin la source la plus fréquente de dépenses oubliées.

Le rapport d'usage détaillé fait foi. Les deux fournisseurs exportent un rapport horaire, au niveau de chaque ligne — AWS Cost and Usage Report, Azure Cost Details — vers un stockage objet, avec environ un jour de décalage. Les tableaux de bord de la console n'en sont que des agrégations : quand un chiffre demande une explication, interrogez l'export.

L'amortissement change la lecture. Un paiement anticipé de capacité réservée apparaît comme une grosse charge sur un seul mois en coûts non combinés (unblended), et se répartit uniformément en coûts amortis. Analysez les tendances en coûts amortis, sinon un seul prépaiement ressemblera à un service qui s'emballe.

-- Cost and Usage Report chargé dans un moteur de requêtes : plus fortes variations d'un mois sur l'autre
SELECT line_item_product_code,
       resource_tags_user_team               AS team,
       SUM(CASE WHEN month = 8 THEN line_item_unblended_cost END) AS prev,
       SUM(CASE WHEN month = 9 THEN line_item_unblended_cost END) AS curr
FROM cur_daily
WHERE line_item_line_item_type = 'Usage'
GROUP BY 1, 2
ORDER BY (curr - prev) DESC NULLS LAST
LIMIT 25;

Deux décisions structurelles simplifient tout ce qui suit : regrouper les comptes ou abonnements sous un même accord de facturation, pour que les paliers de volume et les engagements soient partagés à l'échelle de l'organisation, et séparer les environnements dans des comptes distincts, pour ne jamais avoir à démêler par tag la dépense de production de celle de développement.

Économie unitaire : où part l'argent

Trois compteurs dominent presque toutes les factures.

Le calcul représente généralement la plus grosse part. Vous payez une capacité allouée dans le temps, pas un travail effectué — une machine virtuelle à 4 % de CPU coûte autant qu'à 90 % — si bien que, pour les charges sur serveurs, tout se joue sur le taux d'utilisation. Le comportement au repos diffère nettement selon le modèle d'exécution : machines virtuelles et nœuds de conteneurs sont facturés en continu, tandis que les fonctions serverless ne le sont que pendant leur exécution, à un tarif plus élevé par unité de temps de calcul. Les fonctions l'emportent nettement pour du travail en pics, à faible taux d'activité, et perdent face aux services soutenus à fort débit, où le surcoût par invocation s'accumule.

Le stockage est bon marché au gigaoctet et cher une fois cumulé, parce que rien n'est jamais supprimé. Les compteurs à surveiller sont la capacité, le nombre de requêtes (qui peut dépasser le coût de la capacité pour les charges faisant beaucoup de petites lectures), les frais de récupération sur les classes de stockage froides, les durées minimales de stockage qui vous facturent une suppression anticipée, et les snapshots — incrémentaux, mais conservés indéfiniment tant qu'aucune politique ne les supprime. Le stockage bloc attaché aux machines virtuelles coûte plusieurs fois le prix du stockage objet au gigaoctet, et il est provisionné plutôt que consommé : un disque de 1 To rempli à 5 % coûte autant qu'un disque plein.

Le transfert de données est le compteur qui surprend, parce que sa tarification est directionnelle et asymétrique. Le trafic entrant dans le cloud est généralement gratuit. Entre ressources d'une même zone de disponibilité, il l'est habituellement aussi ; entre zones d'une même région, il coûte un montant modeste, souvent facturé des deux côtés ; entre régions, davantage ; et vers internet, le plus, à un tarif plusieurs fois supérieur au coût inter-régions. Un service mesh bavard réparti sur trois zones, ou un job analytique qui rapatrie chaque nuit un jeu de données depuis un bucket situé dans une autre région, peut générer une facture de transfert supérieure au calcul qui fait le travail.

Deux effets induits méritent d'être nommés. Les NAT gateways facturent chaque gigaoctet traité en plus d'un forfait horaire : y faire passer tout le trafic sortant — y compris celui destiné au stockage objet du fournisseur lui-même — revient à payer une taxe discrète que les private endpoints suppriment. Et les services managés facturent souvent selon une dimension à laquelle vous n'aviez pas pensé : ingestion de logs au gigaoctet, données scannées par requête, unités de débit provisionnées, ou frais par requête sur un coffre à secrets appelé à chaque requête au lieu d'être mis en cache.

Modes d'achat

Pour les charges stables, le prix public n'est le prix payé que si vous ne regardez jamais. Quatre modèles coexistent.

Les engagements sont des instruments financiers, pas techniques : vous vous engagez sur un niveau d'usage ou de dépense horaire pendant un ou trois ans, payé entièrement d'avance, partiellement d'avance ou mensuellement, en échange d'un tarif nettement inférieur. Les durées de trois ans et le paiement anticipé donnent les remises les plus fortes et le moins de marge pour changer d'avis. La règle générale : s'engager sur le plancher de votre courbe d'usage — le niveau dont vous êtes sûr qu'il sera encore consommé dans dix-huit mois — et laisser la part variable en on-demand. Sous-engager fait perdre des économies ; sur-engager fait payer une capacité que vous n'utilisez plus, ce qui est pire, car irréversible.

Préférez l'instrument flexible quand il existe. Un compute savings plan s'applique automatiquement à tout calcul éligible que vous faites tourner : passer des machines virtuelles aux conteneurs ou à une génération d'instances plus récente ne laisse donc pas l'engagement orphelin. Les réservations pour les bases de données, caches et clusters de recherche managés sont en général liées à une configuration précise, et doivent donc être dimensionnées plus prudemment.

La capacité spot est l'inventaire excédentaire du fournisseur, proposé à une fraction du tarif on-demand et repris avec un court préavis. Elle transforme l'économie de tout ce qui est interruptible : runners de CI, batchs analytiques, traitement média, entraînement de modèles de machine learning avec checkpoints, et tiers web stateless capables de perdre une partie de leur flotte. Pour bien l'utiliser : diversifiez sur plusieurs types d'instances et plusieurs zones pour qu'une reprise dans un pool ne vide pas la flotte, traitez l'avis d'interruption pour drainer proprement, posez des checkpoints dans les jobs longs, et combinez un socle de capacité on-demand ou engagée avec un complément en spot.

Rightsizing, planification horaire et autoscaling

Acheter de la capacité moins cher vaut moins que ne pas l'acheter du tout. Trois techniques apportent l'essentiel de la réduction possible dans un parc typique.

Le rightsizing ajuste la capacité provisionnée à l'usage observé. Les deux fournisseurs produisent des recommandations à partir des métriques historiques ; traitez-les comme une liste de départ, car elles voient le CPU et la mémoire, mais pas la fenêtre de batch où la charge a réellement besoin de marge. Regardez l'utilisation maximale et le p99 sur plusieurs semaines plutôt que la moyenne, et ne modifiez qu'une dimension à la fois. Les familles d'instances récentes offrent en général un meilleur rapport performance/coût : un changement de génération est souvent un rightsizing sans contrepartie.

La planification horaire éteint ce que personne n'utilise. Les environnements hors production utilisés aux heures de bureau sont inactifs environ les deux tiers de la semaine ; les arrêter en dehors des heures ouvrées supprime cette part de leur coût de calcul. C'est l'action au meilleur rendement et au plus faible risque dans la plupart des organisations, et elle a besoin d'un responsable, car elle n'arrive jamais spontanément.

# Poser le tag une fois, puis arrêter selon un planning tout ce qui le porte
aws ec2 create-tags --resources i-0a1b2c3d --tags Key=schedule,Value=office-hours

ids=$(aws ec2 describe-instances \
  --filters "Name=tag:schedule,Values=office-hours" "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].InstanceId' --output text)
[ -n "$ids" ] && aws ec2 stop-instances --instance-ids $ids

L'autoscaling est un levier de coût autant que de disponibilité, mais seulement s'il sait réduire. Beaucoup de parcs montent en charge sous la pression et ne redescendent jamais, parce que la politique de scale-in est absente, trop prudente, ou bloquée par des connexions longues. Vérifiez que la capacité baisse effectivement la nuit ; si la courbe est un escalier qui ne fait que monter, la politique ne fait pas son travail. Sur Kubernetes, la même logique s'applique à deux niveaux — autoscaling des pods sur des métriques réelles, et cluster autoscaler autorisé à supprimer des nœuds — avec en plus des requests honnêtes, puisque des requests surdéclarées réservent une capacité facturée et jamais utilisée. Voir les fondamentaux de Kubernetes pour la mécanique.

Le cycle de vie du stockage en est l'équivalent pour les données. Écrivez une politique qui fait basculer les objets vers des classes de stockage plus froides à mesure qu'ils vieillissent et les supprime à la fin de leur durée de rétention, et appliquez le même raisonnement aux snapshots, aux images de conteneurs dans les registres et à la rétention des logs. L'ingestion de logs et de télémétrie figure souvent parmi les cinq premières lignes de la facture ; échantillonner les traces, supprimer les logs de niveau debug en production et raccourcir la rétention à chaud en archivant vers le stockage objet la réduisent généralement de beaucoup, sans perdre la capacité d'investiguer. Les plateformes analytiques facturées à l'octet scanné réagissent spectaculairement au partitionnement et aux formats colonnaires, comme expliqué dans l'architecture big data.

Répartition : tags, showback et chargeback

Impossible de déléguer la responsabilité des coûts à une équipe qui ne voit pas les siens, et cette visibilité dépend entièrement de la répartition.

Définissez un petit jeu de tags obligatoires — typiquement responsable ou équipe, environnement, application ou service, centre de coûts et classification des données — et imposez-le à la création plutôt que de l'auditer après coup. Les moteurs de politiques des deux plateformes peuvent refuser la création de ressources non taguées, et les modules d'infrastructure as code peuvent appliquer les tags par défaut, pour que la conformité soit la voie de moindre résistance. Activez ces tags comme tags de répartition des coûts dans la console de facturation, sans quoi ils n'apparaissent jamais dans les rapports.

Une partie de la dépense est réellement partagée : le hub réseau, la plateforme d'observabilité, l'outillage de sécurité, la remise issue des engagements. Décidez et publiez une règle de répartition — à parts égales, à l'usage, par équipe ou laissée dans un pool central — avant que quiconque n'en débatte. L'objectif n'est pas une répartition parfaite, mais une règle que tout le monde comprend.

Le showback publie la dépense de chaque équipe sans transfert d'argent, et suffit à la plupart des organisations pour faire évoluer les comportements. Le chargeback impute réellement le coût au budget de l'équipe, ce qui crée des incitations plus fortes et nettement plus de débats ; il ne vaut la peine que lorsque les équipes ont un vrai pouvoir budgétaire.

Le chiffre qui change les conversations n'est pas la dépense totale, mais le coût unitaire : coût par client actif, par millier de commandes, par gigaoctet ingéré. Une dépense totale en hausse de 20 % avec un coût unitaire en baisse de 10 %, c'est une entreprise en croissance qui gagne en efficacité. Sans le dénominateur, chaque hausse ressemble à un échec et chaque baisse à une victoire.

Budgets, anomalies et boucle FinOps

Définissez des budgets par compte, par équipe et par service majeur, avec des alertes à plusieurs seuils et sur la prévision plutôt que sur la seule dépense réelle — une alerte sur prévision le 8 du mois est utile, une alerte sur dépense réelle le 29 est un post-mortem. Ajoutez par-dessus la détection d'anomalies : les deux fournisseurs proposent une détection fondée sur le machine learning qui signale un service dont la dépense s'écarte de son propre profil, et c'est ce qui permet de repérer un cluster provisionné par erreur ou une boucle de retry emballée en une journée plutôt qu'en fin de mois.

Le FinOps, nom sous lequel la pratique est généralement connue, décrit une boucle récurrente en trois phases. Informer : répartition, tableaux de bord, métriques unitaires, prévisions — chacun voit ses propres chiffres. Optimiser : rightsizing, planification horaire, achats d'engagements, évolutions d'architecture, chaque action ayant un responsable et une économie estimée. Opérer : en faire un processus continu — le coût comme point des revues d'architecture, une estimation de coût jointe aux changements d'infrastructure significatifs, une revue périodique du portefeuille d'engagements, et des garde-fous qui empêchent les pires erreurs. Le pilier coût du Well-Architected Framework traduit cette même boucle en questions de revue.

Les mauvaises surprises à anticiper

Les ressources oubliées. Load balancers sans cible, disques non attachés, NAT gateways inactives, snapshots d'une migration vieille de deux ans, cluster de proof of concept dans une région que personne ne surveille. Recherchez-les selon un planning ; elles ne disparaissent jamais d'elles-mêmes.

Le bavardage inter-zones et inter-régions. Un mesh de microservices réparti sur plusieurs zones pour la disponibilité démultiplie le transfert inter-zones. Un routage qui tient compte des zones et privilégie un réplica local en supprime l'essentiel.

L'egress d'un service gourmand en données. Servir des médias ou de gros exports directement depuis le stockage objet vers internet fait compter chaque octet. Un CDN placé devant est généralement moins cher, en plus d'être plus rapide.

L'explosion des logs et des métriques. Un seul flag de debug oublié en production, ou un label de métrique à forte cardinalité comme un identifiant utilisateur, peut multiplier une facture d'observabilité du jour au lendemain.

Des frais par requête appelés en boucle. Les coffres à secrets, les magasins de paramètres et les services de gestion de clés facturent chaque appel d'API. Récupérer un secret à chaque requête au lieu de le mettre en cache transforme une ligne négligeable en ligne bien visible.

Le hors-production laissé allumé. Presque universel, entièrement évitable, et généralement la plus grosse économie disponible lors d'une première revue des coûts.

Points clés à retenir

• Une facture cloud est un journal de compteurs très fin ; l'export d'usage détaillé fait foi, et les ressources inactives restent facturées jusqu'à leur suppression.
• Le calcul est facturé au temps alloué quel que soit le taux d'utilisation, le stockage s'accumule parce que rien n'est supprimé, et le transfert de données est directionnel et asymétrique — l'egress et le trafic inter-régions dominent.
• Engagez-vous sur le plancher de l'usage stable avec des savings plans flexibles, réservez les ressources fixes et durables, et faites tourner le travail interruptible en spot, avec diversification et gestion des interruptions.
• Ne pas acheter de capacité vaut mieux que l'acheter moins cher : dimensionnez d'après les pics observés, éteignez le hors-production en dehors des heures ouvrées, vérifiez que l'autoscaling sait réduire, et faites expirer les données avec des politiques de cycle de vie.
• Imposez un petit jeu de tags obligatoires dès la création, publiez un showback par équipe et suivez le coût unitaire, pour ne pas confondre croissance et gaspillage.
• Le FinOps est une boucle continue informer, optimiser, opérer, adossée à des budgets sur prévision et à des alertes d'anomalie qui font remonter les erreurs en quelques jours plutôt qu'en fin de mois.