Fin des IPs basiques sur les VPNs basiques

Si vous avez lu mon article de juillet 2025 sur les VPN Azure et la deadline du 30/09, vous vous souvenez du test avec une VPN Gateway Basic SKU avec une IP publique dynamique. Le verdict était brutal : suppression de la connexion, suppression de la gateway, impossibilité de migrer l’IP dynamique, création d’une nouvelle IP Standard, recréation complète de la gateway, changement d’adresse IP à la clé. Un calvaire. Bonne nouvelle : Microsoft a depuis simplifié la procédure pour les VPN Gateways Basic SKU. En 2026, c’est un clic dans le portail, sans coupure réseau, sans changement d’IP, en moins de cinq minutes.

Pour rappel, jusqu’ici les VPN Gateways Basic SKU pouvaient être créées avec une IP publique Basic SKU. Azure a migré ces IPs en interne vers des IPs Standard SKU depuis. Il reste une dernière action à faire côté client : supprimer la référence à l’ancienne ressource IP Basic dans la configuration de la gateway. C’est ce qu’on va faire ensemble, capture après capture.

Attention : cet article concerne uniquement la VPN Gateway Basic SKU (le SKU développement/lab, sans SLA). Si vous avez une gateway VpnGw1 à VpnGw5 ou un SKU legacy (Standard, High Performance), le processus est différent : utilisez l’outil de migration dédié dans la Configuration de la gateway. Ce n’est pas ce dont on parle ici.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

1. Pré-requis : êtes-vous concerné ?

Avant de toucher quoi que ce soit, vérifiez que vous êtes bien dans le cas de figure de cet article. Le piège classique : confondre « VPN Gateway Basic SKU » et « IP publique Basic SKU ». Ce sont deux ressources distinctes. Ici, on parle bien du SKU de la gateway elle-même.

SituationAction
VPN Gateway Basic SKU avec une référence à une IP publique Basic SKU✅ Vous êtes concerné par cet article
VPN Gateway Basic SKU sans référence IP Basic (déjà nettoyée)✅ Rien à faire, vous êtes bon
VPN Gateway VpnGw1 à VpnGw5 (non-AZ ou AZ)❌ Pas cet article : utiliser l’outil « Migrate to Standard IP » dans Configuration
VPN Gateway SKU legacy (Standard, High Performance)❌ Pas cet article : suivre le guide de migration dédié Microsoft

Pour rappel, la VPN Gateway Basic SKU est un SKU développeur, sans SLA. Elle ne retire pas, contrairement à ce que beaucoup pensaient (moi y compris, au moment de mon article 2025). Microsoft a confirmé qu’elle reste disponible : c’est uniquement la référence à l’IP Basic qui doit être nettoyée.

2. Étape 0 : identifier la présence de la référence IP Basic

Deux façons de vérifier si votre gateway est concernée : depuis la CLI Azure ou directement depuis le portail.

Via Azure CLI : récupérez d’abord l’ID de l’IP publique associée à votre gateway.

az network vnet-gateway show \
    --name <nom-de-votre-gateway> \
    --resource-group <votre-resource-group> \
    --query "ipConfigurations[].publicIpAddress.id" \
    --output tsv

Copiez l’ID retourné, puis vérifiez le SKU de cette IP :

az network public-ip show \
    --ids <id-copié-ci-dessus> \
    --query "sku.name" \
    --output tsv

Si la commande retourne Basic, vous êtes concerné. Si elle retourne Standard, votre gateway est déjà propre :

Via le portail Azure : naviguez vers votre ressource Virtual network gateway. Dans le menu de gauche, sous Settings, cliquez sur Configuration. Si votre gateway est concernée, vous verrez une section Validation avec un bouton Delete Basic Public IP Reference. C’est la confirmation visuelle que vous devez agir.

Si vous ne voyez pas cette section, soit votre gateway n’a plus de référence IP Basic (déjà nettoyée), soit vous n’êtes pas sur un gateway Basic SKU.

3. Étape 1 : vérifier la validation dans le portail

Toujours sur la page Configuration, regardez la section Validation. Chaque ressource listée doit afficher le statut Succeeded avant de pouvoir continuer.

Attention : si une ou plusieurs ressources affichent un statut autre que Succeeded, ne continuez pas. Résolvez d’abord les erreurs signalées avant de déclencher la suppression.

4. Étape 2 : supprimer la référence IP Basic

Toutes les ressources sont en Succeeded ? Le moment de vérité. Cliquez sur le bouton Delete Basic Public IP Reference.

Concrètement, ça donne quoi ? Cette action retire l’association entre la ressource IP publique Basic SKU et la gateway. Ce n’est pas une migration. Azure avait déjà basculé l’IP en interne vers une ressource Standard SKU non visible dans votre subscription : vous ne faites que supprimer le pointeur côté client.

This action removes the association between your Basic SKU public IP address resource and the Basic SKU VPN gateway. It’s not a migration operation. The public IP address itself is already moved internally by Azure to a Standard SKU public IP address resource used by the VPN gateway.

Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn
Mon retour terrain : dans mon article de 2025, le Test III montrait qu’il fallait supprimer la connexion VPN, supprimer la gateway, recréer une IP Standard, et tout reconstruire. L’IP changeait au passage. C’était le comportement de l’époque pour une IP dynamique. La procédure 2026 est radicalement différente pour la Basic SKU Gateway : un bouton, zéro downtime, l’IP reste la même. Microsoft a bien bossé sur ce point.

5. Étape 3 : vérifier le résultat

Une fois l’opération terminée, retournez sur la page de la gateway. Et là, surprise possible : l’adresse IP peut apparaître comme null dans le portail, ou le nom de l’ancienne ressource IP Basic est encore affiché sans lien cliquable.

Attention : ce comportement est un bug cosmétique connu et documenté par Microsoft. La gateway fonctionne parfaitement, l’IP n’a pas changé, et vos connexions S2S/P2S continuent de tourner. Ne paniquez pas.

Pour vérifier l’IP réelle utilisée par la gateway, deux options. Depuis le portail, cliquez sur JSON View en haut à droite de la page Overview de la gateway : les propriétés réelles de la ressource y sont correctement renseignées, avec l’adresse IP effective.

Ou depuis la CLI, via la propriété tunnelIpAddresses :

az network vnet-gateway show \
    --name <nom-de-votre-gateway> \
    --resource-group <votre-resource-group> \
    --query "bgpSettings.bgpPeeringAddresses[0].tunnelIpAddresses[0]" \
    --output tsv

6. Étape 4 : supprimer l’ancienne ressource IP Basic

La suppression de la référence ne supprime pas la ressource IP publique Basic SKU de votre subscription. Elle reste dans votre resource group, et Azure continue de vous la facturer tant que vous ne la supprimez pas manuellement.

Depuis le portail, naviguez vers votre resource group, repérez la ressource de type Public IP address avec le SKU Basic, et supprimez-la. Ou en CLI :

az network public-ip delete \
    --name <nom-de-votre-ip-basic> \
    --resource-group <votre-resource-group>

Une fois supprimée, la facturation de cette ressource s’arrête. La gateway continue d’utiliser une IP Standard SKU gérée en interne par Azure, non visible et non facturée séparément dans votre subscription.

7. Pièges à éviter

Piège n°1 : tenter d’upgrader l’ancienne ressource IP Basic manuellement. Après avoir supprimé la référence, vous pourriez être tenté d’upgrader la ressource IP Basic restante vers un Standard SKU via le portail ou PowerShell. Ne le faites pas. Microsoft a documenté que cette tentative provoque un état de provisionnement Failed sur la ressource. La bonne action est la suppression pure et simple, pas l’upgrade.
Piège n°2 : paniquer devant l’affichage null dans le portail. Comme vu à l’étape 3, le portail peut afficher l’IP comme null ou encore le nom de l’ancienne ressource Basic sans lien. C’est purement cosmétique. Fiez-vous à la vue JSON ou à la CLI pour vérifier l’état réel, et testez vos tunnels VPN : ils fonctionnent.
Piège n°3 : ne rien faire avant le 30 juin 2026. Si vous ne supprimez pas la référence avant la deadline, votre gateway continuera de fonctionner, mais dans une configuration non supportée, sans garantie de SLA. Microsoft ne viendra pas corriger ça pour vous. La VPN Gateway Basic SKU est déjà un SKU sans SLA en temps normal : sans cette action, elle perd toute couverture de support.

8. Questions fréquentes

Microsoft a publié une FAQ détaillée sur cette procédure. Voici les points que je trouve les plus utiles à avoir en tête.

Cette opération change-t-elle le SKU ou migre-t-elle ma gateway ?

Non. C’est le point qui perturbe le plus : on parle de « migration IP » partout, mais cette opération ne migre rien et ne change pas le SKU de la gateway. Elle supprime uniquement la référence côté client.

This operation doesn’t change the VPN Gateway SKU and doesn’t migrate the gateway. It only removes the reference to the Basic SKU public IP address resource from the gateway configuration.

Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Qu’arrive-t-il exactement à mon adresse IP ?

La valeur de l’IP ne change pas. En revanche, après l’opération, la ressource IP publique Basic SKU côté client n’est plus liée à la gateway. L’IP est désormais portée par une ressource Standard SKU interne, non visible dans votre subscription.

The IP address value itself doesn’t change and continues to be used by the VPN gateway. However, after removing the reference: the customer-visible Basic SKU public IP address resource is no longer linked to the gateway. The IP address is now associated with an internal Standard SKU public IP address resource that isn’t visible in your subscription.

Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Pourquoi ne puis-je pas accéder à la nouvelle ressource IP Standard créée par Azure ?

Parce qu’elle est intentionnellement invisible. C’est une ressource interne Azure-managed, hors du périmètre de votre subscription. Vous ne pouvez pas la gérer, la voir, ni la facturer.

The Standard SKU public IP address that’s used by the VPN gateway after this process is an internal Azure-managed resource. It isn’t customer-visible or customer-manageable.

Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Y a-t-il des changements de facturation ?

L’opération elle-même n’entraîne aucun nouveau frais. Mais l’ancienne ressource IP Basic reste dans votre subscription et continue d’être facturée jusqu’à sa suppression manuelle. La nouvelle IP Standard interne, elle, n’est pas facturée séparément.

Dis-associating the Basic public IP reference from your VPN gateway doesn’t introduce any new charges and doesn’t result in additional billing. Once you delete it, billing for that Basic public IP resource stops. Your VPN gateway continues to use an internally managed Standard SKU public IP address provided by Azure. This internal Standard SKU public IP address isn’t customer-visible and isn’t billed separately.

Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Que se passe-t-il si je ne fais rien avant le 30 juin 2026 ?

Votre gateway continue de tourner, mais dans une configuration officiellement non supportée. Pas de SLA, pas d’intervention Microsoft. Et contrairement à ce qu’on pourrait espérer, Microsoft ne fera rien à votre place.

If you don’t take action, your VPN gateway will continue running in an unsupported state. The VPN Gateway Basic SKU doesn’t include SLA guarantees and isn’t intended for production use. Microsoft won’t automatically modify or clean up resources in your subscription. Your gateway might continue to function, but reliability, availability, and support aren’t guaranteed.

Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

9. Conclusion

Voilà, en quatre étapes : vérification CLI ou portail, validation de la section Configuration, clic sur Delete Basic Public IP Reference, suppression de l’ancienne ressource IP Basic. Dix minutes grand maximum, zéro coupure réseau, l’IP ne change pas.

Par rapport à la situation de 2025 décrite dans mon article sur la deadline du 30/09, Microsoft a vraiment simplifié la procédure pour le cas VPN Gateway Basic SKU. En 2025, le seul chemin pour une IP dynamique était la destruction et la recréation complète, avec changement d’IP à la clé. En 2026, c’est un bouton dans le portail.

Les trois pièges à retenir :

  1. Ne pas tenter d’upgrader l’ancienne ressource IP Basic après dissociation, sous peine de la mettre en état Failed.
  2. L’affichage null dans le portail est cosmétique : vérifier via la vue JSON ou la CLI.
  3. Deadline le 30 juin 2026. Microsoft ne fait rien pour vous si vous ne bougez pas.

Foncez tester en lab si vous n’êtes pas encore passé à l’acte, et planifiez la prod dans la foulée. C’est le genre d’opération qui se fait en dix minutes et qui évite une mauvaise surprise après le 30 juin.

Et pendant que vous êtes dans le portail Azure, profitez-en pour jeter un œil au Service Retirement Workbook, accessible depuis Azure Advisor > Workbooks > Service Retirement. Ce classeur liste toutes vos ressources impactées par des retraits Azure en cours, avec les dates d’échéance et les actions recommandées. Je l’avais déjà présenté dans mon article de 2025 et il reste, aujourd’hui encore, le meilleur moyen de ne rien rater dans votre tenant.

VPN Azure : Attention au 30/09/25 !

Peu importe le fournisseur de Cloud choisi, d’anciens services sont régulièrement dépréciés au profit de nouveaux. Ces transitions sont fréquentes et planifiées. Mais, malgré les messages d’information, il est de notre responsabilité de les suivre, de les estimer afin de les traiter. Encore faut-il en comprendre les conséquences pour mesurer leur impact sur les environnements existants.

Pour vous aider à anticiper les changements à venir sur les VPN Gateways Azure, voici un tableau synthétique des impacts, échéances et actions nécessaires liés aux différentes annonces de retrait et de migration des SKU provenant de source officielle Microsoft :

ÉvénementImpact clientCalendrier prévuActions requisesDocumentation / Annonces
Migration IP publique Basic SKU (hors Basic SKU Gateway)– Nouvelle tarification
– Jusqu’à 10 min d’interruption
– Pré-requis IP/subnet
– 4 août 2025 : outil en preview
– Mi-nov. 2025 : GA prévue
– Jusqu’à fin mars 2026 : migration possible
– Avril 2026 : retrait des IP Basic
– Vérifier IP/subnet
– Migrer vers IP Standard SKU si nécessaire
Migration IP Basic SKU
Retrait IP Basic SKU
Migration IP publique Basic SKU (pour Basic SKU Gateway)– Pas de changement d’IP
– Pas d’interruption
– Fin oct. 2025 : automatisation disponible
– Fin mars 2026 : retrait complet
– Mettre à jour scripts/ARM si IP Basic référencéeRetrait IP Basic SKU
Retrait des SKU VPN Gateway non-AZ– Migration vers SKU AZ
– Pas d’interruption
– Nouvelle tarification
– Janv. 2025 : nouvelle tarification
– Mai 2025 à sept. 2026 : migration
– Sept. 2026 : retrait complet
– Migrer vers IP publique Standard SKU si encore en BasicMigration SKU VPN Gateway
Retrait des SKU Standard / High Perf– Migration vers VpnGw1/VpnGw2 ou AZ
– Pas d’interruption
– Mai à mars 2026 : migration
– Mars 2026 : retrait complet
– Aucune action requiseRetrait SKU Standard/High Perf
Retrait des VPN Gateways classiques– Décommissionnement complet– Août 2024 : début du retrait
– Août 2025 : fin du service
– Migrer vers un gateway Azure Resource ManagerMigration VPN classique

Comment Microsoft informe des futurs services dépréciés ?

Microsoft communique les dépréciations, changements et nouvelles fonctionnalités Azure par plusieurs canaux officiels. Voici les principaux moyens de rester informé sur ce sujet :

Comment savoir si mes ressources Azure seront impactées ?

Azure fournit une méthode directe pour voir quelles ressources dans votre propre tenant seront affectées par une dépréciation :

Le classeur Service Retirement fournit une vue unique et centralisée des ressources sur les retraits de services. Il vous aide à évaluer l’impact, les options et à planifier la migration des services et fonctionnalités retirés. Le modèle de classeur est disponible dans la galerie Azure Advisor.

Microsoft Learn

J’aime beaucoup ce classeur, car il affiche une vue simple et rapide des ressources de votre environnement, comme le montre le tableau ci-dessus avec des ressourcées créées il y a une heure à peine.

Concernant les services concernant les VPN Azure, qu’est-ce que Microsoft dépréciera au 30 septembre prochain ?

Microsoft a annoncé la fin de vie de certains services de réseaux Azure au 30/09/2025 :

  • Anciens SKU Standard et High Performance pour les Azure VPN Gateway. Dès le 30 septembre 2025, ces modèles ne seront plus supportés. Il est donc fortement recommandé de migrer dès maintenant vers les SKU modernes VpnGw1 ou VpnGw2, qui offrent de meilleures performances, une haute disponibilité via les zones (AZ), et un meilleur rapport qualité/prix.
  • Les adresses IP publiques Basic SKU vont disparaître. Dès le 31 mars 2025, il ne sera plus possible d’en créer, et au 30 septembre 2025, toutes les IP Basic encore utilisées seront désactivées. Pensez à les remplacer par des IP Standard SKU, compatibles avec les architectures modernes (zones redondantes, SLA, sécurité).

Microsoft effectuera t-il des migrations automatiquement ?

Oui, mais seulement en partie :

Nous simplifions notre portefeuille de références SKU de passerelle VPN. En raison de l’absence de redondance, de disponibilité inférieure et de coûts potentiels plus élevés associés aux solutions de basculement, nous transférons toutes les références SKU prises en charge par la zone de non-disponibilité (AZ) vers les références SKU prises en charge par AZ.

  • À compter du 1er juin 2025 : la création de nouvelles passerelles VPN à l’aide de références SKU VpnGw1-5 (non-AZ) ne sera plus possible. Cette date a été mise à jour à partir de la date initialement annoncée le 1er janvier 2025
  • Période de migration : de septembre 2025 à septembre 2026, toutes les passerelles VPN existantes utilisant des références SKU VpnGw1-5 (non-AZ SKU) peuvent être migrées en toute transparence vers des références SKU VpnGw1-5 (AZ).

Cela concerne t-il aussi les VPN Standard et High Performance ?

Pas de panique si vous utilisez encore des SKU Standard ou High Performance pour vos VPN Gateway : aucune action immédiate n’est requise. En attendant, les services existants continuent de fonctionner normalement.

Une communication officielle, accompagnée d’une documentation détaillée, sera envoyée pour guider les administrateurs pas à pas dans cette transition :

Ne pouvant plus créer de passerelle VPN Standard ou High Performance, je ne pourrais pas partager avec vous mon retour d’expérience :

Et qu’en est-il du VPN Basic ?

Pendant plusieurs mois, je pensais que le VPN Basic allait disparaître. Mais j’étais dans l’erreur, et je ne pense pas être le seul :

Visiblement, Microsoft ne classe plus le VPN Basic comme un SKU Legacy :

Cette personne travaillant chez Microsoft donne du crédit à ce raisonnement :

Mais même certaines intelligences artificielles se trompent encore !

Microsoft met également fin au support du SKU VPN Basic, souvent utilisé dans les déploiements de test ou à faible coût. À partir du 30 septembre 2025, les passerelles VPN Basic ne fonctionneront plus du tout. Il est impératif de migrer vers un SKU plus récent, comme VpnGw1, pour garantir la continuité de service.

ChatGPT

En regardant au plus près la documentation Microsoft, voici la réponse à notre question :

Donc il n’y aura rien à faire pour les liaisons VPN Basic ?

Cela n’est pas tout à faire juste :

L’information de taille à prendre en compte concerne les adresses IP Basic. Celles-ci sont utilisées dans différents services Azure comme :

  • VPN Basic
  • VPN Standard
  • Machine virtuelle
  • Équilibreur de charge

Concernant le VPN Basic Azure, au travers d’une autre page de la documentation Microsoft, on y apprend que l’on va devoir gérer le processus de migration manuellement. Ce qui entraînera mécaniquement un downtime :

Et qu’en plus, l’adresse IP publique aura changé après cette migration manuelle :

Une fois ces choses dites, je vous propose de tester cela depuis un environnement de démonstration afin de voir ce qu’il est actuellement possible de faire ou de ne pas faire de nôtre côté :

Maintenant, il nous reste plus qu’à tester tout cela 😎

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

  • Un abonnement Azure valide
  • Un tenant Microsoft
  • Un réseau virtuel Azure

Test I – Migration d’une IP publique basique statique :

J’ai souhaité commencé au plus simple en créant simplement une adresse IP publique basique et statique.

J’ai créé cette ressource Azure au moyen d’une seule commande CLI depuis Azure Cloud Shell :

az network public-ip create \
  --name myPublicIP0 \
  --resource-group vpn-rg \
  --sku Basic \
  --allocation-method static \
  --location uksouth

Une fois l’adresse IP publique créée, je suis allé sur la page de cette ressource, et j’ai constaté le message d’information suivant :

J’ai cliqué sur ce message d’information, puis j’ai confirmé mon choix de migration :

A peine une seconde plus tard, la notification Azure suivante est apparue :

De retour sur la page de la ressource, j’ai pu confirmer la réussite de la migration de mon IP vers le SKU Standard, ainsi que la conservation de mon adresse IP publique :

Cette migration du SKU basique vers le SKU standard est donc très simple et rapide et conserve la même adresse IP publique

Test II – Migration d’une IP publique basique statique attachée :

Continuons les tests, toujours avec une adresse IP publique basique et statique :

az network public-ip create \
  --name myPublicIP4 \
  --resource-group vpn-rg \
  --sku Basic \
  --allocation-method static \
  --location uksouth

Une fois l’adresse IP publique créée, je suis allé sur la page de cette ressource :

J’ai rattaché cette adresse IP publique à une machine virtuelle Azure :

Comme mon adresse IP publique est rattachée, la fonction de migration vers le SKU standard précédemment utilisé ne me permet plus de le faire :

Azure confirme cela dans la page de configuration :

Il est nécessaire de désassocier l’adresse IP de la carte réseau de la machine virtuelle :

Une fois l’adresse IP publique désassociée, j’ai recliqué sur le message d’information :

Mais j’ai cette fois confirmé mon choix :

De retour sur la page de la ressource, j’ai pu confirmer la réussite de la migration de mon IP vers le SKU Standard :

Par la suite, il m’a fallu résassocier l’adresse IP publique à la carte réseau :

A la carte réseau de la machine virtuelle :

De retour sur la page de la machine virtuelle, j’ai pu confirmer la réussite de la migration de mon IP publique vers le SKU Standard, ainsi que la conservation de l’adresse publique :

Ces deux premiers tests nous montre que lorsque l’adresse publique est basique et de type statique, alors la migration vers le SKU standard ne pose alors aucun souci.

Intéressons-nous maintenant aux adresses IP basiques dynamiques.

Test III – Migration d’une IP publique basique dynamique attachée :

Dans ce test, j’ai souhaité voir s’il était possible de migrer une IP basique rattachée à une passerelle VPN basique.

Microsoft a restreint la création de nouvelles passerelles VPN Basic ainsi que l’utilisation de nouvelles adresses IP publiques Basic SKU statiques, j’ai dû partir sur une adresse IP dynamique :

az network public-ip create \
  --name myPublicIP \
  --resource-group vpn-rg \
  --sku Basic \
  --allocation-method Dynamic \
  --location switzerlandnorth

Pour cela, j’ai donc commencé par ajouter un sous-réseau dédié à ma passerelle :

Et comme il n’est plus possible de créer une passerelle VPN depuis le portail Azure, j’ai créé la ressource depuis Azure Cloud Shell :

az network vnet-gateway create \
  --name myVpnGateway \
  --resource-group vpn-rg \
  --location switzerlandnorth \
  --public-ip-addresses myPublicIP \
  --vnet vnet-vpn \
  --gateway-type Vpn \
  --vpn-type RouteBased \
  --sku Basic \
  --no-wait

Voici le groupe de ressources avec tous les éléments nécessaires à ma connexion VPN :

Le SKU de ma passerelle VPN créée est bien basique :

Une connexion depuis cette passerelle VPN est bien active :

Le SKU de mon adresse IP publique est bien basique :

Là aussi, j’ai cliqué sur le message d’information suivant :

Comme mon adresse IP publique est rattachée, la fonction de migration ne me permet pas de le faire :

Il m’est donc nécessaire de commencer par désassocier l’adresse IP, mais cela est impossible pour une passerelle VPN :

Je commence donc par supprimer la connexion de ma passerelle VPN :

Je confirme mon choix en cliquant sur Oui :

Puis je supprime ma passerelle VPN :

La suppression de la passerelle VPN prend plusieurs minutes :

Une fois l’adresse IP publique désassociée, j’ai recliqué sur le message d’information :

Mon adresse IP publique n’est plus rattachée, mais la fonction de migration refuse toujours de le faire car l’adresse IP publique est dynamique et non statique :

Je n’ai d’autres choix que de supprimer l’adresse IP publique dynamique :

Et je confirme mon choix en cliquant sur Oui :

Je créé donc une seconde adresse IP publique depuis le portail Azure :

Mais cette fois, je la créé avec le SKU de type standard :

Voici le SKU et l’adresse IP publique une fois la ressource Azure créée :

Cette adresse IP est bien redondante entre plusieurs zones Azure :

Je continue en créant la passerelle VPN de type basique via la commande CLI suivante :

az network vnet-gateway create \
  --name myVpnGatewaygood \
  --resource-group vpn-rg \
  --location switzerlandnorth \
  --public-ip-addresses myPublicIPgood \
  --vnet vnet-vpn \
  --gateway-type Vpn \
  --vpn-type RouteBased \
  --sku Basic \
  --no-wait

J’attends quelques minutes la fin de la création de la passerelle VPN

Je recréé à nouveau ma connexion VPN :

Ce test nous a monté que la migration d’une passerelle VPN basique avec une adresse IP dynamique n’est pas automatique. Nous avons dû supprimer et recréer les ressources, comme la documentation Microsoft nous l’indiquait :

Et qu’en plus, l’adresse IP publique a changé :

Conclusion

La dépréciation annoncée des anciens SKU VPN Gateway et des adresses IP Basic dans Azure n’est pas un simple changement cosmétique : elle implique une révision proactive de vos architectures réseau. Comme nous l’avons vu, certaines migrations sont simples et automatiques, d’autres nécessitent des manipulations plus lourdes, incluant la suppression et la recréation de ressources critiques.

Il est essentiel d’anticiper ces évolutions, non seulement pour assurer la continuité de service, mais aussi pour aligner votre environnement sur les meilleures pratiques Azure : haute disponibilité, sécurité, et scalabilité.

Le 30 septembre 2025 est une échéance technique mais surtout stratégique. N’attendez pas l’automne pour agir : identifiez, planifiez, migrez.