Vous avez acheté des instances réservées (RI) Azure, vous vous êtes toujours dit qu’en cas de changement de workload vous pourriez les échanger, et vous découvrez maintenant que ce filet de sécurité va disparaître ? Cet article est fait pour vous. On part de l’annonce Microsoft du 30 juillet 2026 et on déroule ce qui change, ce qui ne bouge pas, les scénarios chiffrés, et le plan d’action à mener avant le 1er février 2027.
Pour rappel, jusqu’ici l’échange était le joker des réservations Azure : vous aviez surdimensionné une série de VM, vous vous étiez trompé de région, vous aviez migré de Dsv3 vers Dsv5, et hop, un échange remettait le compteur d’engagement à zéro et sans pénalité :
Ce joker se referme bientôt : à partir du 1er février 2027, si un service Azure est couvert par un saving plan, la réservation correspondante n’est plus échangeable.
Pour vous guider plus facilement dans ce changement à venir, voici des liens rapides :
- 1. Ce qui change vraiment au 1er février 2027
- 2. Les services concernés
- 3. Ce qui ne change pas
- 4. Pourquoi Microsoft fait ça : ma lecture
- 5. Cinq scénarios concrets
- 6. Réservation ou savings plan : la grille d’arbitrage
- 7. Le trade-in en pratique
- 8. Les pièges à connaître
- 9. Votre plan d’action avant le 1er février 2027
Mais avant de rentrer dans ce sujet bientôt brûlant, et si les réservations d’instance ne sont pas encore votre tasse de thé :
Qu’est ce qu’une instance réservée Azure ?
Pour faire simple, les Azure RIs sont comme des places de parking que vous louer pour 1 ou 3 ans, et où les VM (ou d’autres services de compute), peuvent y être affectées, afin d’économiser des frais de stationnement, donc ici des coûts d’infrastructure auprès de Microsoft.
Voici une vidéo qui va vous éclairer sur les RIs :
Et voici une vidéo expliquant cette fois les saving plans :
Voici donc comment on peut voir comment faire son choix entre instance réservée et un saving plan :
1. Ce qui change vraiment au 1er février 2027
La règle tient en une phrase, et Microsoft l’écrit noir sur blanc :
Starting February 1, 2027, reservations purchased after this date aren’t eligible for exchange if the corresponding service is supported by savings plans.
Source : Changes to the Azure reservation exchange policy, Microsoft Learn
En clair, à partir du moment où un service dispose d’un savings plan, Microsoft considère que vous avez déjà l’outil de flexibilité qu’il vous faut, et retire donc la flexibilité de la réservation. Deux régimes cohabitent, et tout se joue sur la date d’achat.
| Date d’achat de la réservation | Droit d’échange |
|---|---|
| Avant le 1er février 2027 | Échanges illimités jusqu’au 31 janvier 2027, puis un échange final après cette date |
| À partir du 1er février 2027 | Aucun échange possible |
Le mot important est final. Une réservation active achetée avant la bascule conserve le droit à un échange, un seul, et la réservation issue de cet échange n’est plus échangeable du tout. Microsoft le confirme dans la FAQ de son annonce : une fois l’échange final consommé, la réservation obtenue ne peut plus être échangée.
La politique est aussi prospective, et c’est un point que beaucoup vont rater : tout produit compute ou base de données qui deviendra éligible aux savings plans après le 1er février 2027 tombera automatiquement sous la même règle, et les réservations déjà achetées pour ce produit basculeront à leur tour sur le régime de l’échange unique.
Deux catégories restent en dehors du périmètre :
- les réservations de produits ou services dépréciés et proches de la fin de vie ;
- les réservations de produits non couverts par les savings plans, Azure VMware Solution étant l’exemple cité par Microsoft ;
La première exclusion mérite qu’on s’y arrête, parce qu’elle recoupe directement un sujet que j’ai traité récemment. Les séries D, Ds, Dv2, Dsv2, Ls, Av2, Amv2, B, F, Fs, Fsv2, G, Gs et Lsv2 ont toutes une date de retraite annoncée en 2028, et j’ai détaillé ce calendrier dans VM Azure : anticipez les dépréciations. Ces séries entrent a priori dans la catégorie des produits dépréciés et proches de la fin de vie, donc dans l’exclusion.
2. Les services concernés
La page Learn se contente de « Azure Virtual Machines, Azure App Service, Azure SQL Database, and similar services », ce qui est un peu court quand on doit auditer un portefeuille d’engagements. L’annonce sur le Tech Community, elle, donne la liste exacte au moment de la publication :
| Compute | Bases de données |
|---|---|
| Azure Virtual Machines, y compris les échanges entre stockage non premium et premium | Azure Database for PostgreSQL |
| Azure Dedicated Host | Azure Database for MySQL |
| Azure App Service | Azure DocumentDB |
| Azure Cosmos DB | |
| Azure SQL Database | |
| Azure SQL Managed Instance |
Soit trois services compute et six services de bases de données, neuf au total. Notez la mention entre parenthèses sur les VM : l’échange F1 vers F1s, celui qu’on utilisait tranquillement pour passer une réservation vers une taille compatible stockage premium, entre lui aussi dans le périmètre.
À l’inverse, deux familles gardent leur échangeabilité complète parce qu’elles ne sont pas couvertes par les savings plans : Azure VMware Solution et Nutanix on Azure BareMetal, qui restent d’ailleurs des cibles d’échange valides au sein de la famille compute.
3. Ce qui ne change pas
Avant de paniquer, faisons le tri. Beaucoup de choses restent en place, et Microsoft insiste lourdement sur le fait que les réservations ne sont pas en cours de retrait.
- L’instance size flexibility pour les VM n’est pas touchée. Votre réservation D4s_v5 continue de couvrir deux D2s_v5 sans que vous ayez quoi que ce soit à faire.
- La politique d’annulation ne bouge pas : le plafond reste à 50 000 USD de commitment annulé sur 12 mois glissants, par billing profile ou par enrollment.
- Le trade-in vers un savings plan reste possible, sans limite de date, et sa politique est inchangée.
- L’achat et le renouvellement de réservations restent disponibles pour tous les services concernés.
Sur la question « est-ce que Microsoft tue les réservations ? », la FAQ officielle répond non, et précise que le changement porte uniquement sur l’échangeabilité. Ce qui disparaît, c’est le droit à l’erreur, pas le produit.
4. Pourquoi Microsoft fait ça : ma lecture
Ce n’est pas la première tentative
Avant d’analyser le pourquoi, un rappel qui change la lecture de toute l’annonce : Microsoft a déjà essayé de fermer ce robinet, deux fois, et a reculé les deux fois.
- Octobre 2022, au moment même du lancement du savings plan : Microsoft annonce la dépréciation de l’échange des réservations compute au 1er janvier 2024. L’argumentaire est déjà mot pour mot celui d’aujourd’hui, le savings plan apportant la flexibilité automatiquement, la politique d’échange des réservations est ajustée en conséquence.
- Octobre 2023, premier recul : une période de grâce repousse l’échéance à « au moins le 1er juillet 2024 », avec déjà le principe d’un dernier échange conservé pour les réservations achetées avant la fin de cette période.
- Mai 2024, deuxième recul, et cette fois sans nouvelle date.
- 30 juillet 2026 : la notification promise arrive, pour le 1er février 2027. Six mois et deux jours de préavis. Microsoft tient son engagement au calendrier près.
Originally with a deadline of 1 July 2024, we have extended this and customers may continue exchanging their compute reservations for different instance series and regions until we notify them again, which will be at least 6 months in advance of the new deadline.
Source : Azure compute reservation exchanges will remain available until further notice (Tech Community, 16 mai 2024)
Cette phrase de 2024 est la clé pour comprendre pourquoi il faut prendre 2027 au sérieux. Le préavis promis vient d’être consommé. Il n’existe plus aucun engagement derrière lequel espérer un troisième report, et parier sur « ils vont encore reculer », c’est parier contre la seule garantie que l’on avait.
Il y a même un précédent dans l’autre sens, et il est récent. La fin des réservations un an sur les anciennes séries de VM était initialement fixée au 15 novembre 2027 : Microsoft l’a avancée au 1er juillet 2026, soit plus d’un an plus tôt que prévu. J’ai documenté cet épisode dans VM Azure : anticipez les dépréciations. Autrement dit, une date annoncée sur les engagements Azure peut aussi bien reculer que se rapprocher, et construire un plan sur l’hypothèse d’un report est le plus mauvais des paris.
Deuxième différence de taille : en 2022, la mesure ne visait que le compute, soit les réservations Azure Reserved Virtual Machine Instances, Azure Dedicated Host et Azure App Service. La version 2027 y ajoute six services de bases de données. Ce n’est pas la même annonce repoussée de trois ans, c’est une version élargie.
La justification officielle est l’alignement : Microsoft explique que la mesure aligne la politique d’échange des réservations sur la flexibilité déjà offerte par les savings plans, et donne un cadre de choix clair et prévisible entre les deux mécanismes d’engagement.
Concrètement, ça donne quoi ? Depuis l’arrivée du savings plan, Azure proposait deux produits qui se recouvraient partiellement : une réservation échangeable à volonté offrait à peu près la même souplesse qu’un savings plan, avec en prime une remise plus élevée. Le portefeuille était incohérent. En retirant l’échange, Microsoft rend les deux produits réellement distincts : la réservation devient un engagement ferme sur une configuration précise, avec la remise maximale ; le savings plan devient l’engagement souple, avec une remise plus faible mais applicable partout.
5. Cinq scénarios concrets
Les trois premiers cas sont ceux documentés par Microsoft, les deux suivants sont les questions que l’on me pose systématiquement en atelier FinOps.
Cas n°1 : réservation achetée avant la bascule
Vous achetez une réservation compute ou base de données d’un an ou trois ans avant le 1er février 2027. Vous pouvez l’échanger autant de fois que vous voulez tant que la date n’est pas passée. Si vous l’échangez après le 1er février 2027, la nouvelle réservation issue de l’échange n’est plus échangeable, parce que l’échange est traité comme une annulation, un remboursement et un nouvel achat, et que ce nouvel achat tombe sous les conditions du 1er février 2027.
Le piège classique est là : beaucoup vont croire qu’ils « gardent le droit d’échange » indéfiniment sur une réservation ancienne. Non. Le mécanisme d’échange fabrique une réservation neuve, et une réservation neuve après la bascule est verrouillée.
Cas n°2 : réservation achetée après la bascule
Vous achetez une réservation d’un an ou trois ans après le 1er février 2027. Vous ne pouvez pas l’échanger. Point. Il vous reste deux sorties : le trade-in vers un savings plan, toujours possible, et le remboursement dans la limite du plafond de 50 000 USD.
Cas n°3 : échange partiel de quantités
C’est le cas le plus intéressant et le moins connu. Vous achetez avant la bascule une réservation avec 10 quantités. Après le 1er février 2027, vous en échangez 2. Les 8 quantités restantes sur la réservation d’origine conservent chacune leur droit à un échange supplémentaire.
Autrement dit, l’échange final se compte à la quantité, pas à la réservation. C’est une marge de manœuvre réelle si vous savez déjà que votre parc va bouger par vagues : vous pouvez étaler vos ajustements plutôt que de tout jouer d’un coup.
Cas n°4 : l’échange coûte plus cher que prévu
Vous avez une réservation trois ans à 100 USD par mois, vous avez déjà payé 18 mensualités. Votre engagement restant est de 1 800 USD. Pour échanger, la nouvelle réservation doit avoir une valeur totale d’au moins 1 800 USD, que vous payiez au mois ou en une fois. Même logique sur un achat upfront : une réservation d’un an payée 2 400 USD, échangée après six mois, laisse un engagement restant de 1 200 USD, et la nouvelle réservation doit donc valoir 1 200 USD ou plus.
Et le terme repart de zéro. La réservation issue de l’échange démarre un nouveau cycle d’un ou trois ans à compter de la date d’échange. Si vous consommez votre échange final en fin de vie d’une réservation, vous vous rengagez donc pour un cycle complet, sur un actif désormais figé.
Cas n°5 : le trade-in plutôt que l’échange
Vos réservations VM ne collent plus à votre parc, mais vous ne savez pas vers quelle série aller. Plutôt que de brûler votre échange final sur un pari, vous les échangez contre un savings plan compute. Azure annule les réservations, vous rembourse au prorata, annule les échéances futures si vous payiez au mois, et vous engage sur un nouveau commitment horaire d’un an ou trois ans.
6. Réservation ou savings plan : la grille d’arbitrage
Le savings plan, c’est un engagement en dollars par heure sur des services compute ou bases de données éligibles, appliqué automatiquement quelle que soit la région. La réservation, c’est un engagement sur un type d’instance ou une famille d’instances, dans une région donnée.
Microsoft prend l’exemple d’une D2v4 en Japan East pour un an d’un côté, et de 5,00 USD par heure pendant trois ans de l’autre.
| Critère | Réservation | Savings plan |
|---|---|---|
| Nature de l’engagement | Instance ou famille d’instances, région fixée | Dépense horaire, toutes régions éligibles |
| Niveau de remise | Le plus élevé quand l’utilisation est pleine | Remise significative, mais inférieure |
| Souplesse | Instance size flexibility uniquement | Application automatique sur les services éligibles |
| Échange | Un échange final, puis plus rien après le 1er février 2027 | Non échangeable par construction |
| Profil de workload | Continu, stable, sans changement prévu | Dynamique, évolutif, multi-familles ou multi-régions |
Microsoft propose une séquence d’optimisation en cinq temps, et elle vaut le détour parce qu’elle remet l’ordre des opérations à l’endroit :
- Right-sizer d’abord, en supprimant les ressources inutilisées ou surdimensionnées. Une remise réduit un tarif, elle ne réduit pas du gaspillage.
- Échanger les réservations sous-utilisées vers des configurations mieux adaptées, tant que c’est encore possible.
- Basculer en trade-in les réservations sous-utilisées dont l’usage est variable.
- Acheter de nouvelles réservations, uniquement sur les workloads stables et bien compris.
- Ajouter des savings plans, dimensionnés sur une base de consommation déjà nettoyée.
Les points 2 et 3 ont maintenant une date de péremption. C’est tout l’enjeu des prochains mois.
7. Le trade-in en pratique
Le trade-in est le mécanisme qui survit intégralement au changement de politique, autant savoir s’en servir correctement.
Ce qui est éligible
Les réservations Azure Virtual Machines, Dedicated Hosts et Azure App Service s’échangent contre un savings plan compute, avec un nouvel engagement d’un an ou trois ans. Les réservations de bases de données s’échangent contre un savings plan database, avec un engagement d’un an. En dehors de ces produits, aucune autre réservation ni aucun pre-purchase plan n’est éligible au trade-in. Vous pouvez traiter jusqu’à 100 réservations dans une même opération d’achat de savings plan.
Les droits nécessaires
Il vous faut être owner du Reservation Order concerné, et disposer du rôle Savings plan purchaser ou être owner de la subscription qui portera l’achat. Et voici le piège qui fait échouer la moitié des premières tentatives : les permissions EA Admin write et Billing profile contributor, qui suffisent pour un achat direct de savings plan, ne fonctionnent pas pour un achat réalisé dans le cadre d’un trade-in de réservation.
Calculer le bon commitment horaire
Attention, celui-ci mérite qu’on s’y arrête. Lors d’un trade-in, le commitment horaire proposé par défaut est calculé à partir de la valeur monétaire restante des réservations retournées. Ce montant n’est pas forcément suffisant pour couvrir les VM que les réservations couvraient. Vous risquez donc de sortir de l’opération avec une couverture en baisse sans vous en rendre compte.
La méthode Microsoft pour calculer le vrai commitment, produit par produit, en partant de la calculatrice de prix Azure et d’un affichage upfront :
- Récupérer le coût upfront annuel du produit concerné pour le terme de savings plan visé.
- Diviser ce coût par 8 760 pour un savings plan d’un an, ou par 26 280 pour un savings plan de trois ans.
- Multiplier le résultat par le nombre d’instances que vous retournez.
- Répéter pour chaque produit du trade-in, puis additionner : c’est votre commitment horaire.
8. Les pièges à connaître
Sept points de vigilance à garder sous la main quand vous allez manipuler votre portefeuille d’engagements dans les prochains mois.
- Le plafond de remboursement. 50 000 USD de commitment annulé maximum sur 12 mois glissants, par billing profile ou enrollment. Bonne nouvelle : les remboursements issus d’un échange ne consomment pas ce plafond. Mauvaise nouvelle : si l’échange n’est plus disponible, toute sortie passe désormais par un remboursement qui, lui, décompte.
- Le réapprovisionnement du plafond. Il n’est pas annuel civil. Si vous annulez 2 400 USD, votre marge tombe à 47 600 USD et remonte de 2 400 USD exactement 365 jours après l’opération.
- Les gros engagements bloqués. Sur une réservation trois ans à 3 000 USD par mois, soit 108 000 USD, vous ne pouvez rien annuler tant que vous n’avez pas consommé 58 000 USD de votre engagement, parce que le reste dépasse le seuil de 50 000 USD.
- Pas d’échange entre familles de produits. Une réservation Cosmos DB ne s’échange pas contre une réservation SQL Database. Les échanges restent cantonnés à la famille : compute avec compute, SQL avec SQL.
- Certaines réservations n’ont jamais été échangeables. Les plans Red Hat, les plans SUSE Linux et tous les pre-purchase plans sont exclus de l’échange comme du remboursement, et ce point n’a pas changé.
- Les droits sur le Reservation Order. Il faut être owner ou Reservation administrator sur le Reservation Order pour échanger ou rembourser. Ce n’est pas un rôle de subscription, et ça se prépare à l’avance.
- Le cas CSP. Un client CSP ne peut pas échanger, annuler, renouveler ou rembourser lui-même : c’est le partenaire qui effectue l’opération pour son compte. Si vous êtes dans ce modèle, calez le sujet avec votre partenaire dès maintenant, pas le 25 janvier 2027.
Deux précisions financières utiles pour le dossier que vous allez devoir monter en interne. Côté EA, un remboursement revient sous forme de crédit sur l’Azure Prepayment, et ce crédit n’est valable que 90 jours : passé ce délai, il est perdu. Côté frais, Microsoft ne facture pas de frais de résiliation anticipée aujourd’hui, mais la documentation mentionne explicitement la possibilité de 12 % à l’avenir, sans date annoncée.
9. Votre plan d’action avant le 1er février 2027
Il vous reste environ cinq mois. Microsoft résume l’action attendue en une ligne : passez en revue votre portefeuille de réservations, évaluez vos besoins futurs de flexibilité, envisagez les savings plans là où c’est pertinent, et planifiez la façon dont vous voulez utiliser l’échange final. Voici comment je le décline concrètement.
- Inventoriez. Exportez la liste de vos réservations avec, pour chacune, le service, la date d’achat, le terme, la date d’expiration, la quantité et le taux d’utilisation. Si vous n’avez pas encore fait l’inventaire de vos VM par série, la procédure pas-à-pas est dans VM Azure : anticipez les dépréciations, et les deux exercices se font très bien dans la foulée.
- Classez chaque ligne en trois piles : stable et bien dimensionnée, sous-utilisée, ou obsolète parce que le workload a bougé.
- Right-sizez le parc avant de toucher aux engagements. On n’optimise pas une remise sur des ressources qu’on va éteindre, ni sur une série qui part à la retraite en 2028.
- Traitez la pile « sous-utilisée » avant le 31 janvier 2027, tant que les échanges sont encore illimités. C’est votre fenêtre de correction gratuite.
- Pour les workloads dont vous ne savez pas dire où ils seront dans un an, privilégiez le trade-in vers un savings plan plutôt que de consommer l’échange final sur un pari.
- Documentez, pour chaque réservation antérieure à la bascule, si son échange final est encore disponible. Sans ce suivi, personne ne saura répondre en 2028.
- Vérifiez dès maintenant les droits : owner ou Reservation administrator sur les Reservation Orders, rôle Savings plan purchaser pour les trade-in.
- Reprenez vos gabarits d’achat et vos process internes : à partir du 1er février 2027, un achat de réservation est un engagement ferme, il mérite le même niveau de validation qu’un investissement.
Conclusion
Voilà, en neuf sections, de quoi arrêter de subir cette annonce. Le changement n’est pas une catastrophe, c’est une remise à plat : Azure vous propose désormais deux produits d’engagement clairement séparés, un rigide et très remisé, un souple et un peu moins remisé, et vous demande de choisir en connaissance de cause.
Les quatre pièges à retenir :
- Un échange réalisé après le 1er février 2027 produit une réservation définitivement figée, parce qu’un échange est techniquement un rachat.
- L’échange final se compte à la quantité, pas à la réservation : c’est une marge de manœuvre, à condition de la suivre.
- Le commitment horaire proposé par défaut lors d’un trade-in ne garantit pas votre niveau de couverture précédent.
- Sans échange, la seule porte de sortie restante est le remboursement, et lui se heurte au plafond de 50 000 USD sur 12 mois glissants.
Sortez votre export de réservations, comptez les lignes sous-utilisées, et calez l’exercice avant fin janvier. Foncez, c’est le genre de chantier qui prend deux heures maintenant et coûte très cher plus tard.
Cet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur. Conformément à l’AI Act (UE) en vigueur depuis le 2 août 2026.
