Gouverner — Documentation — FinOps Move2Cloud

Allocation des coûts

L’allocation des coûts attribue les dépenses cloud de votre organisation à ceux qui les engagent : équipes, applications, produits, projets, environnements, centres de coûts ou responsables. Elle répond à la question « qui dépense quoi ? » sans jamais modifier les dépenses brutes lues chez vos fournisseurs : elle les répartit, une fois, et dit ce qui reste à attribuer.

Formules : l’allocation de base (règles directes, sur la dimension Équipes, sans coût partagé) vient avec Standard ; l’allocation avancée (clés fixes, métriques, coûts partagés, toutes les dimensions) avec Pro et Entreprise. Starter n’a pas d’allocation. L’allocation s’applique dès qu’une version de ses règles est publiée.

Règles d’attribution

Une règle choisit des coûts par des conditions — fournisseur, compte, sous-compte, projet, service, ressource, tag, label, région ou environnement — et les attribue à un ou plusieurs bénéficiaires d’une même dimension (les équipes, les applications, les centres de coûts…). Toutes les conditions doivent correspondre ; une information absente de la source n’est jamais devinée.

Attribution directe : tout le coût va à un bénéficiaire. C’est la règle de l’allocation de base.
Pourcentages fixes : une clé de répartition, par exemple 40 %, 25 %, 15 % et 20 %, qui totalise toujours 100 % (Pro et Entreprise).
Répartition selon une métrique : au prorata d’une mesure de la période, comme les heures CPU d’un cluster, avec sa source (Pro et Entreprise).
Allocation manuelle, toujours accompagnée d’une justification (Pro et Entreprise).

Chaque règle a une priorité : la plus petite l’emporte. Si deux règles de même priorité visent le même coût, il reste non alloué, avec cette cause. Chaque ligne de coût n’est attribuée qu’une fois, éventuellement répartie entre plusieurs bénéficiaires de la même dimension. Les responsables financier et technique d’une équipe ou d’une application se choisissent parmi les membres de l’organisation.

Onglet Règles : règles directes, au prorata d'une métrique et à clé fixe, avec leur priorité, leurs bénéficiaires et une proposition en brouillon.

Coûts partagés et coûts non alloués

Un coût partagé — services communs, sauvegardes, cluster Kubernetes — se répartit par une clé fixe ou au prorata d’une métrique. Pour un service commun de 3 000 € réparti à 50 %, 30 % et 20 %, chaque bénéficiaire reçoit 1 500 €, 900 € et 600 € ; les arrondis conservent toujours le montant source.

Onglet Coûts partagés : services partagés à clé fixe 40/25/15/20 et Kubernetes au prorata des heures CPU.

Ce qu’aucune règle n’attribue reste non alloué, et visible : son montant et sa part, sa cause (aucune règle, conflit de priorité, métrique sans mesure, devise non établie), le fournisseur, le compte, l’évolution et la ressource quand elle est connue. Pour chaque devise, alloués + non alloués = coûts éligibles : le total ne change jamais.

Onglet Non alloués : bacs à sable et application sans responsable, avec la cause et le montant.

Simuler, puis publier

Une version des règles se simule d’abord pour un mois : vous voyez les montants attribués, les non alloués, les conflits et l’écart avec la publication précédente, sans rien changer. La publication, confirmée explicitement, vaut pour toute l’organisation et pour ce mois ; l’historique garde chaque version, simulation, publication et correction avec son auteur et sa date. Si un fournisseur corrige ses coûts après coup, la console signale qu’un recalcul est nécessaire et garde les résultats publiés jusqu’à la nouvelle publication. Les analyses, budgets, recommandations et le Savings Tracker montrent l’attribution publiée.

Exemple

Dans l’organisation fictive NovaRetail Cloud, octobre 2026 compte 42 000 € de coûts éligibles sur six fournisseurs. Trois règles directes attribuent les projets de chaque équipe ; les services partagés sont répartis à clé fixe 40/25/15/20 entre E-commerce, Data & IA, Back-office et Plateforme, et le cluster Kubernetes de la vitrine au prorata des heures CPU (70 % E-commerce, 30 % Data & IA). Résultat publié : 14 662,74 € pour E-commerce, 12 502,43 € pour Data & IA, 10 775,02 € pour le Back-office et 700,01 € pour Plateforme, soit 38 640,20 €. Restent 3 359,80 € non alloués — des bacs à sable et une application de promotion sans responsable : la couverture est de 92 %.

Limites

Les devises restent séparées et ne sont jamais converties implicitement ; des coûts en devise non établie restent non alloués.
Une métrique sans mesure exploitable pour le mois laisse ses coûts non alloués plutôt que de les répartir au hasard.
L’allocation travaille sur les coûts mensuels lus chez les fournisseurs : elle ne crée ni facture ni écriture comptable.
Un mois qui compte beaucoup de lignes de coûts est calculé en arrière-plan ; la simulation s’ouvre dès qu’elle est prête.

Questions fréquentes

Qui configure l’allocation ? Le propriétaire et les administrateurs créent les règles, simulent et publient. Tous les membres qui lisent les coûts consultent et exportent les allocations, en CSV avec leur référence de publication.
Une règle peut-elle partager un coût entre plusieurs équipes ? Oui, avec Pro et Entreprise : clé fixe, métrique ou répartition manuelle justifiée. Avec Standard, une règle attribue directement un coût à une équipe.
Désactiver une règle change-t-il le passé ? Non : les résultats déjà publiés restent tels quels, et chaque version reste dans l’historique.
Que se passe-t-il si un fournisseur corrige sa facture ? La console demande un recalcul ; les résultats publiés restent en place jusqu’à la publication suivante.

Dans la console : Allocation des coûts, connexion requise. Le guide de la console détaille la création des dimensions, des entités et des règles, puis la publication.

Coûts unitaires

Les coûts unitaires rapportent la dépense cloud à l’activité qu’elle sert : un coût par client actif, par transaction, par commande, par utilisateur ou par millier d’appels API. Ils disent si le cloud coûte plus parce que l’activité grandit, ou parce que chaque unité coûte plus cher à servir.

Formules : avec Pro, deux indicateurs dont les volumes se saisissent à la main, sans objectif ; avec Entreprise, autant d’indicateurs que nécessaire, l’import CSV des volumes, les objectifs et leurs alertes. Le module est désactivé par défaut : le propriétaire ou un administrateur l’active pour son organisation.

Le calcul

Coût unitaire = dépense attribuée ÷ volume de la même période, un mois civil. La dépense vient d’une allocation publiée, pour les bénéficiaires choisis (une équipe, une application, un produit) ; le volume est une métrique métier que vous fournissez, avec sa provenance. Chaque indicateur garde son unité, sa devise, son périmètre et ses versions.

Sans allocation publiée, le coût est indisponible, jamais nul.
Un volume absent reste absent ; un volume de zéro est une activité mesurée nulle, pour laquelle le ratio n’est pas défini.
Les coûts non alloués ne sont pas ajoutés, les devises ne s’additionnent pas et aucun taux de change n’est appliqué implicitement.

Métriques métier et volumes

Un indicateur se définit par son nom, son unité, sa devise, sa base économique, son responsable et la source de ses volumes : saisie manuelle, ou import CSV avec Entreprise. Toutes les lignes d’un import sont vérifiées avant d’être enregistrées, et une collecte incomplète reste signalée. Corriger un volume crée une nouvelle observation sans effacer l’ancienne ; changer la définition crée une nouvelle version.

Onglet Indicateurs : coût par client actif, par commande et par 1 000 appels API, qualifiés.

Objectifs et évolution

Avec Entreprise, un indicateur reçoit un objectif, un seuil de coût unitaire ou un pourcentage de dégradation, mois par mois ; franchi, il prévient par le centre de notifications. L’évolution se lit d’un mois civil au suivant, à version, unité, devise, base et périmètre identiques : deux séries incompatibles ne se comparent pas.

Onglet Objectifs : objectifs et seuils d'alerte par indicateur et par mois.

Un résultat reste provisoire tant qu’une revue financière ne l’a pas rapproché d’une facture ou d’un export de référence ; les résultats provisoires ou incomplets ne déclenchent pas d’alerte. Cette revue vaut pour une publication d’allocation et n’est pas une certification du fournisseur.