Le problème des politiques à dix tags
Owner, centre de coût, environnement, application, projet, criticité, date de fin, équipe… Sur le papier, une politique de tagging complète permet de tout savoir. En pratique :
- les tags sont incomplets : personne ne remplit dix champs à chaque création de ressource ;
- ils sont incohérents : « Prod », « prod », « PRD », « production » ;
- ils divergent de la CMDB : l'owner change, le tag ne suit pas ;
- personne ne les maintient dans la durée.
Résultat : une partie de la facture n'est rattachée à aucune équipe. Personne ne la regarde, donc personne ne l'optimise.
L'idée : un seul tag, et la CMDB pour le reste
La plupart des grandes entreprises ont déjà une source de vérité sur leurs applications : la CMDB (ServiceNow ou autre). Elle connaît l'owner, le centre de coût, l'entité, la criticité, souvent l'environnement. Inutile de recopier ces informations dans des tags qui finiront par diverger.
Il suffit d'un tag obligatoire, par exemple un code application, qui fait le lien entre chaque ressource cloud et la CMDB. Toutes les autres informations sont récupérées par jointure, dans le dashboard.
Comment l'imposer
- Dès la création : sur Azure, une Azure Policy refuse la création d'un resource group sans le tag, et une autre fait hériter le tag du resource group vers ses ressources. Sur AWS, les Tag Policies et les Service Control Policies jouent le même rôle.
- Sur l'existant : des tâches de remédiation appliquent le tag aux ressources déjà créées.
- Avec des valeurs contrôlées : seuls les codes qui existent dans la CMDB sont acceptés.
Contrôler la cohérence automatiquement
Un contrôle régulier compare le cloud et la CMDB : codes inexistants, applications décommissionnées qui consomment encore, owners partis. Chaque écart devient une action, suivie dans le dashboard avec la tagging compliance.
Les coûts qui ne se taggent pas (réseau partagé, sécurité, support) sont répartis avec des clés de répartition simples et connues de tous.
Ce que ça change
- Chaque coût est rattaché à une application et à son owner.
- Le showback, puis le chargeback, deviennent possibles : chaque équipe voit et assume sa consommation.
- Les recommandations d'optimisation sont adressées à la bonne personne.
- Les budget alerts partent vers le bon owner.
Les erreurs à éviter
- Des tags en texte libre, sans liste de valeurs autorisées.
- Tagger les ressources une par une au lieu de s'appuyer sur l'héritage depuis le resource group.
- Oublier l'existant : une politique qui ne s'applique qu'aux nouvelles ressources laisse le passé non taggé.
- Ne jamais mesurer : sans indicateur de compliance, la dérive revient.
Le tagging est le socle de la gouvernance FinOps. Sans lui, pas de chargeback, pas de responsabilisation, et des économies qui ne tiennent pas.