Broker de cloud plutôt que chaos de cloud : 30 % de réduction des coûts de multi-cloud

Un constructeur mécanique typique des PME répartit ses workloads sur trois hyperscalers, sans jamais connaître le coût total. Un courtier cloud et une pratique FinOps rigoureuse peuvent réduire sensiblement la facture multi-cloud, de l’ordre de 30 % dans les programmes bien pilotés. Ce retour d’expérience anonymisé reconstitue un scénario réaliste et montre quels leviers actionner et où l’économie relève du travail plutôt que de la magie.

Les points clés en bref

• Les courtiers cloud créent de la transparence avant la négociation : Avant de pouvoir discuter des remises, l’entreprise avait besoin d’une vue consolidée sur les trois fournisseurs. Le courtier l’a fournie en tant que couche intermédiaire centrale pour les achats et la facturation.
• Les 30 % proviennent de trois sources : Le rightsizing des instances inutilisées, les remises sur engagement via les Reserved Instances et les Savings Plans auprès de chaque fournisseur, ainsi que le déplacement des workloads portables vers les environnements où ils fonctionnent à moindre coût par unité de performance.
• FinOps est une opération, pas un projet : La plus grande leçon a été organisationnelle. Sans un mandat de coûts clair entre le service financier et l’équipe plateforme, les économies se seraient envolées après deux trimestres.

Articles liés :Modèle Frontier hors ligne sur décision administrative : la leçon d’architecture  /  Inférence désagrégée : pourquoi AWS et Cerebras séparent le GPU

Qu’est-ce qu’un courtier cloud ?

Qu’est-ce qu’un courtier cloud ? Un courtier cloud est un intermédiaire entre une entreprise et plusieurs fournisseurs cloud. Il regroupe les achats, la facturation et parfois la gestion technique sur AWS, Microsoft Azure, Google Cloud et des fournisseurs spécialisés plus petits. Au lieu de négocier individuellement avec chaque hyperscaler, l’approvisionnement passe par une couche centrale qui agrège les consommations, négocie les remises et fournit une vue unifiée des coûts.

Dans la région DACH, ce modèle reste jusqu’ici peu utilisé. Dans de nombreuses PME, des workloads ont été placés chez le fournisseur le plus pratique au fil des années, sans jamais donner lieu à une facture consolidée. C’est précisément là que s’inscrit le cas décrit ici : le constructeur mécanique avait des charges de production chez AWS, un environnement proche de Microsoft 365 sur Azure et quelques workloads d’analyse de données sur Google Cloud. Trois contrats, trois logiques de facturation, aucune vue d’ensemble.

Le courtier n’a d’abord pas fonctionné comme une machine à économies, mais comme un traducteur. Ce n’est qu’une fois toutes les consommations réunies dans une seule vue qu’il est devenu visible où se trouvait l’argent.

Le point de départ : trois fournisseurs, aucun contrôle des coûts

Avant le projet, l’approvisionnement cloud était décentralisé. Chaque équipe réservait des ressources selon ses besoins, et personne ne consolidait les factures. Le service financier ne voyait que trois regroupements de dépenses mensuels, en augmentation constante, sans que quiconque puisse expliquer cette hausse.

Les symptômes typiques d’un paysage multi-cloud sans FinOps se sont rapidement manifestés. Les environnements de développement tournaient 24 heures sur 24, bien qu’ils ne soient utilisés que pendant la journée. Les instances de bases de données étaient dimensionnées pour des pics de charge qui ne se sont jamais produits. Les snapshots et les anciens volumes s’accumulaient, car personne n’était responsable de leur suppression. Et sur les trois fournisseurs, les paiements se faisaient presque exclusivement au prix catalogue, faute d’accords de type Reserved ou Savings.

Le premier inventaire réalisé par le courtier a révélé qu’une part importante des dépenses concernait des ressources soit surdimensionnées, soit purement et simplement oubliées. Ce n’est pas un cas isolé. Les études sectorielles documentent bien ce phénomène : les capacités inutilisées et surdimensionnées sont considérées à l’échelle de l’industrie comme l’un des principaux facteurs de gaspillage cloud.

Les trois leviers qui ont vraiment compté

L’économie de 30 % environ ne s’est pas répartie de manière uniforme. Elle provenait de trois mesures clairement distinctes, appliquées dans cet ordre.

En premier lieu, le rightsizing. L’équipe plateforme a comparé l’utilisation effective aux capacités réservées et a réduit les instances surdimensionnées. Les environnements de développement non utilisés ont reçu des horaires d’arrêt automatiques en dehors des heures de travail. Les volumes et snapshots orphelins ont été supprimés de manière systématique. Ce premier pas a donné les résultats les plus rapides, car il n’exigeait aucune négociation contractuelle.

En deuxième lieu, les réductions basées sur les engagements. Pour les charges de travail stables et en cours permanent, l’entreprise a conclu des Reserved Instances et Savings Plans. Ces engagements sont liés à un fournisseur, ils doivent donc être conclus séparément chez AWS, Azure et Google Cloud. L’avantage de la couche broker réside dans l’achat : elle regroupe le volume global et obtient ainsi de meilleures conditions que l’entreprise ne pourrait négocier individuellement par fournisseur. Par rapport à l’utilisation purement on-demand, les réductions pour des engagements à long terme varient selon les fournisseurs et la durée, mais se situent clairement dans la plage des deux chiffres.

Troisièmement, la localisation des charges de travail. Certaines charges de travail d’analyse n’étaient ni liées à un fournisseur ni critiques en termes de latence. Elles ont migré vers les lieux où elles étaient les plus économiques par unité de calcul. C’est le levier le plus exigeant, car il nécessite du travail architectural et ne fonctionne que là où aucun critère de résidence des données ou de latence ne s’y oppose.

Source : Représentation propre du programme FinOps décrit.

Quels outils et indicateurs ont fait la différence

Techniquement, le programme reposait sur une plateforme de gestion des coûts, déployée via le broker et normalisant les trois fournisseurs. Ce qui a eu une importance cruciale, c’était moins l’outil individuel que l’unification : ce n’est qu’une fois que les consommations AWS, Azure et Google Cloud pouvaient être comparées selon une logique commune que les charges de travail ont pu être évaluées de manière pertinente les unes par rapport aux autres.

L’entreprise a mis en place quelques rares, mais suivies de près, métriques comme indicatrices. Parmi celles-ci figuraient les coûts par unité commerciale plutôt que simplement la somme totale, la part des dépenses couvertes par des engagements, ainsi que le taux de ressources inutilisées. Ces indicateurs FinOps sont courants en pratique car ils associent les coûts à la création de valeur plutôt qu’à la simple taille de l’infrastructure.

Un concept de tagging a permis d’associer chaque ressource à une équipe et à un porteur de coût. Sans cette association, toute analyse des coûts reste fragmentée, car personne n’est alors clairement responsable.

Leçons apprises : Où le projet aurait presque échoué

Les leviers techniques ont été rapidement identifiés. La véritable difficulté résidait dans l’organisation. L’équipe de la plateforme pouvait formuler des recommandations, mais n’avait pas de mandat pour les faire appliquer contre les départements métier. Ainsi, les périodes d’arrêt sont restées théoriques, car chaque équipe défendait ses processus en continu.

Seulement lorsque la direction générale et la comptabilité ont donné à l’équipe de la plateforme un mandat clair en termes de coûts, les mesures ont pris effet durablement. FinOps ne fonctionne que comme mode opératoire permanent avec une responsabilité claire, et non comme une action ponctuelle. Si la discipline n’est pas institutionalisée, le gaspillage revient en quelques trimestres, car les nouvelles charges reprennent les mêmes erreurs.

La deuxième leçon concernait le broker lui-même. Une telle couche intermédiaire réduit le lien direct avec les hyperscalers et crée une dépendance. L’entreprise a donc gardé volontairement le savoir-faire technique en interne et a utilisé le broker pour l’approvisionnement et la transparence, et non comme substitut à sa propre compétence en cloud.

Foire aux questions

Plus d’articles du réseau MBF Media

Source de l’image : générée par IA (Juli 2026)