FinOps, architecture des coûts et dépendance au fournisseur

Le coût est une qualité architecturale

La section 2.7 (sécurité, utilisabilité et autres qualités) a rangé le coût parmi les attributs de qualité et recommandé de l’exprimer par unité de travail. Dans un centre de données, le coût était surtout fixe : le matériel était acheté à quelques années d’intervalle et les choix d’un architecte faisaient à peine bouger la facture mensuelle. Dans le cloud, chaque décision d’architecture est aussi une décision d’achat, prise en continu par les ingénieurs plutôt qu’une fois par an par le service des achats. Une frontière de service bavarde, un niveau de journalisation debug, un environnement de test oublié ou un appel synchrone entre régions apparaissent chacun sur la facture du mois suivant. Le coût est devenu un attribut de qualité qui change à chaque déploiement.

Deux disciplines aident. Le FinOps est la pratique opérationnelle qui rend les dépenses cloud visibles, attribuées à des responsables et pilotées. L’architecture attentive aux coûts est la pratique de conception qui rend les systèmes peu coûteux à exploiter par unité de valeur dès le départ. Cette section traite des deux, puis se tourne vers leur voisin encombrant : la dépendance au fournisseur, c’est-à-dire le coût du départ.

FinOps : phases, principes et qui fait quoi

Le FinOps est défini par la FinOps Foundation, un projet de la Linux Foundation, comme un cadre opérationnel et une pratique culturelle qui maximise la valeur métier de la technologie grâce à des décisions prises en temps utile et fondées sur les données, et à une responsabilité financière partagée entre l’ingénierie, la finance et le métier. Le nom fait délibérément écho au DevOps : de même que le DevOps a abattu le mur entre la construction et l’exploitation des logiciels, le FinOps abat le mur entre la dépense d’argent et la décision sur la façon de construire les logiciels.

Le FinOps Framework organise le travail en trois phases itératives. Informer : rendre les coûts visibles, les répartir entre les équipes et les produits qui les génèrent, établir des prévisions et des comparaisons. Optimiser : réduire le gaspillage et améliorer les tarifs, par le redimensionnement, la planification, les engagements et les changements de conception. Opérer : instaurer les habitudes qui maintiennent les coûts sous contrôle, comme les budgets, les politiques, la responsabilité et la prise en compte du coût dans chaque décision de conception. Les organisations parcourent le cycle à plusieurs reprises, en progressant, pour chaque capacité, de « ramper » à « marcher » puis à « courir ». Parmi les principes du cadre : les équipes collaborent ; la valeur métier guide les décisions technologiques ; chacun assume la responsabilité de son usage de la technologie ; les données de coût sont accessibles, disponibles en temps utile et exactes ; le FinOps est soutenu de manière centralisée ; et le modèle de coût variable du cloud doit être mis à profit. Les versions récentes étendent le cadre au-delà du cloud public à d’autres dépenses technologiques, comme les licences SaaS, les centres de données et les services d’IA.

Économie unitaire : le coût par commande

Une facture cloud qui passe de 80 000 à 100 000 par mois peut être un désastre ou un triomphe, selon que l’activité a progressé de 5 % ou de 50 %. L’économie unitaire (unit economics) exprime le coût par unité de valeur métier : le coût par commande pour la plateforme de livraison de repas, par client actif pour un service de streaming, par millier d’appels d’API pour une plateforme destinée aux développeurs. Elle distingue l’efficacité de la croissance, relie les décisions d’ingénierie aux résultats métier et donne aux équipes un objectif sur lequel elles peuvent agir.

La calculer correctement exige trois choses. D’abord, une unité qui compte pour le métier, choisie avec la finance et le produit, et non inventée par les ingénieurs. Ensuite, la répartition des coûts : les coûts directs (le calcul et la base de données du service des commandes) attribués au moyen d’étiquettes ou de namespaces, et les coûts partagés (le plan de contrôle Kubernetes, la pile d’observabilité, les outils de l’équipe plateforme) répartis selon une règle convenue, comme l’usage proportionnel. Enfin, une distinction entre coût moyen et coût marginal : le coût moyen par commande inclut des coûts fixes qui n’augmentent pas avec les commandes, si bien que le coût des mille commandes suivantes est généralement inférieur à ce que suggère la moyenne, ce qui compte pour fixer le prix d’une promotion ou prévoir la croissance.

Où va l’argent : les facteurs de coût courants

La plupart des factures cloud surprenantes proviennent d’une poignée de facteurs, et presque tous sont déterminés par l’architecture plutôt que par la négociation de meilleurs prix.

Payer moins pour la même capacité

Une fois le gaspillage éliminé, le tarif payé pour la capacité restante peut être abaissé. La capacité à la demande est la plus souple et la plus chère. Une remise pour engagement d’utilisation échange de la souplesse contre un prix : les Reserved Instances et Savings Plans d’AWS, les réservations et plans d’économies d’Azure et les committed use discounts de Google Cloud offrent des réductions substantielles (AWS annonce jusqu’à 72 % pour certains engagements) en échange d’un engagement sur un niveau d’utilisation ou de dépense pendant un ou trois ans. Les engagements ne doivent couvrir que le socle dont on aura certainement besoin pendant toute la durée ; s’engager sur la capacité de pointe transforme une remise en gaspillage.

La capacité spot (AWS Spot Instances, Azure Spot Virtual Machines, Google Cloud Spot VMs) vend de la capacité excédentaire avec de fortes remises, souvent de 60 % à 90 %, mais le fournisseur peut la récupérer avec un court préavis : deux minutes sur AWS, environ 30 secondes sur Azure et Google Cloud. Elle convient au travail sans état, interruptible et pouvant être relancé, comme le traitement par lots, les runners de CI, le rendu et certaines couches web sans état réparties sur de nombreux types d’instances. Elle ne convient pas aux bases de données ni à tout ce qui ne peut pas être arrêté en cours de tâche. L’architecture décide de la part d’une charge de travail qui peut utiliser le spot : les tâches idempotentes et dotées de points de reprise le peuvent ; les tâches longues et avec état ne le peuvent pas.

Étiquetage, showback et chargeback

Personne n’optimise un coût qu’il ne voit pas. La répartition commence par une politique d’étiquetage (tags ou labels) : chaque ressource porte un petit ensemble d’étiquettes obligatoires, comme l’équipe propriétaire, le service, l’environnement et le centre de coûts, imposées par des garde-fous dans le code d’infrastructure et les politiques d’organisation du cloud, car les étiquettes ajoutées à la main finissent vite par manquer. Pour Kubernetes, les coûts sont répartis par namespace et par label avec des outils comme le projet open source OpenCost ou les fonctions de répartition des coûts des fournisseurs eux-mêmes. La spécification FOCUS de la FinOps Foundation définit un format commun pour les données de facturation, afin que les coûts de plusieurs fournisseurs puissent être combinés.

Une fois les coûts répartis, une organisation choisit comment les utiliser. Le showback présente à chaque équipe ses coûts sans toucher à son budget ; il développe la prise de conscience et constitue le point de départ habituel. Le chargeback (refacturation interne) impute les coûts au budget de chaque équipe, ce qui crée des incitations plus fortes mais exige une répartition exacte, des règles convenues pour les coûts partagés et un moyen de traiter les litiges. Dans les deux cas, publiez la part des dépenses qui ne peut pas être répartie : une part non étiquetée supérieure à quelques pour cent signifie que les chiffres ne sont pas encore assez fiables pour fonder des décisions.

Les décisions architecturales qui déterminent les coûts

Les économies les plus importantes viennent de la conception, pas des remises, et elles sont les moins chères à obtenir avant que le système soit construit. Chacune des décisions suivantes a un profil de coût prévisible. La granularité des services : chaque saut réseau coûte du calcul, de la sérialisation et éventuellement du transfert de données, si bien que des services à grain fin répartis dans de nombreuses zones coûtent plus cher par requête qu’un monolithe modulaire. La diffusion synchrone en éventail (fan-out) : une requête qui appelle dix services maintient onze ensembles de ressources occupés pendant toute sa durée. Le nombre d’environnements : des copies complètes de la production pour chaque équipe et chaque branche multiplient la facture ; des environnements partagés avec isolation ou des prévisualisations éphémères coûtent bien moins cher. La conservation et la réplication des données : chaque copie et chaque région supplémentaires multiplient le stockage et les transferts. Le cache et les CDN : une réponse servie par le cache coûte généralement bien moins cher qu’un nouveau calcul, et une réponse servie par le CDN évite la sortie de données depuis l’origine. Le modèle de calcul : la tarification serverless à la requête est moins chère que la capacité permanente en dessous d’un volume de bascule, et plus chère au-dessus.

Consignez les conséquences importantes sur les coûts dans les enregistrements de décision, aux côtés des autres compromis de qualité, et envisagez d’ajouter le coût aux fonctions d’aptitude qui protègent l’architecture : par exemple, une vérification mensuelle que le coût par commande n’a pas augmenté de plus de 10 % sans explication.

La dépendance au fournisseur est un compromis, pas un péché

La dépendance au fournisseur (lock-in) est le coût et la difficulté de quitter quelque chose une fois que vous en dépendez. On en parle généralement comme d’une chose à éviter à tout prix ; l’article de Gregor Hohpe publié en 2019 sur martinfowler.com, Don't get locked up into avoiding lock-in, soutient que c’est en soi un piège. Il distingue plusieurs formes de dépendance : envers le fournisseur (contrats et conditions commerciales), le produit (les API et fonctionnalités d’un produit particulier, même open source), la version, l’architecture (un style comme le serverless), la plateforme (comptes, identité et modèles de sécurité), les compétences (ce que savent vos collaborateurs), le juridique (conformité et licences) et le mental (les présupposés qui vous empêchent d’envisager d’autres options). Utiliser des logiciels open source réduit la dépendance envers le fournisseur mais laisse subsister la plupart des autres.

L’essentiel est de traiter la dépendance comme un problème d’évaluation d’option. Le coût de migration (switching cost) est ce que coûterait un changement ; multiplié par la probabilité de changer un jour, il donne le coût attendu de la dépendance. Réduire le coût de migration a lui-même un prix : abstraction supplémentaire, conceptions au plus petit dénominateur commun et fonctionnalités auxquelles on renonce. Un changement qui coûterait 50 000 et a 5 % de chances de se produire représente un coût attendu de 2500 : dépenser bien plus que cela pour l’éviter est une mauvaise affaire. La matrice de Hohpe, qui croise l’utilité unique et le coût de migration, en fait une classification rapide.

Le coût de la portabilité et la stratégie de sortie

La portabilité n’est pas gratuite. Concevoir chaque composant pour qu’il tourne sur plusieurs clouds signifie n’utiliser que les fonctionnalités qu’ils ont tous en commun, construire et tester des couches d’abstraction qui fuient (voir masquage de l’information et abstractions qui fuient), entretenir des compétences sur plusieurs plateformes et renoncer à des services managés qui auraient économisé des efforts. Beaucoup de stratégies multicloud finissent avec les coûts de tous leurs fournisseurs et les avantages d’aucun. La portabilité est la moins chère là où des standards ouverts existent déjà : images de conteneurs OCI, manifestes Kubernetes, bases de données compatibles PostgreSQL, API de stockage objet compatibles S3, protocoles standard comme HTTP, AMQP et le protocole Kafka, et OpenTelemetry pour l’observabilité. Même les outils utilisés pour rester portable, comme Terraform ou OpenTofu, sont des dépendances à part entière.

Les praticiens ne s’accordent pas sur jusqu’où aller. Les partisans de la portabilité invoquent les hausses de prix, les pannes, les sanctions, la réglementation et les cas où quitter le cloud a été payant (voir le rapatriement depuis le cloud à la section 10.1). Les partisans de l’engagement envers un seul fournisseur invoquent la rapidité et la fiabilité obtenues en utilisant pleinement les services managés. Une position intermédiaire solide consiste à accepter délibérément la dépendance là où elle apporte une valeur claire, à garder la logique métier indépendante des API du fournisseur derrière des ports et adaptateurs aux quelques points de jonction les plus susceptibles de changer, à conserver les données dans des formats exportables, et à mettre par écrit une stratégie de sortie.

La réglementation exige de plus en plus cette dernière étape. Le règlement européen sur la résilience opérationnelle numérique (Digital Operational Resilience Act, règlement (UE) 2022/2554, applicable depuis le 17 janvier 2025 ; à ne pas confondre avec les métriques de livraison DORA) impose aux entités financières de disposer de stratégies de sortie pour les services TIC qui soutiennent des fonctions critiques ou importantes. Les règles du règlement européen sur les données (Data Act) relatives au changement de fournisseur cloud s’appliquent depuis le 12 septembre 2025 : les clients peuvent changer de fournisseur avec un préavis de deux mois au maximum, et les fournisseurs ne peuvent facturer que leurs coûts directs de changement, sortie de données comprise, jusqu’au 12 janvier 2027, et plus rien ensuite. En 2024, les plus grands fournisseurs ont aussi annoncé la gratuité du transfert de données pour les clients qui les quittent, sous conditions. Une stratégie de sortie doit désigner le remplaçant de chaque service critique, estimer le temps et le coût de la migration, montrer que les données peuvent être exportées dans un format utilisable, et être répétée au moins en partie, par exemple en restaurant une sauvegarde dans un autre environnement.