7 Min. Temps de lecture

Un logisticien nord-rhénan-Westphalien a réduit sa facture multi-cloud de 31 %. Pas grâce à un nouveau fournisseur, pas grâce à une migration, mais grâce à trois trimestres de discipline FinOps, une équipe avec une véritable responsabilité budgétaire et une constitution de tag qui ne récolterait pas d’applaudissements lors d’une conférence.

Les points clés en bref

• Le multi-cloud ne paie pas de lui-même : Qui opère trois hyperscalers en parallèle sans allocation de coûts au niveau de la charge de travail finance principalement l’opacité. Les contrats, les instances réservées et les niveaux de stockage s’exécutent alors les uns contre les autres au lieu de travailler ensemble.
• L’intelligence des coûts est une équipe, pas un outil : Les stratégies de tag échouent rarement à cause du logiciel. Elles échouent parce que personne ne décide de manière contraignante quelle dimension reçoit de l’argent et quelle ne reçoit pas.
• La logistique rend la pression visible plus tôt : Les pics de charge saisonniers et les faibles marges ne permettent pas de moyen terme FinOps. Ce que les expéditeurs doivent apprendre en quelques semaines, d’autres secteurs le repoussent pendant des années.

Related :38 % de coûts cloud en moins dans la construction mécanique  /  Étude FinOps 2026 : le courtage comme chemin par défaut

Où la facture multi-cloud explose silencieusement

Le logisticien dont je parle ici utilise des charges de travail sur AWS, Azure et une plus petite plate-forme européenne pour les données de fournisseurs réglementées. Trois contrats, trois périodes de facturation, trois sémantiques de tag différentes. La facture s’établissait fin 2024 à environ 4,2 millions d’euros par an, tendance à la hausse, car plus d’envois produisent plus de télémétrie.

Le problème ne venait pas du prix des instances individuelles. Le problème était que personne ne pouvait dire avec certitude quelle division causait quelle part. Les instances réservées expiraient sans que personne ne réagisse. Le stockage dans une région augmentait chaque mois de 6 %, sans que personne ne se demande si la classe de données était encore correcte. Une équipe a commandé pendant six semaines une capacité de calcul doublée pour un projet de migration, parce que la responsabilité de l’arrêt n’était pas claire.

C’est ainsi que la réalité multi-cloud se présente dans une entreprise de taille moyenne. Pas une seule mauvaise décision, mais une douzaine de petites lacunes qui s’ajoutent chaque mois.

Comment l’équipe a construit Cost-Intelligence sans nouvel outil

La première idée qui a émergé était d’acheter un outil supplémentaire. Il existe des fournisseurs dont les arguments dans ce segment sont très solides. L’équipe en a évalué deux et a finalement décidé de ne pas les utiliser. Pas parce que les outils étaient mauvais, mais parce qu’ils ne résolvaient pas le problème fondamental : Qui décide au sein de l’entreprise quelle dimension doit être taguée ?

À la place, ils ont procédé en trois étapes.

1. Configuration de taggage sur une seule page. Quatre tags obligatoires : kostenstelle, produkt, umgebung, owner. Plus trois tags optionnels pour les charges de travail de conformité. Tout le reste a été supprimé. Quiconque voulait créer un nouveau tag devait obtenir l’approbation du responsable financier. Le document faisait deux pages, approuvé par le directeur informatique, accepté par le conseil d’administration.
2. Les ressources non taguées deviennent plus chères. Un travail cron marque toutes les ressources sans tags obligatoires depuis le deuxième trimestre. Après sept jours, les coûts de ces ressources sont débités sur un compte de collecte interne géré par l’équipe de plateforme. Soudain, l’équipe de plateforme avait une incitation à téléphoner aux divisions pour obtenir les informations, au lieu de les demander poliment.
3. Examen mensuel des coûts avec les propriétaires, et non avec les outils. Chaque division voit dans un PDF d’une page ses coûts des 60 derniers jours, segmentés par produit et région. Pas de tableau de bord. Pas de drill-down. Volontairement réduit, car la conversation est plus importante que la visualisation.

Cela semble peu spectaculaire. Et c’est le cas. L’effet n’était pas dans la méthode, mais dans le fait que la méthode existait encore après cinq mois.

Ce que le taggage seul ne résout pas

Le taggage est le sésame. Il apporte de la transparence dans l’inventaire, mais il apporte peu si les décisions sur les engagements et les réservations restent dans le service des achats, qui ne connaît pas la charge de travail. Dans notre exemple, c’était la deuxième vague de réforme : les instances réservées et les plans d’économies ont été transférés aux propriétaires de la plateforme, et non plus au service des achats informatiques centralisé. Justification : Qui supporte le risque technique doit également évaluer le risque commercial.

Cela a deux effets. Premièrement, pour la première fois, une discussion honnête a eu lieu sur les charges de travail réellement planifiables et celles qui ne le sont pas. Deuxièmement, les instances réservées qui avaient été prolongées par un ancien acheteur pour des raisons de conformité, alors que la division avait déjà arrêté le produit, ont été supprimées.

C’était l’un de ces gains silencieux qui n’apparaissent dans aucune annonce. Montant économisé : environ 380 000 euros par an. Pas de nouvelle technologie, pas de changement d’architecture. Juste quelqu’un qui a finalement pris la responsabilité.

Les trois compromis que personne n’aborde ouvertement

La FinOps multi-cloud est souvent présentée dans de nombreux discours comme un programme d’efficacité. En vérité, c’est la conséquence de compromis que l’entreprise accepte consciemment.

• Standardisation contre vitesse : Qui met en place une configuration de taggage et un contrôle des engagements de manière centralisée ralentit certaines équipes. Qui veut de la vitesse accepte des pertes de dispersion. Il n’y a pas de moyen terme qui offre les deux. Qui promet cela ne l’a jamais géré.
• Couverture des outils contre responsabilité : Les outils FinOps spécialisés soulagent l’équipe, mais ils déplacent les connaissances vers l’outil au lieu de les mettre dans les têtes. Lorsque le contrat avec le fournisseur d’outils se termine, la Cost-Intelligence disparaît très rapidement.
• Engagement réservé contre flexibilité : Un plan d’économies de trois ans permet d’économiser de l’argent, mais il lie l’entreprise à une hypothèse d’architecture qui peut être fausse dans trois ans. Qui conduit des réservations de manière agressive devrait calculer honnêtement ce que coûte une résiliation anticipée.

Ces compromis ne peuvent pas être automatisés. Une pratique FinOps qui les nomme honnêtement est nettement plus robuste qu’une pratique qui veut promettre les trois à la fois.

Que reste-t-il lorsque l’engouement est passé

FinOps est depuis deux ans le sujet à la mode dans chaque conférence sur le cloud. Une grande partie est justifiée, certaines sont excessives. Ce qui reste après l’exemple du logisticien est étonnamment peu méthodique et étonnamment beaucoup organisationnel. Une constitution de tagging qui n’a pas été creusée. Une équipe de plateforme qui est devenue propriétaire de ressources non taguées. Responsabilité des propriétaires pour les engagements. Des examens mensuels avec des personnes, pas avec des tableaux de bord.

Le résultat après trois trimestres : 31 pour cent de coûts multi-cloud inférieurs, une meilleure précision de prévision dans les prévisions et une discussion nettement plus sobre sur les nouvelles initiatives cloud. Si quelqu’un propose maintenant un projet, il doit répondre à la question de savoir qui supportera l’engagement réservé si l’hypothèse ne se concrétise pas. Cette question n’existait pas auparavant.

Qui espère une solution miracle ne la trouvera pas ici. Qui accepte que l’intelligence des coûts soit avant tout une question de responsabilité a un chemin réaliste.

Foire aux questions

Quand un outil FinOps dédié est-il plus avantageux que les outils intégrés ?

Dès que trois conditions sont réunies : plus de deux hyperscalers, plus de 50 propriétaires responsables et un budget cloud dépassant les cinq millions d’Euro par an. En dessous, la solution interne avec les explorateurs de coûts natifs et une constitution de tags disciplinée est généralement moins chère et plus durable.

Combien de temps faut-il pour que la constitution de tags ait un effet ?

Les premières économies mesurables sont visibles après huit à douze semaines, car le modèle de compte collectif oblige les propriétaires de plateforme à attribuer rapidement les ressources non taguées. Les effets structurels sur les instances réservées et les classes de stockage ne se produisent qu’après deux à trois trimestres.

Qui devrait assumer la responsabilité de propriétaire pour les instances réservées ?

Les responsables de plateforme ou de produit qui connaissent techniquement la charge de travail. Un achat informatique centralisé sans contexte de charge de travail prend souvent des engagements de manière défensive et prolonge les contrats avec des secteurs qui ne sont plus exploités. C’est l’erreur la plus coûteuse en pratique.

Combien de tags obligatoires sont judicieux ?

Quatre à cinq tags obligatoires suffisent pour la plupart des entreprises. Un nombre plus élevé entraîne des lacunes, car personne ne peut maintenir tous les champs de manière cohérente. En général, les tags judicieux sont le lieu de coût, le produit, l’environnement et le propriétaire, plus un pour la classe de conformité, si des charges de travail réglementées sont présentes.

Que se passe-t-il avec les coûts d’egress et de région croisée ?

L’egress est la position la plus gênante, car elle a souvent deux propriétaires : le système émetteur et le système récepteur. La solution pratique consiste à attribuer l’egress à la charge de travail émettrice et à la mentionner explicitement comme une ligne distincte dans les révisions mensuelles. Sinon, il disparaît comme un poste invisible dans le budget global.

Plus de contenu du réseau MBF Media

Source de l’image : générée par IA (mai 2026), certificat C2PA intégré dans l’image