Blog/FinOps
FinOps

FinOps après la migration : qui porte le budget cloud au mois 6 ?

Au mois 6, le double run est fini et l'équipe projet dissoute : la facture cloud n'a plus de propriétaire. Qui doit la porter, et avec quel mandat.

Premaccess07 / 09 / 20266 min de lecture

La réponse tient en une phrase : le budget cloud est porté par l'équipe qui peut le faire bouger, c'est-à-dire celle qui déploie, avec un interlocuteur nommé côté finance et une revue mensuelle. Si ce nom n'a pas été écrit avant la bascule, il n'existe pas au mois 6 — et la facture, elle, continue d'arriver.

Pourquoi le mois 6 et pas le mois 2

Les premiers mois ne posent pas de problème, parce que tout le monde sait pourquoi la facture monte. On fait tourner l'ancien et le nouveau en parallèle, on surdimensionne pour sécuriser la bascule, on garde des environnements de recette qui n'existaient pas avant. C'est assumé, c'est temporaire, et c'est financé comme du projet.

Au mois 6, trois choses se sont produites en même temps. Le double run est terminé, donc l'excédent que l'on tolérait n'a plus d'explication. Les premières décisions d'engagement de capacité arrivent, et les prendre ou non est un arbitrage budgétaire avant d'être un choix technique. Enfin l'équipe projet s'est dissoute : les personnes qui savaient pourquoi telle base de données est dimensionnée ainsi sont sur autre chose. Le coût, lui, est devenu récurrent sans que personne ait signé pour.

Les trois propriétaires qu'on nous propose

Quand nous posons la question en comité, la réponse tombe presque toujours dans l'une de ces trois cases. Aucune ne tient seule.

  • La finance. Elle voit le montant sans voir ce qui le produit, et elle n'a aucun levier direct : arbitrer entre deux lignes d'un tableau ne change pas la taille d'une instance.
  • La DSI, globalement. Un budget porté par tout le monde n'est porté par personne. Un montant consolidé au niveau de la direction ne redescend jamais jusqu'à la décision technique qui le ferait bouger.
  • Le prestataire. Il optimise ce qu'il exploite, et c'est déjà beaucoup. Il ne décide pas à votre place qu'une préproduction s'éteint la nuit, ni qu'une application que plus personne n'ouvre est arrêtée.

Ce qui fonctionne est un partage explicite plutôt qu'un propriétaire unique : l'équipe qui déploie porte le chiffre, la finance porte la trajectoire et la contradiction, l'exploitant porte la mesure et l'outillage. Trois rôles, trois noms, une réunion par mois.

Ce qui rend un budget réellement portable

  1. Un découpage qui correspond à une équipe réelle. Tant que la facture est un seul nombre pour toute l'entreprise, elle n'est actionnable par personne. Comptes séparés par domaine, ou étiquetage imposé à la création de la ressource : l'un ou l'autre fonctionne, l'absence des deux ne fonctionne pas.
  2. Une part non attribuée, mesurée et décroissante. Il en restera toujours : réseau partagé, socle, journalisation, sauvegardes. Ce qui compte est de la connaître et de la faire baisser, pas de la répartir au prorata pour que le tableau soit propre.
  3. Un chiffre que l'équipe voit sans avoir à le demander. Un montant qu'il faut réclamer à quelqu'un est un montant que l'on regarde une fois par trimestre, c'est-à-dire trop tard pour agir dessus.
  4. Un mandat d'agir. Le porteur doit pouvoir éteindre, redimensionner et supprimer dans son périmètre sans convoquer un comité. Sans ce mandat, il constate une dérive ; il ne porte pas un budget.

Ce que nous regardons en premier

Sur les environnements que nous reprenons en infogérance cloud après une migration, l'ordre est presque toujours le même, parce qu'il va du réversible vers l'engageant. D'abord ce qui tourne sans servir : environnements hors production allumés la nuit et le week-end, volumes détachés de toute machine, sauvegardes sans politique de rétention, adresses IP réservées puis oubliées. Ensuite le dimensionnement, une fois que l'on dispose de semaines de métriques réelles et non des hypothèses du dossier de migration. Ensuite seulement les engagements de durée. Les prendre en premier est l'erreur la plus coûteuse que nous voyons : elle fige une empreinte que l'on n'a pas encore corrigée et transforme une dérive en dépense contractualisée.

Aucun de ces leviers n'est nouveau, et ce n'est pas le sujet. Nous les avons détaillés dans cinq leviers pour réduire votre facture cloud et, côté AWS, dans la gestion des coûts au quotidien. Ce qui manque au mois 6 n'est pas la liste des leviers, c'est le nom de la personne qui décide de les actionner.

Les signaux qu'il n'est porté par personne

  • La facture n'est commentée qu'en comité trimestriel, à partir d'un export retravaillé à la main.
  • Personne ne sait dire, sans instruction préalable, ce qui explique l'écart du mois précédent.
  • Le mot « optimisation » n'apparaît qu'après un dépassement, jamais dans une décision d'architecture.
  • Toutes les demandes d'arrêt d'environnement remontent à la même personne, et cette personne est débordée.

Le décider avant, pas après

Le bon moment pour nommer le porteur du budget est la conception de la migration, quand le découpage en comptes et la convention d'étiquetage sont encore un choix et pas une reprise. À ce moment-là, cela tient dans une réunion ; six mois plus tard, c'est un chantier. Si vous êtes déjà au mois 6, la démarche est la même en sens inverse : reconstituer le découpage, nommer le porteur, puis seulement mesurer et arbitrer.

Sur ce que recouvre concrètement la démarche, voir notre offre FinOps, et si la question porte d'abord sur le périmètre exploité, notre conseil et audit.

Aller plus loin

Ce sujet vous concerne ? Découvrez notre offre FinOps : réduire votre facture cloud, ou parlez à un expert (réponse sous 24 heures ouvrées).

Questions fréquentes
Qui doit porter le budget cloud après une migration ?

L'équipe qui déploie, parce qu'elle est la seule à pouvoir le faire bouger, avec un interlocuteur nommé côté finance et une revue mensuelle. La finance seule constate sans levier ; une DSI « globalement responsable » ne redescend jamais jusqu'à la décision technique ; le prestataire optimise ce qu'il exploite mais ne décide pas de l'arrêt d'une application.

Pourquoi la facture cloud pose-t-elle problème une fois la migration terminée ?

Elle n'augmente pas forcément : elle cesse d'être expliquée. Le double run, le surdimensionnement de sécurité et les environnements créés pour la bascule étaient financés comme du projet. Quand le projet se ferme, ces coûts restent et changent de nature : ils deviennent de l'exploitation récurrente que personne n'a arbitrée.

Faut-il prendre des engagements de capacité au mois 6 ?

Pas en premier. Un engagement fige une empreinte pour un ou trois ans : le prendre avant d'avoir supprimé l'inutilisé et corrigé le dimensionnement transforme une dérive en dépense contractualisée. L'ordre qui fonctionne est d'arrêter ce qui ne sert pas, de redimensionner sur des métriques réelles, puis d'engager seulement ce qui est stable.

P
PremaccessExperts Cloud · Franco-suisse depuis 2007
/ À lire aussi