Pour créer un tableau de bord des coûts du cloud que les équipes d'ingénierie utilisent réellement, il faut le concevoir en fonction des décisions que les ingénieurs doivent prendre, et non des rapports que le service financier souhaite consulter. Cela implique de mettre en avant les données de coûts au niveau du service, de l'équipe ou de la charge de travail, en temps quasi réel, au sein même des outils que les ingénieurs utilisent déjà. La plupart des tableaux de bord échouent car ils sont conçus uniquement dans un souci de visibilité. Les sections ci-dessous expliquent ce qui fait la différence, du choix des indicateurs pertinents à l’intégration adéquate dans les flux de travail.
Quels indicateurs les équipes d'ingénierie prennent-elles réellement en compte dans un tableau de bord des coûts du cloud ?
Les équipes d'ingénierie accordent une importance particulière au coût par déploiement, au coût par service ou par charge de travail, à l'évolution des coûts dans le temps, ainsi qu'aux alertes d'anomalies signalant des pics de dépenses inattendus. Ces indicateurs ont un lien direct avec les décisions sur lesquelles les ingénieurs peuvent agir. Les totaux abstraits ou les comparaisons entre budget et réalité n'ont que peu d'intérêt pour un développeur qui souhaite savoir si une nouvelle fonctionnalité coûte plus cher que prévu.
Les indicateurs qui favorisent l'implication des ingénieurs ont généralement un point commun : ils sont attribuables. Les ingénieurs souhaitent connaître les dépenses liées au cloud de leur propre équipe, et non un chiffre global à l'échelle de l'entreprise. Parmi les indicateurs utiles, on peut citer :
- Coût par service ou microservice afin que les équipes puissent attribuer les dépenses aux charges de travail spécifiques dont elles sont responsables
- Coût par pull request ou déploiement pour établir un lien entre les coûts d'infrastructure et l'activité d'ingénierie
- Dépenses liées aux ressources inutilisées ou sous-utilisées les possibilités de rationalisation sont ainsi immédiatement visibles
- Évolution des coûts sur une période glissante pour distinguer les variations saisonnières du gaspillage réel
- Alertes de détection d'anomalies qui permettent de détecter des changements inattendus avant qu’ils ne s’aggravent
Les indicateurs liés à la valeur métier, tels que le coût par transaction ou le coût par utilisateur actif, sont encore plus pertinents, car ils permettent d’aborder les dépenses liées au cloud dans un langage commun aux ingénieurs et aux chefs de produit. Ils font passer le débat de “ nous avons dépensé plus ” à “ nous avons dépensé plus par unité de valeur fournie ”, ce qui est une question à laquelle il vaut la peine de répondre.
Pourquoi la plupart des tableaux de bord sur les coûts du cloud sont-ils ignorés par les équipes d'ingénieurs ?
La plupart des tableaux de bord consacrés aux coûts du cloud sont ignorés, car ils sont conçus pour les équipes financières et transmis aux ingénieurs après coup. Ils présentent des dépenses agrégées, des écarts budgétaires et des totaux mensuels qui n’ont aucun lien direct avec le travail quotidien d’un ingénieur. Lorsqu’un tableau de bord ne permet pas de répondre à la question “ Que devrais-je faire différemment dès maintenant ? ”, on cesse de le consulter.
Plusieurs problèmes structurels sont à l’origine de ce phénomène. Premièrement, les données relatives aux coûts sont souvent disponibles avec un retard de plusieurs heures, voire plusieurs jours, ce qui les rend inutilisables dans le cadre de cycles d’ingénierie très rapides. Deuxièmement, les coûts sont présentés au niveau d’un compte ou d’un abonnement plutôt qu’au niveau d’une équipe, d’un service ou d’une fonctionnalité, de sorte qu’aucun individu ne se sent responsable. Enfin, le tableau de bord se trouve dans un outil distinct que les ingénieurs ne consultent jamais dans le cadre de leur flux de travail habituel.
Il existe également une dimension culturelle. Lorsque les dépassements de coûts sont considérés comme un problème financier plutôt que comme une préoccupation commune des ingénieurs, ces derniers ne sont absolument pas incités à s’intéresser aux données relatives aux coûts. Un tableau de bord qui suscite des reproches plutôt que de favoriser une prise de décision éclairée sera évité. Le problème sous-jacent est que gestion des coûts du cloud est considérée comme un simple exercice de reporting plutôt que comme une discipline opérationnelle dont les équipes d'ingénierie sont responsables, au même titre que la performance et la fiabilité.
Comment organiser les données relatives aux coûts du cloud pour que les ingénieurs puissent en tirer parti ?
Vous structurez les données relatives aux coûts du cloud destinées aux ingénieurs en les organisant en fonction de la responsabilité, et non de la hiérarchie organisationnelle. Chaque enregistrement de coût doit être associé à une équipe, un service ou un produit, afin que la personne consultant le tableau de bord puisse immédiatement se demander : “ Est-ce que cela me concerne, et puis-je le modifier ? ” Le balisage et l'affectation constituent les fondements de cette structure.
Une structure pratique s'articule autour de trois niveaux :
- Étiquetage au niveau des ressources Ainsi, chaque ressource cloud comporte des métadonnées permettant d'identifier l'équipe propriétaire, l'environnement et le service
- Règles de répartition des coûts partagés tels que la mise en réseau, les frais d'assistance et les services de plateforme partagée, de sorte que les coûts soient répartis équitablement plutôt que mis en commun de manière invisible
- Agrégation par équipe et par service ainsi, la surface du tableau de bord que chaque équipe voit ne reflète que ce dont elle est responsable
Une fois la structure des données nettoyée, le tableau de bord peut passer de la simple présentation des coûts à une visualisation de ces coûts dans leur contexte. Cela implique de croiser les dépenses avec les indicateurs d’utilisation, de comparer les coûts à une valeur de référence ou à des prévisions, et de mettre en évidence les ressources susceptibles d’être redimensionnées. Les ingénieurs n’ont pas besoin de comprendre en détail la facturation du cloud. Ce qu’ils doivent voir, c’est : voici ce que vous dépensez, voici ce qui semble anormal, et voici ce que vous pouvez optimiser.
Quels sont les meilleurs outils pour créer un tableau de bord des coûts du cloud destiné aux ingénieurs ?
Les meilleurs outils pour un tableau de bord des coûts cloud destiné aux équipes d'ingénierie combinent les données natives des fournisseurs de cloud avec une couche spécifique aux FinOps qui ajoute des fonctionnalités d'affectation des ressources, de détection des anomalies et de recommandations de redimensionnement. Pour les entreprises utilisant AWS, Azure ou GCP, les outils natifs de gestion des coûts constituent un point de départ, mais ils offrent rarement la granularité au niveau des équipes ou la visibilité inter-cloud dont les équipes d'ingénierie ont besoin.
Les outils FinOps spécialement conçus vont encore plus loin. Apptio Cloudability, par exemple, s'intègre aux trois principaux fournisseurs de cloud et prend en charge les workflows d'allocation, de « showback » et d'optimisation qui transforment un tableau de bord purement informatif en un outil permettant de prendre des mesures concrètes. Il permet aux équipes de créer des vues des coûts par service, par environnement et par équipe, sans que les ingénieurs aient besoin de devenir des experts en facturation.
Lors de l'évaluation des outils, les critères pertinents pour leur adoption par les ingénieurs sont les suivants :
- Granularité : Cet outil permet-il d'imputer les coûts jusqu'au niveau du service ou du conteneur ?
- Fraîcheur : Dans quelle mesure les données relatives aux coûts sont-elles proches du temps réel ?
- Intégration : Cet outil s'intègre-t-il à Slack, Jira ou au pipeline CI/CD afin que les données relatives aux coûts s'affichent là où les ingénieurs travaillent déjà ?
- Recommandations en matière de rationalisation des effectifs : Cet outil met-il en évidence des possibilités d'optimisation concrètes et spécifiques plutôt que de simples observations générales ?
Aucun outil ne suffit à lui seul à garantir son adoption. Le choix de l'outil importe moins que la fiabilité des données qu'il contient et que la capacité des processus associés à inciter les ingénieurs à agir.
Comment intégrer la visibilité sur les coûts du cloud dans les processus d'ingénierie ?
Vous intégrez la visibilité sur les coûts du cloud dans les workflows d'ingénierie en amenant les données de coûts là où les ingénieurs prennent déjà leurs décisions, plutôt que de leur demander de consulter un tableau de bord distinct. Cela implique d'intégrer les indicateurs de coûts dans les pipelines CI/CD, les canaux Slack, les revues de sprint et les revues d'infrastructure en tant que code.
Parmi les points d'intégration concrets, on peut citer :
- Contrôles des coûts des pipelines : Signaler l'impact financier estimé dans le cadre d'un pipeline de déploiement afin que les ingénieurs puissent en prendre connaissance avant de procéder à la fusion
- Alertes Slack ou Teams : Envoyez les alertes d'anomalies et de dépassement de seuils directement dans les canaux de l'équipe afin que les pics de coûts soient immédiatement repérés
- Cérémonies de sprint ou de planification : Intégrer un bref point sur les coûts à l'ordre du jour de manière permanente, afin que les coûts fassent partie intégrante des discussions techniques et ne constituent plus une surprise trimestrielle.
- Annotations « Infrastructure-as-code » : Afficher les estimations de coûts parallèlement à la définition des ressources afin que les ingénieurs puissent comparer les différentes options avant le provisionnement
L'objectif est de faire du coût une préoccupation technique à part entière, au même titre que les performances et la fiabilité. Lorsque les données relatives aux coûts apparaissent dans les mêmes outils et discussions que ceux où les ingénieurs abordent la disponibilité et la latence, elles cessent d'être un indicateur financier pour devenir un élément à part entière de la manière dont une équipe évalue la qualité.
Comment savoir si votre tableau de bord des coûts du cloud contribue réellement à faire évoluer les comportements ?
Vous savez que votre tableau de bord des coûts du cloud favorise un changement de comportement lorsque les ingénieurs prennent des mesures en fonction de ce qu’ils y voient, sans y être incités par le service financier ou la direction. Les indicateurs les plus évidents sont une réduction des dépenses liées aux ressources inutilisées, une augmentation des mesures de redimensionnement et un temps de réaction plus court entre l’apparition d’une anomalie de coût et l’intervention de l’équipe pour y remédier.
Parmi les signaux utiles à surveiller, on peut citer :
- Le nombre de recommandations de rationalisation mises en œuvre par sprint
- Délai moyen entre une alerte d'anomalie et sa résolution
- Les courbes de tendance des coûts s'améliorent-elles après la mise en place du tableau de bord ?
- Si les équipes d'ingénieurs abordent spontanément les questions de coûts lors des réunions de planification et de rétrospective
Si le tableau de bord est consulté mais que les coûts ne varient pas, le problème tient généralement à l'une des deux raisons suivantes : soit les données ne sont pas suffisamment détaillées pour permettre aux ingénieurs de savoir sur quoi agir, soit il n'existe pas de structure de gouvernance intégrant la prise en compte des données de coûts dans l'évaluation du travail d'ingénierie. La visibilité sans responsabilisation engendre la prise de conscience, mais pas l'optimisation.
Comment nous vous aidons à créer un tableau de bord FinOps utilisé par les équipes d'ingénierie
Nous aidons les organisations à passer d'un simple reporting des coûts du cloud à une pratique FinOps dans laquelle les équipes d'ingénieurs gèrent activement leurs propres dépenses liées au cloud. Notre approche couvre l'ensemble de la chaîne, de la qualité des données au comportement des équipes :
- Répartition des coûts complets y compris les conteneurs et les services partagés, afin que chaque équipe dispose d'une vue fiable de ses propres dépenses
- Analyse de rationalisation des effectifs sur AWS, Azure et GCP, avec des recommandations concrètes que les équipes d'ingénierie peuvent mettre en œuvre dès leur prochain sprint
- Conception du modèle opérationnel FinOps qui définit les rôles, les pouvoirs de décision et la cadence permettant d'intégrer la gestion des coûts dans les processus d'ingénierie
- Mise en œuvre de l'outillage utiliser Apptio Cloudability pour offrir une visibilité en temps quasi réel sur les coûts du cloud au niveau des équipes
- Évaluation du niveau de maturité FinOps comme point de départ pour déterminer où en est actuellement votre organisation et où se situent les améliorations les plus rentables
Nous ne nous contentons pas de vous remettre un tableau de bord puis de nous mettre en retrait. Nous travaillons en étroite collaboration avec vos équipes financières, informatiques et d'ingénierie afin que la visibilité sur les coûts se traduise par des décisions et des économies mesurables. Si vous souhaitez comprendre ce qu'est un système bien structuré Pratique FinOps à quoi cela pourrait ressembler pour votre organisation, contactez-nous et nous commencerons par une évaluation concrète de votre situation actuelle.