Les droits de quai

Un port ne vend pas de la surface, il vend du mouvement.

L'exploitant facture le conteneur manutentionné, la journée d'immobilisation sur le parc, le mètre de quai occupé pendant l'escale, le branchement électrique du frigorifique, et le passage de la barrière à la sortie. L'armateur qui compare deux ports sur le seul prix du mètre linéaire se trompe de facture.

À côté de ce tarif au mouvement, il existe l'autre modèle : la concession annuelle. On paie le quai qu'on l'utilise ou non, et la tonne traitée revient beaucoup moins cher dès qu'on le remplit.

Azure fonctionne exactement comme ça, et la confusion y produit les mêmes malentendus. Une machine virtuelle se facture à l'heure allumée, plus le disque, plus le trafic sortant, plus la sauvegarde, plus l'adresse publique qu'on avait réservée pour un test en mars.

Le cloud n'est pas cher. Il est variable, et la variable est activée par défaut au maximum.

La première économie n'est pas une remise négociée. C'est une ressource qu'on éteint parce que personne ne s'en sert.

Trois questions avant tout tableau de bord

La capitainerie sait répondre à trois choses sur n'importe quelle escale : quel client, pour quelle marchandise, et si le navire est venu à moitié vide.

Une facture cloud se pilote avec les mêmes trois questions.

Qui consomme. Sans réponse, la dépense n'a pas de propriétaire, et une dépense sans propriétaire ne baisse jamais.

Pour quoi. Une même somme peut financer la production d'un produit qui rapporte ou trois environnements de recette oubliés.

Est-ce dimensionné. C'est la seule question qui compare le payé au servi.

Ces trois questions se traitent dans un cycle, pas dans un projet à date de fin. On estime avant, on mesure pendant, on optimise, on recommence.

flowchart LR E["Estimer
prix unitaires
et coût total"] --> D["Déployer
avec balises
et budgets"] D --> M["Mesurer
analyse des coûts
par balise et par portée"] M --> O["Optimiser
les cinq leviers"] O --> R["Revoir
tous les mois"] R --> E M -.-> A["Alerte de budget
seuil franchi"] A -.-> O classDef etape fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef alerte fill:#a0413e,stroke:#8a4d16,color:#f5f2ec; class E,D,M,O,R etape; class A alerte;

L'ordre compte. Optimiser avant de mesurer produit des économies invérifiables et des arbitrages pris au feeling.

La maîtrise des coûts n'est pas un chantier ponctuel de réduction. C'est une boucle mensuelle, avec un propriétaire nommé et une donnée exploitable.

Estimer avant de déployer

Avant de signer une concession, un opérateur demande un devis à l'autorité portuaire. Ce devis chiffre le quai, la grue et la manutention. Il ne chiffre jamais le carburant des camions qui viendront chercher les conteneurs.

La calculatrice de prix Azure rend le même service, avec la même limite. Elle chiffre très bien ce qu'on lui déclare, et pas du tout ce qu'on a oublié de déclarer. Microsoft propose aussi un outillage d'estimation du coût total de possession, qui compare une infrastructure existante à son équivalent hébergé et intègre les postes indirects comme l'électricité, l'espace et le renouvellement du matériel.

Les postes manquants sont toujours les mêmes, quel que soit le projet.

Poste oublié Pourquoi il échappe à l'estimation Où il finit par apparaître
Sortie de données facturée à l'usage, invisible sur un schéma d'architecture ligne réseau, en croissance continue
Sauvegardes et instantanés dimensionnées après coup, rétention rarement bornée stockage, poste qui ne redescend jamais
Environnements hors production estimés sur la production, puis multipliés par le nombre d'équipes calcul, sur des ressources allumées la nuit
Journaux et supervision facturés à l'ingestion et à la conservation espace de travail d'analyse de journaux
Adresses IP publiques et disques orphelins rattachés à rien, donc absents de tout inventaire réseau et stockage, en dépense pure
Support et licences hors du prix unitaire des ressources lignes distinctes sur la facture

Deux réflexes suffisent à corriger l'essentiel. Estimer la production, puis appliquer un facteur explicite pour les environnements amont plutôt que de les oublier. Et poser une hypothèse de trafic sortant, même grossière, plutôt que zéro.

Une estimation ne se juge pas à sa précision, mais à l'exhaustivité de sa liste de postes. Un poste absent vaut toujours plus cher qu'un poste mal chiffré.

Rendre la facture lisible

Sur un terminal, chaque conteneur porte un marquage qui dit à qui il appartient, ce qu'il transporte et sous quel régime douanier il est entré. Sans ce marquage, le bordereau de fin de mois est un total unique que personne ne sait contester.

Les balises jouent ce rôle sur Azure, et elles ont une propriété désagréable : elles ne rattrapent pas le passé. Les données de consommation sont horodatées avec les balises présentes au moment de l'usage. Baliser une ressource aujourd'hui n'attribue pas rétroactivement les six mois écoulés.

Trois balises suffisent pour commencer, à condition qu'elles soient imposées et non suggérées : le propriétaire, l'environnement, le centre de coût. Comme les balises ne s'héritent pas automatiquement du groupe de ressources vers la ressource, on les fait appliquer par une stratégie à effet Modify, sujet traité dans le billet sur la gouvernance et l'étiquetage.

Côté lecture, Microsoft Cost Management s'ouvre sur plusieurs portées : le compte de facturation, un groupe d'administration, un abonnement, un groupe de ressources. La portée décide de ce qu'on voit et de qui peut le voir. Une équipe produit qui n'a accès qu'à son abonnement ne verra jamais la réservation achetée au niveau facturation.

Un détail change beaucoup de conversations : le coût réel montre l'achat au moment où il est facturé, le coût amorti étale un engagement sur sa durée. Comparer deux mois en coût réel après l'achat d'une réservation de trois ans donne un graphique illisible.

Les budgets viennent ensuite, et il faut être net sur ce qu'ils font.

resource budgetHorsProd 'Microsoft.Consumption/budgets@2021-10-01' = {
  name: 'budget-horsprod-mensuel'
  properties: {
    category: 'Cost'
    amount: 2000
    timeGrain: 'Monthly'
    timePeriod: {
      startDate: '2026-09-01T00:00:00Z'
    }
    filter: {
      tags: {
        name: 'environnement'
        operator: 'In'
        values: [ 'horsprod' ]
      }
    }
    notifications: {
      reel80: {
        enabled: true
        operator: 'GreaterThan'
        threshold: 80
        thresholdType: 'Actual'
        contactGroups: [ actionGroupId ]
      }
      previsionnel100: {
        enabled: true
        operator: 'GreaterThan'
        threshold: 100
        thresholdType: 'Forecasted'
        contactGroups: [ actionGroupId ]
      }
    }
  }
}

Un budget notifie, il ne plafonne pas. Rien ne s'arrête au franchissement du seuil. Pour obtenir un effet, on branche la notification sur un groupe d'action qui déclenche une automatisation, par exemple l'extinction des machines d'un environnement hors production.

Le second seuil, celui qui porte sur la prévision plutôt que sur le réel, est celui qui sert vraiment : il alerte quand il reste encore du temps pour réagir.

Pour l'analyse historique et le recoupement avec la comptabilité, on programme une exportation régulière des données de coût vers un compte de stockage. C'est la seule façon de garder une profondeur d'historique indépendante de l'interface du portail.

Une balise absente le jour du déploiement est une dépense définitivement non attribuable. La refacturation ne se rattrape pas, elle se prépare.

Les cinq leviers

Un opérateur portuaire dispose de cinq façons de baisser sa facture, et elles ne se valent pas. Rendre le quai qu'il n'utilise pas. Louer une grue à sa charge réelle plutôt que la plus grosse. Signer une concession pluriannuelle. Prendre une place au tarif de dernière minute, révocable. Ou renoncer à des services qu'il paie sans les consommer.

L'ordre n'est pas décoratif : chacun de ces leviers s'applique à ce qui reste après le précédent. Négocier une remise de trois ans sur des machines qu'on aurait dû éteindre revient à s'engager sur du gaspillage.

flowchart TD S["La charge tourne-t-elle en continu ?"] -->|Non| A1["Éteindre hors plage
et rester au tarif à la demande"] S -->|Oui| T["La charge est-elle interruptible ?"] T -->|Oui| SP["Instances spot"] T -->|Non| C["La taille est-elle figée
sur un à trois ans ?"] C -->|Oui| RE["Réservation"] C -->|Non| PL["Plan d'économies
engagement en dépense horaire"] A1 --> DIM["Dimensionner au bon calibre
dans tous les cas"] SP --> DIM RE --> DIM PL --> DIM classDef q fill:#2c3338,stroke:#8a4d16,color:#f5f2ec; classDef r fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef d fill:#d89253,stroke:#8a4d16,color:#1a1a1a; class S,T,C q; class A1,SP,RE,PL r; class DIM d;

Éteindre ce qui ne sert pas

C'est le levier le plus rentable et le plus négligé, parce qu'il ne ressemble pas à de l'optimisation.

Environnement hors production : 12 machines virtuelles
Prix unitaire supposé : 0,20 USD/heure (à remplacer par le prix réel de ta taille et de ta région)

Allumées en permanence :
12 x 0,20 x 24 x 30 = 1 728 USD par mois

Allumées 12 h par jour, 5 jours sur 7 :
heures par mois = 12 x 5 / 7 x 30 = 257 h
12 x 0,20 x 257 = 617 USD par mois

Écart = 1 111 USD par mois, soit environ 64 %

Deux précisions techniques décident du résultat. Une machine arrêtée depuis son système d'exploitation reste allouée et reste facturée : seule la désallocation libère la ressource de calcul. Et même désallouée, elle continue de payer ses disques managés et son adresse IP publique réservée.

# Machines arrêtées mais toujours allouées : le calcul est encore facturé
az vm list -d --query "[?powerState=='VM stopped'].{nom:name, groupe:resourceGroup, taille:hardwareProfile.vmSize}" -o table

# Désallouer réellement
az vm deallocate --resource-group rg-horsprod --name vm-recette-01

# Adresses IP publiques réservées et attachées à rien
az network public-ip list --query "[?ipConfiguration==null].{nom:name, groupe:resourceGroup, sku:sku.name}" -o table

Dimensionner au bon calibre

Les tailles de machines virtuelles Azure progressent par doublement du nombre de cœurs et de la mémoire. Descendre d'un cran divise donc à peu près par deux le prix du calcul.

Trouver les candidates est la partie facile. Le point délicat est la fenêtre d'observation sur laquelle on juge. Une moyenne processeur basse sur sept jours peut masquer une clôture comptable mensuelle qui sature la machine pendant six heures. On observe sur une fenêtre qui couvre au moins un cycle métier complet, et on regarde les percentiles hauts, pas la moyenne.

Le processeur n'est jamais le seul critère. Une base de données peut afficher 10 % de charge processeur et saturer ses entrées et sorties disque. Réduire la taille supprime alors du débit disque avant de supprimer du coût.

S'engager : réservations et plans d'économies

Une réservation Azure est un engagement de un ou trois ans sur une capacité de calcul donnée, en échange d'un tarif fortement réduit par rapport au paiement à l'usage. Le plan d'économies est un engagement sur une dépense horaire, plus souple, et donc un peu moins remisé.

La question de rentabilité se pose en une ligne.

Machine à 100 USD/mois au tarif à la demande
Réservation à 40 % de ce tarif (hypothèse) -> 40 USD/mois

Seuil d'équilibre = 40 / 100 = 40 % du temps

En dessous de 40 % d'utilisation sur la durée d'engagement,
l'engagement coûte plus cher que le tarif à la demande.

Le seuil d'équilibre est toujours égal au prix remisé, exprimé en part du tarif à la demande. Une remise très forte pardonne beaucoup de sous-utilisation, une remise modeste n'en pardonne aucune.

Quatre paramètres décident du reste. La durée, un an ou trois ans. La portée, qui va d'une ressource unique à un partage sur tout un périmètre de facturation, et qui détermine si la réservation trouvera toujours à s'appliquer. La flexibilité de taille, qui permet à une réservation de couvrir plusieurs tailles d'une même série. Et le degré d'irréversibilité : l'échange et le remboursement anticipé existent, mais ils sont encadrés et les règles ont changé plusieurs fois. Vérifie leur état courant avant de bâtir un plan dessus.

Une réservation de calcul ne couvre pas la licence du système d'exploitation. Sur du Windows Server ou du SQL Server, la remise sur le matériel se cumule avec l'avantage hybride Azure, qui permet de réutiliser des licences déjà détenues. Ce cumul est régulièrement oublié, et il représente une part importante du prix affiché.

Accepter d'être interrompu

Les machines virtuelles spot achètent de la capacité inutilisée à prix cassé, avec une contrepartie nette : Azure peut les reprendre à tout moment, avec un préavis de l'ordre de la demi-minute, et sans engagement de disponibilité.

Ce levier ne se discute pas en pourcentage de remise, il se discute en tolérance à l'éviction. Un traitement par lot qui reprend là où il s'est arrêté, un rendu, une compilation, une campagne de tests : oui. Une passerelle d'API en production : non.

Deux réglages structurent l'usage. Le prix maximum accepté, au-delà duquel l'instance est reprise. Et la politique d'éviction, désallocation ou suppression, qui décide si on retrouve son disque au retour.

Payer le bon niveau de service

Le dernier levier ne touche pas au calcul, il touche aux choix par défaut. Un niveau haut de gamme retenu « au cas où » sur un service managé, une redondance géographique activée sur des données reconstructibles, une rétention de journaux fixée à deux ans parce que personne n'a posé la question.

Microsoft propose par ailleurs des tarifs réduits pour les environnements de développement et de test, sur des abonnements dédiés à cet usage. La contrainte est contractuelle : ces environnements ne doivent pas servir à de la production.

Levier Économie typique Effort Risque Le signe qu'il s'impose
Éteindre jusqu'aux deux tiers sur le périmètre concerné faible faible, sauf charge mal identifiée des machines hors production allumées la nuit et le week-end
Dimensionner un cran de taille en moins divise le calcul par deux environ moyen réel, une pointe non vue devient une dégradation utilisation durablement basse sur un cycle métier complet
Réserver forte, croissante avec la durée faible techniquement, lourd en décision engagement ferme, sortie encadrée socle de calcul stable depuis plusieurs mois
Plan d'économies un peu moindre qu'une réservation faible même engagement, sur une dépense horaire parc mouvant en tailles et en régions
Spot très forte, sans aucune garantie moyen à fort, le code doit encaisser l'éviction éviction à tout moment traitement par lot, calcul rejouable, recette
Niveau de service et licences variable, parfois considérable faible fonctions perdues si on descend trop bas option haut de gamme retenue par défaut, licences détenues non déclarées
Les leviers ne se cumulent pas dans n'importe quel ordre. On éteint, on dimensionne, et seulement ensuite on s'engage sur ce qui reste.

L'entrepôt et le péage de sortie

Sur un terminal, l'entrepôt facture la journée de séjour, et le régime de stockage change tout : le hangar ordinaire, le frigorifique, l'entrepôt sous douane où la marchandise dort des mois. Sortir un conteneur des archives coûte une manutention et prend du temps.

Le stockage objet suit exactement ce modèle, avec des niveaux d'accès qui échangent du coût de conservation contre du coût de lecture.

Niveau d'accès Conservation Lecture Durée minimale facturée Bon usage
Chaud la plus chère la moins chère aucune données lues régulièrement
Froid réduite facturée à l'opération 30 jours données lues quelques fois par mois
Froid étendu encore réduite plus chère que le froid 90 jours données rarement lues mais à garder disponibles
Archive la moins chère réhydratation à demander, en heures 180 jours conservation légale, sauvegardes anciennes

Le piège tient dans la colonne des durées minimales. Descendre un objet en archive puis le supprimer au bout d'un mois déclenche une pénalité de suppression anticipée qui annule le gain. Une stratégie de cycle de vie qui déplace la donnée automatiquement selon son âge se conçoit en même temps que le compte, pas deux ans plus tard.

Reste le péage de sortie. L'entrée de données dans Azure ne se facture pas, la sortie oui, et une part de la circulation interne aussi : entre régions, et selon les cas entre zones ou entre réseaux virtuels appairés. Les grilles figurent dans la tarification de la bande passante.

Ce poste est celui qui pénalise le plus une architecture mal placée. Un traitement qui lit un jeu de données dans une région et écrit dans une autre paie le transfert à chaque exécution, sans que rien dans le schéma d'architecture ne le signale.

Le stockage se conçoit sur deux axes, pas un : combien coûte la garde, et combien coûte le fait d'y toucher. Les architectures les plus chères sont celles qui archivent de la donnée qu'elles relisent tous les jours.

La revue mensuelle

Une capitainerie ne découvre pas ses recettes en fin d'exercice. Elle relit ses mouvements tous les mois, avec les mêmes rubriques, et pose les écarts sur la table.

Azure Advisor fournit la matière première du côté coût : machines sous-utilisées à redimensionner ou à arrêter, ressources réseau inutilisées, opportunités de réservation ou de plan d'économies calculées sur la consommation observée.

Ses recommandations ne se suivent pas les yeux fermés. Elles raisonnent sur des métriques, pas sur ton calendrier métier. La recommandation d'arrêter une machine qui ne sert que lors des clôtures trimestrielles est techniquement juste et fonctionnellement absurde.

Une revue mensuelle utile tient en cinq points, dans cet ordre : l'écart au budget par balise, les trois plus fortes hausses du mois avec leur explication, la couverture d'engagement (quelle part de la consommation stable est effectivement remisée), les recommandations d'Advisor triées par gain, et la liste des ressources sans propriétaire.

Ce dernier point est le plus rentable à long terme. Une ressource sans balise de propriétaire n'est jamais éteinte, parce que personne ne veut être celui qui a coupé quelque chose d'important.

Une revue mensuelle sans décision écrite est une réunion. Chaque ligne examinée sort avec une action, un responsable et une date, ou elle sort avec un « on assume », ce qui est aussi une décision.

Scénario B : 37signals reprend ses serveurs

Le 19 octobre 2022, David Heinemeier Hansson publie sur son blog personnel le billet « Why we're leaving the cloud ». L'éditeur de Basecamp et de HEY y annonce qu'il quitte le cloud public pour revenir à du matériel qu'il possède, hébergé en colocation.

L'argument n'est pas idéologique. Il tient en deux constats. D'une part, une entreprise de taille moyenne avec une charge stable et prévisible paie très cher la location de machines dont elle connaît exactement le besoin. D'autre part, la simplicité opérationnelle promise ne s'est pas matérialisée : à leur échelle, l'équipe d'exploitation n'a pas rétréci pour autant.

Quelques mois plus tard, l'entreprise publie sur son blog technique sa dépense cloud de l'année 2022, un peu plus de 3,2 millions de dollars. Le chiffre est rendu public volontairement, ce qui est rare, et il rend le raisonnement vérifiable au lieu de le laisser à l'état d'opinion. L'entreprise annonce ensuite un ordre de grandeur de sept millions de dollars d'économies attendues sur cinq ans, puis, une fois la sortie réalisée, un bilan chiffré de la dépense évitée.

Un détail du calendrier intéresse directement ce billet : le déménagement des grands volumes de fichiers a été traité séparément, et plus tard que celui des applications. Le stockage de masse et le transfert de données posent un problème différent de celui du calcul, avec leurs propres coûts de sortie.

La lecture honnête de ce cas demande de rappeler ce que son auteur écrit lui-même dans le billet d'origine. Le cloud y reste le bon choix pour des applications très petites et peu sollicitées, et pour des charges dont le profil varie sauvagement et de façon imprévisible. Leur situation coche l'inverse de ces deux cases : une charge connue, stable, comprise, servie par une équipe qui sait exploiter du matériel.

Ce n'est donc pas un verdict général sur le cloud, et personne ne devrait le lire comme tel.

Ce que ce cas démontre est plus étroit et plus utile : une facture cloud est le résultat de décisions de conception. 37signals a mesuré la sienne, l'a attribuée, l'a comparée à une alternative chiffrée, puis a tranché. La plupart des organisations ne franchissent pas la première étape.

Points clés

  • Le coût suit trois questions, dans l'ordre : qui consomme, pour quoi, et est-ce dimensionné. Aucun tableau de bord ne compense l'absence de réponse à la première.
  • Les balises ne rattrapent pas le passé. Une consommation non balisée au moment de l'usage est définitivement non attribuable.
  • Un budget notifie, il ne plafonne pas. Le seuil sur la prévision sert bien plus que le seuil sur le réel, et il faut une automatisation branchée derrière pour obtenir un effet.
  • Les leviers s'appliquent dans l'ordre : éteindre, dimensionner, puis s'engager. Une réservation posée sur du gaspillage verrouille le gaspillage pour trois ans.
  • Le seuil d'équilibre d'un engagement est égal à son prix remisé, exprimé en part du tarif à la demande. En dessous de ce taux d'utilisation, l'engagement coûte plus cher que le paiement à l'usage.

Dans la série

Palier 1 : Ouvrir le port. Domaine : Gouvernance.

Pour aller plus loin