Le travail à prendre en charge détermine le choix
Supposons qu’une recommandation de réduction des ressources cloud reste sans suite. Avant d’ouvrir un poste, examinez ce qui manque : si des personnes identifiées peuvent analyser la dépense, arbitrer puis modifier le service, une responsabilité partagée reste une option. Si un travail durable d’analyse, de coordination ou de construction technique dépasse leur disponibilité, un poste consacré au sujet devient une option, à condition de disposer de relais techniques et financiers. Sans cette vérification, le recrutement serait prématuré.
La distinction porte sur le travail que vous confiez au poste et sur celui que les autres équipes doivent continuer à accomplir. La FinOps Foundation précise que ses personas représentent des groupes de parties prenantes, et qu’une personne peut remplir les fonctions de plusieurs personas dans une très petite organisation. Cumuler les rôles ne supprime donc pas les responsabilités correspondantes.
Dans notre situation hypothétique, le blocage a aussi un coût : vous continuez à mobiliser des personnes pour examiner le sujet sans avoir organisé la prise de décision ni l’exécution de celle-ci. Nous proposons de partir de cet obstacle concret pour choisir l’organisation, plutôt que de choisir d’emblée l’intitulé du poste à ouvrir.
Les décisions en attente révèlent le besoin réel
Reprenez une décision récente concernant vos coûts cloud et reconstituez son parcours avec les personnes concernées. Demandez quelle information a déclenché l’examen, quelle analyse a été produite et ce qu’il restait à décider. Identifiez ensuite la personne qui devait modifier le service et le résultat qu’il fallait observer pour savoir si la recommandation avait été appliquée.
Cette distinction entre recommandation et réalisation figure dans le cadre de la FinOps Foundation. L’optimisation des usages relève principalement des équipes techniques, selon des orientations construites avec les autres parties concernées. La fonction FinOps suit le traitement des recommandations jusqu’à son terme et compare leur impact constaté aux estimations. Une recommandation documentée ne prouve donc pas, à elle seule, qu’une économie a été réalisée.
Dans notre exemple hypothétique, demandez pourquoi la modification n’a pas eu lieu. Si personne n’a pu examiner ses conséquences pour le service, vous devez préciser l’analyse attendue. Si cette analyse existe mais qu’aucune priorité n’a été fixée, le problème relève de l’arbitrage. Si la décision est prise mais que personne ne peut exécuter le changement, déterminez si ce sont les compétences, les accès ou le temps qui font défaut. Ces réponses conduisent à des besoins différents.
Pour chaque étape bloquée, notez le livrable attendu, la personne responsable et l’appui nécessaire. Examinez ensuite si le même travail revient dans d’autres décisions. Une tâche isolée permet d’identifier un obstacle, mais ne suffit pas à établir la nécessité d’un poste complet. Le groupe de travail de la FinOps Foundation recommande précisément de comprendre la situation actuelle et les objectifs avant de déterminer les effectifs nécessaires et de répartir les rôles.
La responsabilité partagée exige des engagements explicites
La FinOps Foundation décrit notamment des équipes virtuelles réunissant des personnes de la finance et des équipes techniques. Elle recommande aussi de documenter qui conseille, qui décide et comment ces responsabilités s’articulent avec les mécanismes de gouvernance existants. Le partage suppose donc une attribution explicite du travail.
Pour retenir cette option, désignez la personne qui suit l’avancement du sujet. Faites confirmer par la finance qui apporte et interprète les informations financières, puis par l’équipe technique qui examine et exécute les changements retenus. Précisez enfin qui tranche lorsqu’une action entre en concurrence avec une autre priorité. Dans son guide de gestion des coûts cloud, Amazon Web Services demande un soutien de direction permettant de faire respecter la priorité accordée aux optimisations.
Vérifiez ces engagements sur la décision que vous venez d’examiner. La personne chargée du suivi peut-elle obtenir les informations nécessaires ? Le responsable technique peut-il réserver du temps pour le changement envisagé ? Celui qui doit arbitrer accepte-t-il cette responsabilité ? Demandez une confirmation concrète de la disponibilité et des droits d’intervention, plutôt que de vous contenter du nom d’un service. AWS précise que la fonction doit consacrer du temps à la gestion et à l’optimisation des coûts, même lorsque cette activité n’occupe qu’une partie du temps d’une personne.
Consignez ensuite la marche à suivre lorsqu’un écart de dépense apparaît et convenez du moment où vous réexaminerez cette répartition. AWS recommande, dans son périmètre, une procédure commune entre finance et technique pour traiter ces écarts. Vous pouvez prendre ce livrable comme point de départ, puis vérifier sur la prochaine décision si chacun a pu tenir son engagement. Si personne ne dispose durablement du temps nécessaire pour accomplir ce travail, le partage formel des responsabilités ne résout pas le manque de capacité.
Un poste consacré au sujet doit pouvoir faire agir les équipes
La création d’un poste doit permettre de prendre en charge le travail durable que l’examen précédent a permis d’identifier. Le groupe de travail de la FinOps Foundation invite à dimensionner la fonction selon les objectifs financiers et opérationnels, plutôt qu’en appliquant un ratio particulier. Le seul montant de la facture ne suffit donc pas à définir le besoin.
Distinguez notamment l’analyse quotidienne de la construction technique. Le rôle FinOps Analyst décrit par ce groupe de travail contribue, avec d’autres équipes, aux prévisions, au traitement des anomalies et aux optimisations. La personne qui exerce le rôle FinOps Engineer/Architect construit et maintient l’infrastructure technique et les automatisations qui soutiennent la fonction FinOps. Si le travail qui reste sans prise en charge concerne surtout le suivi des décisions, ouvrir un poste centré sur les automatisations pourrait laisser ce besoin sans réponse.
Avant de choisir l’intitulé, décrivez ce que la personne devra produire et précisez les décisions qu’elle pourra prendre. Déterminez les données auxquelles elle devra accéder, les compétences nécessaires et les équipes dont dépendra son action. Un poste peut prendre en charge certaines modifications techniques si la personne dispose des compétences et des droits requis. Son intitulé ne permet pas de présumer qu’elle pourra intervenir sur tous les services.
Les relais doivent eux aussi s’engager. La FinOps Foundation demande aux équipes techniques de participer à l’évaluation de l’effort et de l’impact des optimisations, puis de convenir d’échéances réalistes pour les recommandations retenues. Demandez donc aux responsables concernés comment ils examineront les propositions du futur titulaire et qui pourra les mettre en œuvre. Précisez avec la finance les contributions attendues et avec la direction le recours prévu en cas de désaccord sur les priorités.
Vous pouvez alors cadrer un besoin de recrutement : le travail est identifié, les livrables sont compréhensibles et les contributions attendues des autres équipes ont chacune un responsable identifié. Si vous retenez un recrutement par approche directe, ce cadrage permet de préciser les compétences à rechercher. Lorsque les accès ou les relais restent indéterminés, résolvez d’abord ces points : consacrer un poste au sujet ne lui donne pas automatiquement les moyens d’agir.
La prochaine décision porte sur le responsable et ses moyens
Si les personnes présentes peuvent prendre en charge le travail et faire appliquer les décisions, formalisez leurs engagements. Si un travail durable dépasse leur disponibilité, préparez un poste dont les relais techniques et financiers sont confirmés. Nous vous proposons de suspendre le choix d’organisation tant que vous ne savez pas qui peut décider puis exécuter : réunissez les personnes concernées autour d’une décision restée en attente pour établir ce qui manque. Ce diagnostic permet d’attribuer une responsabilité, sans garantir à lui seul une baisse des dépenses.
Sources
FinOps Foundation : FinOps Personas
FinOps Foundation : FinOps Practice Operations Capability
FinOps Foundation : Building FinOps Teams: Roles, Structures, Career Paths
FinOps Foundation : Usage Optimization FinOps Framework Capability
