L'écart des économies réalisées

Le schéma que tout responsable FinOps connaît

Entrez dans n'importe quelle entreprise dotée d'un programme mature de gestion des coûts cloud, et vous trouverez le même artefact : un tableau de bord rempli d'occasions d'optimisation, chacune assortie d'une valeur en dollars, la plupart restant exactement là où elles étaient le trimestre précédent. La visibilité est bien réelle. Les économies, en grande partie, ne le sont pas.

Ce n'est pas un échec des outils. Le niveau visibilité de la pile FinOps fait son travail : il ingère la télémétrie cloud, met en évidence les inefficacités et quantifie le gaspillage avec une sophistication croissante. L'échec se situe en aval. Une fois une occasion identifiée, la capter exige du travail d'ingénierie : traduire une recommandation en infrastructure-as-code, l'ordonnancer parmi des priorités concurrentes, la faire cheminer dans la gestion du changement, puis vérifier qu'elle a bien été appliquée en production. Ce travail entre en concurrence avec tous les autres éléments de la feuille de route de l'équipe plateforme, et il perd habituellement cette bataille.

Le résultat est un schéma généralisé que les dirigeants financiers ont appris à anticiper : les économies identifiées grimpent régulièrement sur le tableau de bord, tandis que les économies réalisées sur la facture cloud progressent beaucoup plus lentement, quand elles progressent. Pendant ce temps, les frais de plateforme pour l'outil de visibilité, eux, sont récurrents et certains. Avec le temps, l'équation devient inconfortable.

Pourquoi l'écart persiste

La raison structurelle est que les plateformes de visibilité n'ont jamais été conçues pour boucler la boucle. Leur proposition de valeur s'arrête à la recommandation. Tout ce qui suit (l'IaC, la révision, le déploiement, la surveillance) devient le problème du client. Lorsque l'équipe d'ingénierie du client est déjà pleinement occupée (et elle l'est toujours), l'écart entre la recommandation et la remédiation s'élargit silencieusement, trimestre après trimestre.

La raison plus profonde est que les « économies potentielles » constituent un chiffre confortable pour tout le monde, sauf pour la personne qui paie pour la plateforme. Le fournisseur le rapporte. Le ou la responsable FinOps le présente. L'équipe d'ingénierie en est consciente, mais n'est pas évaluée sur sa capacité à le concrétiser. Personne n'est propriétaire de l'écart entre ce qui a été identifié et ce qui a réellement été livré, ce qui signifie que personne n'en est responsable quand les deux divergent.

Deux couches, un seul flux de travail

Il est utile de considérer la gestion des coûts cloud comme un flux de travail composé de couches distinctes. La couche en amont est analyser et visualiser : ingérer la télémétrie, produire les tableaux de bord, mettre en évidence les inefficacités, générer les indicateurs unitaires que les dirigeants financiers utilisent pour piloter l'entreprise. C'est là que se situe le niveau analytique FinOps, un espace mature, précieux et bien instrumenté.

La couche en aval est corriger : prendre une occasion signalée, la transformer en code d'infrastructure, la faire passer par le processus de révision et d'approbation du client, la déployer dans l'environnement, puis vérifier que l'économie s'est bien concrétisée. Cette couche a toujours été manuelle. Elle dépend de la disponibilité de l'ingénierie, qui entre en concurrence avec toutes les autres priorités de la feuille de route de l'équipe plateforme, et qui perd la plupart de ces arbitrages. Les économies identifiées par les tableaux de bord sont rarement captées en totalité, non pas parce que les recommandations sont erronées, mais parce que rien n'opère nativement au niveau de la couche correction.

L'erreur que commettent la plupart des entreprises est de traiter la couche analyse comme si elle représentait l'ensemble du flux de travail. Ce n'est pas le cas. Une pratique FinOps qui s'arrête au tableau de bord est une pratique qui a construit de la visibilité sur la fuite, sans rien construire pour l'arrêter.

À quoi ressemble la couche correction

Le virage dont la catégorie a besoin est une plateforme qui opère nativement au niveau de la couche correction, en complément des outils analytiques FinOps existants plutôt qu'en remplacement. La couche analytique continue de faire ce qu'elle fait bien : rapports de direction, détection des anomalies, indicateurs unitaires, mise en récit des données pour l'entreprise. La couche correction prend le relais là où les tableaux de bord s'arrêtent, récupère les occasions signalées et les transforme en changements prêts à être livrés.

C'est la couche dans laquelle opère Jetscale AI. Là où le niveau analytique dit « ce cluster est surprovisionné », Jetscale AI génère le Terraform qui le redimensionne correctement, ouvre la pull request, vérifie le changement par rapport aux politiques d'affaires du client (fenêtres de changement, seuils d'approbation, contraintes de conformité), puis l'achemine dans le flux de travail Git existant du client. Les ingénieurs et ingénieures révisent et fusionnent le changement, l'optimisation se déploie, et l'étape Monitor vérifie qu'elle tient bien en production. Le tableau de bord n'a pas eu à changer; la couche qui se trouve en dessous a enfin une réponse native.

Cette complémentarité compte. Les entreprises n'ont pas à arracher leurs outils FinOps existants pour opérer au niveau de la couche correction : elles conservent les tableaux de bord dans lesquels elles ont investi, les modèles d'allocation dont dépend leur équipe financière, les rapports d'indicateurs unitaires qu'elles utilisent pour piloter l'entreprise. Ce qui change, c'est ce qui se produit après que le tableau de bord a fait ressortir une occasion. Le transfert vers un arriéré de remédiation manuel est remplacé par un transfert vers un flux de travail automatisé qui produit des changements révisables.

Des données d'exécution, pas seulement de l'observation

Opérer au niveau de la couche correction apporte un avantage plus profond que les outils d'observation seule ne peuvent, par nature, produire : la rétroaction. Lorsque la plateforme participe à l'exécution, elle voit ce qui s'est réellement passé en production : quels changements ont tenu, lesquels ont régressé, lesquels ont livré l'économie projetée et lesquels non. Ces données d'exécution alimentent la recommandation suivante, puis la suivante. Un outil analytique qui observe les résultats peut en rendre compte, mais il n'y participe jamais, et ne peut donc pas en tirer des leçons de la même façon.

La visibilité était la bonne réponse pour la dernière décennie de la gestion des coûts cloud. La prochaine décennie appartient aux plateformes capables de boucler la boucle, qui ne se contentent pas de dire aux entreprises quoi faire, mais qui transforment la recommandation en un changement que l'équipe peut réellement livrer, et qui apprennent de ce qui se passe après la livraison.