Le relevé mensuel du fournisseur cloud arrive chez le comptable, qui le transmet au dirigeant avec une question courte : pourquoi ce montant a-t-il autant augmenté alors qu'aucun projet n'a démarré ce trimestre ? Le dirigeant ouvre un document de plusieurs pages où figurent des libellés qu'il ne reconnaît pas. Le responsable informatique ouvre la console et découvre plusieurs centaines de lignes de produits, réparties sur des comptes créés à des moments différents par des personnes qui ne sont plus toutes dans l'entreprise. Les deux sont de bonne foi et aucun des deux ne peut répondre.
Cette situation n'a rien d'exceptionnel et elle ne traduit pas une facturation abusive du fournisseur. Elle traduit un mode de facturation différent de celui auquel les entreprises étaient habituées. Un serveur acheté est une décision unique, visible, inscrite au budget d'investissement. Une ressource cloud est une décision qui se répète automatiquement chaque heure, jusqu'à ce que quelqu'un l'arrête. La discipline de suivi des coûts, appelée FinOps, consiste précisément à redonner un propriétaire et une échéance à chacune de ces décisions permanentes. Nous l'exerçons dans le cadre de notre offre de gestion des coûts cloud.
Le réflexe qui aggrave la situation : éteindre le vendredi soir
La réaction la plus fréquente devant une facture qui dérive consiste à repérer les lignes les plus élevées et à couper ce qui semble inutile, souvent en fin de semaine pour limiter la gêne. C'est le pire enchaînement possible, pour deux raisons.
D'abord parce qu'une ressource au libellé anodin peut appartenir à la production. Un volume de disque détaché en apparence sert peut-être encore de destination à une sauvegarde nocturne. Une adresse réseau apparemment libre est peut-être celle qu'un partenaire a inscrite dans sa configuration. Ensuite parce que les vraies sources de dérive ne sont presque jamais les lignes les plus grosses : ce sont des lignes moyennes, nombreuses, dont chacune paraît raisonnable. Vous coupez donc quelque chose d'utile sans corriger la cause.
L'ordre correct est l'inverse : comprendre ce qui tourne, attribuer chaque ressource à un responsable et à un usage, puis seulement décider des arrêts, avec votre accord écrit pour ceux qui touchent la production.
Les postes de dépense que nous retrouvons dans presque tous les comptes
Les mêmes familles reviennent, que le fournisseur soit américain ou européen, et elles n'ont rien de mystérieux.
- Des ressources devenues orphelines continuent de facturer. Des disques restent alloués après la suppression de la machine à laquelle ils étaient attachés. Des adresses IP réservées ne pointent plus vers rien. Des instantanés de disque s'accumulent depuis une migration terminée depuis longtemps. Un répartiteur de charge reste en service devant zéro serveur actif.
- Les environnements de test tournent en permanence. Un environnement de recette est fréquemment une copie de la production, de la même taille, allumée la nuit, le week-end et pendant les vacances, alors que personne ne l'utilise en dehors des heures de bureau. Aucun arrêt programmé n'a été posé, simplement parce que la question n'a jamais été formulée.
- Le dimensionnement n'a jamais été revu. Une base de données a été taillée pour une charge future qui ne s'est pas produite. Une machine a été agrandie pendant un incident et n'a jamais été réduite ensuite. Ces choix étaient corrects au moment où ils ont été faits, et personne n'a planifié leur relecture.
- Les transferts de données entre régions ou vers Internet pèsent sans être budgétés. Une architecture répartie sur deux régions pour de bonnes raisons techniques génère un trafic facturé que personne n'avait anticipé lors de la conception.
- Les services annexes s'additionnent discrètement. Des journaux d'application très bavards sont envoyés dans un service de collecte facturé au volume. Un contrat de support de niveau élevé reste attaché à un compte servant uniquement à des essais.
- L'absence d'étiquettes rend tout arbitrage impossible. Sans marquage indiquant l'application, l'environnement et l'équipe concernés, vous ne pouvez pas dire à qui appartient une dépense, donc vous ne pouvez pas la remettre en cause.
Nous ne vous annoncerons pas un pourcentage d'économie avant d'avoir ouvert votre compte. Ce chiffre dépend entièrement de votre situation de départ, et une promesse formulée avant l'audit n'aurait aucune valeur. Ce que nous pouvons affirmer, c'est que ces postes sont examinables un par un et que chacun se traite par une décision explicite.
Étiqueter avant d'éteindre, parce qu'une dépense sans propriétaire n'est pas arbitrable
L'étiquetage est la mesure la moins spectaculaire et la plus rentable de tout le sujet. Il consiste à imposer que chaque ressource créée porte des marqueurs simples : l'application à laquelle elle appartient, l'environnement dont il s'agit, l'équipe ou la personne responsable, et si nécessaire le client facturé. Cette règle ne change rien au fonctionnement technique, mais elle transforme la lecture de la facture.
Une fois cet étiquetage en place, le relevé cesse d'être une liste de produits pour devenir une répartition par application et par environnement. Le dirigeant peut alors constater que la recette coûte une part significative du total, ce qui est une information exploitable, là où le libellé du produit ne lui disait rien. Le responsable technique peut de son côté défendre un budget avec des éléments concrets.
Nous complétons ce dispositif par des budgets et des alertes de dépassement, réglés à un niveau qui déclenche une vérification et non une panique. Nous instaurons également une revue mensuelle courte, d'une demi-heure, qui compare le mois écoulé au précédent et examine les nouvelles ressources apparues. C'est cette revue qui empêche la dérive de recommencer six mois plus tard.
Ce que la maîtrise des coûts n'est pas : ni une migration, ni un réglage de performance
Trois sujets sont régulièrement confondus dans un même dossier, et cette confusion produit des devis illisibles.
Une migration déplace des charges de travail d'un endroit vers un autre. Elle peut très bien aboutir à une facture supérieure au serveur qu'elle remplace, notamment si les habitudes de l'ancienne salle serveur ont été recopiées sans changement. L'optimisation technique rend une application plus rapide ou plus résistante à la charge, ce qui peut d'ailleurs augmenter la dépense. La maîtrise des coûts, elle, porte sur le relevé lui-même et sur la gouvernance qui le produit. Ces trois chantiers se mènent séparément, avec des critères de réussite distincts.
Un point mérite d'être souligné : l'audit des coûts commence par les identités et les droits, pas par la ressource la plus chère. Nous rencontrons régulièrement des comptes où des autorisations trop larges permettent à plusieurs personnes de créer des ressources sans qu'aucune trace de décision existe, ou des projets orphelins créés pour une démonstration et jamais fermés. Tant que ce point n'est pas réglé, tout nettoyage se remplit à nouveau. La question du compte principal du fournisseur mérite d'ailleurs un article à elle seule, que nous consacrons au compte racine d'un environnement cloud.
L'ordre dans lequel nous instruisons un audit de coûts
Nous demandons un accès en lecture seule aux consoles et aux outils d'analyse de facturation du fournisseur. Nous produisons une première cartographie sous quelques jours : quels comptes existent, qui les paie, et ce qui tourne réellement dans chacun avec l'âge et le marquage des ressources. Nous établissons ensuite une liste d'actions classées par rapport entre gain et risque. Les ressources orphelines et les arrêts programmés d'environnements de test passent en premier, car ils ne touchent pas la production. Les réductions de dimensionnement en production passent après une période de mesure, et jamais sur une intuition.
Nous n'engageons aucun achat de capacité à long terme au début d'une mission. Réserver de la capacité pour plusieurs années sur une machine que vous allez déplacer ou remplacer dans six mois produit une économie apparente et une contrainte réelle. Cet engagement se décide une fois l'architecture stabilisée. Nos missions se facturent 1000 HT / jour à distance dans toute la France et en Suisse. Le suivi courant se poursuit ensuite dans le cadre d'une maintenance cloud plutôt que par des journées de conseil sans terme.
Si votre relevé mensuel est devenu illisible, transmettez-nous le dernier en date, sans identifiant ni secret. Nous vous dirons s'il existe une matière réelle à un audit, ou si ce montant correspond simplement au prix de ce que vous faites tourner, auquel cas la conclusion est courte et vous coûte peu.