Le coût dès le code : tags, estimation, durée de vie

Le moment le moins cher pour parler de coût est la revue du code, pas la facture du mois suivant. Une pull request qui ajoute une machine, un disque ou un environnement décide d'une dépense récurrente : autant la voir avant l'apply. Cette leçon montre trois leviers qui s'écrivent dans le code : des étiquettes obligatoires qui disent à qui appartient chaque ressource, une estimation du coût produite au moment du plan, et une durée de vie pour tout ce qui est temporaire. Le suivi de la facture, la refacturation et la démarche FinOps complète relèvent de la formation Cloud. Le scénario est celui de l'équipe de quatre personnes : une application web (deux VM, une base, un réseau, un DNS) en dev et prod, infrastructure en cours de passage au code.

Ce que vous allez apprendre

• expliquer pourquoi le coût se traite à la revue du code ;
• définir des étiquettes obligatoires et les faire respecter ;
• placer une estimation de coût dans la pull request ;
• donner une durée de vie à un environnement éphémère ;
• repérer les coûts que le code ne montre pas.

Les extraits de code sont des illustrations à lire, pas des étapes à exécuter.

Pourquoi parler de coût dès le code ?

Parce que le code d'IaC est la décision de dépense. Dans une infrastructure déclarée, créer une ressource, c'est écrire quelques lignes ; la facture qui suit n'est visible nulle part dans la pull request. Sans signal au moment du changement, le coût n'apparaît qu'après coup, mélangé à celui de toute l'organisation, et plus personne ne retrouve qui a décidé quoi.

Le coût dès le code (parfois appelé shift-left du coût : le décaler vers l'amont) suit la même logique que les tests et les politiques. On détecte tôt ce qui coûtera cher à corriger tard. Une machine surdimensionnée repérée en revue se corrige en une ligne ; la même machine découverte après trois mois de facturation a déjà coûté trois mois.

Il ne s'agit pas de faire de chaque développeur un contrôleur de gestion. L'objectif est modeste : rendre le coût attribuable (à qui appartient cette ressource ?), visible (que coûte ce changement ?) et borné (jusqu'à quand existe-t-elle ?). Les trois leviers qui suivent répondent à ces trois questions. Pour comprendre d'où viennent les postes de dépense (VM à l'heure, stockage, trafic sortant), voir Pay-as-you-go : décrypter les modèles tarifaires cloud. La démarche d'ensemble, avec les leviers de réduction et le suivi des dérives, est traitée dans Maîtriser la facture cloud.

Quelles étiquettes rendre obligatoires ?

Une étiquette (appelée tag ou label selon le fournisseur) est une paire clé-valeur attachée à une ressource. Elle ne change rien au fonctionnement, mais elle permet de regrouper et d'attribuer : la facture peut être ventilée par équipe, par application ou par environnement uniquement si les ressources portent ces informations.

Pour le scénario, on reprend les trois étiquettes de la formation Cloud, environnement, equipe et projet (Garde-fous, héritage des politiques et étiquetage), et on en ajoute une, propre à l'IaC : expire_le, qui donne une durée de vie à chaque ressource.

Étiquette	Contenu	Question à laquelle elle répond
environnement	dev ou prod	Puis-je y toucher sans risque ?
equipe	Équipe responsable	Qui prévenir ?
projet	Nom du projet ou de l'application	Qui paie ?
expire_le	Date au format AAAA-MM-JJ, ou valeur permanent	Jusqu'à quand cette ressource doit-elle exister ?

Glissez pour voir

Une étiquette n'a de valeur que si elle est présente partout. Inutile de compter sur la bonne volonté : on la fait imposer par le code et par une règle. Dans les modules versionnés vus dans Modules réutilisables, le module demande environnement, equipe et projet comme entrées obligatoires et les applique à chaque ressource qu'il crée. Une règle de policy as code refuse ensuite tout plan qui crée une ressource sans les étiquettes attendues.

Attention aux limites : toutes les ressources ne sont pas étiquetables, et chaque fournisseur a ses contraintes de syntaxe et de longueur. La leçon Garde-fous, héritage des politiques et étiquetage en traite côté cloud.

Comment estimer le coût d'un changement avant l'apply ?

Une estimation de coût calcule, à partir du plan, ce que coûteraient les ressources créées ou modifiées, et la différence avec l'existant. Elle s'insère dans la pull request, à côté du plan : le relecteur voit « ce changement ajoute environ tant par mois » avant d'approuver. C'est une estimation, pas une facture.

Un outil open source existe pour cela : Infracost. Ses dépôts infracost/infracost et infracost/cli (la ligne de commande) sont publiés sous licence Apache-2.0 (vérifié le 2026-10-13). La documentation de l'outil indique que la CLI estime le coût de projets Terraform, Terragrunt, CloudFormation et AWS CDK, et que infracost setup guide l'obtention d'une clé d'API gratuite. Infracost propose aussi une offre hébergée, Infracost Cloud, un tableau de bord qui centralise les règles d'étiquetage et les seuils : ses conditions tarifaires ne sont pas détaillées ici, à vérifier sur son site avant de l'adopter. Infracost illustre la démarche sans l'épuiser ; d'autres outils ou des calculateurs de tarifs des fournisseurs peuvent jouer le même rôle.

Dans le pipeline de la leçon Pipeline IaC et GitOps, l'estimation vient au même endroit que les contrôles : après le plan, avant l'approbation. Le résultat se présente comme un commentaire de la pull request avec la variation mensuelle. Une équipe peut aussi décider d'un seuil, par exemple « toute augmentation au-dessus de tant demande une approbation supplémentaire ».

Soyez lucide sur ce qu'une estimation voit et ne voit pas. Elle connaît bien les ressources à prix fixe (une VM d'une taille donnée, un disque). Elle ne peut que supposer les coûts d'usage : volume de trafic sortant, nombre de requêtes, quantité de données stockées. Ces hypothèses se saisissent à la main, et la qualité du résultat dépend d'elles. Son rôle est de repérer un ordre de grandeur et une variation, pas de remplacer le suivi de la facture réelle.

Comment limiter la durée de vie des environnements éphémères ?

Un environnement éphémère est une copie de l'infrastructure créée pour un besoin temporaire : tester une pull request, répéter une migration, faire une démonstration. Le piège classique est qu'il est facile à créer et que personne ne pense à le détruire. Un dev laissé allumé tous les week-ends ou une copie de test oubliée pendant des mois coûte en continu sans servir à rien.

La parade est de donner à chaque ressource temporaire une date de fin dès sa création, par l'étiquette expire_le. Un job planifié (par exemple chaque nuit) parcourt les ressources, repère celles dont la date est dépassée et déclenche leur destruction, en prévenant d'abord l'équipe indiquée dans equipe. Pour les environnements éphémères liés à une pull request, la destruction se déclenche aussi à la fermeture de la pull request.

Pour le scénario, l'environnement prod porte expire_le = permanent, ce qui est une décision explicite et relue. L'environnement dev partagé est éteint la nuit et le week-end en réduisant le nombre de VM à zéro, par une valeur de variable plutôt que par une manipulation à la main. Une copie créée pour une démonstration reçoit une date de fin à deux semaines, renouvelable par une pull request.

La destruction automatique est un geste sensible : elle ne s'applique qu'aux ressources étiquetées comme temporaires, jamais à la base de données de prod, et jamais sans notification préalable.

Quelles erreurs fréquentes sur le coût ?

• Des étiquettes facultatives. Elles sont oubliées à chaque urgence, et la moitié de la facture reste sans propriétaire.
• Une estimation sans hypothèses d'usage. Le chiffre rassure alors qu'il ignore le trafic, le stockage ou les requêtes, souvent l'essentiel.
• Confondre estimation et budget. L'estimation d'une pull request ne dit rien de l'ensemble de la facture : les alertes sur la dépense réelle restent nécessaires.
• Des environnements éphémères sans date de fin. Ils deviennent permanents par oubli.
• Optimiser trop tôt. Passer des heures sur quelques euros de VM alors que le véritable coût vient du stockage ou du trafic sortant.

À retenir

• Le code d'IaC est la décision de dépense : le coût se discute à la revue, pas à la facture.
• Des étiquettes obligatoires (environnement, equipe, projet, expire_le) rendent le coût attribuable ; on les impose par le module et par une règle de policy as code.
• Une estimation de coût au plan donne un ordre de grandeur et une variation ; elle ignore l'usage réel tant qu'on ne le renseigne pas.
• Tout environnement éphémère reçoit une date d'expiration et une destruction planifiée, avec notification préalable.
• La facture, la refacturation et la démarche FinOps appartiennent à la formation Cloud.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →