FinOps est un de ces termes qui signifient des choses très différentes selon la taille de l'entreprise. Pour une entreprise du Fortune 500, c'est une practice de 30 personnes avec un sponsor CFO, un budget outillage plus gros que votre masse salariale, et des comités de pilotage trimestriels. Pour votre SaaS de 30 personnes, c'est plutôt : « pourquoi la facture AWS est-elle 27 % plus élevée que le trimestre dernier, et à qui revient le job de comprendre pourquoi ? » Cet article s'adresse au second groupe.

D'abord, la bonne nouvelle : le gaspillage cloud est ennuyeux. L'écrasante majorité provient des cinq mêmes schémas, dans toutes les entreprises, à toutes les échelles. Du compute inactif que personne n'a éteint. Des instances surdimensionnées provisionnées pour un pic qui n'est jamais revenu. Des ressources non taguées que personne ne peut attribuer, donc dont personne ne se sent responsable. Des environnements de développement et de staging oubliés qui tournent 24 h/24 pour un logiciel livré deux fois par mois. Et du stockage qui reste sur des tiers premium des années après la dernière lecture. Aucun de ces problèmes ne nécessite une certification FinOps Foundation pour être corrigé. Tous nécessitent juste que quelqu'un regarde vraiment.

Le schéma qu'on observe le plus souvent mérite son propre paragraphe. Un développeur lance une c5.4xlarge pour un test de charge un jeudi. Le test se termine à 16 h le vendredi. L'instance tourne tout le week-end, parce que l'éteindre est une étape manuelle dans une console que personne n'ouvre un samedi. Au standup du lundi, l'équipe a brûlé 180 € sur une machine inactive - pas par incompétence, mais parce que le comportement par défaut du système est « continuer à facturer ». Multipliez ça par chaque équipe, chaque week-end, chaque expérimentation oubliée, et vous obtenez un pourcentage significatif de votre budget infrastructure qui ne fait strictement rien.

Pourquoi les tableaux de bord ne règlent-ils pas ce problème ? Parce que la visibilité n'a jamais été le goulot d'étranglement - votre fournisseur cloud a déjà un cost explorer, et vous ne l'ouvrez déjà pas. Un tableau de bord vous dit ce qui s'est passé après que l'argent a disparu, dans un endroit qu'il faut penser à visiter, dans un format qui demande vingt minutes de filtrage avant de dire quoi que ce soit d'actionnable. Entre « la donnée existe » et « quelqu'un a agi dessus » se trouve toute la discipline réelle du FinOps - et c'est précisément la partie pour laquelle une petite équipe n'a aucune capacité de reste.

Il y a aussi un problème structurel que les tableaux de bord ne peuvent pas résoudre : la fragmentation multi-cloud. Dès l'instant où vous faites tourner AWS pour le produit, Hetzner pour les workloads batch, et un projet DigitalOcean égaré que quelqu'un a lancé en 2024, « combien dépensons-nous » cesse d'avoir une seule réponse. Chaque fournisseur exporte les coûts dans son propre format, selon son propre calendrier, avec sa propre idée de ce qu'est un projet. La plupart des petites équipes réagissent en suivant attentivement la grosse facture et en laissant dériver les petites - c'est ainsi qu'une fuite de 400 €/mois survit deux ans.

Alors, à quoi ressemble réellement le FinOps pour une équipe sans équipe FinOps ? Dans notre expérience, quatre habitudes couvrent l'essentiel de la valeur. Un : une source de vérité unique pour les dépenses chez tous les fournisseurs, ventilée par service, projet et environnement - pas parce que les tableaux de bord règlent les choses, mais parce que les débats d'attribution meurent quand tout le monde voit les mêmes chiffres. Deux : une détection d'anomalies plus intelligente qu'un simple seuil - les factures cloud sont naturellement bruitées, et un « alertez-moi au-dessus de X € » statique se déclenche soit tout le temps, soit jamais ; repérer de véritables écarts par rapport à votre propre référence est un travail pour le ML, pas pour un cron job et un espoir. Trois : des recommandations de right-sizing à cadence régulière - une liste mensuelle « ces douze instances sont surdimensionnées, voici la taille inférieure sûre, voici l'économie » que quelqu'un examine en quinze minutes. Quatre : des alertes budgétaires qui escaladent - un avertissement discret à l'ingénieur à 80 %, un plus fort au team lead à 100 %, parce qu'un budget dont personne n'est responsable n'est qu'un vœu pieux.

Remarquez ce que ces quatre habitudes ont en commun : elles raccourcissent la boucle entre l'observation et l'action. C'est tout le jeu. Pas plus de données - moins de distance entre « le système a remarqué » et « un humain a décidé ». Une petite équipe n'a pas besoin d'une practice FinOps ; elle a besoin des vingt minutes par semaine où les décisions de coût se retrouvent bien préparées, pré-priorisées, et au même endroit.

C'est ce que nous avons intégré à Sencai : dépenses par service, projet et environnement chez tous les fournisseurs connectés ; anomalies de coût détectées par ML ; recommandations de right-sizing programmées ; alertes budgétaires qui escaladent. La boucle entre l'observation et l'action, compressée pour tenir dans un standup. Et la prochaine étape de la feuille de route - Autopilot - consiste à fermer entièrement cette boucle pour les cas ennuyeux : arrêt automatique programmé des ressources de dev taguées, exécution du right-sizing approuvé pendant les fenêtres de maintenance. Le jugement reste entre vos mains ; appuyer sur le bouton ne devrait pas avoir besoin d'y rester.

Si vous voulez savoir où vous en êtes aujourd'hui, voici un exercice de quinze minutes : sortez la facture du mois dernier de chaque fournisseur que vous utilisez - y compris ceux que vous aviez oubliés. Triez par service. Entourez tout ce que vous ne pouvez pas attribuer à une fonctionnalité produit active en dix secondes. Dans la plupart des entreprises, ce qui est entouré représente 25 à 35 % du total. Ce n'est pas un problème de budgétisation. C'est juste de l'entropie - et l'entropie, ça se corrige très, très bien.