Ce que dit l'avis, et ce qu'il ne dit pas
L'avis Azure Service Health rapporte une augmentation de prix au 1er février 2027 pour certaines offres Azure VM et Storage, dans sept régions. L'amplitude annoncée dans l'avis va de 8 % à 17 %. Ces chiffres proviennent de la notice et ne sont pas vérifiés indépendamment ici.
Les taux indiqués par région sont les suivants : North Europe (Dublin) +17 % ; France Central et France South +11 % ; West Europe (Amsterdam), Norway East et Norway West +9 % ; Southeast Asia (Singapore) +8 %.
L'accès à la notice se fait après connexion, selon la source. La première étape n'est donc pas une analyse, mais un accès documentaire et l'extraction de la liste des ressources concernées. Un avis de ce type donne un taux et un périmètre ; il ne donne ni votre exposition réelle, ni la répartition de votre consommation entre les SKU concernés et les SKU exclus.
Exclusions VM : lire la série, pas seulement la région
Le périmètre dépend du SKU autant que de la région. Les séries de VM suivantes sont exclues de cette hausse régionale : v1 — Bv1, D, Ds, F, Fs, G, Gs, L, NP, HCS ; v2 — Av2, Amv2, Dv2, Dsv2, Fsv2, Lsv2 ; v7 — Dsv7, Ddsv7, Dlsv7, Dldsv7, Esv7, Edsv7.
Conséquence pratique : deux ressources situées dans la même région peuvent réagir différemment. Une hausse de 11 % en France Central n'est pas une hausse de 11 % de votre facture VM ; c'est une hausse de 11 % sur les SKU non exclus que vous y consommez réellement.
Le raisonnement utile consiste donc à partir du SKU et de la région, puis à croiser avec la consommation. Le critère principal est l'exposition : part de la consommation située dans les sept régions, et part de cette consommation portée par des SKU dans le périmètre.
Storage : une liste d'exclusions, mais pas une liste complète des hausses
Pour le Storage, les exclusions listées dans la notice sont : Azure Container Storage, Azure Managed Lustre, Azure NetApp Files (Cross Region Replication), Blob Features, Change Feed, General Block Blob, Import/Export, Queues, Queues v2, Standard Page Blob, Storage Actions, Storage Bandwidth, Storage Discovery, Tables et le SKU Transaction Optimized.
Réserve importante : la notice ne liste pas tous les SKU Storage dont le prix augmentera. Une réponse Microsoft Q&A du 5 octobre indiquait qu'il n'existait pas, à cette date, d'article public détaillé. C'est un point de vigilance : l'absence d'un SKU dans la liste des exclusions ne prouve pas qu'il est exonéré.
Cette asymétrie entre une liste d'exclusions précise et une liste de hausses incomplète est ce qui rend le chiffrage Storage fragile. Elle justifie une démarche de clarification auprès de Microsoft ou d'un partenaire avant de figer une prévision.
Critères de décision et arbitrages
Les critères à combiner sont : la date d'effet au 1er février 2027 ; la région de chaque ressource ; le SKU exact ; la part de consommation concernée ; l'existence éventuelle d'un prix contractuel protégé ou d'un mécanisme d'indexation dans le price sheet ; et le traitement des offres Storage ambiguës.
L'arbitrage porte sur le niveau de précision. Une estimation par taux régional moyen est rapide, mais peut surestimer ou sous-estimer l'effet selon votre mix de SKU. Une estimation ligne à ligne, SKU par SKU, est plus fiable mais plus coûteuse en temps. Une approche intermédiaire consiste à chiffrer les SKU confirmés dans le périmètre, puis à isoler le reste dans une enveloppe d'incertitude explicite.
Un autre arbitrage concerne l'horizon : la hausse est datée au 1er février 2027, mais une prévision budgétaire annuelle doit aussi tenir compte de l'évolution des volumes, des nouveaux déploiements et des ressources qui pourraient être migrées ou redimensionnées d'ici là.
Questions à poser avant de chiffrer 2027
Mon SKU précis, dans ma région, entre-t-il dans le périmètre de la hausse ?
Quelles offres Storage exactes sont concernées, au niveau du SKU, et pas seulement de la famille de service ?
Le price sheet contractuel prévoit-il une protection de prix ou un mécanisme d'indexation avant renouvellement ?
L'augmentation s'applique-t-elle aux ressources existantes, aux nouveaux déploiements, ou aux deux ?
À partir de quelle date de facturation l'effet devient-il visible ?
Ces réponses conditionnent directement la prévision. En leur absence, documenter les hypothèses retenues, avec leur niveau de confiance, est la seule option défendable.
Checklist proposée (exemple hypothétique, à adapter)
Cette liste est une suggestion de méthode, pas une prescription. Elle suppose que vous disposez d'un accès à la notice et d'un accès à Cost Management.
Ouvrir l'avis Service Health et l'onglet Impacted Resources. Exporter la liste obtenue. Croiser cette liste avec Cost Management, par SKU et par région. Vérifier également votre propre inventaire de ressources : l'onglet peut manquer des ressources.
Marquer les SKU dans le périmètre et les séries exclues. Interroger Microsoft ou votre partenaire sur toute offre Storage ambiguë. Mettre à jour la prévision 2027 en appliquant le taux régional aux seules consommations dans le périmètre, et non à la facture totale.
Enfin, tester une sensibilité à 8 %, 11 % et 17 % selon les régions concernées, afin de voir comment le budget réagit à la borne basse et à la borne haute de la fourchette annoncée.
Ce que cela change pour un budget Azure
L'effet budgétaire correspond au produit de la consommation dans le périmètre par le taux applicable. Ce n'est pas un pourcentage appliqué à la facture totale. Si vos séries exclues dominent votre consommation dans ces régions, l'impact peut rester limité ; s'il repose sur des SKU non exclus en North Europe, l'effet peut être plus marqué.
L'incertitude principale reste le Storage, faute de liste complète des SKU concernés. La question utile n'est donc pas seulement « de combien le prix augmente-t-il ? », mais « quelle part de ma consommation est réellement exposée, et à quelle date ? »
Pour un budget 2027, la valeur d'une prévision vient moins de son chiffre exact que de la traçabilité de ses hypothèses : périmètre, taux, volumes, et incertitudes identifiées.
Le post à l’origine de cette analyse
Article développé à partir du post LinkedIn. Les liens ci-dessous sont ceux du post d’origine ; leur présence ne constitue pas une vérification indépendante.
LinkedIn ↗