La démarche FinOps se repositionne comme une priorité, car la DSI doit piloter des trajectoires de coûts qui se jouent désormais sur plusieurs terrains : cloud public, hybridation, data centers, SaaS, licences, et de plus en plus IA. Gartner projette 723,4 Md$ de dépenses mondiales en public cloud en 2025 et précise que 90% des organisations adopteront une approche hybride jusqu’en 2027. Au niveau de la réalité terrain, Flexera indique que 84% des organisations ont du mal à gérer leurs dépenses liées au cloud.
Thomas Galipot, Domain Leader Lean Architecture & expert FinOps chez Inside, pose sur le FinOps un cadre plus large que la simple chasse aux ressources. Pour lui, il recouvre une discipline de pilotage, une maîtrise de l’environnement de l’ensemble de son Système d’Information et donc une exigence de méthode. L’audit FinOps, ou l’évaluation de maturité FinOps, sert précisément à ça : (re)mettre de la précision sur l’intégralité du périmètre (CAPEX, OPEX).
Quand et pourquoi est-il important d’évaluer sa pratique FinOps ? Qu’est-ce qui justifie pour toi le lancement d’un audit ?
Il n’existe pas de “bon moment” pour lancer un audit FinOps. Même quand vous avez des certitudes, il reste des angles morts : des usages qui dérivent, des allocations discutables, un tagging incomplet, ou une trajectoire de coûts qui semble logique sur le papier mais ne résiste pas au réel. Le regard extérieur compte, parce que FinOps est un sujet stratégique : il touche directement votre capacité à décider vite, avec des données partagées, plutôt qu’avec des intuitions.
Dans la pratique, certains déclencheurs reviennent souvent :
- une dérive de coûts inexpliquée après une migration on-prem vers le cloud (LIEN https://insidegroup.fr/expertises/ops-infrastructure/architecture-cloud/) parce que les usages n’ont pas été cadrés
- une perte de maîtrise budgétaire : prévision vs réel qui se décale fortement sans explication claire
- une montée en charge ou un passage à l’échelle : vous devez piloter une trajectoire de coûts entre une situation actuelle et une cible SI
- un changement organisationnel (fusion de SI, industrialisation) qui impose de rationaliser
Enfin, je ne réserve pas cet exercice aux grands comptes ! Pour une PME/ETI, démarrer tôt, même sur un périmètre réduit ou une brique précise du SI, évite d’empiler de la dette de pilotage et sécurise la croissance.
Un audit FinOps s’applique dès que vous dépensez sans savoir précisément combien, pour qui et comment anticiper. Chez les PME/ETI, plus vous installez cette maîtrise tôt, plus vous sécurisez la prévision. Notre démarche d’audit a aussi été conçue pour être adaptée à ces structures.
Quels axes évalues-tu dans ce type de missions d’évaluation FinOps ?
Le FinOps est un sujet multi-domaines. Dans mes missions, je regarde ainsi tout ce qui touche à la vie du système d’information et à son écosystème, pas uniquement les ressources cloud. Le cadre que j’utilise est structuré en 9 piliers, que je module ensuite selon votre contexte et vos priorités :
- Visibilité des coûts : ce que vous consommez, où, et à quel niveau de détail vous pouvez l’expliquer.
- Optimisation : réduire le gaspillage sans dégrader le service.
- Responsabilisation : qui porte la dépense, qui arbitre, et avec quels rituels.
- Prévision & budget : trajectoire de coûts, forecast vs actual, capacité à anticiper.
- Automatisation : éviter de “payer le week-end” quand ce n’est pas nécessaire, industrialiser les garde-fous.
- Maturité & connaissances : est-ce que les équipes intègrent ces réflexes dès qu’un produit évolue ou qu’un usage démarre.
- Collaboration : engineering, finance, métiers, procurement… avec des dashboards et des décisions partagées. Le framework FinOps insiste d’ailleurs sur la collaboration et la responsabilité de chacun.
- Sécurité & conformité : optimiser sans créer de nouveaux risques quand vous déplacez des pans d’infra.
- GreenOps / durabilité : optimiser aussi l’efficience des workloads et l’empreinte, parce que les deux sujets se renforcent
Dans ce type d’évaluation, je mets vite en lumière un point qui parle à tout le monde : en moyenne 30% d’un budget “alloué” à un environnement est perdu chaque mois entre dette, manque d’optimisation et absence d’automatisation. Ce diagnostic doit aussi impliquer toutes les parties prenantes : chacun est concerné par au moins un pilier, du DSI à la finance, jusqu’aux utilisateurs selon les usages.
La finance est souvent perçue comme l’ennemi de l’IT. Dans une démarche FinOps, je cherche l’inverse : recréer du lien et fluidifier la collaboration, parce que la décision a besoin d’une lecture partagée du coût et de la valeur.
Quels KPI suivez-vous en priorité dès le démarrage de l’audit pour objectiver la situation et déclencher des actions ?
Les KPI et indicateurs possibles sont nombreux. Je vous propose de nous concentrer sur ceux que je mets en place initialement car ils permettent de prendre conscience et d’agir.
Je commence souvent par la sous-utilisation et la non-utilisation des ressources, parce que c’est là que le gaspillage est le plus visible et le plus actionnable (dimensionnement, arrêt, plages de fonctionnement, etc.). Cette logique correspond très directement aux pratiques de workload optimization du FinOps Framework : sélectionner, dimensionner, exécuter “uniquement quand nécessaire” et viser une utilisation élevée.
Ensuite, je mets en visibilité le coût de la dette technique et de l’obsolescence. Vous pouvez avoir des systèmes anciens indispensables. L’intérêt du KPI est de distinguer ce qui est structurel de ce qui est simple à corriger sans attendre une refonte.
Troisième indicateur, je mesure la qualité d’allocation via le tagging et les métadonnées : quelle part des ressources et des coûts remonte avec des informations exploitables (à quoi ça sert, pour qui, combien).
Enfin, je pose deux KPI de pilotage : l’écart prévision vs réel et la répartition des coûts par produit / projet / client, pour détecter les zones où la dépense se décorrèle de la logique attendue et comprendre pourquoi. La FinOps Foundation formalise d’ailleurs le suivi du forecast vs actual via un seuil de variance, et donne des repères de tolérance (par exemple 20% au niveau Crawl, 15% en Walk, 12% en Run dans une version antérieure du Framework)
Ces KPI servent à décider, mais aussi à se situer : la FinOps Foundation publie des abaques et des repères (par exemple des prix moyens par service) qui permettent de comparer vos métriques et prendre du recul.
Comment cartographier rapidement les dépenses ? Quels rôles impliquer côté client pour un audit efficace ?
En première étape, je démarre systématiquement par un questionnaire cadré et consolidé qui couvre l’intégralité du périmètre.
Ensuite, en deuxième étape, je travaille avec deux familles d’interlocuteurs, parce que la cartographie “qui dépense quoi” se construit dans le croisement des vues. Côté fonctionnel, j’interpelle le responsable financier et, dans une PME/ETI, souvent directement le DSI pour récupérer les éléments chiffrés disponibles (exports de coûts, tableaux de bord, méthodes de suivi). Côté technique, je rapproche ces chiffres de la réalité de consommation, avec une lecture très pragmatique du tagging existant : parfois il existe sans permettre d’expliquer “à quoi ça sert, pour qui, combien”, donc il faut mesurer l’écart entre ce qui est attendu et ce qui remonte réellement. Je travaille ici avec des interlocuteurs plus techniques.
Une fois cette base posée, j’analyse les regroupements intelligents : si plusieurs périmètres consomment la même technologie, sous quels contrats, avec quel niveau de mutualisation, et quelles opportunités de rationalisation ou de négociation. Enfin, je vais sur le terrain avec des utilisateurs pour confronter la projection à la réalité, parce qu’il existe souvent un décalage entre l’usage imaginé et l’usage réel.
En combinant ces étapes, vous obtenez en quelques semaines une cartographie exploitable : qui consomme quoi, pour quels usages, et avec des ordres de grandeur chiffrés.
Une cartographie efficace se joue dans une triangulation entre la vision finance, la réalité technique, et la validation terrain.
Dans l’évaluation FinOps, comment distinguer quick wins vs chantiers structurants et formaliser les gains attendus ?
Notre approche est pragmatique. Je pars d’un rapport structuré par pilier : observations, axes d’amélioration, premiers leviers. Ensuite, je complète avec ce qui fait vraiment la différence : le delta entre la théorie et le terrain (ce qui est déclaré vs ce qui est réellement consommé, taggé, piloté, arbitré). C’est ce décalage qui permet de qualifier rapidement. Il est associé à une proposition de démarche avec les axes d’améliorations priorisés sur chacun des piliers.
Les quick wins (30–90 jours) sont les actions que vous pouvez lancer sans changer vos règles de gouvernance : optimisation immédiate, mise sous contrôle de certains usages, premiers automatismes. Les chantiers structurants demandent d’installer ou de faire évoluer la mécanique : rituels, responsabilisation, allocation, culture de décision partagée.
Enfin, la trajectoire dépend de votre cible et de la stratégie de la DSI. Si vous voulez réduire les coûts via l’automatisation, nous pouvons descendre à une granularité très fine (ressources, infra, usages). Si l’enjeu est macro, nous travaillons davantage sur l’organisation et la gouvernance. Dans tous les cas, la priorisation des chantiers selon leur Time-to-Value et les ressources nécessaires se fait en atelier avec le client.
Quels sont les cas d’usages et les contextes où il apporte en particulier de la valeur ?
Il apporte le plus de valeur dans les contextes où la DSI doit prendre des décisions structurantes avec une visibilité incomplète, typiquement dans une transformation cloud ou hybride. Les grandes orientations sont souvent claires (“migrer”, “moderniser l’infrastructure”, “externaliser”), mais l’opérationnalisation est plus complexe : sans allocation et sans pilotage, vous découvrez les écarts trop tard, quand le budget a déjà dérivé.
Un cas très parlant que j’ai rencontré dans le retail : un enjeu d’archivage légal. Il n’existait pas de solution outillée, et surtout aucun tagging : impossible d’identifier les flux, leur origine, leur fréquence, ni de relier les coûts à l’archivage légal. Nous avons alors lancé le projet avec un budget annuel défini dès le départ et un cadre de sizing. Mon approche a été progressive : d’abord provisionner ce qu’il fallait pour cadrer, puis dérouler une roadmap (flux, automatisation, tagging…), avant d’aboutir à une architecture cible.
La valeur, c’est justement là : poser un cadre de consommation, instrumenter l’usage, puis piloter la dérive. Dans ce cas, la solution a été utilisée hors cadre, mais la démarche FinOps a permis d’identifier rapidement pourquoi (quelle entité, pour quel usage, à quelle fréquence), d’anticiper le dépassement et de décider : ajuster les ressources, ou recadrer l’usage.
La valeur de la démarche est maximale quand les décisions sont stratégiques mais que l’opérationnel est flou : le pilotage FinOps sert à détecter tôt les usages hors cadre, expliquer le pourquoi, et arbitrer avant la dérive budgétaire.
Comment Inside accompagne les grandes organisations et les PME/ETI dans leur démarche FinOps ?
Notre force chez Inside, c’est de pouvoir mobiliser plusieurs pôles d’expertises et de nous adapter à la complexité réelle de votre environnement. Que vous cherchiez à piloter un SI global ou à sécuriser un projet spécifique, nous gardons le même cap. Pour moi, FinOps et Lean Architecture visent le même objectif : aligner durablement la dépense technique avec la valeur métier.
Concrètement, pour l’audit, nous nous appuyons sur un outil d’assessment que j’ai construit, mais qui n’a pas vocation à être rempli “en autonomie”. Vous pouvez trouver des checklists en ligne ; la différence, c’est l’accompagnement et la co-construction. L’outil sert à assister la démarche, à comparer et à structurer l’échange, mais la vraie valeur est dans l’analyse, au regard de votre contexte humain et métier.
Et surtout, l’audit n’est pas une fin en soi : c’est le point de départ pour décider mieux, plus vite, avec des données partagées. La bonne question à se poser est simple : êtes-vous certain de maîtriser vos coûts ?
Si vous voulez objectiver votre niveau de maîtrise et identifier vos leviers, contactez-nous pour mener une évaluation FinOps adaptée à votre contexte !