La couche des résultats

La recommandation qui ne voit jamais le jour

Tout programme FinOps finit par accumuler le même arriéré : une file d'occasions d'optimisation des coûts, chacune techniquement juste, chacune en attente d'un ingénieur qui aura le temps et le contexte pour la mettre en œuvre. Certaines finiront par être livrées. La plupart ne le seront pas. Celles qui le sont prennent généralement des semaines, voire des mois, pour passer de « repérée » à « fusionnée », car le travail entre ces deux états n'a rien de trivial : traduire une occasion en infrastructure-as-code, la soumettre à des tests de régression, la séquencer par rapport au reste de la feuille de route, puis l'accompagner à travers le processus de gestion du changement.

C'est ce qu'on appelle la taxe de mise en œuvre, et c'est le tueur silencieux des programmes de coûts cloud. La projection du fournisseur suppose que les recommandations seront suivies d'effet. Le dossier de RCI de l'acheteur suppose la même chose. L'équipe d'ingénierie, devant un arriéré qui dépasse déjà sa capacité, fait le seul choix rationnel possible et priorise le travail lié aux revenus ou à la fiabilité. L'optimisation des coûts est reportée. Les économies restent théoriques. Douze mois plus tard, la conversation de renouvellement devient délicate.

Pourquoi « des semaines ou des mois » est la mauvaise unité de mesure

Si les recommandations de coûts prennent des semaines ou des mois à mettre en œuvre, ce n'est pas parce que les changements eux-mêmes sont complexes : la plupart des optimisations de dimensionnement et d'engagement sont simples. La raison, c'est que le livrable que reçoit l'équipe est une recommandation, pas un changement. Une recommandation décrit ce qui devrait se produire. La transformer en quelque chose qui peut être livré exige qu'un ingénieur l'interprète, rédige l'IaC, la valide par rapport à l'environnement, puis la fasse cheminer dans le processus de révision. C'est ce travail qui consomme les semaines.

Ce modèle comporte aussi une lacune en matière d'imputabilité. Quand une économie projetée ne se concrétise pas, le fournisseur peut pointer vers la recommandation qu'il a soumise; l'équipe d'ingénierie peut pointer vers l'arriéré de travail plus prioritaire; le responsable FinOps se retrouve avec un chiffre qu'il ne peut pas défendre. Personne ne s'approprie l'écart entre ce qui a été recommandé et ce qui a réellement été livré, ce qui fait que cet écart ne se referme jamais.

Réduire la taxe au temps d'une revue de PR

Le virage dont cette catégorie a besoin porte sur le livrable lui-même. Au lieu d'une recommandation qu'un ingénieur doit traduire, le livrable devient le changement : déjà codé, déjà validé par rapport à l'environnement, déjà structuré pour la révision. L'effort d'ingénierie nécessaire pour capter l'économie passe ainsi d'un problème de cycle de sprint à un simple problème de revue de code.

C'est le modèle autour duquel Jetscale a été conçu. Chaque recommandation arrive sous forme de Terraform prêt à fusionner, dans une demande de tirage (pull request). Les ingénieurs la révisent de la même façon qu'ils réviseraient tout autre changement d'infrastructure. Pour la majorité des optimisations, le travail entre la recommandation et l'économie réalisée se mesure en minutes de revue de PR, et non en semaines d'ingénierie. Les changements architecturaux plus importants exigent encore du jugement humain (Jetscale ne prétend pas éliminer complètement l'effort d'ingénierie), mais le travail de correction courant qui remplit la majorité des arriérés d'optimisation des coûts devient radicalement moins coûteux à exécuter.

La mauvaise question d'évaluation

La plupart des évaluations de plateformes de coûts cloud commencent par la même question : qui produit les meilleures recommandations? C'est un réflexe compréhensible, les acheteurs veulent s'assurer qu'ils obtiennent une analyse plus pointue que celle de leurs outils existants, mais ce n'est pas le bon cadre pour la décision. Comparer des recommandations à d'autres recommandations suppose que le goulot d'étranglement de la gestion des coûts cloud se situe dans la qualité des conseils. Ce n'est pas le cas. Le goulot d'étranglement se situe dans ce qui se passe après que le conseil a été donné.

Une recommandation qui ne voit jamais le jour ne vaut rien, peu importe sa qualité. Une recommandation qui est livrée et qui génère une économie réelle vaut sa pleine valeur en dollars, même si un autre outil l'aurait formulée de façon plus élégante. La véritable compétition se joue à la couche des résultats, pas à la couche des recommandations, et c'est une compétition pour laquelle la plupart des plateformes de coûts ne sont pas structurées.

Les architectures fondées uniquement sur les recommandations présentent un problème plus discret : les recommandations formulées depuis l'extérieur de l'environnement du client sont aveugles au contexte. L'outil ne sait pas quelles charges de travail sont gelées, quelles équipes exigent une approbation de deux semaines, ni quelles ressources sont contraintes par une matrice de soutien d'un fournisseur logiciel. Une recommandation techniquement juste qui ignore la réalité opérationnelle du client demeure inutile. Elle génère du bruit que les ingénieurs apprennent à ignorer, et le rapport signal-bruit de l'ensemble du programme se détériore.

Lorsque les recommandations sont filtrées à travers la réalité opérationnelle du client avant d'être soumises, plutôt qu'après, par un ingénieur qui trie la file d'attente, le niveau de bruit chute nettement. Les ingénieurs consacrent leur temps de révision aux changements qui conviennent à l'environnement, et non à rejeter ceux qui n'y conviennent pas. Le même flux produit un signal plus propre à chaque étape.

Une imputabilité qui vit dans Git

La question de l'imputabilité obtient une réponse plus nette dans le même mouvement. Chaque changement généré par Jetscale est un artefact Git accompagné d'une trace de raisonnement complète : la recommandation, les politiques par rapport auxquelles elle a été vérifiée, l'impact projeté, et le registre de fusion et de déploiement. Six mois plus tard, qu'une économie tienne ou non, l'ensemble du parcours décisionnel se trouve dans le même système que l'équipe de plateforme utilise déjà pour gérer les changements d'infrastructure. Il n'y a pas de feuille de calcul distincte à réconcilier, pas de jeu d'accusations entre le fournisseur et l'ingénierie, pas d'ambiguïté sur qui a promis quoi.

La boucle Recommander, Déployer, Surveiller, Apprendre pousse cette logique encore plus loin. Chaque optimisation est observée en production après sa mise en service, si bien que les économies manquées se révèlent en quelques jours plutôt que de s'accumuler en une érosion silencieuse de la projection.

La ligne budgétaire que la plupart des dossiers de RCI oublient

L'erreur la plus courante dans l'évaluation d'une plateforme d'auto-remédiation consiste à comparer ses frais à une base zéro, comme si le travail d'ingénierie qu'elle absorbe était gratuit. Il ne l'est pas. Le dimensionnement, la gestion des engagements et la mise en œuvre des recommandations de coûts sont un travail que quelqu'un accomplit déjà, habituellement sur le temps d'un ingénieur de plateforme sénior. Quand ce travail bascule vers la plateforme, ces heures se redirigent vers des projets à plus forte valeur ajoutée. Cette substitution constitue souvent la plus grande ligne d'un dossier de RCI crédible, et c'est celle que les acheteurs omettent le plus souvent dans leur cadrage initial.

La bonne question à poser lors de toute évaluation de coûts cloud n'est pas qui produit les recommandations les plus pointues, mais quelle plateforme transforme réellement ses recommandations en économies. La première question peut être débattue indéfiniment; la seconde a une réponse mesurable qui apparaît sur la facture cloud. Une fois que la conversation se déplace vers la couche des résultats, la comparaison cesse d'être un débat sur la qualité de l'analyse et devient un audit du taux de capture réalisé.