Espace clientSe connecter
Planifier un échange
Méthodologie détaillée

Les règles qui rendent chaque chiffre vérifiable

Cette page complète les neuf phases de la méthodologie : comment les leviers sont priorisés et séquencés, ce que la mesure doit prouver, comment l'avancement se suit et comment les écarts se gouvernent. Les seuils cités sont des valeurs par défaut, fixées au cadrage et visibles dans le classeur.

Priorisation

Une matrice qui rend l'arbitrage explicite

Chaque levier qualifié est classé sur trois axes : le gain mensuel calculé sur votre coût observé, l'effort de mise en œuvre en jours et le risque, avec sa nature et sa réversibilité. La matrice ne décide pas à votre place : elle rend l'arbitrage explicite et chiffré, se rejoue si vous changez de politique et sert de support à la restitution.
  • Gain : potentiel mensuel calculé sur le coût observé de votre facture (amorti et décaissé), jamais sur un prix public seul. Tant qu'un montant n'est pas confirmé ressource par ressource, il est donné en ordre de grandeur.
  • Effort : jours de travail par levier, avec des valeurs par défaut que vous corrigez (1 jour pour un achat d'engagement, 2 jours pour les disques ou la sauvegarde, 3 jours pour un right-sizing, 5 jours pour un Start & Stop). Hors machines virtuelles, chaque levier reçoit aussi une note de facilité, de 1 (très facile) à 5 (difficile).
  • Score : par défaut, le gain mensuel divisé par les jours d'effort ; si vous corrigez un effort ou un risque, le rang se recalcule. À score équivalent, les environnements les moins sensibles passent en premier. L'ordre que vous décidez prime sur le score calculé, et les deux restent visibles.
  • Trois horizons : les gains rapides (au plus 3 jours d'effort par défaut, ou une facilité de 1 ou 2) se réalisent en 0 à 6 semaines ; le moyen terme (1 à 6 mois : redéploiements, changements de gamme, migrations) se planifie dans vos fenêtres de maintenance ; les options à arbitrer sortent de la politique que vous avez retenue.
  • Options à arbitrer, par exemple : réduire la production, modifier une application dont l'éditeur certifie des tailles précises, baisser la résilience des sauvegardes de production. Elles sont chiffrées pour que votre direction décide en connaissance de cause et restent sans date, hors du total planifié, tant qu'elle ne les a pas retenues.
  • Nature de la décision : une politique centrale, c'est-à-dire une seule décision pour tout le parc, est traitée en premier. Une action de propriétaire demande à chaque équipe d'accepter puis d'exécuter : c'est là que l'exécution se perd, et c'est là que le suivi se concentre. Un achat d'engagement relève des achats et suit le calendrier des échéances.
  • L'urgence et la durée de vie avant la taille : ce qui échoue si ce n'est pas fait à temps (échéance d'un engagement, date imposée) passe devant le plus gros gain. Un engagement dont le point mort tombe après la fermeture prévue d'un environnement est déconseillé, et un périmètre en sortie descend en bas de la liste, raison consignée.

Votre politique, en configuration. Leviers acceptés (right-sizing nulle part, hors production ou partout ; Start & Stop ; engagements), cibles de couverture par environnement, exclusions. Le hors production passe en premier et la production n'est jamais réduite dans le plan de base. Si vous changez de politique, le plan se rejoue sans réécrire les règles et montre ce qui change.

Sans double compte. La matrice affiche un total brut, les recouvrements estimés entre leviers, puis un total net. Dans le plan d'actions, seules les lignes de levier portent une valeur ; les actions de processus (notes, campagnes, cadences) n'en portent aucune, si bien que le plan se réconcilie exactement avec le potentiel.

La matrice

Ce que chaque situation implique

Situation du levierGain, effort, risqueCe que cela implique
Gain rapideGain moyen à élevé ; au plus 3 jours d'effort, ou facilité 1 à 2 ; risque faible, réversible, à chaudLancé dès les premières semaines ; l'accord du propriétaire de la ressource suffit, sans attendre un comité
Achat d'engagementGain élevé ; environ 1 jour d'effort ; engagement de duréePrioritaire mais séquencé : après la réduction et la vérification des engagements existants, acheté par tranches avec contrôle de l'utilisation
Chantier de moyen termeGain élevé ; plusieurs jours, facilité 3 à 5 ; risque moyen (arrêt, latence, copie de données)Planifié sur 1 à 6 mois dans vos fenêtres de maintenance, regroupé par ressource, précédé d'un pilote
Option à arbitrerGain variable ; risque élevé ou hors politique (production, tailles certifiées par l'éditeur, résilience)Chiffrée, sans date, hors du total planifié jusqu'à décision de votre direction
Petit gain facileGain, effort et risque faiblesTraité en lot : une seule demande par propriétaire, un changement par type d'action, ou une politique centrale
Petit gain coûteuxGain faible, effort élevéReporté ou écarté avec son motif ; sur la longue traîne, arrêt ou décommissionnement plutôt qu'optimisation
Gain non confirmé par la mesureNon compté ; risque inconnuListé pour information, sans économie comptée tant que les métriques ne le confirment pas
Dépendances et séquencement

Chaque recommandation peut être juste et le plan rester faux

Deux leviers qui portent sur la même ressource ne s'additionnent pas, et un engagement acheté trop tôt fige une sur-réservation. Le plan est donc séquencé : chaque action porte ses prérequis, ce qui peut avancer en parallèle, son responsable et sa fenêtre. Présenté à la restitution, il s'applique pendant l'exécution.
  • Réduire avant de réserver : right-sizing, puis Start & Stop, puis engagements. Chaque levier est calculé sur ce que laisse le précédent : le Start & Stop d'une machine réduite de moitié porte sur un coût déjà divisé par deux.
  • Les engagements existants d'abord : avant tout achat, nous vérifions leur étendue et leur utilisation. La capacité réservée que libère le right-sizing est réaffectée à l'usage à la demande de la même famille et de la même région, la production en premier ; la part que rien n'absorbe est chiffrée comme capacité perdue et donne lieu à une action d'échange ou de réemploi.
  • Conflits sur une même ressource : quand Start & Stop et engagement sont tous deux possibles sur une machine, la règle par défaut garde celui qui rapporte le plus et trace le conflit. Sur un disque, seul le meilleur levier est retenu, et dans la vue par périmètre les recouvrements sont répartis au prorata.
  • Start & Stop et engagements partagés : arrêter une machine couverte par un engagement partagé ne fait économiser que si une autre machine à la demande du même pool tourne à la même heure. Le Start & Stop se déploie donc en vagues, d'abord sur les machines dont les heures libérées sont absorbées sans perte.
  • Génération des machines : engagement long sur les générations récentes ; engagement court à couverture réduite sur les anciennes, le temps de migrer par vagues ; aucun achat avant la mise à niveau pour les familles qui migrent.
  • Le calendrier des engagements est un chemin critique : inventaire des échéances, scénarios de renouvellement (durée, couverture cible, mode de paiement), décision prise assez tôt pour laisser le temps de l'achat, selon un délai fixé au cadrage, puis une règle de gouvernance des engagements (seuil de couverture, qui décide, quand).
  • Achats par tranches : la quantité part d'une base stable de l'usage mesuré, servie 9 jours sur 10, arrondie à la baisse et exprimée dans la plus petite taille de la famille. L'utilisation est contrôlée dans les jours qui suivent l'achat ; un complément n'est acheté le mois suivant que si l'utilisation est pleine.
  • Une fenêtre par ressource : les changements d'une même machine (taille, type de disque, modernisation) sont regroupés dans une seule fenêtre de redémarrage, avec l'ordre des opérations et l'interruption estimée.
  • Dépendances d'exploitation : si le patching ou les sauvegardes du week-end supposent des machines allumées, le Start & Stop démarre sur les nuits de semaine et s'étend au week-end une fois les scripts d'exploitation adaptés ; la supervision doit distinguer une extinction planifiée d'un incident.
  • Propagation des refus : refuser le right-sizing d'une machine écarte aussi les changements de niveau de ses disques ; refuser la réaffectation d'une capacité réservée la laisse chiffrée comme perdue, avec une ligne au plan d'actions.

Dès la semaine 1. Ce qui ne dépend de rien démarre tout de suite : disques non attachés, sauvegarde hors production, services faciles. Ces actions sont locales, réversibles et sans engagement ; elles demandent l'accord du propriétaire de la ressource, pas un comité.

Avant tout. Le cadrage conditionne le reste, sans gain direct : règles validées en comité, un référent nommé par périmètre, droits d'achat d'engagements vérifiés, listes de ressources figées et envoyées, point hebdomadaire ouvert.

Les dépendances

Ce qui doit précéder, et pourquoi

DépendanceCe qui doit précéderCe que cela évite
Achat d'engagementRight-sizing, Start & Stop, contrôle des engagements existants, réaffectation de la capacité libéréeSur-réservation, engagement payé sur des heures supprimées
Start & Stop d'une machine réduiteRight-sizing de cette machineCompter deux fois la même économie
Start & Stop d'une machine couverte par un engagement partagéVérifier qu'une autre machine du pool absorbe les heures libérées, sinon attendre l'échéanceHeures réservées perdues, économie nulle
Engagement sur une génération ancienneMigration ou mise à niveau de la famille, ou engagement courtS'engager plusieurs années sur une famille appelée à disparaître
Changement de type de disqueFenêtre d'arrêt de la machine, regroupée avec son right-sizingDeux interruptions pour la même machine
Extinction le week-endAdaptation du patching et des sauvegardesIncident d'exploitation, sauvegarde manquée
Extension à tout un périmètreRetour d'expérience du piloteGénéraliser un planning ou une procédure non éprouvés
Toute actionCadrage : règles validées, référent nommé, listes figées, droits vérifiésActions bloquées faute de décideur ou de droits
Preuves par la mesure

Une économie n'est comptée que si vos métriques la confirment

Les recommandations natives des fournisseurs (Azure Advisor, AWS Compute Optimizer, Google Cloud Recommender) servent de point de départ, pas de preuve. Une économie n'est comptée que lorsque les métriques mesurées sur votre parc la confirment, sur une fenêtre de 30 jours avec un nombre minimal de points ; sinon la recommandation reste visible, sans montant.
  • Double preuve pour réduire une machine : la recommandation native et les métriques des 30 jours doivent être sous le seuil retenu : CPU au 95e centile, mémoire au 95e centile quand elle est mesurée et, quand le fournisseur les expose, IOPS disque au pic. Seuil par défaut 50 % ; la règle prudente retient 40 %, pour que la taille moitié reste sous 80 % d'utilisation. Sans recommandation native, aucune réduction n'est proposée.
  • Assez de points : une machine qui n'atteint pas le nombre minimal de points sur la fenêtre, désallouée ou éphémère, est affichée à part et n'entre pas dans les taux.
  • Mémoire non mesurée : sans agent de collecte, la mémoire est inconnue ; le gain est alors minoré, ou la machine n'est pas comptée, et la limite est écrite sur la ligne.
  • Production : jamais réduite dans le plan de base. Si vous décidez de l'ouvrir, la fenêtre de mesure s'allonge, en général à 90 jours, pour voir les pics de clôture mensuelle, et une validation applicative est demandée.
  • Start & Stop : on part de l'usage observé, avec les heures facturées et un planning cible de 12 heures par jour ouvré, week-ends et jours fériés éteints. Les profils horaires mesurés classent chaque machine dans l'un de trois cas : sans activité le week-end, bruit de fond constant (agents, supervision), activité réelle 7 jours sur 7 à confirmer avec son propriétaire. Quand la collecte à la minute existe, une fenêtre d'allumage est proposée machine par machine, avec une marge d'une heure et une fenêtre minimale de 8 heures.
  • Tri des recommandations natives : une recommandation d'engagement répétée à l'identique sur chaque abonnement est une information ; un doublon est retiré quand un levier mesuré chiffre déjà le même gain ; une recommandation calculée au prix catalogue, alors qu'une remise négociée s'applique déjà, n'est jamais additionnée.
  • Une preuve lisible par le propriétaire : chaque ligne soumise porte une colonne « Pourquoi cette recommandation » qui cite les valeurs mesurées. Les preuves sont conservées avec leur fenêtre et leur niveau de confiance : un auditeur peut recalculer chaque montant.
  • Contrôle après action, sur les mêmes métriques : après une réduction, le CPU au pic doit rester sous 70 % et la mémoire disponible au-dessus de 20 % pendant une fenêtre fixée au cadrage, sinon la machine revient à sa taille d'origine ; l'utilisation d'un engagement est contrôlée dans les jours qui suivent l'achat.

Facturation seule. Si seul l'accès à la facturation est ouvert, les montants sont présentés comme des hypothèses structurelles, en fourchette basse et haute, avec la mention d'estimation, et nous demandons l'accès aux métriques avant toute action. Si la collecte des métriques d'un service échoue, ses règles passent en mode prudent et n'affichent aucun gain.

Historique des métriques. Lorsque la collecte continue est en place, les métriques sont conservées à la minute par machine et par jour : les centiles se recalculent sur 30, 60 ou 90 jours sans interroger de nouveau le fournisseur, toujours en lecture seule.

Leviers et mesures

Ce qui est mesuré, sur quelle fenêtre, avec quel garde-fou

Les seuils sont des valeurs par défaut, modifiables au cadrage et visibles dans l'onglet de paramètres du classeur.

Réduction de taille d'une machine

Recommandation native, CPU au 95e centile, mémoire au 95e centile si mesurée, IOPS au pic.

  • Fenêtre : 30 jours avec un nombre minimal de points ; en général 90 jours si la production est ouverte
  • Seuil : sous 50 % (40 % en règle prudente), taille moitié disponible dans la famille
  • Garde-fou : non confirmée, la ligne reste « recommandation native seule », sans économie comptée

Start & Stop

Heures facturées, profil horaire, activité du week-end.

  • Fenêtre : fenêtre d'analyse, puis les 7 derniers jours complets pour le suivi
  • Seuil : week-end peu actif (CPU moyen sous 5 %, maximum sous 30 %) ; fenêtre minimale de 8 heures
  • Garde-fou : une activité 7 jours sur 7 est confirmée avec le propriétaire avant tout planning

Niveau et taille des disques

Pics d'IOPS et de débit, espace réellement utilisé.

  • Fenêtre : 30 jours
  • Seuil : pics sous 80 % des plafonds du niveau cible ; taille égale à l'espace utilisé plus 30 %
  • Garde-fou : un disque saturé (95 % ou plus) n'est jamais abaissé ; aucune baisse sans métrique

Bases, plans d'hébergement et stockage

CPU, DTU ou mémoire au maximum ; transactions pour un stockage peu sollicité.

  • Fenêtre : 30 jours
  • Seuil : maximum sous 20 % ; moins de 5 000 transactions par jour pour un stockage
  • Garde-fou : ordre de grandeur, à confirmer ressource par ressource

Ressource inactive

CPU maximum, trafic réseau, connexions.

  • Fenêtre : 30 jours
  • Seuil : CPU maximum sous 5 %, trafic quasi nul
  • Garde-fou : désallocation, puis conservation pendant une période fixée au cadrage avant suppression, avec l'accord du propriétaire

Engagements

Heures quotidiennes à la demande et réservées, prix et remise observés.

  • Fenêtre : série quotidienne
  • Seuil : base servie 9 jours sur 10, arrondie à la baisse
  • Garde-fou : achat par tranches, après réduction ; pas d'achat sur un usage instable ; contrôle de l'utilisation (au moins 95 %) dans les jours qui suivent l'achat
Indicateurs d'exécution

L'avancement se mesure en valeur et en preuves

Pas en nombre de réunions. Trois chiffres structurent chaque revue : la cible (potentiel identifié), la trajectoire (run-rate sécurisé) et la preuve (économies générées à date, contre-vérifiées sur la facture). Les autres indicateurs expliquent l'écart entre ces trois chiffres.
  • Une seule chaîne de valeur : identifié (chiffré et publié après les contrôles de qualité et d'alignement sur votre politique), validé par le propriétaire, planifié (date et référence de changement ou de commande), réalisé, constaté en facture. Les montants de chaque étape ne s'additionnent jamais ; les statuts sont repris d'une analyse à l'autre et tenus en revue avec vos équipes.
  • Chaque action porte un responsable, un statut d'action (à faire, en cours, réalisée, abandonnée), un taux de réalisation, une date et un commentaire. Tant qu'une action n'est pas marquée réalisée avec une date, son gain n'est pas compté comme généré.
  • Une économie constatée, pas déclarée : pour une ressource modifiée, l'économie se lit sur la facture, comme l'écart entre le coût moyen par jour avant et après la date du changement. Pour une machine couverte par un engagement, seules la part à la demande et les licences comptent tant que le pool ne réabsorbe pas les heures libérées.
  • Pont des variations : chaque euro de variation de la facture est rattaché à une ressource et à une cause (baisse d'usage, changement de taille ou de niveau, passage sous engagement, ressource supprimée). La somme des causes égale exactement la variation, et les économies évitées restent dans le plan.
  • Constats hors plan et hygiène des chiffres : les optimisations visibles sans ligne au plan et les coûts nouveaux sont signalés à part. Crédits, corrections ponctuelles et écarts théoriques qu'aucune facture ne confirme ne sont jamais comptés comme économies, et l'on raisonne à périmètre constant.
  • Comportement : le taux de réponse des propriétaires plutôt que le nombre de demandes envoyées ; les taux de conversion (validé sur identifié, réalisé sur validé) ; les actions bloquées au-delà d'un délai fixé au cadrage.

Trois chiffres par revue

  • La cible : potentiel identifié, net des recouvrements
  • La trajectoire : run-rate sécurisé
  • La preuve : économies générées à date, contre-vérifiées sur la facture

Ce qui est outillé. Le moteur calcule le run-rate sécurisé, le généré à date et le pont des variations. Le constat avant et après, ressource par ressource, et le repérage des écarts hors plan se tiennent dans nos classeurs de suivi.

Le tableau de bord

Huit indicateurs clés

IndicateurDéfinitionFréquence et suivi
Potentiel identifié (la cible)Gain mensuel net des actions du plan, hors options, après recouvrements entre leviersÀ chaque collecte ; présenté à la direction
Run-rate sécurisé (la trajectoire)Potentiel multiplié par le taux de réalisation des actions en cours ou réalisées, en euros par moisChaque semaine ; référent FinOps
Généré à date (la preuve)Run-rate sécurisé multiplié par les mois écoulés depuis la date de réalisation, en cumulChaque semaine ; référent FinOps, contrôle de gestion
Facture en coût amorti (la contre-vérification)Coût amorti à périmètre constant sur les 7 derniers jours puis sur le mois, expliqué par le pont des variationsChaque semaine et chaque mois ; contrôle de gestion
Options en attente d'arbitrageGain des options chiffrées non encore décidéesÀ chaque revue de direction
Taux de conversionValidé divisé par identifié ; réalisé divisé par validéChaque mois ; comité de pilotage
Actions bloquéesActions sans avancement au-delà d'un délai fixé au cadrageChaque semaine ; référent FinOps, avec escalade
Couverture des engagementsPart de l'usage couvert, avant et après le plan d'achat, par périmètre, famille et environnementChaque mois ; référent FinOps, achats

Selon le besoin s'y ajoutent la part du potentiel sécurisée, le sécurisé en année pleine, le taux de réponse des propriétaires, l'exécution des achats d'engagements, la part des machines à réduire, le taux de Start & Stop du hors production et la qualité de la mesure.

Écarts et revues

Un plan s'écarte toujours de sa version initiale

Un propriétaire refuse, une fenêtre glisse, une action annoncée n'apparaît pas sur la facture. Ces écarts sont enregistrés, motivés et pris en compte au calcul suivant : le potentiel affiché reste vrai, et les décisions ne se perdent pas. Ce dispositif s'applique de la validation au transfert, et se cale sur vos comités existants au lieu de s'y ajouter.
  • Les rôles : un sponsor nommé porte la démarche et figure dans chaque communication. Un binôme FinOps la pilote : notre consultant et votre référent FinOps interne. Un référent par entité, souscription ou application figure dans la colonne responsable du plan d'actions. L'exploitation ou l'infogérant exécute ; les achats et la finance décident des engagements.
  • Registre des retours : pour chaque ressource et chaque levier, une décision de ligne (validée, écartée avec motif, à instruire), avec sa source et sa date. Le registre est relu à chaque analyse : une recommandation écartée sort du potentiel au calcul suivant, son motif reste visible, et elle ne revient pas chaque mois.
  • Configuration et journal : les exclusions de périmètre et les décisions sur les engagements sont enregistrées dans votre configuration et réappliquées à chaque calcul. Un journal date chaque décision et chaque jalon, avec son périmètre, sa référence et son effet dans le suivi.
  • Écarts lus sur la facture : une action annoncée mais non constatée est signalée, par exemple une ressource déclarée supprimée encore facturée. Une ligne absente de l'analyse suivante passe en « sans objet » ou « à vérifier », avec son motif.
  • Une escalade convenue au cadrage : un délai de réponse, une relance à l'échéance, puis une escalade graduée au responsable de l'entité et enfin à la direction, selon des paliers fixés au cadrage, toujours avec l'impact chiffré. Chaque chantier porte un statut couleur : vert, ambre ou rouge.
  • Règles de décision : un backlog unique, tenu dans votre outil, avec pour chaque ligne la valeur, le propriétaire, la décision, la date d'effet et un motif de rejet obligatoire. Les actions sans coupure ni risque passent avec le seul accord du propriétaire ; une politique sans date d'effet n'est pas considérée comme décidée.
  • Ce qui n'est pas automatisé : KeeFinops n'agit sur aucune de vos ressources, ne crée aucun ticket et ne modifie rien. Nous préparons les actes ; vos équipes exécutent, et la vérification se fait sur votre facture.

Le rythme. Chaque semaine, l'analyse est rejouée sur la dernière collecte ou sur l'archive que vous déposez : rejouer une période la réécrit, sans doublon. Pendant l'exécution accompagnée, un point hebdomadaire court passe en revue les statuts, les trois chiffres de synthèse et la contre-vérification sur la facture, puis traite les blocages.

Dans la durée. Cadence de l'exécution et du pilotage continu : un jour par semaine pendant trois mois, puis une demi-journée par mois. Avec l'option autonomie, une revue trimestrielle du potentiel.

Les rendez-vous

Qui se réunit, quand, pour quoi faire

Rendez-vousFréquence et participantsContenu
Mise à jour de l'analyseChaque semaine ; collecte en lecture seule ou archive déposée, contrôlée par KeeFinopsComplétude, classeur et indicateurs mis à jour, nouvelles lignes au statut « identifié »
Point d'exécutionChaque semaine pendant l'exécution accompagnée ; référent FinOps, KeeFinops, référents concernésStatuts, taux et dates ; cible, trajectoire et preuve ; blocages et arbitrages
Lancement d'un périmètreUne fois par périmètre ; référent, propriétaires, KeeFinopsValidation des recommandations, calendrier, fenêtres de changement
Rapport de directionChaque mois ; sponsor, directionUne page : cible, identifié, validé, réalisé, constaté en facture, blocages, options à arbitrer
Point d'étape de directionÀ chaque jalon ; direction, référent FinOps, KeeFinopsDécisions et options, compte rendu avec actions, responsables et échéances
Revue des engagementsChaque trimestre ; achats, finance, référent FinOps, KeeFinopsCouverture, utilisation, échéances ; une décision par engagement, prise avant son échéance

Les fréquences sont fixées avec vous au cadrage et calées sur vos comités existants.

Grands comptes

La gouvernance renforcée, lot par lot

Pour un groupe à plusieurs entités, le même dispositif s'élargit : un cadre commun que chaque entité applique, des comités qui décident, des indicateurs d'adoption par entité. Il s'installe par lots au forfait, s'opère avec un FinOps intégré à vos équipes, puis se transfère.
  • Lot 1, cadre commun : dictionnaire des dimensions, règles d'allocation si/alors, clés de répartition des coûts partagés et de refacturation, validées avec chaque entité.
  • Lot 2, rôles et comités : sponsor, binôme FinOps, référent par entité, propriétaires d'applications, achats, contrôle de gestion, responsable Green IT ; point hebdomadaire de 30 minutes, revue d'optimisation de 45 minutes, comité mensuel d'une heure, comité fournisseurs à chaque échéance.
  • Lot 3, indicateurs et contrats : KPI d'adoption par entité (part du coût allouée, actions avec propriétaire et date, délai entre identification et décision, couverture et part inutilisée des engagements, indicateurs Green IT) ; registre des contrats, consommation contre engagement, revue trimestrielle avec les achats.
  • Lot 4, opération et transfert : budget re-prévu chaque mois, chaque écart expliqué par sa cause (volume, prix, nouveaux projets, optimisations) ; reprise par vos référents ou par un FinOps interne.

Outillage, sans surpromesse. Showback et variations expliquées : dans notre application. Tagging virtuel, clés de refacturation et registre des contrats : sur classeur, en attendant leur intégration, prévue. Indicateurs Green IT : outillés ; émissions publiées par le fournisseur : pratiqué en mission.

Reporting. Un format groupe et un format par entité, GreenOps compris, calé sur la publication mensuelle des fournisseurs.

Exigences de revue

Ce que nous vérifions avant de soumettre une recommandation

Ces exigences sont tenues en revue, ligne par ligne, avec vos équipes ; elles ne supposent aucun statut calculé automatiquement.

Un constat, une famille, un seul compte

Nous rangeons chaque constat dans une famille définie par le levier qui le traite : supprimer, réduire, planifier, mieux acheter, revoir l'architecture, attribuer et gouverner. Une même ressource n'est jamais comptée deux fois : une ressource inactive ne figure pas aussi en right-sizing.

Des données reliées

Nous relions coût, inventaire, configuration, usage, organisation et décisions, car un coût isolé n'est pas actionnable. Un export de facturation non activé au niveau ressource est une limite majeure, écrite comme telle.

Le contexte avant la recommandation

Nous vérifions avec vos propriétaires l'application, l'environnement, la criticité, les contraintes de l'éditeur et la fenêtre de maintenance de chaque ressource. Une éligibilité inconnue vaut interdiction pour toute action destructive.

Des notions d'économie jamais mélangées

Nous distinguons l'économie théorique au prix public, le coût évitable brut, l'économie de trésorerie nette après engagements, l'opportunité de réallocation d'un engagement libéré et l'économie bloquée. Une économie ne dépasse jamais le coût observé.

L'effet sur les engagements, écrit en clair

Nous vérifions l'effet de chaque action sur vos réservations et savings plans : couverture avant et après, engagement libéré, réallocation possible. Quand la donnée de couverture manque, l'effet est dit inconnu, jamais nul.

Assez de mesures avant de conclure

Nous lisons les métriques sur 30 jours au 95e centile, avec un nombre minimal de points. Une seule métrique élevée suffit à écarter une réduction ; des métriques intermédiaires passent en revue manuelle, et une mémoire non mesurée est écrite en limite.

Ressources inactives : jamais de suppression directe

Arrêt, puis observation pendant une durée fixée au cadrage, sauvegarde des volumes, notification du propriétaire et suppression après validation. Nous ne proposons pas de suppression si le propriétaire, l'éligibilité ou l'état de sauvegarde est inconnu.

Six questions par recommandation

Pourquoi elle est valide, pourquoi elle compte financièrement, si elle est sûre, quand l'appliquer, qui en est responsable, si les outils natifs l'ont déjà trouvée. Une recommandation sans justification ni limite est incomplète.

Un propriétaire pour chaque ligne

Nous cherchons le propriétaire par tag, CMDB ou convention de nommage, puis par relation : un disque suit sa machine. À défaut, une dimension de repli porte la ligne, signalée comme telle jusqu'à la revue.

Pratiques selon le contexte

Ce que la méthode ajoute quand le contexte le demande

Ces pratiques s'ajoutent aux neuf phases selon la nature de la mission ; elles sont décrites sans chiffre propre à une mission.

Cadrage

Partir de l'existant

  • Une période d'immersion, quand la mission commence ainsi : un rapport d'étonnement en plusieurs formats, dont une synthèse d'une page pour décider. Les forces passent avant les limites.
  • Une grille de maturité par pilier (allocation, budget, reporting, optimisation, gouvernance, outillage et données, culture) : quand l'allocation est déjà solide, nous industrialisons sa production au lieu de la refaire.
  • Une vue de coût de référence par usage (finance, pilotage d'équipe, usage technique, optimisation), avec un glossaire partagé.
  • Un rôle FinOps exprimé comme un besoin métier, formalisé avec votre équipe sécurité : consultation des coûts et des rapports enregistrés, lecture de l'export détaillé. Il ne donne aucun droit d'écriture ; les objets de facturation (catégories de coûts, budgets, alertes) sont configurés par votre équipe, à partir de nos propositions.
Collecte et diagnostic

Lire ce que la facture ne dit pas seule

  • Une demande de données priorisée : priorité, levier débloqué, emplacement de la donnée et statut (reçue, partielle, à fournir). Tout est demandé en lecture seule.
  • Des indicateurs de power management pour le hors production : une ressource est pilotée si son planning est configuré, allumée 24/7 si elle tourne presque toute la fenêtre. Un planning posé sur une ressource qui tourne 24/7 signale une automatisation défaillante.
  • Les bases de données managées : seul le compute est compté ; sur certains services, une base arrêtée redémarre seule au bout de sept jours, et l'arrêt d'une base couverte par une réservation ne rapporte rien en trésorerie.
  • Des signaux à instruire : décommissionnement dont le coût augmente, hors production 24/7 dans un compte de production, haute disponibilité active hors production. Pour chacun, une hypothèse et la donnée qui manque.
Priorisation

Un plan qui suit les dépendances

  • Un plan pluriannuel en classeur, qui part de la facture et des économies déjà captées, réconcilie le backlog existant pour éviter tout double comptage et liste les données à fournir. Les recommandations de l'outil natif servent de plancher.
  • Un séquencement trimestre par trimestre, dans l'ordre des dépendances : d'abord les actions sans regret, puis le right-sizing et l'arrêt planifié, ensuite les conversions d'engagements à leur échéance.
  • Des engagements quand la couverture est déjà mature : maintenir la couverture, racheter les réservations expirées, améliorer le taux ; engagements longs sur l'empreinte fixe, plus courts et dégressifs sur la part qui peut évoluer, couverture plafonnée et revue chaque trimestre.
  • Un parc dont l'usage va évoluer (croissance, regroupement, fin de vie) : la trajectoire d'usage attendue, validée avec l'IT et le métier, donne à chaque machine une action par période ; chaque décision est justifiée, avec son impact et son risque.
Exécution

Faire porter le FinOps par les équipes

  • Le FinOps porté par la plateforme : des exigences non fonctionnelles publiées par votre équipe plateforme (arrêt planifié, right-sizing des conteneurs et des bases, rétention des sauvegardes et des journaux, tags d'allocation), chacune avec un indicateur d'adoption, un ticket et un responsable.
  • Les coûts d'IA générative : chaque appel passe par un profil applicatif qui porte les tags obligatoires (centre de coût, application, environnement, responsable), complété par des budgets dédiés, le choix du modèle selon la tâche et la mise en cache.
  • L'investigation d'une anomalie : date de rupture, volume et taille moyenne des éléments facturés avant et après, hypothèse principale et message prêt à envoyer à l'équipe responsable. Voir l'article Détecter une anomalie de coût avant l'incident.
  • Le Start & Stop d'environnements SAP hors production : chiffré sur le coût compute amorti d'un mois complet et raisonné par système, pas par machine ; la séquence d'arrêt et de redémarrage est validée et automatisée par votre exploitant, après un pilote sur un système de développement à faible risque.
Pilotage continu

Un reporting que chaque lecteur comprend

  • Des catégories de coûts et des budgets par équipe, produit et centre de coût, avec des alertes à 50, 80 et 100 % ; chaque dérive a un responsable, une cause et une action.
  • Un showback mensuel contrôlé : usage à la demande, sous savings plans et sous réservations avec leur quote-part ; l'écart entre facture et reconstitution doit tendre vers zéro.
  • Un reporting de direction sur le coût amorti, avec une projection annuelle et un atterrissage révisé par les économies réalisées et planifiées.
  • Des rituels à plusieurs niveaux, à des fréquences fixées avec vous : point avec l'équipe plateforme, comité de direction, session d'acculturation, et une feuille de route par incréments trimestriels, chacun avec ses critères de succès.
Transfert

Une passation qui tient sans nous

  • Une procédure par chaîne récurrente, au moins le showback et le reporting de direction, avec un classeur piloté par formules et une liste de contrôles à chaque cycle (période, changement d'année, part sans tag, taux de change).
  • Aux côtés d'un intégrateur ou d'un infogérant : ses données servent d'entrées et ne sont jamais reproduites, ses modèles propriétaires sont exclus de nos livrables, et le partage des rôles est écrit.

Voyons comment cette méthodologie s'applique à votre périmètre

Trente minutes pour choisir le point d'entrée, le format et le calendrier.