L'écart d'é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 infonuagiques et vous y trouverez le même artefact : un tableau de bord rempli d'occasions d'optimisation, chacune étiquetée d'une valeur en dollars, et la plupart toujours exactement là où elles étaient le trimestre dernier. La visibilité est bien réelle. Les économies, pour l'essentiel, ne le sont pas.

Ce n'est pas une défaillance de l'outillage. Le palier de visibilité de la pile FinOps fait son travail — il ingère la télémétrie infonuagique, fait remonter les inefficacités et quantifie le gaspillage avec une sophistication croissante. La défaillance se situe en aval. Une fois qu'une occasion a été identifiée, la capter exige du travail d'ingénierie : traduire une recommandation en infrastructure-as-code, l'ordonnancer face à des priorités concurrentes, la piloter à travers la gestion du changement et vérifier qu'elle a bien atterri en production. Ce travail entre en concurrence avec tous les autres éléments de la feuille de route de l'équipe de plateforme, et il perd habituellement.

Le résultat est un schéma répandu dans toute la catégorie, que les responsables financiers ont appris à anticiper : les économies identifiées grimpent régulièrement sur le tableau de bord; les économies réalisées sur la facture infonuagique progressent beaucoup plus lentement, quand elles progressent. Les frais de plateforme de l'outil de visibilité, eux, sont récurrents et certains. Avec le temps, le calcul devient inconfortable.

Pourquoi l'écart persiste

La raison structurelle, c'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, le suivi — relève du client. Quand l'équipe d'ingénierie du client est 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, c'est que les « économies potentielles » sont un chiffre confortable pour tout le monde, sauf pour celui qui paie la plateforme. Le fournisseur le rapporte. Le responsable FinOps le présente. L'équipe d'ingénierie en est consciente, mais n'est pas évaluée sur sa capacité à le réduire. Personne n'assume la différence entre ce qui a été identifié et ce qui a réellement été livré, ce qui signifie que personne n'est imputable quand les deux divergent.

Deux paliers, un seul flux de travail

Il est utile de penser à la gestion des coûts infonuagiques comme à un flux de travail comportant des paliers distincts. Le palier en amont est analyser et visualiser : ingérer la télémétrie, produire les tableaux de bord, faire remonter les inefficacités, générer les données d'économie unitaire que les dirigeants financiers utilisent pour gérer l'entreprise. C'est ici que vit le palier d'analytique FinOps, un espace mature, précieux et bien instrumenté.

Le palier en aval est corriger : prendre une occasion signalée, la transformer en code d'infrastructure, l'acheminer à travers le flux de révision et d'approbation du client, la déployer dans l'environnement et vérifier que l'économie a bien atterri. Ce palier a historiquement été manuel. Il dépend d'une bande passante d'ingénierie qui entre en concurrence avec toutes les autres priorités de la feuille de route de l'équipe de plateforme, et il perd la plupart de ces concurrences. Les économies que les tableaux de bord identifient sont rarement captées en totalité, non pas parce que les recommandations sont mauvaises, mais parce que rien n'opère nativement au palier de correction.

L'erreur que commettent la plupart des entreprises est de traiter le palier d'analyse comme s'il constituait 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 bâti de la visibilité sur la fuite sans rien bâtir pour la colmater.

À quoi ressemble le palier de correction?

Le virage dont la catégorie a besoin, c'est une plateforme qui opère nativement au palier de correction — une plateforme qui complète l'analytique FinOps existante plutôt que de la remplacer. Le palier d'analytique continue de faire ce qu'il fait bien : rapports pour la direction, détection d'anomalies, économie unitaire, narration d'affaires. Le palier de correction prend le relais là où les tableaux de bord s'arrêtent, saisit les occasions signalées et les transforme en changements prêts à être livrés.

C'est le palier où opère JetScale. Là où le palier d'analytique dit « ce cluster est surdimensionné », JetScale génère le Terraform qui le redimensionne, ouvre le pull request, vérifie le changement par rapport aux politiques d'affaires du client — fenêtres de changement, seuils d'approbation, contraintes de conformité — et l'achemine à travers le flux de travail Git existant du client. Les ingénieurs révisent et fusionnent; l'optimisation se déploie; l'étape Monitor vérifie qu'elle a tenu en production. Le tableau de bord n'a pas eu à changer; le palier qui se trouve dessous a enfin une réponse native.

La complémentarité importe. Les entreprises n'ont pas à arracher leur outillage FinOps existant pour opérer au palier de correction — elles conservent les tableaux de bord dans lesquels elles ont investi, les modèles d'allocation dont leur équipe des finances dépend, les rapports d'économie unitaire qu'elles utilisent pour gérer l'entreprise. Ce qui change, c'est ce qui se produit après que le tableau de bord a fait remonter une occasion. Le transfert vers un arriéré de remédiation manuelle 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

Il y a un bénéfice plus profond à opérer au palier de correction, que l'outillage purement observationnel est architecturalement incapable de produire : la rétroaction. Quand 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 ne l'ont pas fait. Ces données d'exécution alimentent la recommandation suivante, et la suivante. Un outil d'analytique qui observe les résultats peut en faire rapport, mais il n'y participe jamais, donc il ne peut pas en tirer des apprentissages 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 infonuagiques. La prochaine décennie appartient aux plateformes capables de boucler la boucle — celles qui ne s'arrêtent pas à 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 produit après la livraison.