Coût total de possession

La facture qui ne raconte que le prix du compteur

En 2022, 37signals, l'entreprise derrière Basecamp et le service de messagerie Hey, a jugé que ses factures AWS et Google Cloud étaient devenues l'un des postes les plus coûteux de son activité, et a commencé à rapatrier cette infrastructure dans ses propres centres de données. En 2024, sa facture cloud annuelle était passée de 3,2 millions de dollars à 1,3 million de dollars, une économie annoncée de 2 millions de dollars par an, après un achat initial de matériel d'environ 700 000 dollars, l'entreprise projetant plus de 10 millions de dollars d'économies sur 5 ans. C'est un cas réel et bien documenté où posséder du matériel coûte moins cher que louer la capacité équivalente, pour la charge de travail spécifique, stable et prévisible de cette entreprise.

C'est aussi, en soi, une comparaison incomplète, et comprendre pourquoi est exactement le rôle du coût total de possession.

Ce que le TCO signifie réellement

Le coût total de possession est le coût complet d'acquisition, d'exploitation et de maintenance d'un système sur une période définie, généralement 3 à 5 ans, pas seulement le prix d'une seule ligne. Une facture cloud montre le compteur : calcul, stockage et transfert de données, facturés pour le mois qui vient de s'écouler. Un devis matériel montre le prix affiché de la machine. Ni l'un ni l'autre n'est le TCO. Le TCO, c'est ce que vous obtenez une fois que vous ajoutez tout ce qui entoure ce montant visible, des 2 côtés de la comparaison.

Coûts directs contre coûts que personne ne met sur la facture

Les coûts directs et mesurés sont ceux qu'une facture cloud montre déjà : calcul, stockage et transfert de données. Le transfert de données mérite une remarque précise, parce qu'il n'est pas symétrique. AWS, comme la plupart des fournisseurs, ne facture pas l'entrée de données dans son cloud, mais facture, par paliers, la sortie de données, appelée egress. Une charge de travail qui lit peu de données mais en exporte régulièrement de grandes quantités peut porter une facture de transfert de données bien plus lourde que ne le suggérerait son seul coût de calcul.

Tout le reste est un coût indirect, et il se trouve des 2 côtés de la comparaison, pas seulement d'un seul. Côté cloud : le travail ponctuel de migration ou de réarchitecture d'une charge de travail pour qu'elle y tourne, le temps du personnel consacré à configurer, superviser et optimiser les ressources cloud, les outils de gestion des coûts et de supervision achetés spécifiquement pour suivre cette dépense, et les outils de sécurité ou de conformité ajoutés par-dessus. Côté sur site : l'électricité et le refroidissement de la salle qui héberge le matériel, l'immobilier lui-même, un renouvellement du matériel tous les quelques années à mesure qu'il vieillit, et le temps du personnel consacré à installer en baie, appliquer les correctifs et finalement mettre au rebut le matériel retiré, la même charge de maintenance que la première leçon de ce domaine décrivait comme l'une des raisons originelles de l'existence du cloud.

Le piège : ne comparer que ce qui est facile à comparer

Il est tentant de faire cette comparaison en regardant 2 chiffres, la facture cloud de ce trimestre et le prix affiché d'un matériel serveur équivalent, puis de déclarer vainqueur celui qui est le plus bas. Aucun des deux chiffres n'est le TCO. La facture cloud omet le personnel et les outils construits autour. Le prix affiché du matériel omet l'électricité, le refroidissement et le cycle de renouvellement qui revient dans 3 à 5 ans.

Le cas de 37signals illustre bien à quel point ce piège est facile, même quand une entreprise cherche sincèrement à être rigoureuse. Les comptes rendus indépendants sur cette migration ont spécifiquement noté que les chiffres d'économies publiés ne tenaient pas encore compte des futurs coûts de renouvellement du matériel, du personnel d'exploitation supplémentaire que la migration a exigé, ni du coût continu de faire tourner l'espace, l'électricité et le refroidissement de son propre centre de données. Ce n'est pas une critique de la décision de 37signals, qui pourrait très bien tenir malgré tout une fois ces catégories comptées. C'est une démonstration que même une entreprise qui défend publiquement le choix de posséder son matériel n'avait pas, au moment où ces chiffres ont été rapportés, fini de compter chaque catégorie qu'exige une comparaison TCO complète.

Exemple chiffré : une comparaison sur 3 ans, faite honnêtement

Prenons une charge de travail au trafic stable et prévisible, et comparons 3 ans de possession sur site à 3 ans dans le cloud, en comptant les coûts indirects des 2 côtés.

Pour cette charge de travail spécifique et stable, la comparaison honnête sur 3 ans favorise le matériel sur site, d'environ 56 000 dollars, et pas simplement parce que la facture cloud mesurée serait plus élevée que le prix affiché du matériel. Ça ne devient clair qu'une fois le personnel et les outils comptés des 2 côtés. C'est le même type de décision que 37signals a prise, à une bien plus grande échelle.

Changez une seule hypothèse et la réponse peut s'inverser. Donnez à cette charge de travail un profil de trafic qui monte à 3 fois sa base pendant 2 semaines par an, et le côté sur site a maintenant besoin d'un matériel dimensionné pour un pic qu'il utilise 2 semaines et laisse inactif le reste de l'année, exactement le problème de surprovisionnement que le cloud a été construit pour supprimer. Le côté cloud, lui, monte simplement en charge pendant ces 2 semaines et redescend ensuite, en ne payant que la capacité supplémentaire réellement utilisée. Ce seul changement dans le profil de la charge de travail suffit souvent à faire basculer la comparaison dans l'autre sens. Ni « le cloud est toujours moins cher » ni « le cloud est toujours une arnaque » n'est une règle à mémoriser ; le TCO est un calcul que vous menez pour une charge de travail précise, pas un verdict qui se transpose d'une entreprise à une autre.

FinOps : la discipline qui empêche le TCO de devenir obsolète

Un calcul de TCO est un instantané, chiffré une fois pour une décision prise à un moment donné. La dépense cloud, elle, ne reste pas figée après cette décision : elle change chaque fois qu'un ingénieur crée une nouvelle ressource, ce qui la distingue justement d'un budget de centre de données fixe, défini une fois par an et laissé tel quel. Le FinOps est la discipline construite pour gérer cette différence. La FinOps Foundation le définit comme un framework opérationnel et une pratique culturelle qui maximise la valeur commerciale de la technologie, permet une prise de décision rapide fondée sur les données, et crée une responsabilité financière grâce à la collaboration entre les équipes d'ingénierie, de finance et métier, plutôt que de traiter le coût comme quelque chose que seul un service financier examine après coup.

C'est la même idée que pointent les principes d'optimisation des coûts du Well-Architected Framework d'AWS : mettre en place une véritable gestion financière du cloud comme une capacité organisationnelle à part entière, et analyser et attribuer en continu la dépense pour que le propriétaire d'une charge de travail puisse voir, et agir sur, ce qu'elle coûte réellement. Le FinOps, c'est ce à quoi ressemble le fait de mener cette analyse en continu plutôt qu'une fois par an.

Ce que vous en retenez

Une facture cloud et un devis matériel sont tous les deux des réponses partielles. Avant de comparer 2 façons de faire tourner une charge de travail, listez chaque coût direct et indirect des 2 côtés, chiffrez-les sur la même fenêtre pluriannuelle, et comparez seulement ensuite les totaux. Prenez cette habitude une bonne fois, dans un tableur, et le FinOps n'est rien d'autre que continuer à le faire en continu plutôt qu'une seule fois.

Cela clôt l'économie du cloud : le problème qu'il résout, comment on le paie, et ce qu'il coûte réellement à exploiter. Le prochain domaine laisse le coût de côté et se tourne vers les services eux-mêmes, en commençant par les 3 façons dont les fournisseurs cloud empaquettent ce qu'ils vendent : IaaS, PaaS et SaaS.