Cloud : sortir du mythe “ça coûte moins cher” et reprendre le pilotage

Pendant des années, le cloud a été vendu comme une évidence économique : “vous payez à l’usage”, “vous évitez les investissements”, “vous scalez quand vous voulez”. La promesse était simple, presque mécanique : en quittant le datacenter, la facture baisserait. Dans la réalité, beaucoup d’entreprises vivent l’inverse : coûts en hausse, prévisibilité en baisse, arbitrages flous, tensions entre IT, finance et métiers. Le cloud n’est pas naturellement moins cher. Il est plus pilotable, à condition de le traiter comme un produit vivant — avec des métriques, des règles, et une culture de responsabilité.

Le problème n’est pas le cloud. Le problème, c’est l’idée qu’il se gère tout seul.

Le malentendu d’origine : “payer à l’usage” ne veut pas dire “payer moins”

“Pay-as-you-go” signifie “payer exactement ce que l’on consomme”. Et c’est précisément là que le piège se referme : dans une entreprise moderne, la consommation n’a rien de stable. Les environnements se multiplient (dev, test, préprod, prod), les données gonflent, les architectures se complexifient, l’observabilité s’améliore (donc coûte), et les usages explosent dès qu’une équipe trouve un levier de productivité. Le cloud rend l’expansion facile… donc fréquente.

Autre confusion : on compare souvent le cloud au datacenter comme si l’on comparait deux factures. Or on compare souvent un CAPEX amorti (serveurs déjà payés, coûts “lissés”) à un OPEX détaillé (chaque service facturé, chaque gigaoctet, chaque sortie réseau). Psychologiquement, le cloud “fait plus cher” parce qu’il est plus transparent. Comptablement, il peut l’être réellement si l’entreprise n’a pas défini ses garde-fous.

Les trois moteurs cachés de la dérive

La prolifération : des ressources créées puis oubliées. Des environnements de test qui tournent la nuit, des snapshots jamais supprimés, des disques détachés, des bases “temporaires” devenues permanentes.

L’asymétrie d’incitation : les équipes techniques sont récompensées sur la livraison, rarement sur l’efficience coût. Les métiers veulent de la vitesse et de la disponibilité. Sans mécanisme de responsabilité (showback/chargeback), la facture est “celle de l’IT”, donc “celle de personne”.

La facture illisible : sans tagging, sans modèle de coût et sans métriques, le cloud devient un ticket de caisse de supermarché : long, incompréhensible, impossible à relier à de la valeur métier. Quand on ne sait pas ce qui coûte, on ne sait pas quoi optimiser.

Les métriques qui changent la conversation

Le pilotage commence par des indicateurs simples, répétés, partagés. Pas une forêt de KPI, mais quelques repères qui relient coût, usage et valeur.

Coût unitaire (unit cost)

Le plus puissant : coût par transaction, coût par commande, coût par dossier, coût par utilisateur actif, coût par API call. Peu importe l’unité, tant qu’elle est stable et comprise. L’objectif n’est pas d’avoir “un cloud moins cher”, mais un cloud efficient par unité de valeur.

Taux d’utilisation et gaspillage

CPU moyen, mémoire, IOPS, stockage “froid” vs “chaud”, ressources sous-utilisées. Si une VM tourne à 5% de CPU moyen, ce n’est pas une architecture : c’est une habitude.

Couverture de tagging et ownership

Pourcentage de ressources correctement taggées (application, environnement, owner, centre de coût). Sans owner, il n’y a pas de décision possible.

Coût des données

Stockage + sauvegardes + réplications + logs + requêtes + egress (sortie réseau). Dans beaucoup d’organisations, “la donnée” devient la première ligne de coût, et personne ne la pilote comme un actif.

Prévisibilité

Écart entre prévision et réalisé. Un bon pilotage FinOps ne rend pas seulement la facture plus basse : il la rend moins surprenante.

FinOps : pas une équipe, une discipline

FinOps n’est pas “un contrôleur des coûts cloud”. C’est une façon de travailler à trois : IT, Finance, Métiers. L’idée est simple : rapprocher ceux qui consomment, ceux qui paient, et ceux qui arbitrent.

Trois pratiques font l’essentiel du travail.

Rendre visible : showback d’abord, chargeback ensuite

On commence par montrer : “voici ce que coûte telle application”, “voici ce que coûte tel produit”, “voici ce que coûte la data”. Sans refacturation au début, pour éviter la guerre. Le showback crée la prise de conscience. Ensuite seulement, si l’organisation le permet, on bascule vers du chargeback (refacturation interne), qui force l’arbitrage.

Créer des garde-fous : budgets, alertes, et règles d’hygiène

Le cloud doit avoir des “limites de vitesse” :

• budgets par produit ou par domaine,
• alertes sur dérive hebdo (pas uniquement mensuelle),
• politiques d’arrêt automatique des environnements non-prod la nuit,
• expiration par défaut des ressources temporaires,
• interdiction de certains patterns coûteux (par exemple bases surdimensionnées sans justification).

Ce n’est pas de la bureaucratie : c’est de l’urbanisme.

Optimiser en continu : un cycle, pas un projet

On ne “fait pas FinOps” une fois. On installe un rythme : revue hebdo des anomalies, revue mensuelle des gros postes, revue trimestrielle des engagements (reserved instances/savings plans), et surtout une boucle de feedback : ce qui a été optimisé, ce qui a été dégradé, et pourquoi.

Les bonnes pratiques qui paient vraiment

Rightsizing et autoscaling

La première optimisation est rarement exotique : dimensionner correctement. Le second levier est l’élasticité réelle : scaler sur des signaux fiables, pas sur des “au cas où”.

Réserver intelligemment

Les engagements (réservations, savings plans) sont efficaces quand on a une base stable. Sinon, on transforme une facture variable en mauvaise dette. Le bon réflexe : réserver le socle stable, laisser le burst en à-la-demande.

Finir avec le “tout-VM”

Les services managés simplifient, mais ils peuvent aussi coûter plus cher. L’arbitrage est stratégique : payer plus pour réduire l’effort opérationnel est souvent une bonne décision… si on sait qu’on le fait. L’erreur, c’est d’empiler le managé partout sans mesurer le coût de confort.

Maîtriser l’observabilité

Logs, métriques, traces : indispensables. Mais la collecte sans stratégie peut exploser. La règle : définir ce qui est critique, ce qui est utile, ce qui est “nice to have”, et mettre des durées de rétention cohérentes. L’observabilité doit éclairer le système, pas l’engloutir.

Traiter la donnée comme un produit

Qui possède les datasets ? Qui décide de la rétention ? Qui valide les duplications ? Sans gouvernance data minimale, le stockage et les traitements deviennent un tonneau sans fond.

Les arbitrages : le vrai sujet, rarement assumé

Le cloud oblige à clarifier une question que beaucoup d’entreprises évitent : qu’est-ce qu’on optimise ?

• Optimiser le coût peut dégrader la résilience.
• Optimiser la vitesse peut augmenter la facture.
• Optimiser la sécurité peut ajouter des couches (donc du coût) mais réduire un risque existentiel.
• Optimiser l’autonomie des équipes peut multiplier les outils et les environnements.

Le pilotage ne consiste pas à “faire baisser la facture” par principe. Il consiste à choisir : où l’on met de la performance, où l’on accepte de la frugalité, et pourquoi. C’est un dialogue de gouvernance, pas une chasse au gaspillage.

Reprendre le contrôle : une méthode simple en 6 semaines

Semaine 1-2 : cartographier (top 20 lignes de coûts, tagging, owners, environnements).

Semaine 2-3 : fixer les règles d’hygiène (non-prod off, expiration, tagging obligatoire, budgets/alertes).

Semaine 3-4 : mettre en place le showback par produit/domaine.

Semaine 4-5 : optimiser les quick wins (droitsizing, stockage, snapshots, logs, egress).

Semaine 5-6 : décider les engagements (réservations) et installer la gouvernance (rituels, rôles, arbitrages).

Puis : tenir le rythme.

C’est souvent là que le cloud devient enfin ce qu’il promettait : non pas un eldorado “moins cher”, mais un système plus lisible, plus maîtrisé, plus aligné sur la valeur.

La conclusion qui dérange (et libère)

Le cloud est un amplificateur. Il amplifie les bonnes pratiques — et les mauvaises. Sans discipline, il transforme l’IT en flux continu de dépenses. Avec FinOps, des métriques utiles et des arbitrages assumés, il devient un levier de performance : on sait ce que l’on consomme, pourquoi on le consomme, et ce que cela apporte.

Sortir du mythe “ça coûte moins cher”, c’est entrer dans une réalité plus intéressante : ça coûte ce que vous décidez d’en faire. Et ça, pour une DSI qui veut reprendre le pilotage, c’est une excellente nouvelle.