J’étais à la table ronde LeHibou le 16 juin sur les coûts Cloud & Data. Deux intervenants : Axel Douchin, fondateur de Douchin Consulting, et Samuel Quaireau, co-fondateur d’Alvéole IT — animés par Alexandre de Charnacé, Directeur Commercial Paris chez LeHibou. Avec Stéphane Boutterouma et Blanche Metteil à l’organisation.

Ce que j’en retiens surtout : je pensais mal tomber en mission. Non. C’est très courant.

FinOps, c’est le mot tendance, on voit ca sur LinkedIn ou les réseaux sociaux. Mon avis est tranché sur le sujet: ” FinOps” c’est du jargon pour habiller quelque chose qui s’appelle simplement gérer son exploitation. On savait le faire il y a 20 ans, les organisations avançant on s’est perdus, retournons aux basiques.

Le point de départ : le néant

Alexandre de Charnacé insiste sur des essentiels de gouvernance, qui pour moi ont été perdus. Quand on arrive sur un écosysteme sans inventaire, sans vision de ce qui tourne, quels pourcentage de resources utilisées pour quels projets… essayer d’optimiser est compliqué. Souvent il n’y a pas de stratégie d’étude ou d’évaluation, pas de cycle de gouvernance adapté.

Ce n’est pas une critique, c’est un constat. On ne peut pas piloter ce qu’on ne voit pas. Et si on ne voit rien, on ne peut rien décider. C’est le premier chantier, avant tout le reste : savoir ce qu’on a et mapper les resources aux projets.

Personne n’ose éteindre

Alexandre a insisté aussi sur la peur du décommissionnement. Arrêter un projet, c’est perçu comme un échec. Alors on laisse tourner. On paie. On accumule.

C’est une erreur de lecture. Un projet qu’on décommissionne, c’est un projet qui a fait son boulot. C’est une décision adulte, pas une capitulation. Tant qu’on ne retourne pas cette perception, les catalogues vont continuer à grossir et les factures avec.

Je suis complètement d’accord : et c’est l’objet du début des missions de transition, inventorier et trancher. Rien qu’avec cela se dessinent les premiers quick-wins.

FinOps, c’est pas seulement des tags dans AWS

Samuel Quaireau met bien en avant que la gestion du coût du projet, et son optimisation, est d’abord un sujet d’ architecture, de décisions de dev, de design de systèmes.

Les sur-dimensionnements, les sur-architectures, les ressources allumées la nuit et le week-end parce que personne n’a pensé à les éteindre. Tout mettre sur Snowflake parce que c’est pratique — sans regarder ce que ça coûte à l’échelle. Partir sur du multi-cloud sans modéliser les flux inter-cloud et les coûts de connexions dédiées. Ce sont des décisions techniques qui font exploser les factures, pas des oublis comptables.

Et les équipes ne sont pas accompagnées là-dessus. Dans la plupart des missions que j’ai faites, les équipes ne savaient même pas combien coûtait un serveur. On découvrait les montants plus tard, ou jamais (décisions politiques), ou par surprise. C’est de la navigation à l’aveugle.

Le vrai problème : les silos

C’est ma lecture.

Les DSI évoluant, on a structuré les équipes fortement autour de chaque projet et d’équipes “socles communs”. Les coûts se cachent pas que dans la technique — ils se cachent dans les angles morts dessinés par la structure des équipes.

Chaque projet raisonne pour lui-même. Personne n’a de vue transverse. Personne ne sait ce que consomment les autres, ni quelles ressources pourraient être mutualisées. Résultat : chaque équipe surdimensionne pour être tranquille, personne ne partage, et la facture globale n’appartient à personne.

Ce qu’il faut, c’est une conscience des ressources communes. Pas juste remonter des données à la gouvernance — faire redescendre l’information aux projets. Chaque équipe doit savoir ce qu’elle coûte, en temps réel, et comprendre pourquoi ça compte. Elles doivent aussi savoir ce qui est à leur disposition et ce qu’elles peuvent utiliser ou pas. Il faut aussi qu’elles soient en mesure de réclamer ce qui pourrait être bénéficiaire et pas juste se contenter de dire “on se conforme au socle car il nous est imposé”.

Ma séquence quand j’arrive : inventaire, architecture lisible ou DAT, mapping ressources par projet avec coûts associés, puis descente d’information aux équipes. Là on peut parler.

Ce qu’on peut faire, concrètement

Audit. Scan. Attribution des ressources aux projets. Cycles de review. Réajustement. Clôture des projets morts.

Une idée simple que j’ai retenue de la soirée : dans chaque petite équipe, désigner un référent du suivi et de la gestion des coûts — pas un rôle permanent, un rôle tournant qui a sa place dans le comment faire, tantôt métier, tantôt dev, tantôt lead, tantôt PO. Chaque membre de l’équipe passe par là à un moment. C’est comme ça qu’on diffuse une culture, pas en mettant un seul expert en bout de chaîne.

Les décisions sont réversibles. Arrêtez d’attendre.

Un des points qui m’a marqué : en général la plupart des décisions sont 2 way door. On peut y aller, tester, corriger. L’immobilisme n’est pas une protection, c’est un coût. Chaque mois qu’on passe à ne pas décider, c’est de l’argent qui part.

Ce que j’ai retenu de cette soirée, ce n’est pas une révélation technique. C’est une confirmation : le problème est humain, organisationnel, culturel. La technique, on peut l’apprendre. Changer la façon dont une organisation perçoit ses ressources et ses coûts, faire revenir le pragmatisme dans la boucle — c’est le vrai travail.