Réduire sa facture cloud : un plan d'action pratique
Les factures cloud explosent rarement en un jour. Elles dérivent : un environnement de test que personne n'a arrêté, une base dimensionnée pour un lancement qui n'a jamais eu lieu, des journaux conservés indéfiniment, des données copiées un milliard de fois par mois entre zones. Bonne nouvelle : les premières économies sont souvent les plus faciles. Ce plan ordonne le travail, des gains rapides aux changements structurels, et explique comment conserver les économies une fois l'équipe projet partie.
D'abord, savoir où part l'argent
On ne réduit pas ce que l'on ne voit pas. Avant toute optimisation :
- Exportez les données de facturation détaillées (AWS Cost and Usage Report, exports de coûts Azure, export de facturation Google Cloud vers BigQuery). La spécification FOCUS de la FinOps Foundation propose un format commun entre fournisseurs, utile si vous utilisez plusieurs clouds.
- Étiquetez les ressources par équipe, produit et environnement, et imposez-le par politique. Une dépense sans étiquette est une dépense sans responsable. Notre guide de l'allocation des coûts décrit le modèle d'étiquetage.
- Classez les services par dépense. Dans la plupart des environnements, une poignée de services (calcul, bases managées, stockage, transfert de données) représente l'essentiel de la facture. Commencez par là.
Une première vue utile : un tableau avec une ligne par équipe et par environnement, le coût mensuel et la tendance d'un mois sur l'autre. La séparation production / hors production est souvent la plus révélatrice.
Extrait de la fiche « Tagging, Advisor and Cost Optimization » · Demander la fiche complète
Vague 1 : gains rapides (semaines 1 à 4)
Aucun changement d'architecture, peu de risque.
| Levier | Ce qu'il faut chercher | Comment |
|---|---|---|
| Ressources inactives | Volumes non attachés, vieux snapshots, IP publiques inutilisées, load balancers sans trafic, instances arrêtées avec stockage attaché, environnements de test oubliés | Conseillers des fournisseurs (AWS Trusted Advisor et Compute Optimizer, Azure Advisor, Google Cloud Recommender), plus un script listant les ressources sans étiquette de responsable |
| Horaires hors production | Environnements de développement et de test allumés la nuit et le week-end | Arrêt et démarrage automatiques ; un fonctionnement aux seules heures ouvrées ne laisse tourner qu'environ un tiers de la semaine |
| Redimensionnement | Instances et bases peu sollicitées en CPU et mémoire sur plusieurs semaines | Réduire d'un cran à la fois, surveiller les performances, recommencer |
| Classes de stockage | Données rarement lues mais stockées en niveau chaud | Règles de cycle de vie vers les niveaux accès peu fréquent ou archive ; hiérarchisation automatique si l'accès est imprévisible (voir le coût des niveaux de stockage) |
| Types de volumes | Générations anciennes de stockage bloc | Migrer vers les générations actuelles (par exemple gp2 vers gp3 sur AWS, qui découple performance et taille) |
| Rétention des journaux | Journaux conservés sans limite dans des niveaux coûteux | Fixer une rétention par groupe de journaux ; archiver ce que la loi impose |
| Familles récentes | Les anciennes générations coûtent souvent plus cher par unité de performance | Passer aux générations actuelles, y compris ARM quand le logiciel le permet |
Le redimensionnement demande de la prudence : mesurez les pics, pas les moyennes, et associez le responsable de l'application. Une base réduite qui ralentit la clôture mensuelle coûte plus qu'elle ne rapporte.
Vague 2 : engagements (mois 1 à 3)
Une fois l'environnement nettoyé et redimensionné, engagez-vous sur le socle. S'engager avant de nettoyer revient à figer le gaspillage.
| Fournisseur | Mécanismes |
|---|---|
| AWS | Savings Plans (Compute, EC2 Instance), Reserved Instances pour bases et caches, Spot pour les traitements interruptibles |
| Azure | Réservations, Savings Plan for compute, machines virtuelles Spot |
| Google Cloud | Committed use discounts (par ressource ou par montant), remises automatiques d'usage soutenu sur certaines familles, VM Spot |
Les fournisseurs annoncent des remises atteignant environ 70 % sur certains engagements de trois ans, et davantage pour la capacité Spot, mais les chiffres réels dépendent de la famille, de la région et de la durée : vérifiez les pages tarifaires à jour ou notre comparateur de prix cloud.
La règle de décision pour une ressource :
Ub = Pe / Pd
où Ub est le taux d'utilisation d'équilibre (part des heures de la période d'engagement pendant laquelle la ressource doit tourner, entre 0 et 1), Pe le prix horaire effectif avec engagement (EUR par heure, paiement initial réparti sur la durée) et Pd le prix horaire à la demande (EUR par heure). Si la ressource tournera plus que Ub du temps sur toute la période, l'engagement est gagnant.
Règles pratiques :
- N'engagez que le plancher de votre consommation, la part qui ne disparaît jamais. Couvrez le reste à la demande ou en Spot.
- Préférez les instruments souples (savings plans sur tout le calcul) tant que l'architecture évolue.
- Revoyez chaque mois la couverture et l'utilisation ; un engagement inutilisé est une perte sèche.
Extrait de la fiche « Azure Pricing and Purchase Options » · Demander la fiche complète
Vague 3 : transferts de données et lignes cachées
Les frais réseau sont la partie la moins comprise d'une facture. Cherchez :
| Poste | Cause fréquente | Correction |
|---|---|---|
| Egress internet | Fichiers volumineux ou API servis directement depuis le calcul | CDN en frontal, compression, cache |
| Transferts inter-zones | Services bavards répartis entre zones de disponibilité | Routage par zone pour le trafic interne volumineux, en gardant la résilience multi-zones là où elle compte |
| Traitement NAT | Charges privées qui récupèrent images, paquets ou appellent les API cloud via NAT | Points d'accès privés pour le stockage et les registres, caches locaux |
| Réplication inter-régions | Réplication activée « au cas où » | La conserver seulement là où les objectifs de reprise l'exigent |
Notre article sur la comparaison honnête des prix cloud montre comment l'egress, les plans de contrôle et les load balancers modifient le coût réel d'une offre.
Vague 4 : changements d'architecture (mois 3 à 12)
Les économies les plus importantes viennent de la façon dont les systèmes sont construits. Ce sont aussi les plus longues, et chaque changement mérite son analyse de rentabilité.
- Autoscaling sur des signaux de demande réels plutôt qu'une capacité fixe dimensionnée pour les pics.
- Conteneurs et mutualisation sur un cluster Kubernetes partagé, avec requêtes et limites fixées à partir de mesures.
- Serverless pour les charges irrégulières ou faibles, en surveillant le prix par requête à fort volume.
- Service managé ou autogéré : une base managée coûte plus cher à l'heure mais moins en temps d'exploitation ; la comparaison doit inclure les personnes.
- Conception de la plateforme data : partitionnement, clustering et modèles incrémentaux réduisent souvent les coûts d'entrepôt bien plus qu'une remise (voir dimensionnement des bases et FinOps).
- Consolidation : moins d'environnements, plus grands et partagés, plutôt qu'une pile complète par développeur.
Durer : l'organisation FinOps
Les économies s'évaporent en quelques mois si personne n'en est responsable. Le cadre de la FinOps Foundation décrit trois phases itératives (Informer, Optimiser, Opérer) et une responsabilité partagée entre ingénierie, finance et produit. Socle minimal pour une PME ou une ETI :
| Élément | Minimum |
|---|---|
| Responsable | Un référent FinOps nommé (à temps partiel, c'est suffisant) avec un sponsor à la finance ou à la direction |
| Visibilité | Coût par équipe et par produit, publié chaque mois |
| Budgets et alertes | Budgets par compte ou projet avec alertes sur dépassement prévisionnel |
| Garde-fous | Étiquettes obligatoires, régions restreintes, familles d'instances autorisées, arrêt automatique hors production |
| Rituels | Revue mensuelle des plus fortes variations et de la couverture des engagements |
| Coût unitaire | Coût par client, par transaction ou par gigaoctet traité, pour distinguer croissance et gaspillage |
Plus de détails sur le modèle opérationnel dans notre guide FinOps.
Extrait de la fiche « The FinOps Framework on Azure » · Demander la fiche complète
Ce qu'une mission de réduction des coûts doit livrer
- Un état initial : dépense par service, équipe et environnement, avec les règles d'allocation
- Une liste d'économies classée, chacune avec impact mensuel estimé, effort et risque
- Les gains rapides mis en œuvre, de préférence en code (horaires, règles de cycle de vie, politiques)
- Un plan d'engagements avec des cibles de couverture
- Des tableaux de bord et alertes remis à votre équipe
- Une remesure après un ou deux cycles de facturation
Signaux d'alerte
- Une rémunération au pourcentage des économies, sans plafond ni fin : elle récompense les coupes ponctuelles et peut coûter plus que les économies dans la durée.
- Des engagements vendus avant le nettoyage : vous figez le gaspillage pour un à trois ans.
- Un redimensionnement sans données de performance : des économies qui reviennent sous forme d'incidents.
- Un rapport sans mise en œuvre : la facture ne baisse que quand quelqu'un modifie une ressource.
Notre accompagnement
Le volet CI/CD et FinOps de Tadata couvre la visibilité des coûts, la mise en œuvre des gains rapides en code, la planification des engagements et les garde-fous ; voir notre page Cloud & DevOps. Pour comparer fournisseurs et régions, commencez par notre comparateur de prix cloud.