Sommaire
30 min avec nous, et votre cloud ne sera plus jamais le même.
Nous vous montrerons comment identifier vos gisements d’économies et mettre en place une gouvernance FinOps simple.
Comment choisir une naming convention qui survit à l’année prochaine ?
La tentation, quand on démarre, c’est de vouloir tout prévoir. On ouvre un Google Sheet, on liste quinze clés possibles, on imagine des sous-catégories pour chaque cas particulier — et trois semaines plus tard, plus personne ne suit la convention parce qu’elle est devenue illisible. Une naming convention trop ambitieuse est une naming convention morte-née.
Ce qui marche, dans notre expérience, c’est l’inverse : partir petit, et accepter que la convention évoluera. Cinq à sept clés, pas plus, au démarrage. Cette convention de nommage (naming convention) doit rester identique sur l’ensemble des environnements cloud afin de garantir une allocation des coûts homogène. Chaque clé doit répondre à une question business précise : qui paie, qui est responsable, à quoi ça sert. Si une clé ne sert à répondre à aucune question qu’un CFO ou un CTO se pose un jour, elle n’a rien à faire dans la convention initiale. On l’ajoutera plus tard, si le besoin se confirme.
Un point qu’on néglige trop souvent : la casse et le format comptent. Environment, environment et ENV ne sont pas la même clé pour un moteur d’allocation de coûts, ils créent trois lignes différentes dans vos rapports, et personne ne s’en rend compte avant l’audit. Décidez d’une convention de nommage stricte (minuscules, kebab-case, peu importe laquelle tant qu’elle est unique) et documentez-la dans un endroit que les gens consultent réellement pas un wiki Confluence enterré sous quarante autres pages, mais un README dans le repo d’infrastructure, ou mieux, un schéma imposé directement dans l’outil de provisioning.
Et surtout : une convention qui n’a pas de propriétaire n’a pas d’avenir. Quelqu’un doit être responsable de la faire évoluer, de trancher les cas litigieux (« est-ce que team désigne l’équipe produit ou l’équipe technique ? »), et de la communiquer aux nouveaux arrivants. Sans ce rôle, la convention se délite au bout de six mois, remplacée par des variantes locales que chaque équipe invente dans son coin.
Quels tags sont vraiment obligatoires, et lesquels sont du confort ?
Il y a une différence fondamentale entre « ce qu’il serait sympa de savoir » et « ce sans quoi on ne peut pas allouer un coût ». On confond souvent les deux, et le résultat, c’est une liste de vingt tags obligatoires que personne n’applique jamais intégralement parce que remplir vingt champs pour déployer une instance, ce n’est pas du tagging, c’est de la paperasse.
Notre position, et elle est tranchée : trois à cinq tags obligatoires, pas un de plus. En dessous de ce seuil, vous n’avez pas assez d’information pour allouer un coût de façon fiable. Au-dessus, vous créez de la friction, et la friction, en environnement cloud, se traduit systématiquement par du contournement des ressources déployées sans tag « parce qu’on n’a pas eu le temps », des scripts qui bypassent la CI pour aller plus vite.
Concrètement, dans la plupart des organisations, les tags cloud obligatoires sont : cost-center ou owner (selon votre organisation, l’un des deux, rarement les deux), environment (prod, staging, dev, sans ambiguïté possible), project ou application, et si votre structure le justifie, team. C’est tout. Le reste, expiry-date, data-classification, backup-policy a de la valeur, indéniablement, mais ce sont des tags de niveau deux. Ils viennent enrichir une base saine, pas la remplacer.
Ce qu’on observe chez nos clients, c’est que la tentation d’ajouter des tags « parce qu’on pourrait en avoir besoin un jour » est presque irrésistible pour les équipes techniques les plus rigoureuses précisément parce qu’elles sont capables de l’implémenter. Mais la rigueur technique n’est pas la question. La question, c’est : est-ce que ce tag sera rempli, correctement, par la personne pressée qui déploie une ressource à 18h un vendredi ? Si la réponse est non, le tag est décoratif, et un tag décoratif pollue vos rapports plus qu’il ne les enrichit.
Le policy as code, ou comment arrêter de compter sur la bonne volonté
On a tous connu la période « documentation et bonne volonté ». Un Slack message annonçant la nouvelle convention de tags, un lien vers le wiki, et l’espoir, sincère mais naïf, que tout le monde va s’y conformer. Ça marche pendant deux semaines. Puis un nouveau développeur arrive, ne lit jamais le wiki (soyons honnêtes, qui le fait vraiment), et déploie cinquante ressources sans le moindre tag.
La bonne volonté ne scale pas. Le code, si.
C’est là qu’intervient le policy as code, l’idée qu’au lieu de demander gentiment aux gens de bien vouloir taguer leurs ressources, on empêche techniquement la création d’une ressource non conforme. Terraform avec des Sentinel policies ou OPA (Open Policy Agent), AWS avec des Service Control Policies ou des Tag Policies natives via AWS Organizations, Azure avec Azure Policy les outils existent, et ils sont matures. Il n’y a plus vraiment d’excuse technique pour ne pas les utiliser. Ces mécanismes permettent d’automatiser la gouvernance du tagging cloud et d’améliorer durablement la qualité des données utilisées par les outils FinOps.
Le principe est simple, presque brutal : si une ressource ne porte pas les tags obligatoires au moment de sa création, elle n’est pas créée. Point. Pas de rattrapage a posteriori, pas d’exception « juste pour cette fois ». On peut trouver cela rigide, on trouve ça sain. Parce que la seule alternative au contrôle en amont, c’est le nettoyage en aval, et le nettoyage en aval coûte systématiquement plus cher, en temps comme en frustration, que la contrainte initiale.
Cela dit et c’est un point qu’on tient à souligner, parce qu’on le voit mal fait trop souvent, il faut doser l’agressivité du policy as code selon la maturité de l’organisation. Bloquer en dur dès le premier jour, dans une équipe qui découvre le concept, c’est le meilleur moyen de générer une résistance générale et un contournement systématique (via des comptes AWS parallèles, par exemple, ce qui est pire que le problème initial).
On préfère une approche progressive : d’abord un mode « warning » qui notifie sans bloquer, pendant quatre à six semaines, le temps que les équipes s’adaptent et que les cas limites remontent. Puis, seulement ensuite, le mode bloquant. La rigueur sans pédagogie génère du contournement ; la pédagogie sans rigueur ne change jamais rien. Il faut les deux, dans cet ordre.
Les contrôles qui font la différence entre un tag et un vœu pieux
Un tag posé au moment du déploiement, c’est une bonne nouvelle. Un tag qui reste correct six mois plus tard, c’est une autre histoire. Les ressources cloud vivent, changent de propriétaire, changent de finalité, un environnement de test qui devient, sans que personne ne l’ait décidé formellement, une dépendance de production. Et le tag, lui, ne bouge pas tout seul.
C’est pour ça que le policy as code, aussi solide soit-il, ne suffit pas. Il faut des contrôles récurrents, pas juste un contrôle à la création. Deux niveaux nous semblent indispensables.
Le premier, c’est un contrôle de conformité automatisé et régulier, quotidien ou hebdomadaire selon le volume de vos ressources qui scanne l’ensemble du parc et identifie tout ce qui a dérivé : tags manquants, valeurs qui ne correspondent à aucune valeur autorisée (un environment tagué « prod » au lieu de « production », par exemple, ce genre de micro-incohérence qui casse silencieusement vos rapports), ressources orphelines dont le owner a quitté l’entreprise depuis huit mois. AWS Config, Azure Policy Compliance, ou des outils tiers de gouvernance FinOps font ce travail très bien, l’essentiel, c’est que le résultat soit visible, pas enterré dans un rapport PDF que personne n’ouvre. L’objectif n’est pas uniquement de vérifier la présence des tags, mais aussi leur cohérence afin de garantir une allocation fiable des coûts cloud.
Le second niveau, plus qualitatif, c’est une revue périodique, trimestrielle, dans l’idéal avec les équipes, pas uniquement automatisée. Parce qu’un tag peut être techniquement présent et correct sur le papier tout en étant devenu faux dans les faits : le projet a changé de nom, l’équipe a été réorganisée, le cost-center n’existe plus dans le référentiel finance. Aucun scanner automatique ne détecte ce genre de dérive sémantique. Seule une conversation la révèle.
On insiste sur ce point parce qu’on voit beaucoup d’organisations investir massivement dans l’automatisation du contrôle et négliger complètement la dimension humaine comme si un dashboard de conformité à 98 % garantissait une allocation fiable. Ce n’est pas le cas. 98 % de conformité technique peut très bien cacher 30 % de tags sémantiquement obsolètes.
Le backlog de correction : par où commencer sans y passer un trimestre
Et puis il y a l’existant. Le vrai sujet, celui qu’on évite d’aborder parce qu’il fait peur : vous avez, quelque part, des centaines voire des milliers de ressources non taguées ou mal taguées, accumulées depuis des années. La tentation, face à ce chantier, c’est soit de l’ignorer (« on repart propre à partir de maintenant »), soit de vouloir tout corriger d’un coup dans un sprint dédié qui, immanquablement, dérape sur trois mois et démotive tout le monde.
Aucune des deux approches ne fonctionne. Ignorer l’existant, c’est se condamner à allouer correctement 20 % de sa facture pendant que les 80 % restants continuent de fausser tous vos calculs. Vouloir tout corriger d’un coup, c’est sous-estimer l’ampleur réelle du chantier et cramer la patience des équipes en quelques semaines.
Ce qui fonctionne, c’est la priorisation par impact financier, pas par ordre alphabétique ou par ancienneté. Sortez la liste des ressources non conformes, triez-la par coût mensuel décroissant, et attaquez le top 20 %. Dans la quasi-totalité des cas qu’on a observés, ces 20 % représentent 70 à 80 % du coût total non alloué c’est la loi de Pareto qui s’applique presque parfaitement aux infrastructures cloud, parce que quelques ressources massives (bases de données, clusters de calcul, stockage volumineux) pèsent toujours disproportionnellement plus que la longue traîne de petites instances oubliées.
Concrètement, ça veut dire un backlog dédié, distinct du backlog produit, avec un budget de temps fixe et récurrent, deux jours par sprint, par exemple, pas plus, mais de façon constante plutôt qu’un effort ponctuel et héroïque. La régularité bat l’intensité, sur ce sujet comme sur beaucoup d’autres en gouvernance cloud. Et on fixe un objectif réaliste : viser 90 % de conformité sur les ressources à fort impact financier en un trimestre, pas 100 % de conformité sur l’intégralité du parc en un mois. Les 10 % restants, souvent des ressources legacy dont personne ne connaît plus vraiment l’utilité, méritent une question plus radicale que le tagging : pourquoi existent-elles encore ?
Bon à savoir
Une naming convention mal pensée, ou des tags obligatoires qui ne le sont que sur le papier, et c’est toute votre allocation de coûts qui devient fictive.
Chez Leonys, on vous aide à construire une politique de tagging qui tient dans le temps, pas seulement sur le papier de la première réunion. Recevez notre naming convention type et notre liste de tags recommandés, le point de départ que beaucoup d’équipes auraient aimé avoir avant, plutôt qu’après, leur premier audit raté.
On pourrait s’arrêter là, sur cette liste de bonnes pratiques bien rangées. Mais la vraie question, celle qu’on pose rarement, c’est : qu’est-ce que ça dit de votre organisation, le fait qu’une simple étiquette sur une ressource cloud soit si difficile à faire respecter ?
Le tagging cloud n’est jamais un problème technique. C’est un problème de gouvernance, déguisé en problème technique parce que c’est plus confortable à traiter comme tel.
FAQ
Pour une allocation fiable des coûts cloud, trois à cinq tags suffisent généralement : le projet ou l'application, l'environnement (production, développement, test) et un responsable financier (owner ou cost center). Selon l'organisation, un tag équipe (team) peut également être ajouté.
Une stratégie de tagging efficace repose sur une convention de nommage simple, quelques tags obligatoires, une automatisation via le policy as code et des contrôles réguliers pour maintenir la qualité des données dans le temps.
Le policy as code consiste à appliquer automatiquement les règles de gouvernance cloud. Une ressource qui ne respecte pas les tags obligatoires peut être signalée ou bloquée dès son déploiement grâce à des outils comme Terraform, AWS Tag Policies ou Azure Policy.
Les incohérences apparaissent lorsque les conventions ne sont pas maintenues dans le temps, que les équipes utilisent des valeurs différentes ou que les ressources changent de propriétaire sans mise à jour des tags. Des contrôles automatisés et des revues régulières permettent de limiter ces dérives.
Le meilleur indicateur est le taux de conformité des ressources et surtout la part des dépenses correctement taguées. Une organisation mature cherche à couvrir plus de 95 % de ses coûts cloud avec des tags fiables et homogènes.
