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.

Microsoft a préparé quelques changements depuis l’écriture de cet article :

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énement	Impact client	Calendrier prévu	Actions requises	Documentation / 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ée	– Retrait 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 Basic	– Migration 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 requise	– Retrait 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 Manager	– Migration 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 :

Azure Advisor : Services Retirement Workbook

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.

AVD/W365 + RDP Multipath = 😍

Excellente nouvelle pour celles et ceux rencontrant des soucis de connexion à Azure Virtual Desktop ou Windows 365 ! Disponible en préversion depuis début 2025, le RDP Multipath vient d’être annoncé il y a peu en disponibilité générale par Microsoft. Nous allons justement voir comment en bénéficier, et qu’est-ce que cela apporte par rapport à du TCP ou à l’UDP simple-path.

Comment fonctionne la connexion d’un utilisateur à une VM AVD ?

Azure Virtual Desktop héberge des sessions client sur des hôtes de session s’exécutant sur Azure. Microsoft gère des parties des services au nom du client et fournit des points de terminaison sécurisés pour la connexion des clients et des hôtes de session.

Le diagramme suivant fournit une vue d’ensemble générale des connexions réseau utilisées par Azure Virtual Desktop.

Microsoft Learn

Azure Virtual Desktop (AVD) utilise le protocole RDP pour établir et acheminer vos sessions vers les machines virtuelles ; voici comment la connexion se déroule :

Découverte du feed (Feed Discovery)
- L’utilisateur s’authentifie auprès de Microsoft Entra ID et obtient un jeton OAuth.
- Le client envoie ce jeton au service de feed AVD, qui retourne la liste des desktops et applications disponibles sous forme de fichiers .rdp signés numériquement Microsoft Learn.
Connexion au gateway AVD
- Quand l’utilisateur lance l’un des fichiers .rdp, le client se connecte via TLS 1.2 (HTTPS) à Azure Front Door, qui redirige vers l’instance du Remote Connection Gateway la plus proche (latence minimale et charge équilibrée) Microsoft Learn.
- Le gateway valide la requête et fait appel au Connection Broker pour orchestrer la suite.
Établissement du canal de contrôle
- L’hôte de session (VM AVD) maintient en permanence un canal de communication sortant chiffré (TLS) vers le broker AVD, géré par le service Reverse Connect Transport plutôt qu’un listener TCP classique Microsoft Learn.
- Le broker utilise ce canal pour indiquer au session host de joindre le même gateway que le client.
Ouverture du canal de données (RDP data channel)
- Reverse connect transport (TCP via le gateway) : le trafic RDP transite en TCP chiffré sur 443 via le gateway, idéal si UDP est bloqué ou non configuré.
- RDP Shortpath (UDP direct) : le client et le session host créent un canal UDP direct (STUN/TURN + ICE), évitant le relay du gateway pour réduire latence et jitter Microsoft Learn.
- Le basculement entre TCP et UDP Shortpath est transparent et contrôlé par le client selon la configuration et la qualité réseau.
Session active et résilience
- Une fois le canal de données établi, RDP gère l’envoi d’affichage, d’audio, de redirections périphériques, etc.
- En mode Shortpath, chaque paquet voyage de façon indépendante : en cas de perte ou de réordonnancement, RDP multi‑path ou le TCP se chargent des retransmissions, tandis que le reverse connect TCP reprend toujours – garantissant la continuité de la session même sur des réseaux instables.

Le bon vieux duel TCP vs UDP ?

Voici un tableau comparatif des principaux aspects de TCP et UDP :

Critère	TCP (Transmission Control Protocol)	UDP (User Datagram Protocol)
Type de connexion	Orienté connexion (handshake en trois temps)	Sans connexion (pas de handshake)
Fiabilité	Fiable : accusés de réception et retransmissions automatiques	Non fiable : pas d’accusés de réception ni retransmissions
Ordonnancement	Garantit l’ordre des paquets	Pas d’ordre garanti
Contrôle de flux	Oui (fenêtre glissante)	Non
Contrôle de congestion	Oui (algorithmes AIMD, slow start, etc.)	Non
Taille de l’en‑tête	Au moins 20 octets	8 octets
Vitesse (latence)	Plus lente (overhead de contrôle)	Plus rapide (faible overhead)
Utilisations courantes	HTTP, HTTPS, FTP, SMTP, SSH, bases de données	DNS, VoIP, streaming vidéo, jeux en temps réel
Gestion des erreurs	Vérification de somme de contrôle + retransmission	Vérification de somme de contrôle uniquement
Transmission multiple	Flux unique, multiplexé par port	Datagrammes indépendants par port
Connection keep‑alive	Oui (optionnel)	Non
Adapté pour…	Applications nécessitant intégrité et fiabilité	Applications temps réel et tolérantes à la perte

Dans quels cas ne pas utiliser l’UDP pour AVD ?

Certains utilisateurs ont ressenti des difficultés lors de session Azure Virtual Desktop lorsque on passe systématiquement à l’UDP. On évitera d’activer le transport UDP sur Azure Virtual Desktop dans les cas suivants :

Réseaux d’entreprise très « verrouillés » :
- Pare‑feu ou appliance de sécurité qui ne laissent passer que le trafic HTTPS/TCP sur le port 443.
- Proxies ou load‑balancers interdisant ou foreçant l’inspection de flux UDP.
- Absence d’ouvrages STUN/TURN nécessaires au Shortpath UDP.
Topologies NAT ou VPN problématiques :
- NAT très restrictif (symmetric NAT) qui empêche la découverte de chemin direct STUN.
- VPN d’entreprise qui n’autorise que le protocole TCP encapsulé (SSLVPN, SSTP…), rendant l’UDP inopérant.
Contraintes de conformité ou d’audit :
- Politiques de sécurité interne imposant que tout le trafic soit chiffré/TLS sur TCP pour centraliser la journalisation et l’inspection.
- Nécessité de passer via des IDS/IPS qui ne gèrent que le TCP.
Scénarios de diagnostic ou de troubleshooting :
- Pour isoler un problème de connectivité ou comparer les performances TCP vs UDP : on désactive l’UDP pour forcer le fallback TCP.
- Lorsque vous suspectez que le UDP est la source de coupures intempestives (perte, réordonnancement).
Clients legacy ou plateformes non supportées :
- Certains clients RDP anciens ou intégrés (HTML5 via RemoteApp) ne gèrent pas le Shortpath UDP.

Un article écrit sur ce blog montre comment justement rester sur du TCP via une configuration depuis la machine AVD ou le poste local.

Qu’est-ce que le RDP Multipath ?

Le RDP Multipath (ou « UDP Multi‑Path ») est une évolution du transport RDP Shortpath qui évite les coupures et micro‑latences en :

Ouvrant plusieurs sous‑canaux UDP simultanément entre le client et l’hôte de session, au lieu d’un seul.
Surveillant en continu la qualité (latence, perte, gigue) de chacun de ces chemins via ICE/STUN/TURN.
Bascule instantanée du trafic sur le ou les sous‑canaux les plus sains dès qu’un chemin se dégrade, sans interrompre la session.

Concrètement, si l’un des liens subit une perte de paquets élevée, un pic de gigue ou tombe complètement, Multipath redirige automatiquement les paquets vers un autre sous‑chemin en quelques dizaines de millisecondes, assurant une expérience fluide et sans reconnexion visible pour l’utilisateur.

Comment fonctionne le RDP Multipath pour Azure Virtual Desktop ?

RDP Multipath pour Azure Virtual Desktop établit plusieurs sous‑canaux UDP simultanés (via ICE, STUN et TURN) et mesure en continu leur qualité (latence, perte, gigue).

Dès qu’un lien se dégrade, il bascule automatiquement en quelques dizaines de millisecondes vers le canal le plus performant, sans interrompre la session.
Si tous les canaux UDP tombent, Multipath retombe de façon transparente sur TCP, garantissant ainsi une expérience AVD quasi ininterrompue et nettement plus stable sur des réseaux instables.

L’excellente vidéo de Dean Cefola depuis sa chaîne YouTube Azure Academy nous permet d’en savoir un peu plus :

Le diagramme suivant illustre le fonctionnement de RDP Multipath avec Azure Virtual Desktop. Dans ce scénario, le principal chemin actif est la connexion UDP via STUN, complétée par deux connexions UDP redondantes via un serveur TURN :

Microsoft Learn

Comment en bénéficier ?

RDP Multipath fonctionne automatiquement lorsque les conditions suivantes sont remplies :

Assurez-vous que RDP Shortpath est configuré comme protocole de transport principal. Pour plus d’informations, voir Configurer RDP Shortpath. Nous ne prenons pas actuellement en charge les connexions WebSocket (basées sur le protocole TCP) et ces utilisateurs n’en tirent aucun avantage pour le moment.

Les connexions doivent être établies à partir d’un appareil Windows local utilisant Windows App, version 2.0.366.0 ou ultérieure, ou le client Remote Desktop, version 1.2.6074 ou ultérieure. Les autres plateformes ne sont pas prises en charge actuellement.

Afin de comprendre mieux le fonctionnement et l’impact entre les 3 protocoles disponibles pour Azure Virtual Desktop, j’ai préparé un environnement dédié.

Voici les différentes étapes que j’ai suivies :

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 :

Une abonnement Azure valide
Un tenant Microsoft

Etape I – Création de l’environnement AVD

J’ai créé un nouvel environnement Azure Virtual Desktop composé de 3 machines virtuelles et placées dans un même pool d’hôtes :

Comme le recommandait Microsoft avant la fin de la préversion, mon pool d’hôtes est encore être configuré en tant qu’environnement de validation :

Enfin j’ai laissé par défaut la configuration de la fonctionnalité RDP shortpath afin de gérer le protocole utilisé de façon individuelle sur chacune des 3 machines virtuelles AVD :

Commençons par configurer la première machine virtuelle AVD afin que celle-ci n’accepte que les connexions RDP en TCP.

Etape II – VM1 Forcer le flux TCP côté serveur :

Il est possible de forcer le serveur à n’accepter que des connexions TCP, ce qui est particulièrement utile dans des environnements où la stabilité prime. Pour cela, vous pouvez modifier le registre du serveur ou déployer une GPO.

Avant modification, le serveur accepte par défaut les connexions en UDP. Pour forcer TCP, la modification est simple : il suffit d’ajouter la clé de registre SelectTransport.

Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :

REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v SelectTransport /t REG_DWORD /d 1 /f

Après avoir mis à jour la clé de registre, il est nécessaire de redémarrer la machine AVD pour que la modification prenne effet.

Après modification, la connexion se fait exclusivement en TCP. Cette commande force le serveur à utiliser uniquement TCP pour les connexions RDP.

Continuons par configurer la seconde machine virtuelle AVD pour que celle-ci n’accepte que les connexions RDP en UDP simple-path.

Etape III – VM2 Forcer le flux UDP simple-path côté serveur :

Avant modification, le configuration par défaut de mon AVD accepte les connexions en UDP Multipath si cela est possible.

Mais il est possible de forcer le serveur à n’accepter que des connexions UDP sans Multipath. Pour cela, vous pouvez modifier le registre du serveur ou déployer une GPO.

Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings" /v SmilesV3ActivationThreshold /t REG_DWORD /d 0 /f

Après avoir mis à jour la clé de registre, les utilisateurs doivent se déconnecter et se reconnecter à l’hôte de la session pour que la modification prenne effet.

Après la modification, la connexion AVD se fait exclusivement en UDP simple-path :

Terminons de préparer notre environnement par la configuration de la dernière machine virtuelle AVD pour que celle-ci accepte les connexions RDP en UDP Multipath.

Etape IV – VM3 Forcer le flux UDP Multipath côté serveur :

Compte tenu de la configuration de notre nouvel environnement Azure Virtual Desktop, il n’y a rien à faire. La connexion de notre utilisateur de test nous le prouve :

Nos machines virtuelles AVD sont prêtes. Continuons maintenant sur la préparation de notre protocole de test.

Etape V – Préparation de l’environnement de test :

J’ai utilisé la version d’essai gratuite de Connection Emulator.

Connection Emulator est un outil qui vous permet de simuler des conditions réseau dégradées (latence, perte, gigue, réordonnancement, duplication, corruption).

Voici le lien pour le télécharger en version d’essai, cliquez-ici pour télécharger et installer la version Windows :

Caractéristiques principales de l’outil

Limite la vitesse de connexion
Imite une latence fixe ou variable
Simule la perte, la corruption, la duplication et la réorganisation de paquets individuels et séquentiels.
Affiche un graphique de simulation de paquets en direct
Prend en charge plusieurs profils de simulation

Etape VI – Réalisation des 2 tests :

J’ai réalisé deux scénarios d’émulation réseau avec Connection Emulator :

Test 1 : latence 100 ms, perte 8 %, duplication 5 %, réordonnancement 30 %, corruption 2 %
Test 2 : latence 200 ms, perte 16 %, duplication 10 %, réordonnancement 40 %, corruption 4 %

Pour chaque scénario, j’ai démarré simultanément trois VM AVD configurées en TCP, UDP simple-path et UDP Multipath, puis lancé la même vidéo sur chacune.

Cette méthode met en évidence, de manière visuelle, la dégradation de la qualité pour TCP et UDP mono-chemin et la résilience supérieure de l’UDP Multipath face aux pires conditions réseau.

Voici ma vidéo de comparaison des 3 protocoles de connexion :

Etape VII – Configuration sur Windows 365 :

Finissons cette dernière étape par la configuration sur Windows 365. Voici les informations de connection sur un poste Windows 365 avant la modification de registre :

Pour activer RDP Multipath avant le déploiement complet, définissez la valeur de la clé de registre suivante sur 100, puis relancez la session de votre utilisateur

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings" /v SmilesV3ActivationThreshold /t REG_DWORD /d 100 /f

Voici les informations de connection sur un poste Windows 365 après la modification de registre :

Si vous préférez désactiver RDP Multipath jusqu’à ce que le déploiement soit terminé, définissez la valeur de la clé de registre sur 0 :

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings" /v SmilesV3ActivationThreshold /t REG_DWORD /d 0 /f

Conclusion

En synthèse, RDP Multipath représente une véritable avancée pour Azure Virtual Desktop : il combine la rapidité et la légèreté du transport UDP avec robustesse et la redondance.

Grâce à la création et à la surveillance en continu de plusieurs sous‑canaux UDP, vos sessions basculent en quelques dizaines de millisecondes vers le chemin le plus sain, tout en retombant de façon transparente sur TCP si nécessaire.

Le résultat ?

Une expérience utilisateur fluide, sans micro‑coupure ni latence excessive, même sur des réseaux fortement dégradés.

N’attendez plus pour activer RDP Multipath sur vos environnements AVD : testez-le dès aujourd’hui et constatez par vous‑même l’amélioration significative de la résilience et de la qualité de vos connexions distantes.

Ajoutez du MCP à votre IA !

Alex Wolf, de la chaîne YouTube The Code Wolf, continue de peaufiner son application DBChatPro version après version et dévoile la v6 ! Cette nouvelle version intègre maintenant un serveur MCP, exposant les fonctionnalités clés de DBChatPro à d’autres outils d’IA (GitHub Copilot, etc.) ou même à vos propres applications. Dans cet article, nous explorons les fondamentaux du MCP, puis nous détaillons l’installation du serveur MCP de DBChatPro.

Avant toute manipulation technique, et pour bien saisir l’intérêt d’une architecture MCP, je vous recommande la lecture de l’excellent billet disponible sur Digidop, écrit par Thibaut Legrand. Voici un extrait de ce billet qui illustre parfaitement l’avantage d’une architecture MCP :

Qu’est-ce que le Model Context Protocol (MCP) ?

Le Model Context Protocol (MCP) est un standard ouvert conçu par Anthropic (l’entreprise à l’origine de Claude) qui offre aux modèles d’IA un accès sécurisé à diverses sources de données et outils externes.

Il fonctionne comme un « USB-C universel » pour l’IA, facilitant la communication avec n’importe quel service ou base de données.

Pourquoi le MCP a été créé ?

Avant le MCP, relier un LLM à des sources externes était laborieux et non standardisé. Les grands modèles de langage (GPT, Claude, Gemini…) présentent deux limites majeures :

Limite de contexte : Ils ne peuvent raisonner que sur les informations présentes dans leur contexte immédiat
Impossibilité d’action : Ils peuvent générer du texte mais ne peuvent pas agir sur le monde extérieur

La métaphore du « problème M×N » illustre parfaitement cette situation : pour connecter un nombre M modèles d’IA à un nombre N outils externes, il fallait créer M×N intégrations différentes. Le MCP transforme cette équation en M+N, réduisant drastiquement la complexité d’intégration.

Prenons un exemple concret :

une entreprise utilisant 4 modèles d’IA différents (Claude, GPT-4, Gemini, Deepseek) qui souhaite les connecter à 5 services externes (GitHub, Slack, Google Drive, Salesforce, base de données interne).

Sans MCP, cela nécessiterait 4×5=20 intégrations personnalisées. Avec MCP, on passe à seulement 4+5=9 composants (4 clients MCP et 5 serveurs MCP), soit une réduction de 55% de la complexité et du temps de développement.

MCP vs API traditionnelles : quelles différences ?

Pour comprendre l’importance du MCP, comparons-le aux API REST traditionnelles :

Caractéristique	MCP	API REST traditionnelles
Communication	Bidirectionnelle et en temps réel	Généralement requête-réponse unidirectionnelle
Découverte d’outils	Automatique et dynamique	Configuration manuelle nécessaire
Conscience du contexte	Intégrée	Limitée ou inexistante
Extensibilité	Plug-and-play	Effort d’intégration linéaire
Standardisation	Protocole unifié pour tous les modèles	Variable selon les services
Orientation	Conçu spécifiquement pour les modèles d’IA	Usage général

Cette standardisation représente un changement de paradigme pour quiconque souhaite développer des applications IA véritablement connectées.

Architecture et fonctionnement du MCP

L’architecture du MCP repose sur trois composants principaux qui interagissent de façon coordonnée :

Les composants clés du MCP

Hôtes MCP : Ce sont les applications qui intègrent l’IA et ont besoin d’accéder à des données externes. Par exemple, Claude Desktop, un IDE comme Cursor, ou toute application intégrant un LLM.
Clients MCP : Ce sont des intermédiaires qui maintiennent les connexions sécurisées entre l’hôte et les serveurs. Chaque client est dédié à un serveur spécifique pour garantir l’isolation.
Serveurs MCP : Ce sont des programmes externes qui fournissent des fonctionnalités spécifiques et se connectent à diverses sources comme Google Drive, Slack, GitHub, ou des bases de données.

Le flux de communication MCP se déroule typiquement en quatre étapes bien définies :

Découverte : L’hôte (comme Claude Desktop) identifie les serveurs MCP disponibles dans son environnement
Inventaire des capacités : Les serveurs MCP déclarent leurs fonctionnalités disponibles (outils, ressources, prompts)
Sélection et utilisation : Quand l’utilisateur pose une question nécessitant des données externes, l’IA demande l’autorisation d’utiliser un outil spécifique
Exécution et retour : Le serveur MCP exécute l’action demandée (recherche web, accès à un fichier, etc.) et renvoie les résultats à l’IA qui peut alors formuler une réponse complète

Ce processus standardisé permet une communication fluide entre l’IA et les sources de données externes, tout en maintenant un contrôle transparent pour l’utilisateur.

Serveurs MCP existants

Plutôt que de développer vos propres serveurs MCP depuis zéro, vous pouvez exploiter l’écosystème grandissant de serveurs préexistants. Ces solutions prêtes à l’emploi vous permettent d’intégrer rapidement des fonctionnalités avancées dans vos projets IA :

Serveurs officiels et communautaires

GitHub : Ce serveur MCP vous permet d’interagir avec des dépôts de code directement depuis votre application IA. Vous pouvez rechercher des fichiers, créer des issues, analyser des pull requests, ou même générer des commits et du code. Idéal pour les assistants de développement qui nécessitent une compréhension du contexte du code.
Google Drive : Offre un accès complet aux documents stockés sur Google Drive. Votre modèle d’IA peut ainsi lire, créer, modifier ou organiser des documents, présentations et feuilles de calcul, en conservant le contexte des informations partagées.
Slack : Permet à vos modèles d’IA d’interagir avec les canaux et conversations Slack. Ils peuvent envoyer des messages, surveiller des chaînes spécifiques, ou même répondre automatiquement à certains types de requêtes, créant ainsi une intégration transparente dans les flux de communication d’équipe.
Puppeteer : Un puissant serveur MCP qui apporte la capacité de naviguer sur le web. Vos modèles d’IA peuvent visiter des sites, remplir des formulaires, capturer des captures d’écran et extraire des données, ouvrant la voie à l’automatisation avancée des tâches web.
Brave Search : Donne à vos modèles d’IA la capacité d’effectuer des recherches web en temps réel via le moteur Brave. Cela permet de répondre à des questions sur l’actualité récente ou d’accéder à des informations au-delà de la date limite de formation du modèle.
PostgreSQL : Connecte vos modèles d’IA directement à vos bases de données PostgreSQL. Les modèles peuvent effectuer des requêtes SQL, analyser des données et même assister à la conception de schémas de base de données.
SQLite : Variante plus légère pour les bases de données locales, particulièrement utile pour les applications de bureau ou les projets avec des exigences de stockage plus modestes.
Qdrant : Serveur spécialisé pour les bases de données vectorielles, essentiel pour les applications IA nécessitant une recherche sémantique ou par similarité.

Afin de voir comment cela marche, voici les différentes étapes que nous allons suivre sur un environnement de test :

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 tenant Microsoft
Une souscription Azure valide

Commençons par créer quelques ressources (IA et DB) sur Azure et Entra.

Etape I – Création des ressources Azure :

Connectez-vous au portail Entra Admin Center pour enregistrer une nouvelle application, puis récupérez ensuite l’Application ID et le Tenant ID :

Créez un secret client puis copiez immédiatement sa valeur car elle ne sera plus visible par la suite :

Ouvrez une session Windows PowerShell, puis définissez trois variables d’environnement pour l’App ID, le Directory ID et le Client Secret :

setx AZURE_CLIENT_ID    "xxx"
setx AZURE_TENANT_ID    "yyy"
setx AZURE_CLIENT_SECRET "zzz"

Vérifiez ces variables dans les Propriétés système de Windows, section « Variables d’environnement », afin de confirmer leur bonne configuration :

Créez un service Azure OpenAI depuis le portail Azure, puis ajoutez votre application en tant que « Cognitive Services OpenAI User » dans « Contrôle d’accès (IAM) » :

Revenez à la page principale de votre service Azure OpenAI, puis cliquez sur Ouvrir dans la Fonderie pour accéder à l’interface de déploiement :

Dans la Fonderie, ouvrez l’onglet Déploiements et cliquez sur Nouveau déploiement, puis nommez-le (par ex : gpt-4o) et copiez l’URL de l’endpoint :

Créez une base de données Azure SQL Database avec des données en exemple, puis copiez la chaîne de connexion complète pour la réutiliser plus tard :

Notre environnement Azure est prêt. Nous allons maintenant pouvoir déployer l’application DBChatPro sur notre poste en local.

Etape II – Déploiement et test de l’application DBChatPro :

Accédez au dépôt GitHub de l’application via le lien, puis téléchargez l’archive ZIP sur votre poste :

Extrayez l’archive ZIP, puis placez-vous dans le dossier extrait pour préparer l’ouverture du projet :

Lancez Visual Studio Code, puis cliquez ici pour sélectionner le dossier du projet :

Sélectionnez le dossier extrait contenant le projet, puis validez pour l’ouvrir dans VS Code :

Observez la nouvelle architecture de DBChatPro avec la partie MCP distincte de l’interface graphique, puis passez à la configuration UI :

Commencez par l’interface graphique en renseignant les endpoints de votre choix dans le fichier de configuration, puis sauvegardez vos modifications :

Dans mon cas, j’ai utilisé le modèle Azure OpenAI :

Ouvrez la console intégrée Terminal de VS Code, positionnez-vous dans le dossier racine de l’application, lancez l’application, puis patientez quelques secondes pour que le serveur local démarre :

Copiez l’URL locale générée par l’application, puis ouvrez-la dans votre navigateur préféré :

Dans le navigateur, constatez que la base de données n’est pas encore configurée, puis cliquez sur Connexion :

Collez votre chaîne de connexion SQL en modifiant le mot de passe, puis cliquez sur Check Connection pour tester la liaison :

Vérifiez la découverte automatique du schéma de la base de données, puis cliquez ici pour sauvegarder pour valider l’import :

Dans le terminal, observez également l’import du plan et du schéma de votre base SQL :

Sur la page principale de l’application, sélectionnez le modèle et la plateforme d’IA, puis saisissez votre prompt :

Patientez quelques secondes pour afficher le résultat généré par le modèle :

Consultez l’onglet Insight pour obtenir des informations complémentaires sur la réponse, puis analysez les données fournies :

Sur l’onglet SQL Editor, constatez la transformation de votre requête en SQL :

Observez les résultats sous forme de tableau retournés par la requête SQL :

Accédez à l’historique des requêtes exécutées, puis identifiez celles que vous souhaitez réutiliser :

La fonction Chat vous permet de relancez une seconde requête basée sur les résultats de la première :

Testez cette seconde requête et constatez les résultats :

Au final, on constate que l’interface graphique de DBChatPro ne cesse d’évoluer pour offrir plus de facilité et une meilleure gestion des bases de données.

Passons maintenant à la partie MCP qui nous intéresse également.

Etape III – Déploiement du serveur MCP :

Revenez sur Visual Studio Code dans le programme MCP afin de paramétrer l’endpoint Azure OpenAI :

Collez également votre connexion SQL complète :

Cliquez sur le bouton Démarrer pour lancer le serveur MCP, puis patientez quelques instants :

Vérifiez que le serveur est démarré et affiche l’état Running :

Ouvrez la fenêtre Chat dans Visual Studio Code :

Assurez-vous que vous êtes en mode agent pour l’intelligence artificielle :

Dans la boîte à outils, confirmez que le serveur MCP et ses sous-modules sont actifs, puis refermez le panneau :

Effectuez un test de base pour vérifier que l’IA vous répond :

Lancez un prompt en spécifiant l’utilisation de DBChatPro avec un modèle et une plateforme AI, puis validez l’alerte :

use DbChatPro to get 10 customers from the database using AzureOpenAI and gpt-4o

Constatez que la connexion à la base de données et au modèle a bien fonctionné :

Observez en chat l’input et l’output de la requête :

Visualisez le résultat sous forme de tableau retourné par l’IA :

Lancez un second prompt sans redéfinir les paramètres du modèle, puis constatez que la réponse est tout de même générée :

Effectuez un autre test avec un prompt différent sur la même base :

Observez le résultat structuré cette fois en liste :

Si vous le souhaitez, testez la plateforme IA de GitHub en paramétrant un token d’accès sur cette page, puis copiez-le :

Sur ce token, autorisez l’accès en lecture pour interroger les modèles GitHub Copilot, puis confirmez cette permission :

Renseignez le modèle GitHub dans la configuration MCP et redémarrez le serveur, puis patientez quelques instants :

Relancez un prompt en utilisant le modèle GitHub Copilot comme plateforme IA :

Constatez le retour de résultats :

Envoyez cette fois un prompt combiné, interrogeant le serveur MCP via les deux modèles d’IA, puis constatez la fusion des réponses :

Enfin, découvrez sur sa vidéo, toujours depuis Visual Studio Code, des fonctions de troubleshooting très pratiques :

Conclusion

L’intégration du MCP transforme votre assistant en un véritable pont entre l’IA et le monde réel. Fini les intégrations sur mesure : grâce à ce protocole standard, un modèle peut interagir avec des bases de données, GitHub Copilot ou tout autre outil compatible.

On passe d’une complexité M×N à un système modulaire, extensible et sécurisé.

En adoptant le Model Context Protocol dès aujourd’hui, vous préparez vos solutions à l’IA de demain : une IA connectée, actionnable et interopérable, capable de faire bien plus que répondre, mais également d’interagir.

Déployez une passerelle VPN OPNsense

Azure VPN Gateway est un service plébiscité pour sa sécurité, sa redondance et la simplicité de son intégration native dans Microsoft Azure. Cependant, pour des projets de plus petite envergure ou lorsque vous disposez déjà de compétences réseau et d’infrastructures maîtrisées, il peut être judicieux d’explorer des solutions open source ou des distributions spécialisées. C’est dans cette optique que nous verrons comment déployer un VPN OPNsense sur Azure.

Comment fonctionne un tunnel IPsec ?

Les tunnels IPsec se mettent en place en deux grandes étapes :

Phase 1 – IKE (Internet Key Exchange)

Les deux extrémités (pair A et pair B) négocient d’abord une association de sécurité IKE SA.
Elles s’authentifient mutuellement (certificat, clé pré-partagée, etc.) et conviennent des paramètres de chiffrement (algorithme, mode DH, durée de vie des clés).
À l’issue, un canal chiffré et authentifié est établi pour protéger les échanges de la phase 2.

Phase 2 – IPsec SA

Dans ce canal sécurisé, les pairs négocient plusieurs Security Associations secondaires (appelées Child SA), qui définiront le chiffrement et l’intégrité du trafic utilisateur.
Elles conviennent des sous-réseaux à protéger, des ports et protocoles autorisés, puis génèrent les clés de session IPsec.
Une fois la Child SA montée, le tunnel est opérationnel : tout paquet envoyé vers le sous-réseau distant est chiffré et encapsulé dans IPsec.

Qu’est-ce qu’une passerelle VPN Azure ?

Une passerelle VPN Azure (Azure VPN Gateway) agit comme un point de terminaison chiffré permettant d’établir des tunnels IPsec/IKE entre votre réseau on-premises (ou vos clients VPN individuels) et vos réseaux virtuels Azure.

Elle prend en charge plusieurs scénarios :

Site-à-Site (connexion permanente entre votre datacenter et Azure)
Point-à-Site (accès distant des utilisateurs)
VNet-à-VNet (liaison sécurisée entre réseaux virtuels)

Quels sont les SKUs disponibles pour les passerelles VPN Azure ?

Les passerelles VPN Azure se déclinent en versions classiques et zone-redondantes :

Génération	SKU	Tunnels S2S/VNet-to-VNet	Connexions P2S (IKEv2/OpenVPN)	Débit agrégé	BGP supporté	Zone-redondant
Gen 1	Basic	Max. 10	Non supporté	100 Mbps	Non	Non
	VpnGw1	Max. 30	Max. 250	650 Mbps	Oui	Non
	VpnGw2	Max. 30	Max. 500	1 Gbps	Oui	Non
	VpnGw3	Max. 30	Max. 1000	1,25 Gbps	Oui	Non
	VpnGw1AZ	Max. 30	Max. 250	650 Mbps	Oui	Oui
	VpnGw2AZ	Max. 30	Max. 500	1 Gbps	Oui	Oui
	VpnGw3AZ	Max. 30	Max. 1000	1,25 Gbps	Oui	Oui
Gen 2	VpnGw2	Max. 30	Max. 500	1,25 Gbps	Oui	Non
	VpnGw3	Max. 30	Max. 1000	2,5 Gbps	Oui	Non
	VpnGw4	Max. 100*	Max. 5000	5 Gbps	Oui	Non
	VpnGw5	Max. 100*	Max. 10000	10 Gbps	Oui	Non
	VpnGw2AZ	Max. 30	Max. 500	1,25 Gbps	Oui	Oui
	VpnGw3AZ	Max. 30	Max. 1000	2,5 Gbps	Oui	Oui
	VpnGw4AZ	Max. 100*	Max. 5000	5 Gbps	Oui	Oui
	VpnGw5AZ	Max. 100*	Max. 10000	10 Gbps	Oui	Oui

Combien coûte les passerelles VPN Azure ?

Le prix de la passerelle VPN dépend du SKU choisi. Voici quelques tarifs :

SKU	Prix mensuel estimé (€)
Basic	22,95 €
VpnGw1	121,11 €
VpnGw2	312,33 €
VpnGw3	796,77 €
VpnGw4	1 338,57 €
VpnGw5	2 326,56 €

Attention : ces prix correspondent uniquement au coût de compute de la passerelle (744 heures d’utilisation par mois) et n’incluent pas les frais de transfert de données sortantes.

L’ancien VPN de type basique présente un tarif particulièrement attractif :

Le 2ème service le moins cher est maintenant le SKU VpnGw1, mais le prix est plus élevé :

En comparaison, le service OPNsense déployé via une VM affiche un coût un plus faible :

Voici également le tarif appliqué pour le VPN OPNsense pour un engagement d’un an sur la machine virtuelle :

Qu’est-ce que la passerelle VPN OPNsense sur Azure ?

OPNsense VPN est la solution de création de tunnels sécurisés intégrée à OPNsense, un pare-feu/routeur open-source basé sur FreeBSD. Elle prend en charge plusieurs protocoles majeurs :

IPsec : idéal pour les liaisons site-à-site ou les connexions distantes, avec négociation IKEv1/IKEv2, clés pré-partagées ou certificats, et prise en charge de BGP pour le routage dynamique.
OpenVPN : pour les accès distants sur TCP ou UDP, avec authentification par utilisateur, certificats ou serveur RADIUS, et options de chiffrement AES-GCM.
WireGuard : un protocole moderne, léger et performant, offrant des temps de mise en place réduits et une empreinte cryptographique simplifiée.

Peut-on déployer la passerelle VPN OPNsense sur Azure ?

Oui, il est tout à fait possible de déployer OPNsense dans Azure en tant que machine virtuelle. Afin de voir si cela marche vraiment, voici les différentes étapes que nous allons suivre sur un environnement de test :

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 tenant Microsoft
Une souscription Azure valide

Pour tester mon environnement, j’ai également provisionné les deux machines virtuelles suivantes pour simuler des ressources opposées :

J’y ai également mis en place une passerelle Bastion :

Enfin, j’ai également déployé une passerelle VPN Azure pour tester le tunnel :

Commençons par créer une nouvelle machine virtuelle Azure contenant la passerelle VPN OPNsense.

Etape I – Préparation de la machine virtuelle OPNsense :

Pour cela, cliquez sur le lien GitHub suivant pour déployer le template ARM sur votre environnement Azure : https://github.com/dmauser/opnazure

Sélectionnez ensuite le scénario OPNsense souhaité et renseignez les informations de base, puis cliquez sur Suivant :

Conservez ou ajustez la taille de la VM, puis validez en cliquant Suivant :

Constatez la présence de deux sous-réseaux, Trusted et Untrusted, puis lancez la validation Azure :

Une fois la validation réussie, le déploiement des ressources démarre automatiquement :

Patientez quelques minutes, puis cliquez ici pour accéder aux ressources créées :

Copiez les adresses IP privées et publiques de la VM OPNsense :

Modifiez la règle de pare-feu pour autoriser l’accès HTTPS à la VM :

Vérifiez la présence du sous-réseau Trusted, puis copiez son plan d’adressage :

Connectons-nous maintenant à notre console d’administration OPNsense pour avancer sur la configuration de notre tunnel.

Etape II – Configuration d’OPNsense :

Ouvrez votre navigateur, collez-y l’IP publique de la VM OPNsense, renseignez les identifiants ci-dessous, puis cliquez sur Login :

Login : root
Mot de passe : opnsense

Changez immédiatement le mot de passe pour des raisons de sécurité :

Commencez par créer une clé partagée destinée au handshake IPsec :

Dans la section VPN IPsec, cliquez-ici pour créer une nouvelle connexion et choisissez vos propositions de chiffrement :

Renseignez les champs requis : l’IP locale de la VM OPNsense et l’adresse IP publique de la passerelle VPN Azure :

Ajoutez une authentification locale en réutilisant la clé partagée, puis enregistrez :

Répétez l’opération pour l’authentification distante, puis sauvegardez :

Éditez ensuite la section Child en renseignant les plans d’adressage respectifs, puis cliquez sur Enregistrer :

Cliquez sur Sauvegarder :

Enfin, cliquez sur Appliquer pour finaliser la configuration IPsec :

Dans la section pare-feu, constatez la règle sortante déjà préconfigurée :

Créez une nouvelle règle entrante pour autoriser l’accès depuis la passerelle VPN Azure :

Activez cette nouvelle règle pare-feu :

Sur le pare-feu OPNsense, ajoutez les règles nécessaires pour établir la liaison IPsec dans la section WAN :

La configuration OPNsense est maintenant terminée. La prochaine étape consiste à configurer la passerelle VPN Azure pour se connecter à la première.

Etape III – Configuration de la passerelle VPN Azure :

Copiez l’adresse IP publique de la passerelle VPN Azure :

Dans le Network Security Group de votre VM OPNsense, créez une règle pour autoriser l’IP de la passerelle VPN Azure :

Créez une Local Network Gateway en renseignant l’IP publique de votre passerelle VPN OPNsense et le plan d’adressage du sous-réseau Trusted :

Établissez ensuite la connexion VPN Azure pour finaliser l’interconnexion entre les deux passerelles :

Collez la clé d’authentification, puis enregistrez la configuration de la connexion :

Associez également une table de routage au sous-réseau Trusted, en y incluant le préfixe 0.0.0.0/0 afin de diriger tout le trafic via la VM OPNsense :

Tout est maintenant en place pour le test de connectivité entre nos deux machines virtuelles.

Etape IV – Test de la connexion VPN :

Retournez dans le menu des connexions IPsec OPNsense, puis cliquez ici pour démarrer la connexion IPsec côté OPNsense :

Attendez quelques secondes jusqu’à l’apparition de la Phase 2 de la connexion IPsec :

Une fois la Phase 2 affichée, cliquez ici pour visualiser le journal contenant les événements IPsec :

Constatez l’apparition des différents états de la connexion entre les deux passerelles VPN :

Vérifiez l’apparition de Security Associations dans la base de données IPsec :

Vérifiez l’apparition de Security Policies dans la base de données IPsec :

Retournez sur le portail Azure et observez le changement de statut de la connexion VPN Azure :

Démarrez les deux machines virtuelles de test pour valider la liaison :

Sur les deux VM de test, désactivez temporairement la règle de pare-feu ICMP suivante pour autoriser le ping :

Effectuez des tests de ping réciproques entre les deux machines virtuelles :

Interrompez la connexion depuis OPNsense :

Constatez la disparition de la Phase 2 dans la console OPNsense :

Vérifiez également l’échec du ping entre les deux VM :

Relancez la connexion IPsec depuis OPNsense et observez la réapparition de la Phase 2 :

Confirmez la reprise du ping sur les deux machines virtuelles de test :

Conclusion

Si Azure VPN Gateway reste la solution de référence pour une interconnexion cloud sécurisée et redondante, l’utilisation d’une VM OPNsense sur Azure offre une alternative open source particulièrement adaptée aux petits projets ou aux environnements où vous souhaitez tirer parti de vos compétences réseau existantes.

Vous gagnez en flexibilité de configuration, en contrôle détaillé des politiques VPN et en possibilité d’étendre facilement vers d’autres protocoles (OpenVPN, WireGuard).

Cette approche hybride combine la robustesse du cloud Azure et la puissance d’OPNsense pour bâtir un VPN sur mesure parfaitement aligné avec vos besoins.

Créez un coffre géré par Veeam dans Azure

Depuis déjà plusieurs années, l’augmentation croissante des menaces, qu’il s’agisse de rançongiciels, de pannes matérielles ou d’erreurs humaines, impose de repenser ses stratégies de sauvegarde dans le cloud. Plutôt que de gérer soi-même un compte de stockage Azure, Veeam Data Cloud Vault se présente comme un coffre 100 % managé, conçu pour simplifier et fiabiliser vos sauvegardes tout en respectant la règle 3-2-1-1-0.

Un premier article parlant de la sauvegarde des données 365 via la solution Veeam Data Cloud SaaS Backup est disponible juste ici.

Dans cet article, je vous guide pas à pas pour déployer votre coffre Veeam depuis Azure Marketplace, l’intégrer à Veeam Backup & Replication et tirer pleinement parti de ses fonctionnalités avancées.

Qu’est-ce que le concept 3-2-1 pour les sauvegardes ?

Le concept de la règle 3-2-1 a été formalisé par le photographe numérique Peter Krogh, et publié pour la première fois en 2005 dans son ouvrage The DAM Book: Digital Asset Management for Photographers

Il s’agit d’une règle simple et éprouvée pour garantir la sécurité et la résilience de vos sauvegardes :

3 copies des données

1 copie « live » : vos données actives sur le système de production
2 copies de sauvegarde : répliquées ailleurs, pour pouvoir restaurer en cas de défaillance ou de corruption

2 types de supports différents

Par exemple :
- Un disque dur interne ou réseau (NAS)
- Un autre support : bande LTO, SSD externe, ou stockage objet cloud
L’idée est de réduire le risque de défaillance matérielle simultanée : un même lot de disques peut tomber en panne, mais un disque dur + une bande ou un système cloud présentent des modes de panne différents.

1 copie hors site

Pour vous prémunir contre :
- Vol, incendie ou inondation de votre site principal
- Corruption logicielle ou rançongiciel (ransomware) qui toucherait tout votre réseau
Cette copie peut être :
- Hébergée dans un cloud public (Azure Blob Storage, Amazon S3, etc.)
- Stockée physiquement dans un autre bureau ou un coffre-fort externe
- Répliquée chez un prestataire spécialisé

Et pourquoi parle-t-on maintenant de 3-2-1-1-0 ?

Le concept 3-2-1-1-0 est une évolution de la règle 3-2-1, pensée pour les menaces modernes (ransomware, erreurs de sauvegarde, etc.). Il rajoute ainsi :

1 copie hors ligne ou immuable (air-gapped/immutable).
Cette copie n’est pas connectée au réseau (ou est protégée en écriture seule), de manière à rester intacte même en cas de ransomware ciblant vos systèmes connectés.

0 erreur de sauvegarde.
Il faut vérifier régulièrement que chaque sauvegarde se termine sans erreur, et tester la restauration pour garantir l’intégrité et la disponibilité de vos données en cas de besoin.

Qu’est-ce que Veeam Data Cloud vault ?

Veeam Data Cloud Vault est un service de stockage cloud sécurisé, pré-configuré et entièrement géré par Veeam sur l’infrastructure Microsoft Azure. Voici une courte vidéo qui vous montre ce service :

Pourquoi passer par Veeam Data Cloud Vault à la place de créer directement un compte de stockage Azure ?

La configuration faite directement par Veeam est le premier avantage à passer par le service Veeam Data Cloud Vault : vous indiquez simplement votre volume de données à sauvegarder, et tout est provisionné sans aucun paramétrage Azure de votre part.

Voici ce que Veeam fait automatiquement pour vous :

Immutabilité et isolation « Zero Trust » intégrées
Veeam Data Cloud Vault repose sur des mécanismes d’immutabilité natifs : chaque objet écrit devient en lecture seule pour la durée configurée, empêchant toute suppression ou modification accidentelle ou malveillante (ransomware). Cette couche d’isolation logique (air-gapped, c’est-à-dire isolée du réseau) est activée par défaut et n’existe pas automatiquement sur un compte de stockage classique sans configuration manuelle

Sécurité et chiffrement bout en bout
Les transferts entre Veeam Backup & Replication et le Vault se font sur des canaux chiffrés via un certificat mutualisé, sans jamais exposer de clés ou de tokens. De plus, toutes les données sont stockées chiffrées au repos, sans configuration supplémentaire. Un compte de stockage classique exige la mise en place manuelle du chiffrement (Azure Storage Service Encryption) et la gestion des clés (Key Vault)

Conformité à la stratégie 3-2-1-1-0
Le Vault répond directement aux exigences :

1 copie hors site : vos backups sont sur l’infrastructure Veeam dans Azure.
1 copie immuable/air-gapped : garantie par la politique d’immutabilité native.
0 erreur : Veeam supervise automatiquement la réussite de chaque sauvegarde et vous alerte en cas de problème.

Un compte de stockage classique n’offre pas cette orchestration automatisée autour de la vérification d’intégrité et de l’immutabilité.

Combien coûte Veeam Data Cloud Vault ?

La partie des coûts proposée par Veeam s’avère intéressante. Contrairement au modèle « pay-as-you-go » (à l’usage) habituellement appliqué à un compte de stockage Azure, Veeam Data Cloud Vault propose un tarif forfaitaire par To incluant le stockage, les appels API, l’egress et les restaurations : plus de risque de « bill shock » lié aux opérations ou au trafic.

Deux SKUs sont proposés par Veeam : Foundation et Advanced :

Foundation débute à 14 USD / To / mois (facturé annuellement).
Advanced est à 24 USD / TB / mois, mais inclut un nombre illimité d’opérations de lecture/restauration.

On peut différencier ces deux offres de la façon suivante :

Granularité de l’emplacement
- Foundation vous permet de choisir le pays où vos données seront stockées, Veeam/Microsoft sélectionnant ensuite la région exacte.
- Advanced vous donne la main sur la région Azure précise (par exemple « West Europe » vs « North Europe ») pour optimiser latence, conformité ou réplication inter-zones.
Durabilité
- Foundation s’appuie sur LRS (Locally Redundant Storage), garantissant « 11 nines » de durabilité (99,999999999 %).
- Advanced utilise ZRS (Zone-Redundant Storage), offrant « 12 nines » (99,9999999999 %) en répartissant les données sur plusieurs zones de disponibilité.
Limites de lecture/restauration
- Foundation applique une politique de fair use sur les appels de lecture et les restaurations.
- Advanced propose des lectures et restaurations illimitées sans restrictions supplémentaires.

Qu’est-ce que contient le Fair Use de Veeam ?

La politique Fair Use de Veeam Data Cloud Vault définit une franchise gratuite d’opérations de lecture/restauration incluse dans votre abonnement, afin d’assurer une utilisation raisonnable et équitable des ressources :

Foundation Edition :
Restauration ou récupération de données jusqu’à 20 % de la capacité totale souscrite sur une période d’un an, sans surcoût.
Advanced Edition :
Restauration ou récupération de données jusqu’à 100 % de votre capacité activement consommée chaque année, sans surcoût.

Au-delà de ces seuils, les opérations de lecture, de récupération et l’egress sont facturés aux tarifs standards Microsoft applicables à la région concernée.

Quelles régions Azure supportent Veeam Data Cloud Vault ?

Voici les régions Azure prises en charge par Veeam Data Cloud Vault :

Comment tester Veeam Data Cloud Vault ?

De nombreuses vidéos sont déjà disponibles sur la chaîne YouTube de Veeam :

Voici les différentes étapes que nous allons suivre afin de tester la solution Veeam Data Cloud Vault sur un environnement de test :

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

Etape 0 – Rappel des prérequis :

Afin de réaliser nos tests sur Veeam Data Cloud Vault, nous allons avoir besoin de :

Un tenant Microsoft actif
Une souscription Azure valide

Commençons par déployer la solution depuis Azure Marketplace.

Etape I – Déploiement de Veeam Data Cloud Vault :

Depuis le portail Azure, recherchez Veeam Data Cloud Vault :

Déployez la solution SaaS dans la souscription, le groupe de ressources et la nom de votre ressource :

Ouvrez la liste des plans disponibles :

Changez votre plan si nécessaire :

Lancez la validation Azure :

Une fois la validation réussie, lancez la création de la solution :

Attendez quelques minutes le temps de la configuration de Veeam Data Cloud Vault :

Une fois la configuration terminée, cliquez sur le bouton de finalisation :

Vérifiez les informations affichées, puis cliquez-ici pour activer la souscription. Selon ma compréhension, l’activation de celle-ci déclenche la facturation sur votre souscription Azure. Vous disposez alors de 72 heures pour vous rétracter une fois celle-ci activée :

Une fois la souscription Veeam activée, cliquez-ici pour basculer sur la console de gestion Veeam Data Cloud Vault :

Choisissez une authentification via Entra ID :

Veeam vous propose de créer votre premier coffre, vérifiez les informations puis cliquez sur Suivant :

Etant parti sur le plan Foundation, choisissez le Pays et non la région Azure, puis cliquez sur Suivant :

Attendez quelques minutes le temps du provisionnement et de la configuration des ressources gérées par Veeam :

Quelques minutes plus tard, le coffre Veeam est créé, copiez les informations suivantes afin de configurer votre application Veeam Backup :

Cliquez sur Suivant afin de terminer la configuration :

La fin de la configuration vous transporte sur le tableau de bord de Veeam Data Cloud Vault :

Du côté d’Azure, vous pouvez constater la ressource SaaS dans le groupe de ressources ; cliquez dessus pour retrouver le détail de la solution :

Un clic sur le lien de cette solution vous permet d’ouvrir l’URL d’accueil de Veeam Data Cloud Vault :

Un autre clic sur le lien ci-dessous vous ouvre votre propre instance de Veeam Data Cloud Vault :

Consultez ou créez au besoin vos coffres sur cette page :

Visualisez les souscriptions Azure sur cet écran :

Le volume de stockage est visible depuis ce même portail après un rafraîchissement de l’information :

L’information est visible sur ce portail après une ou plusieurs heures :

Les informations du volume total de stockage sont alors actualisées sur le tableau de bord principal :

Notre solution Veeam Data Cloud Vault est maintenant configurée et prête à recevoir des données. La prochaine étape consiste à configurer cette dernière depuis un outil de sauvegarde, comme Veeam Backup & Replication.

Etape II – Ajout d’un coffre Veeam :

J’ai créé une machine virtuelle depuis le Marketplace Azure la solution Veeam Backup & Replication pour réaliser les tests.

Une fois la console de gestion de Veeam Backup & Replication ouverte, ouvrez la configuration de l’infrastructure de sauvegarde :

Cliquez sur le type Veeam Data Cloud Vault :

Nommez celui-ci, cochez la case, puis cliquez sur Suivant :

Cliquez sur Ajouter, puis choisissez la connexion avec la clef du coffre :

Collez les informations précédemment copiées du coffre Veeam, puis cliquez sur OK :

Cliquez sur Suivant :

Renseignez un nouveau dossier créé sur le coffre, puis cliquez sur Suivant :

Définissez les informations du stockage local pour les restaurations rapides, puis cliquez sur Suivant :

Cliquez sur Appliquer :

Attendez quelques secondes la mise en place de la configuration, puis cliquez sur Suivant :

Une fois la configuration réussie, cliquez sur Terminer :

Constatez l’apparition du coffre dans la liste des répertoires de Sauvegarde :

Notre coffre Veeam est maintenant un répertoire de sauvegarde. Nous allons maintenant modifier une première police consacrée à la sauvegarde d’un partage de fichiers.

Etape III – Sauvegarde d’un partage de fichier sur le coffre Veeam :

Pour cela, retournez dans les travaux de sauvegarde déjà en place, puis cliquez sur l’un d’entre eux afin de le modifier :

Cochez la case suivante afin de configurer le coffre Veeam comme seconde destination de sauvegarde :

Cliquez sur Avancé :

Cochez la case suivante, configurez un mot de passe, puis cliquez sur OK :

Ajoutez en seconde cible le coffre Veeam, puis cliquez termine la modification de la police de sauvegarde :

Constatez l’apparition d’un second travail de sauvegarde, dont le déclenchement dépendra du premier auquel il est rattaché :

Lancez le premier travail de sauvegarde afin de tester le bon fonctionnement :

Une fois le premier travail de sauvegarde terminé, constatez le démarrage automatique du second travail de sauvegarde dédié au coffre Veeam :

Constatez l’apparition de sauvegarde du partage de fichiers et du nombre de points de restauration disponibles :

Retournez sur les répertoires de sauvegarde afin de visualiser la consommation d’espace sur votre coffre Veeam :

Testons maintenant la même approche de réplication de sauvegarde pour un stockage objet.

Etape IV – Sauvegarde d’objets sur le coffre Veeam :

Retournez à nouveau dans les travaux de sauvegarde objet déjà en place, puis cliquez sur l’un d’entre eux afin d’ajouter comme seconde destination de sauvegarde le coffre Veeam.

Cliquez sur Avancé :

Cochez la case suivante, configurez un mot de passe, puis cliquez sur OK :

Ajoutez en seconde cible le coffre Veeam, puis cliquez termine la modification de la police de sauvegarde :

Constatez l’apparition d’un second travail de sauvegarde, dont le déclenchement dépendra du premier auquel il est rattaché :

Lancez le premier travail de sauvegarde afin de tester le bon fonctionnement, puis constatez l’apparition de sauvegardes de fichiers objets :

Retournez sur les répertoire de sauvegarde afin de visualiser l’augmentation de la consommation d’espace sur votre coffre Veeam :

Terminons notre test par la restauration d’un fichier objet supprimé dans un conteneur Azure, dont la sauvegarde est répliquée sur le coffre Veeam.

Etape V – Restauration d’un fichier objet :

Supprimez un fichier sur un stockage objet :

Depuis Veeam Backup & Replication, retournez sur les points de sauvegarde associés au coffre Veeam, puis lancez la restauration d’un fichier objet :

Attendez quelques secondes le chargement des points restauration disponibles :

Cliquez sur le fichier supprimé à restaurer, puis déclenchez la restauration par écrasement :

Attendez quelques secondes le déclenchement du travail de restauration :

Attendez quelques minutes la fin du travail de restauration :

Constatez la réapparition du fichier sur le stockage objet :

Conclusion

En adoptant Veeam Data Cloud Vault sur Azure, vous déléguez la complexité opérationnelle et garantissez une protection de vos données conforme à la règle 3-2-1-1-0 :

Déploiement en un clic : plus besoin de scripts ni d’ARM templates.
Sécurité renforcée : immutabilité native et chiffrement bout-en-bout activés par défaut.
Surveillance proactive : Veeam supervise vos jobs et vous alerte immédiatement en cas d’anomalie.
Prévisibilité budgétaire : un tarif fixe par To incluant toutes les opérations et l’egress, sans surprises.

Que vous choisissiez l’édition Foundation ou Advanced, Veeam vous offre une solution SaaS prête à l’emploi, alliant performance, sécurité et tranquillité d’esprit 😎

Enfin Veeam propose même un vidéo de la configuration en mode démo :

Faites du NAT avec Azure VPN

Dans un contexte où la migration vers le cloud s’accompagne souvent de contraintes d’adressage et de sécurité, le NAT peut être vu comme une solution pouvant résoudre les problématiques de chevauchement d’adresses et de confidentialité. Vraiment ?

Attention ! Recourir au NAT pour masquer des conflits d’adresses n’est pas toujours une approche saine à long terme, car cela peut introduire une complexité opérationnelle accrue et des difficultés de maintenance ; il doit donc être considéré comme une solution transitoire ou de contournement.

Qu’est-ce que le NAT ?

Le NAT ( ou Network Address Translation) est un mécanisme qui permet de faire correspondre des adresses IP privées (non routables sur Internet) à une ou plusieurs adresses IP publiques (routables). Il joue un rôle clé dans la conservation des adresses IPv4 et dans la sécurisation des réseaux privés.

Voici une courte vidéo qui explique le principe du NAT afin de pallier le souci d’adresses IPv4 pour Internet :

Comment fonctionne le NAT ?

Lorsqu’une machine interne (par exemple 10.0.0.1) envoie une requête vers Internet (par exemple 200.100.10.1), le routeur NAT remplace son adresse source privée par une adresse publique (par exemple 150.150.0.1), et stocke dans sa table de traduction la corrélation :

Le routage du trafic impacte alors le traffic de données dans les deux sens :

Sortant : le paquet quitte le réseau interne avec l’adresse publique.
Entrant : la réponse revient à l’adresse publique, le routeur NAT consulte sa table et renvoie le paquet à la machine interne d’origine.

Quels sont ses avantages et ses limites au NAT ?

Avantages

Économie d’adresses IPv4
Masquage du réseau interne (sécurité renforcée)
Contrôle centralisé du trafic sortant/entrant

Limites

Complexité de dépannage (tables de traduction)
Certains protocoles (FTP actif, SIP, etc.) nécessitent des algorithmes NAT-aware ou des « NAT helpers »
Impact potentiel sur la latence et le débit

SNAT vs DNAT ?

En pratique, le NAT (Network Address Translation) se décline en deux grands modes :

Mode	Abréviation	Fonction principale	Exemple d’usage
Source NAT	SNAT (Source NAT)	Modifier l’adresse source et/ou le port d’une connexion sortante	Votre VM privée (10.0.0.5) → Internet apparaît avec l’IP publique du NAT Gateway
Destination NAT	DNAT (Destination NAT)	Modifier l’adresse de destination et/ou le port d’une connexion entrante	Internet (51.210.34.12:80) → redirigé vers votre VM privée (10.0.0.5:8080)

Règles de NAT sortantes : permettent de présenter votre réseau virtuel Azure à vos sites distants avec un plan d’adressage spécifique.
Règles de NAT entrantes : permettent à vos sites distants d’accéder au réseau virtuel Azure en utilisant un plan d’adressage différent.

Et le NAT dans Azure c’est possible ?

Un premier service, appelé Azure NAT Gateway, est conçu pour offrir un moyen simple, fiable et évolutif de gérer le trafic sortant depuis vos réseaux virtuels vers Internet ou d’autres services Azure, sans exposer vos machines virtuelles (VM) directement avec des adresses IP publiques :

Une passerelle NAT Azure est un service de traduction d’adresses réseau entièrement managé et hautement résilient. Vous pouvez utiliser Azure NAT Gateway pour autoriser toutes les instances d’un sous-réseau privé à se connecter à Internet, tout en restant entièrement privées. Les connexions entrantes non sollicitées depuis Internet ne sont pas autorisées via une passerelle NAT. Seuls les paquets arrivant en tant que paquets de réponse à une connexion sortante peuvent passer via une passerelle NAT.

Microsoft Learn

Quels services Azure proposent du NAT ?

Oui, plusieurs services Azure permettant de faire du NAT entre votre réseau Azure et votre infrastructure on-premise :

Peut-on donc avoir un chevauchement d’adresses entre le LAN et un réseau virtuel Azure ?

La réponse est oui :

Les organisations utilisent fréquemment des adresses IP privées définies dans le document RFC1918 pour la communication interne dans leurs réseaux privés. Quand ces réseaux sont connectés à l’aide d’un VPN via Internet ou à l’aide d’un WAN privé, les espaces d’adressage ne doivent pas se chevaucher.

Si c’est le cas, la communication échoue. Pour connecter deux réseaux ou plus avec des adresses IP qui se chevauchent, le NAT est déployé sur les appareils de passerelle qui connectent les réseaux.

Microsoft Learn

Voici un exemple d’architecture entre plusieurs sites appliquant différentes règles NAT :

Attention, Microsoft liste ici les contraintes pour la fonctionnalité NAT d’Azure VPN Gateway :

NAT est pris en charge sur les références (SKU) suivantes : VpnGw2~5, VpnGw2AZ~5AZ.
NAT est pris en charge pour les connexions intersites IPsec/IKE uniquement. Les connexions de réseau virtuel à réseau virtuel et les connexions P2S (point à site) ne sont pas prises en charge.
Les règles NAT ne sont pas prises en charge sur des connexions pour lesquelles l’option Utiliser des sélecteurs de trafic basés sur des stratégies est activée.
La taille maximale du sous-réseau de mappage externe prise en charge pour le NAT dynamique est /26.
Les mappages de ports ne peuvent être configurés qu’avec des types NAT statiques. Les scénarios NAT dynamiques ne s’appliquent pas aux mappages de ports.
Les mappages de ports ne peuvent pas prendre de plages pour l’instant. Un port individuel doit être entré.
Les mappages de ports peuvent servir pour les protocoles TCP et UDP.

Et en pratique ?

Pour valider la fonctionnalité de NAT au sein de mon architecture Azure, j’ai mis en place un petit exercice de démonstration. Mon environnement se compose de deux réseaux distincts :

Le premier simulant un réseau on-premise
Le second correspondant à un réseau virtuel Azure

Le schéma ci-dessous présente ces deux réseaux créés dans mon environnement Azure :

Dans le portail Azure, j’ai donc créé deux réseaux virtuels configurés sur la même plage d’adressage (10.0.0.0/16) pour illustrer un cas de chevauchement :

Sur chaque réseau virtuel, j’ai provisionné une machine virtuelle, toutes les deux en 10.0.0.4 pour renforcer l’idée d’adressage complètement identique :

Pour établir la connectivité, j’ai déployé deux VPN Gateway de type VpnGw2, configurées en tunnel IPsec site à site entre elles :

J’ai commencé par ajouter des règles NAT sur la passerelle Azure :

Egress rules –> pour présenter votre réseau virtuel Azure avec un adressage translaté à votre réseau on-premise :
- adresses internes : l’adressage IP configuré sur votre réseau virtuel Azure
- adresses externes = l’adressage IP translaté vu par votre réseau on-premise
Ingress rules –> pour accéder à votre réseau on-premise avec des IP différentes de celles configurées :
- adresses internes = l’adressage IP configuré sur votre réseau on-premise
- adresses externes = l’adressage IP translaté vu par votre réseau virtuel Azure

J’ai répliqué la même logique avec une configuration opposée sur la passerelle VPN simulant celle de mon réseau on-premise :

Egress rules –> pour présenter ton réseau on-premise avec un adressage translaté à ton réseau virtuel Azure :
- adresses internes : l’adressage IP configuré sur ton réseau on-premise
- adresses externes = l’adressage IP translaté vu par ton réseau virtuel Azure
Ingress rules –> pour accéder à ton réseau virtuel Azure avec des IP différentes de celles configurées :
- adresses internes = l’adressage IP configuré sur ton réseau virtuel Azure
- adresses externes = l’adressage IP translaté vu par ton réseau on-premise

Enfin, j’ai créé deux passerelle de réseau local correspondant à chaque extrémité :

L’une pour présenter le réseau on-premise à la passerelle Azure
L’autre pour présenter le réseau Azure la passerelle on-premise

La première passerelle de réseau local contient l’IP publique de la passerelle VPN Azure et la plage d’adresses 10.0.0.0/16 :

La seconde passerelle de réseau local contient l’IP publique de la passerelle VPN on-premise et la plage d’adresses 10.0.0.0/16 :

J’ai ensuite établi la connexion site-à-site entre mes deux VPN Gateways (VpnGw2) en utilisant la clé pré-partagée définie lors de la création des ressources.

Lors de la configuration de la première connexion, j’ai directement rattaché les règles Ingress NAT et Egress NAT définies précédemment à cette connexion, afin que toute session transitant par le tunnel soit automatiquement traduite.

J’ai reproduit la même configuration sur la seconde connexion : la clé PSK identique, la même plage 10.0.0.0/16 et les règles NAT :

Pour faciliter la connexion de la VM hébergée dans le réseau virtuel Azure, j’ai ajouté le service Azure Bastion :

Une fois Azure Bastion en place, je me suis connecté à la machine virtuelle Azure directement depuis le portail :

Depuis la machine virtuelle Azure, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la VM simulée on-premise :

Depuis le même service Azure Bastion déployé sur le réseau virtuel Azure, j’ai ouvert une session RDP vers la machine virtuelle simulée sur le réseau on-premise en utilisant l’adresse IP externe traduite définie dans les règles NAT de la connexion VPN :

Depuis la VM simulée on-premise, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la machine virtuelle Azure :

Conclusion

Grâce à l’association d’Azure VPN Gateway et de règles SNAT, nous avons validé une communication bidirectionnelle transparente entre deux environnements au plan d’adressage identique, sans exposer d’IP publiques aux VM. Cette démonstration illustre la puissance du NAT dans Azure pour contourner le chevauchement d’adresses

Notez toutefois que s’appuyer durablement sur le NAT peut complexifier votre architecture et alourdir le dépannage ; il est donc recommandé de considérer cette solution comme une étape temporaire, en prévoyant à terme une refonte de votre plan d’adressage pour une architecture plus saine.

Migrez vers Azure sans droits d’infra, c’est possible !

Réussir la migration d’une infrastructure IT nécessite un objectif clair, un plan d’action, des moyens humains et matériels, et …. , du temps devant soi. Mais il arrive que la migration ne soit pas un parcours de santé, mais plutôt jonché de contraintes impactant les stratégies décidés avant. Par exemple, que doit-on faire si la migration de VMs doit se faire finalement sans aucun accès au niveau hyperviseur ?

Différentes approches de migration ?

Lors d’une migration vers le cloud, plusieurs approches coexistent : le « lift-and-shift » (reprise à l’identique), la replatforming ou refactoring (adaptation partielle) et la reconstruction totale accompagnée de modernisation.

Si le lift-and-shift est souvent privilégié pour sa rapidité de mise en œuvre, il n’exploite pas pleinement les services cloud-native et peut engendrer un surcoût opérationnel à long terme.

À l’inverse, la refonte ou la reconstruction des applications, en recourant par exemple aux microservices, au serverless ou aux bases de données managées, permet d’améliorer la scalabilité, la résilience et l’agilité, tout en optimisant les coûts à terme.

Azure Migrate ?

Bien entendu, dans certains scénarios, notamment lorsqu’on fait face à des délais serrés, à des contraintes budgétaires ou à un manque de compétences, il est nécessaire de migrer en priorité les machines virtuelles existantes « telles quelles ».

On opte alors pour un lift-and-shift à l’aide d’outils comme Azure Migrate ou Azure Site Recovery, qui répliquent les VM sans toucher au code ni à l’architecture.

Pour vous donner un peu de matière, un ancien article parlant d’Azure Migrate vous détaille toutes les grandes étapes.

Mais que faire si l’accès à l’hyperviseur est restreint ?

Toutefois, si aucun niveau d’accès la couche hyperviseur n’est possible, la migration vers Azure s’en trouve alors un peu plus compliquée.

Dans le cadre d’Azure Migrate (et plus précisément du service de réplication Azure Site Recovery), on rencontre 2 rôles clés au sein de l’appliance de réplication déployée :

Serveur de traitement :
- Installé par défaut sur le serveur de configuration, il reçoit les données de réplication envoyées par le Mobility Service installé sur vos machines sources.
- Il optimise ces flux en effectuant de la mise en cache, de la compression et du chiffrement, puis les transmet vers votre compte de stockage Azure.
Serveur de cible principale :
- N’est utilisé que lors du failback (reprise sur site) des machines dès lors qu’elles ont été basculées vers Azure.
- Il reçoit alors les données répliquées en provenance d’Azure, reconstitue les disques (VHD/VMDK) et les écrit sur votre infrastructure on-premises pour restaurer les VM sur site.

En synthèse, le Process Server gère l’envoi optimisé des données vers Azure, tandis que le Master Target Server gère la réception et la restauration de ces mêmes données lors d’un retour en local.

En voyant cette excellente vidéo en mode tutoriel, je trouvais intéressant de tester par moi-même ce cas de figure, en partant d’un environnement VMware vers Azure, sans pouvoir utiliser l’accès hyperviseur.

Cet article est donc divisé en 2 démonstrations quasi-identiques :

Test I – Appliance de réplication sur VMware : se déroule dans un environnement où une nouvelle VM est installée sur VMware pour jouer le rôle d’appliance de réplication.
Test II – Appliance de réplication sur Azure : l’appliance de réplication déployée directement sur Azure, car non déployable sur VMware.

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

Etape 0 – Rappel des prérequis :

Afin de réaliser nos 2 tests de migration, nous allons avoir besoin de :

Un tenant Microsoft actif
Une souscription Azure valide
Un environnement hypervisé (Hyper-V ou VMware)

Commençons par effectuer l’exercice de migration en partant du principe que nous pouvons déployer une machine virtuelle jouant le rôle de d’appliance de réplication sur VMware.

Test I – Appliance de réplication VMware :

Sur votre console hyperviseur, créez une machine virtuelle de type Windows Serveur afin d’y installer par la suite notre appliance de réplication :

Connectez-vous à celle-ci avec un compte administrateur local :

Si besoin, installez un navigateur internet récent :

Connectez-vous au portail Azure, puis recherchez le service Azure Migrate :

Cliquez-ici pour commencer un nouveau projet de migration :

Cliquez-ici pour créer le projet de migration :

Renseignez les toutes informations demandées, puis cliquez sur Créer :

Cliquez sur Découvrir afin d’installer l’appliance de réplication :

Renseignez tous les champs, puis cliquez sur Créer les ressources :

Conservez les options suivantes :

Cliquez sur le bouton suivant afin de télécharger l’installeur de l’appliance de réplication :

Cliquez également sur le bouton suivant afin de sauvegarder la clef utilisée par l’appliance de réplication pour s’enrôler au coffre Azure Recovery :

Lancez l’installeur de l’appliance de réplication :

Attendez quelques minutes la fin de la décompression :

Conservez ce choix, puis cliquez sur Suivant :

Acceptez les termes et conditions, puis cliquez sur Suivant :

Rechercher le fichier clef, puis cliquez sur Suivant :

Conservez ce choix, puis cliquez sur Suivant :

Attendez que tous les contrôles soit effectués, puis cliquez sur Suivant :

Définissez un mot de passe pour la base de données MySQL, puis cliquez sur Suivant :

Si cela est votre cas, cochez cette case, puis cliquez sur Suivant :

Cliquez sur Suivant :

Définissez les 2 liaisons réseaux, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez environ 10 minutes la fin de l’installation de l’appliance de réplication :

Cliquez sur Oui :

Collez cette passphrase dans un fichier texte, puis sauvegardez-le :

Une fois l’installation réussie, cliquez sur Terminer :

L’outil de configuration d’Azure Site Recovery s’ouvre automatiquement, ajoutez-le ou les comptes administrateur de vos machines devant être migrées dans le cloud Azure :

Retournez sur le portail Azure, rafraîchissez la page précédente, puis cliquez ici pour finaliser le processus d’enregistrement de l’appliance de réplication :

Attendez le succès de l’opération via la notification suivante :

Constatez la création de ressources dans le groupe de ressources précédemment défini :

Retournez sur l’appliance de réplication, rendez-vous dans le dossier suivant, puis copiez l’exécutable ci-dessous :

C:\ProgramData\ASR\home\svsystems\pushinstallsvc\repository

Créez un dossier partagé réseau sur votre appliance de réplication, puis collez-y l’exécutable précédemment copié ainsi que le fichier texte contenant la passphrase :

Retournez sur la console hyperviseur, puis connectez-vous à la machine virtuelle devant être migrée vers Azure :

Sur cette machine virtuelle à migrer, vérifiez la version de PowerShell installée (min 5.1) grâce à la commande suivante :

$PSversiontable

Toujours depuis votre machine virtuelle à migrer, vérifiez la connexion sur le port 9443 vers votre appliance de réplication :

Toujours depuis votre machine virtuelle à migrer, ouvrez le dossier partagé réseau de votre appliance de réplication de réplication :

Copiez les fichiers dans un nouveau répertoire local sur votre machine virtuelle à migrer :

Ouvrez un éditeur de texte afin de reprendre et préparer les commandes suivantes :

cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted

UnifiedAgent.exe /Role "MS" /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery" /Platform "VmWare" /Silent  /CSType CSLegacy

cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe  /CSEndPoint <CSIP> /PassphraseFilePath <PassphraseFilePath>

Modifiez les valeurs en rouge par l’adresse IP de votre appliance de réplication et le chemin du fichier contenant la passphrase :

Ouvrez l’invite de commande en mode administrateur, puis exécutez les commandes suivantes pour copier le programme d’installation sur le serveur à migrer :

Exécutez cette commande pour installer l’agent :

Exécutez ces commandes pour enregistrer l’agent auprès du serveur de configuration :

Avant de continuer, vérifiez le succès des opérations :

Retournez sur le projet Azure Migrate, puis cliquez sur Rafraîchir afin de voir apparaître la machine virtuelle à migrer :

Cliquez ensuite sur Répliquer :

Renseignez toutes les champs, puis cliquez sur Continuer :

Sélectionnez les informations d’identification à utiliser pour installer à distance le service de mobilité sur les machines à migrer, puis cliquez sur Suivant :

Sélectionner les machines à migrer, puis cliquez sur Suivant :

Sélectionnez les propriétés cibles pour la migration. Les machines migrées seront créées avec les propriétés spécifiées, puis cliquez sur Suivant :

Sélectionnez la taille de la VM Azure pour les machines à migrer, puis cliquez sur Suivant :

Sélectionnez le type de disque à utiliser pour les machines à migrée, puis cliquez sur Suivant :

Lancez la réplication en cliquant sur Répliquer :

Les notifications suivantes apparaissent alors :

Des ressources Azure liées au projet de migration sont alors créées :

Le compte de stockage commence à recevoir les premières données liées à la réplication :

Dans le coffre Recovery, la réplication commence elle-aussi à être visible :

Environ 1 heure plus tard, celle-ci est terminée :

Un clic sur la machine virtuelle à migrer nous affiche le schéma de réplication des données :

Si tout est OK, retournez sur le projet de migration, actualiser si nécessaire afin de pouvoir cliquer sur Migrer :

Définissez la destination cible, puis cliquez sur Continuer :

Cochez la machine virtuelle à migrer, puis cliquez sur Migrer :

La notification suivante apparaît :

Quelques secondes plus tard, celle-ci affiche le succès du déclenchement de la migration :

Cette migration est visible sur notre projet Azure Migrate :

Le coffre Recovery nous indique que la migration est terminée :

Le groupe de ressources Azure contient alors de nouvelles ressources créées lors de la migration :

Afin de pouvoir nous connecter à la machine virtuelle via Azure Bastion, copiez les commandes suivantes depuis la page Azure de votre machine virtuelle migrée :

# 1. Autoriser les connexions RDP
Write-Host "Activation des connexions RDP…" -ForegroundColor Cyan
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
  -Name 'fDenyTSConnections' -Value 0

# 2. Ouvrir le Pare-feu Windows pour RDP
Write-Host "Configuration du Pare-feu pour autoriser RDP…" -ForegroundColor Cyan
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

# 3. Redémarrer le service TSE/RDP
Write-Host "Redémarrage du service TermService…" -ForegroundColor Cyan
Restart-Service -Name 'TermService' -Force

Write-Host "RDP activé et Pare-feu configuré. Vous pouvez maintenant vous connecter." -ForegroundColor Green

Collez ces commandes, puis lancez celles-ci :

Ensuite, connectez-vous à votre machine virtuelle migrée via Azure Bastion :

Constatez l’ouverture de session Windows sur votre machine virtuelle migrée :

La migration de notre machine virtuelle hébergée sur VMware vers Azure s’est déroulée avec succès.

Continuons l’exercice de migration en partant cette fois du principe que nous ne pouvons pas créer une machine virtuelle jouant le rôle d’appliance de réplication sur l’hyperviseur, et que celle-ci doit donc alors être obligatoirement déployée sur Azure.

Test II – Appliance de réplication sur Azure :

Pour cette approche, commencez par créer un réseau virtuel Azure comprenant plusieurs sous-réseaux virtuels :

Un sous-réseau dédié à l’appliance de réplication.
Un sous-réseau dédié à Azure Bastion.
Un sous-réseau dédié à la passerelle VPN, pour connecter notre machine virtuelle à migrer à notre appliance de réplication hébergée sur Azure.

Créez une machine virtuelle ayant pour futur rôle l’appliance de réplication :

Connectez-vous à celle-ci via Azure Bastion :

Afin de connecter par la suite la machine virtuelle à migrer à l’appliance de réplication Azure, via une connexion Point à Site, des certificats sont nécessaires pour l’authentification IKEv2.

Pour cela, depuis l’appliance de réplication Azure, générez et exportez les certificats :

Un certificat racine auto-signé (à exporter en .cer pour Azure)
Un certificat client signé par ce root (à exporter en .pfx pour votre machine cliente)

Sur votre appliance de réplication Azure, ouvrez une fenêtre PowerShell, puis lancez le script suivant pour générer le certificat racine :

$rootCert = New-SelfSignedCertificate `
  -Type Custom `
  -KeySpec Signature `
  -Subject "CN=AzureP2SRootCA" `
  -KeyExportPolicy Exportable `
  -KeyLength 2048 `
  -CertStoreLocation "Cert:\LocalMachine\My" `
  -FriendlyName "Azure P2S Root CA" `
  -NotAfter (Get-Date).AddYears(10) `
  -HashAlgorithm sha256 `
  -KeyUsageProperty Sign `
  -KeyUsage CertSign

Exportez le certificat public au format CER :

Export-Certificate `
  -Cert $rootCert `
  -FilePath "C:\Certs\AzureP2SRootCA.cer"

Ouvrez le gestionnaire des certificats machines afin de constater sa présence :

Créer et exporter le certificat client signé par le certificat root :

$clientCert = New-SelfSignedCertificate `
  -Type Custom `
  -Subject "CN=AzureP2SClientCert" `
  -KeySpec Signature `
  -KeyExportPolicy Exportable `
  -KeyLength 2048 `
  -CertStoreLocation "Cert:\CurrentUser\My" `
  -Signer $rootCert `
  -FriendlyName "Azure P2S Client Cert" `
  -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2") `
  -NotAfter (Get-Date).AddYears(2)

Exportez la clef privée au format PFX :

$pwd = ConvertTo-SecureString -String "VotreMotDePasseComplexe!" -Force -AsPlainText
Export-PfxCertificate `
  -Cert $clientCert `
  -FilePath "C:\Certs\AzureP2SClientCert.pfx" `
  -Password $pwd

Ouvrez le gestionnaire des certificats utilisateurs afin de constater sa présence :

Afin d’enregistrer les données du certificat public dans Azure, exportez ce dernier depuis le gestionnaire des certificats utilisateurs :

Choisissez Non, puis cliquez sur Suivant :

Sélectionnez Format Base-64 encodé X.509 (.CER), puis cliquez sur Suivant :

Indiquez le chemin de sauvegarde, puis cliquez sur Suivant :

Ouvrez le fichier en base-64 avec un éditeur, puis copiez tout le texte (sauf -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----) :

Dans le portail Azure, rendez-vous sur la page de votre passerelle VPN, puis démarrez la configuration Point à Site :

Définissez un espace d’adressage, le type de tunnel en IKEv2, collez le texte en Base-64 que vous venez de copier dans Données du certificat racine, puis cliquez sur Enregistrer.

Après quelques instants, constatez la notification Azure suivante :

Télécharger le client VPN afin de configurer plus tard le client VPN Windows natif sur la machine virtuelle à migrer :

Toujours sur appliance de réplication Azure, recherchez le service Azure Migrate :

Cliquez-ici pour commencer un projet de migration :

Cliquez-ici pour créer un projet de migration :

Renseignez toutes les informations demandées, puis cliquez sur Créer :

Cliquez sur Découvrir afin d’installer l’appliance de réplication :

Renseignez tous les champs, puis cliquez sur Créer les ressources :

Conservez les options suivantes :

Cliquez sur le bouton suivant afin de télécharger l’installeur de l’appliance de réplication :

Cliquez également sur le bouton suivant afin de sauvegarder la clef utilisée par l’appliance de réplication pour s’enrôler au coffre Azure Recovery :

Une fois téléchargé, lancez l’installeur :

Attendez quelques minutes la fin de la décompression :

Conservez ce choix, puis cliquez sur Suivant :

Acceptez les termes et conditions, puis cliquez sur Suivant :

Rechercher le fichier clef, puis cliquez sur Suivant :

Conservez ce choix, puis cliquez sur Suivant :

Attendez que les contrôles soit effectués, puis cliquez sur Suivant :

Définissez un mot de passe pour la base de données MySQL, puis cliquez sur Suivant :

Si cela n’est pas votre cas, cochez cette case, puis cliquez sur Suivant :

Cliquez sur Suivant :

Définissez les 2 liaisons réseaux, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez environ 10 minutes la fin de l’installation :

Cliquez sur Oui :

Collez cette passphrase dans un fichier texte, puis sauvegardez-le :

Une fois l’installation réussie, cliquez sur Terminer :

L’outil de configuration d’Azure Site Recovery s’ouvre automatiquement, ajoutez-le ou les comptes administrateur des machines devant être migrées dans le cloud Azure :

Retournez sur le portail Azure, rafraîchissez la page précédente, puis cliquez ici pour finaliser le processus d’enregistrement de l’application de réplication :

Attendez le succès de l’opération avec la notification suivante :

Constatez la création de nouvelles ressources dans le groupe de ressources précédemment défini :

Retournez sur l’appliance de réplication, rendez-vous dans le dossier suivant, puis copiez seulement l’exécutable ci-dessous :

C:\ProgramData\ASR\home\svsystems\pushinstallsvc\repository

Créez un dossier partagé réseau sur votre appliance de réplication, puis collez-y :

L’exécutable précédemment copié
Le fichier texte contenant la passphrase

Rendez-vous sur la console hyperviseur, puis connectez-vous à la machine virtuelle devant être migrée sur Azure :

Sur cette machine virtuelle, vérifiez la version de PowerShell installée (min 5.1) grâce à la commande suivante :

Installez le certificat root dans le magasin Trusted Root Certification Authorities du gestionnaire des certificats machines :

Installez le certificat client dans le magasin Personal du certificats utilisateurs :

Installez la configuration VPN Windows précédemment téléchargée depuis la page Azure de la passerelle VPN :

Lancez la connexion VPN :

Cliquez sur Connecter :

Vérifiez le statut de la connexion VPN :

Depuis votre machine virtuelle à migrer, vérifiez la connexion sur le port 9443 vers votre appliance de réplication Azure :

Toujours depuis cette VM à migrer, ouvrez le dossier partagé réseau de votre appliance de réplication de réplication :

Copiez les fichiers dans un nouveau répertoire local sur votre machine virtuelle à migrer :

Ouvrez un éditeur de texte afin de reprendre et préparer les commandes suivantes :

cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted

UnifiedAgent.exe /Role "MS" /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery" /Platform "VmWare" /Silent  /CSType CSLegacy

cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe  /CSEndPoint <CSIP> /PassphraseFilePath <PassphraseFilePath>

Modifiez les valeurs en rouge par l’adresse IP de votre appliance de réplication et le chemin du fichier contenant la passphrase :

Ouvrez l’invite de commande en mode administrateur, puis exécutez les commandes suivantes pour copier le programme d’installation sur le serveur à migrer :

Exécutez cette commande pour installer l’agent :

Exécutez ces commandes pour enregistrer l’agent auprès du serveur de configuration :

Avant de continuer, vérifiez le succès des opérations :

Retournez sur le projet Azure Migrate, puis cliquez sur Rafraîchir afin de voir apparaître la machine virtuelle à migrer :

Cliquez ensuite sur Répliquer :

Renseignez toutes les champs, puis cliquez sur Continuer :

Sélectionnez les informations d’identification à utiliser pour installer à distance le service de mobilité sur les machines à migrer, puis cliquez sur Suivant :

Sélectionner les machines à migrer, puis cliquez sur Suivant :

Sélectionnez les propriétés cibles pour la migration. Les machines migrées seront créées avec les propriétés spécifiées, puis cliquez sur Suivant :

Sélectionnez la taille de la VM Azure pour les machines à migrer, puis cliquez sur Suivant :

Sélectionnez le type de disque à utiliser pour les machines à migrer, puis cliquez sur Suivant :

Lancez la réplication en cliquant sur Répliquer :

Les notifications suivantes apparaissent alors :

Le compte de stockage commence à recevoir les premières données liées à la réplication :

Dans le coffre Recovery, la réplication commence elle-aussi à être visible :

Environ 1 heure plus tard, celle-ci est terminée :

Un clic sur la machine virtuelle à migrer nous affiche le schéma de réplication des données :

Si tout est OK, retournez sur le projet de migration, actualiser si nécessaire afin de pouvoir cliquer sur Migrer :

Définissez la destination cible, puis cliquez sur Continuer :

Cochez la machine virtuelle à migrer, puis cliquez sur Migrer :

Quelques secondes plus tard, la notification suivante affiche le succès de déclenchement de la migration :

Cette migration est visible sur notre projet :

Le coffre Recovery nous indique que la migration est terminée :

Le groupe de ressources Azure contient alors de nouvelles ressources créées lors de la migration :

Afin de pouvoir nous connecter à la machine virtuelle via Azure Bastion, copiez les commandes suivantes depuis la page Azure de votre machine virtuelle migrée :

# 1. Autoriser les connexions RDP
Write-Host "Activation des connexions RDP…" -ForegroundColor Cyan
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
  -Name 'fDenyTSConnections' -Value 0

# 2. Ouvrir le Pare-feu Windows pour RDP
Write-Host "Configuration du Pare-feu pour autoriser RDP…" -ForegroundColor Cyan
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

# 3. Redémarrer le service TSE/RDP
Write-Host "Redémarrage du service TermService…" -ForegroundColor Cyan
Restart-Service -Name 'TermService' -Force

Write-Host "RDP activé et Pare-feu configuré. Vous pouvez maintenant vous connecter." -ForegroundColor Green

Collez ces commandes, puis lancez celles-ci :

Ensuite, connectez-vous à votre machine virtuelle migrée via Azure Bastion :

Constatez l’ouverture de session Windows sur votre machine virtuelle migrée sur Azure :

La migration de notre machine virtuelle hébergée sur VMware vers Azure s’est déroulée avec succès.

Conclusion

En définitive, migrer vos VMs vers Azure sans droits d’infra reste une solution de « seconde main » qui dépanne en cas de contraintes fortes, mais elle ne doit pas devenir la norme.

Pour tirer pleinement parti du cloud, il sera toujours préférable de recréer vos ressources selon les principes cloud-native : refactoring des applications, adoption de services managés et optimisation des coûts.

À long terme, cette approche garantit une meilleure scalabilité, une résilience accrue et une plus grande agilité opérationnelle, tout en maîtrisant vos dépenses. Gardez donc cette méthode de contournement sous le coude, mais visez toujours la modernisation et l’optimisation complètes de votre stack dans Azure.

Modèles de chatbot AI .NET !

Microsoft continue d’aider la communauté des développeurs AI et propose désormais de nouveaux modèles d’applications Chat IA développé en .NET. Avec ces modèles d’application comme point de départ, vous pouvez rapidement créer des applications web de chat avec un ou des modèles d’intelligence artificielle dédiés. Tous ces modèles d’application AI en .NET sont désormais disponibles en préversion depuis mars 2025.

Vous souhaitez vous lancer dans le développement de l’IA, mais vous ne savez pas par où commencer ? J’ai un cadeau pour vous : nous avons un nouveau modèle d’application Web de chat sur l’IA qui est maintenant disponible en avant-première. 😊 Ce modèle fait partie de nos efforts continus pour faciliter la découverte et l’utilisation du développement de l’IA avec .NET

Jordan Matthiesen

A quoi sert une application développée pour du chat IA ?

Une application de chat IA ne se contente pas de générer des réponses : elle les enrichit à partir de contenus existants (comme du code, des documents, etc.).

Un modèle d’embedding, qui transforme des textes en vecteurs numériques.
→ Il est utilisé pour rechercher les passages les plus pertinents dans une base de connaissances locale ou distante.
Un modèle génératif, qui prend ces passages et génère une réponse claire et naturelle, dans le style d’un assistant conversationnel.

Deux modèles, deux usages ?

Quand on développe une application en relation avec des modèles l’intelligence artificielle intégrant de la données, il est important de comprendre la différence entre deux grandes catégories de modèles d’IA :

1. Modèle de génération de texte (aussi appelés LLM – Large Language Models)

🔹 Objectif : Générer du texte naturel en réponse à une consigne
🔹 Entrée : Une instruction, un prompt ou une question
🔹 Sortie : Une réponse en langage humain, souvent contextualisée
🔹 Cas d’usage :

Assistants conversationnels (chatbots)
Rédaction automatique de contenu
Résumé ou reformulation de documents
Réponse à des questions en langage naturel

🧪 Exemple d’interaction :

Entrée : “Explique-moi le fonctionnement d’un moteur thermique.”
Sortie : “Un moteur thermique fonctionne en convertissant la chaleur issue de la combustion d’un carburant en énergie mécanique…”

2. Modèle d’embedding (encodage vectoriel)

🔹 Objectif : Représenter un texte sous forme de vecteur numérique pour comparaison sémantique
🔹 Entrée : Une phrase, un document, une question, etc.
🔹 Sortie : Un vecteur (tableau de nombres) capturant le sens du texte
🔹 Cas d’usage :

Recherche sémantique (trouver un document similaire)
Détection de doublons ou de similarité
Indexation pour des bases vectorielles
Classement ou regroupement de contenus (clustering)

🧪 Exemple d’interaction :

Entrée : “Comment entretenir une voiture électrique ?”
Sortie : [0.12, -0.03, 0.57, ...] (vecteur utilisable pour comparer avec d’autres)

Comment ce modèle d’application est-il construit ?

Architecture et technologies :

Application web Blazor (.NET) avec des composants Razor interactifs côté serveur
Base de données SQLite utilisée pour le cache d’ingestion via Entity Framework Core
Intégration avec les modèles d’IA d’Azure OpenAI Service

Fonctionnalités principales :

Chat avec IA augmentée par récupération (RAG)
- Utilise un modèle d’IA pour générer des réponses intelligentes
- Les réponses sont enrichies par des données extraites de documents
Traitement de documents
- Ingère des fichiers PDF (stockés dans Data)
- Extrait le texte et crée des embeddings vectoriels via un modèle de type embedding
- Stocke les vecteurs dans un JsonVectorStore pour les recherches sémantiques
Interface utilisateur
- Composants de chat interactifs (ChatMessageList, ChatInput)
- Rendu Markdown et sanitisation HTML via les bibliothèques JavaScript

Workflow :

Au démarrage, l’application ingère les documents (par exemple des fichiers PDF), les découpe en fragments, puis les encode sous forme de vecteurs numériques grâce au modèle d’embedding (Modèle 2).
L’utilisateur interagit via l’interface de chat, en posant une question en langage naturel. Cette requête est ensuite traitée par le modèle génératif (Modèle 1), mais pas directement…
Avant de répondre, le système utilise le modèle d’embedding (Modèle 2) pour retrouver les passages les plus pertinents dans les documents indexés, en comparant leur sens avec celui de la question.
Enfin, le modèle génératif (Modèle 1) s’appuie à la fois sur ces passages trouvés et sur ses propres connaissances générales pour générer une réponse complète, claire et contextualisée.

Comment connecte-t-on cette application avec un modèle d’IA ?

Ces exemples d’application ne contiennent pas l’intelligence artificielle elle-même, mais elle interagit avec un modèle IA externe (hébergé dans le cloud, en local ou dans un container).

Enfin, découvrez le dernier épisode du stand-up de la communauté .NET AI, dans lequel Alex, Bruno et Jordan présentent les nouveaux modèles :

Dans cet article, je vous propose de tester l’application en connectant celle-ci vers 3 modèles d’IA :

GitHub
Azure OpenAI
Ollama

Voici les différentes étapes que nous allons suivre :

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

Etape 0 – Rappel des prérequis :

Afin de tester les différents modèles AI en .NET, nous allons avoir besoin de :

Un poste local
Un compte GitHub des modèles GitHub Models
Une souscription Azure si utilisation du service Azure OpenAI

Commençons par créer préparer le poste local.

Etape I – Préparation du poste local :

Rendez-vous sur la page suivante afin de télécharger Visual Studio Code :

Une fois téléchargée, lancez l’installation de ce dernier :

Rendez-vous sur la page suivante afin de télécharger la version 9.0 de .NET :

Une fois téléchargée, lancez l’installation :

Une fois l’installation réussie, fermez celle-ci :

Enfin, redémarrez le poste local :

Une fois le poste local redémarré, ouvrez Windows Terminal :

Installer les modèles de projet pour l’extension .NET liée à Microsoft.Extensions.AI, qui fait partie de l’écosystème Semantic Kernel :

dotnet new install Microsoft.Extensions.AI.Templates

Créez un dossier sur votre poste, puis positionnez-vous dedans :

Ne fermez pas cette fenêtre Windows PowerShell.

Notre environnement local est prêt. Avant de déployer des applications basées sur les templates d’IA, nous avons besoin de récupérer les identifiants de connexion (token) de certains modèles IA. Commençons par le plus simple : GitHub.

Etape II – Test de l’application avec le modèle GitHub :

Rendez-vous sur la page d’accueil de GitHub, puis authentifiez-vous, ou créez un compte au besoin :

Cliquez sur votre photo de profil en haut à droite, puis cliquez sur le bouton des Paramètres :

Tout en bas, cliquez sur le menu des paramètres suivant :

Créez un token à granularité fine, pour une utilisation personnelle de l’API GitHub :

Nommez ce token, puis choisissez une date d’expiration :

Cliquez-ici pour générer ce token :

Confirmez votre choix :

Copiez la valeur du token GitHub :

Retournez sur la fenêtre Windows PowerShell ouverte précédemment, puis lancez la commande suivante afin d’utiliser le template aichatweb pour créer une application web de chat IA en lien avec le modèle GitHub :

dotnet new aichatweb -n GitHubModels --provider githubmodels --vector-store local

Ouvrez l’explorateur Windows afin de constater la création d’un nouveau dossier ainsi que le code de l’application :

Sur votre poste local, ouvrez Visual Studio Code, puis choisissez l’action d’ouverture d’un dossier :

Sélectionnez le dossier créé par l’application IA :

Constatez l’ouverture de l’application dans Visual Studio Code :

Ouvrez la fenêtre Terminal :

Stockez un secret utilisateur localement (ici un token) de manière sécurisée pour notre projet .NET :

dotnet user-secrets set GitHubModels:Token github...

Affichez tous les secrets stockés localement pour le projet courant :

dotnet user-secrets list

Ajoutez ou retirer au besoin des fichiers PDF utilisés durant la phase d’indexation sémantique)

Compilez et exécutez l’application .NET dans le dossier courant :

dotnet run

L’application vérifie dans les sources de données si nouveau documents sont à indexer ou vectoriser :

Ce message vous indique que l’application tourne localement sur le port 5145 :

Ouvrez un navigateur web à cette adresse:port, puis posez une question à l’IA sur un sujet d’ordre général ou propre aux documents ingérés :

Constatez la rapidité du résultat et la ou les sources associés, puis cliquez dessus :

Constatez la sélection de texte en correspondance avec la question posée à l’IA :

Le test avec le modèle GitHub a bien fonctionné, pensez à détruire le token sur le portail de GitHub pour des questions de sécurité

Continuons les tests de l’application de chat IA avec le modèle Azure OpenAI.

Etape III – Test de l’application avec le modèle Azure OpenAI :

Depuis le portail Azure, commencez par rechercher le service Azure OpenAI :

Cliquez-ici pour créer un nouveau service :

Renseignez toutes les informations, conservez le modèle de prix S0 (suffisant pour nos tests), puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Créer :

Une fois le déploiement terminé, cliquez-ici :

Copiez les 2 informations suivantes dans votre bloc-notes afin de vous y connecter plus tard à via API :

Afin de créer les deux modèle d’IA nécessaires au travers d’Azure, cliquez-ici pour ouvrir le portail Microsoft AI Foundry :

Sur ce portail, commencez par rechercher le premier modèle d’IA nécessaire à notre application :

Cliquez sur Déployer :

Conservez le nom d’origine, puis cliquez sur Déployer :

Retournez sur le catalogue des modèles d’IA, puis recherchez le second modèle d’IA nécessaire à notre application :

Cliquez sur Déployer :

Conservez le nom d’origine, puis cliquez sur Déployer :

Vérifiez la présence des 2 modèles déployés dans le menu suivant :

dotnet new aichatweb -n AzureOpenAI --provider azureopenai --vector-store local

Ouvrez l’explorateur Windows afin de constater la création d’un nouveau dossier :

Sur votre poste local, ouvrez Visual Studio Code, puis choisissez l’action d’ouverture d’un dossier :

Sélectionnez le dossier créé par l’application IA :

Constatez l’ouverture de l’application dans Visual Studio Code :

Afin de passer d’une authentification basée sur une identité Azure (DefaultAzureCredential) à une authentification explicite par clé API (AzureKeyCredential), remplacer le code suivant :

var azureOpenAi = new AzureOpenAIClient(
    new Uri(builder.Configuration["AzureOpenAI:Endpoint"] ?? throw new InvalidOperationException("Missing configuration: AzureOpenAi:Endpoint. See the README for details.")),
    new DefaultAzureCredential());

Par celui-ci, puis sauvegardez le fichier Program.cs :

var endpoint = builder.Configuration["AzureOpenAI:Endpoint"] 
    ?? throw new InvalidOperationException("Missing configuration: AzureOpenAI:Endpoint. See the README for details.");
var key = builder.Configuration["AzureOpenAI:Key"] 
    ?? throw new InvalidOperationException("Missing configuration: AzureOpenAI:Key. See the README for details.");

var azureOpenAi = new AzureOpenAIClient(new Uri(endpoint), new AzureKeyCredential(key));

Ouvrez la fenêtre Terminal :

Enregistrez localement (et de manière sécurisée) le point de terminaison de l’instance Azure OpenAI :

dotnet user-secrets set AzureOpenAI:Endpoint https://aichattemplate-rg.openai.azure.co

Enregistrez de manière sécurisée la clé API de l’instance Azure OpenAI dans les secrets utilisateur de .NET :

dotnet user-secrets set AzureOpenAI:Key 1zF4OGPseV...

Affichez tous les secrets stockés localement pour le projet courant :

dotnet user-secrets list

Ajoutez ou retirer au besoin des fichiers PDF utilisées durant la phase d’indexation sémantique)

Compilez et exécutez l’application .NET dans le dossier courant :

dotnet run

Ouvrez un navigateur web à cette adresse:port indiqué, puis posez une question à l’IA sur un sujet d’ordre général ou propre aux documents ajoutés :

Constatez la rapidité du résultat et la ou les sources associés, puis cliquez dessus :

Constatez la sélection de texte en correspondance avec la question posée :

Le test avec le service Azure OpenAI a bien fonctionné, pensez à détruire le service une fois les tests terminés.

Terminons les tests de l’application de chat IA avec le modèle local Ollama.

Etape IV – Test de l’application avec le modèle Ollama :

Rendez-vous sur la page suivante afin de télécharger Ollama :

Une fois téléchargée, lancez l’installation :

Une fois l’installation réussie, vérifiez via l’URL suivante le bon fonctionnement du service :

http://localhost:11434/

Depuis le menu Démarrer, ouvrez l’application CMD, puis lancez la commande suivante :

ollama pull llama3.2

Ollama télécharge alors la version mini de Phi3 d’environ 2 Go

ollama pull all-minilm

Ollama télécharge alors un modèle ouvert d’environ 270 Mo :

Vérifiez la liste des modèles en place avec la commande suivante :

ollama list

dotnet new aichatweb -n llama3.2Model --provider ollama --vector-store local

Ouvrez l’explorateur Windows afin de constater la création d’un nouveau dossier ainsi que le code de l’application :

Sur votre poste local, ouvrez Visual Studio Code, puis choisissez l’action d’ouverture d’un dossier :

Sélectionnez le dossier créé par l’application IA :

Constatez l’ouverture de l’application dans Visual Studio Code :

Ouvrez la fenêtre Terminal :

Ajoutez ou retirer au besoin des fichiers PDF utilisées durant la phase d’indexation sémantique)

Compilez et exécutez l’application .NET dans le dossier courant :

dotnet run

L’application vérifie dans les sources de données configurées si nouveau documents sont à indexer ou vectoriser :

Cette ligne vous indique que l’application tourne localement sur le port 5145 :

Ouvrez un navigateur web à cette adresse:port, puis posez une question à l’IA sur un sujet d’ordre général ou propre aux documents ajoutés :

Constatez le pic d’usage du CPU/GPU selon la configuration matérielle de votre poste local :

Constatez la rapidité/lenteur du résultat :

Conclusion

Avec l’arrivée des nouveaux templates .NET dédiés à l’intelligence artificielle, il n’a jamais été aussi simple de créer des applications web de chat connectées à des modèles IA.

Que vous choisissiez un modèle cloud (comme Azure OpenAI), un modèle public (via GitHub), ou même un modèle local (comme ceux proposés par Ollama), l’infrastructure est prête à l’emploi et parfaitement intégrée à l’écosystème .NET.

Forcer le flux TCP sur Azure Virtual Desktop / Windows 365

Les solutions de bureau à distance, telles qu’Azure Virtual Desktop et Windows 365, reposent sur des protocoles de transport pour offrir une expérience utilisateur fluide et réactive. Par défaut, UDP est souvent privilégié pour sa faible latence, mais dans certains environnements, la fiabilité et la stabilité offertes par TCP priment.

Cet article détaille les spécificités de chacun de ces protocoles, leurs avantages et inconvénients, et propose deux approches pour forcer l’usage de TCP : une modification côté serveur et une modification côté client, que ce soit directement via le registre ou en déployant une stratégie de groupe (GPO).

TCP et son rôle dans les solutions de bureau à distance :

Le Transmission Control Protocol (TCP) est un protocole orienté connexion qui assure la fiabilité des échanges. Il garantit que les paquets arrivent dans l’ordre et, en cas de perte, les retransmet automatiquement.

Avantages de TCP :

Fiabilité et intégrité des données : Chaque paquet est vérifié et retransmis en cas d’erreur ou de perte.
Contrôle d’erreur et ordonnancement : Les données arrivent dans le bon ordre, ce qui est essentiel pour des applications nécessitant une cohérence stricte.

Inconvénients de TCP :

Surcharge et latence accrue : Les mécanismes de contrôle (comme le handshake initial) ajoutent un certain délai.
Moins performant pour les applications ultra-réactives : La latence induite peut être un frein pour certaines applications en temps réel.

UDP et ses applications dans le Remote Desktop :Le User Datagram Protocol (UDP) est un protocole sans connexion qui envoie les paquets sans vérifier leur réception ni leur ordre. Cette approche permet une transmission rapide avec une latence très réduite, idéale pour des sessions interactives.

Avantages de UDP :

Faible latence : Parfait pour des sessions de Remote Desktop où la réactivité est cruciale.
Moindre surcharge : L’absence de contrôle d’erreur exhaustif accélère le transfert des données.

Inconvénients de UDP :

Fiabilité moindre : Sans retransmission automatique, la perte de paquets peut dégrader la qualité de la session.
Absence de contrôle d’erreur intégré : Dans des environnements instables, cela peut entraîner des distorsions.

Fort de cette comparaison, il apparaît que le choix du protocole doit être adapté au contexte réseau. Par exemple, dans des environnements à qualité réseau variable, forcer l’utilisation de TCP peut s’avérer judicieux pour garantir une meilleure stabilité des connexions.

Forcer le flux TCP côté serveur

Modification via Registre

Avant modification, le serveur accepte par défaut les connexions en UDP (comme indiqué par vos captures d’écran). Pour forcer TCP, la modification est simple : il suffit d’ajouter la clé de registre SelectTransport.

Pour ce faire, la modification est simple : il suffit d’ajouter la clé de registre SelectTransport :

Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :

REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v SelectTransport /t REG_DWORD /d 1 /f

Après modification, la connexion se fait exclusivement en TCP. Cette commande force le serveur à utiliser uniquement TCP pour les connexions RDP.

Déploiement via GPO

Microsoft propose également une stratégie de groupe qui permet de spécifier le protocole RDP à utiliser. Vous pouvez la trouver sous :

Computer Configuration > Administration Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Host > Connections

La politique associée permet de choisir entre :

« Use either UDP or TCP (default) » : Si la connexion UDP est possible, la majorité du trafic RDP l’utilisera.
« Use only TCP » : Toutes les connexions RDP se feront exclusivement via TCP.

Si cette stratégie n’est pas configurée ou est désactivée, RDP sélectionnera automatiquement le protocole optimal pour offrir la meilleure expérience utilisateur.

Testons maintenant la configuration côté client.

Forcer le flux TCP côté client

Passons à présent à la configuration côté client. Avant modification, le client se connecte en UDP, comme le montrent les captures d’écran. Pour forcer l’utilisation de TCP (via WebSocket, qui repose sur TCP), il suffit d’ajouter la clé de registre fClientDisableUDP.

Avant modification, le client fonctionnait en UDP, comme vous pouvez le constater sur la capture d’écran ci‑dessous.

Pour ce faire, la modification est simple : il suffit d’ajouter la clé de registre fClientDisableUDP.

Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :

REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP /t REG_DWORD /d 1 /f

Après modification, la connexion se fait exclusivement en TCP. Ce changement assure que le client ne tente plus d’établir une connexion via UDP :

Conclusion

Le choix entre TCP et UDP dans des environnements de bureau à distance comme Azure Virtual Desktop et Windows 365 se résume à un compromis entre rapidité et fiabilité :

UDP offre une faible latence, idéale pour des sessions interactives, mais peut souffrir de pertes de paquets dans des réseaux instables.
TCP, même via une couche WebSocket, garantit la transmission fiable des données, au prix d’un léger surcoût en latence.

Note technique : Forcer l’utilisation de TCP est particulièrement recommandé dans les environnements où la qualité du réseau est variable ou sujette à des perturbations. Dans ces situations, bien que TCP puisse introduire une latence légèrement supérieure, il offre une stabilité et une fiabilité accrues, assurant ainsi une expérience utilisateur plus homogène.

En forçant l’utilisation de TCP via une modification de registre côté serveur (ou via une GPO) et/ou côté client, vous pouvez améliorer la stabilité des connexions, particulièrement dans des environnements où la qualité de la connexion est incertaine.

Ces approches vous permettent de mieux contrôler la configuration de votre infrastructure de Remote Desktop, optimisant ainsi l’expérience pour vos utilisateurs.

IA : Stockez vos vecteurs dans SQL

L’actualité concernant l’intelligence artificielle défile à un rythme effréné. Avec cette avalanche de nouveaux outils, de techniques et de possibles usages, combinant à la fois de réelles avancées, mais aussi parfois des discours marketing très prometteurs, chacun se doit de faire sa propre analyse, et de trier dans ces nouveautés les mises applications possibles dans au quotidien.

Qu’est-ce que les vecteurs dans le domaine de l’IA ?

Dans le domaine de l’IA, un vecteur est généralement utilisé pour représenter des données numériques. Un vecteur est une liste ordonnée de nombres. Par exemple, dans un espace à trois dimensions, un vecteur pourrait être représenté comme [3, 4, 5], où chaque nombre représente une dimension spécifique.

pandia.pro

Dans l’IA, les vecteurs, c’est-à-dire des représentations numériques (ou embeddings) de données permettent donc de transformer du texte, des images ou d’autres données en une série de nombres qui représentent leurs caractéristiques essentielles. Ces représentations numériques facilitent la comparaison et la mesure de la similarité entre différents éléments.

L’embedding est une méthode de transformations de données provenant d’images, de textes, de sons, de données utilisateur, ou de tout autre type d’information, en vecteurs numériques. Cela revient à traduire le langage humain en une langue que les machines peuvent interpréter, capturant ainsi les nuances sémantiques ou contextuelles des éléments traités.

atipik.ch

Grâce à une IA, la façon de rechercher des informations pertinentes repose sur la comparaison des vecteurs pour identifier les documents ou les images similaires. En d’autres termes, les vecteurs aident à comprendre et à exploiter la signification des données pour améliorer la précision des résultats de recherche.

Où sont stockés les vecteurs ?

Traditionnellement, les vecteurs étaient stockés dans des bases de données dédiées, comme Pinecone ou Milvus, conçues spécifiquement pour gérer des données vectorielles et optimiser les recherches par similarité.

Cependant, avec l’évolution des technologies, certains SGBD relationnels, comme Azure SQL Database, intègrent désormais un support natif pour les vecteurs. Cela permet de stocker et d’interroger directement des vecteurs au sein d’une base de données SQL classique, simplifiant ainsi l’architecture des applications et réduisant la nécessité d’avoir un système séparé.

Depuis quand Azure SQL Database peut stocker les vecteurs ?

Azure SQL Database a commencé à prendre en charge du stockage des vecteurs lors de l’EAP (Early Adopter Preview) à partir du 21 mai 2024, avant d’être mis en Public Preview le 6 novembre 2024.

Qu’est-ce que le nouveau type de données Vector ?

Le type vector est un nouveau type de données natif dans Azure SQL Database spécifiquement conçu pour stocker des vecteurs. Plutôt que d’utiliser un format générique comme du JSON ou du varbinary, ce type offre un format dédié, compact et optimisé pour les opérations mathématiques, telles que le calcul de distances (cosinus, euclidienne, etc.).

Il permet ainsi d’effectuer directement dans la base de données des recherches par similarité, sans recourir à des systèmes externes spécialisés dans le stockage vectoriel.

Comment fonctionne la recherche de distance entre 2 vecteurs ?

En utilisant des fonctions intégrées telles que VECTOR_DISTANCE, cela calcule une distance (cosinus, euclidienne, etc.) entre le vecteur de la requête et chaque vecteur stocké, permettant d’ordonner les résultats par similarité (la distance la plus faible indiquant la correspondance la plus proche).

Est-ce disponible sur SQL Server 2022 ?

Non, la fonctionnalité native de support des vecteurs n’est pas disponible dans SQL Server 2022. Actuellement, cette capacité est proposée dans Azure SQL Database. Microsoft prévoit d’intégrer des fonctionnalités similaires dans les futures versions, notamment SQL Server 2025.

Pour la première fois, Microsoft apporte un support vectoriel natif à SQL Server. SQL Server 2025 sera une base de données vectorielle prête pour l’entreprise, capable de générer et de stocker en mode natif des incrustations vectorielles. Cette prise en charge native des vecteurs permettra aux clients de SQL Server d’exécuter des modèles d’IA génératifs en utilisant leurs propres données. Ils peuvent choisir le modèle d’IA requis grâce à la gestion extensible des modèles permise par Azure Arc.

neowin.net

Peut-on tester les vecteurs sur une base de données Azure SQL ?

Comme toujours, Alex Wolf, via son excellente chaîne YouTube The Code Wolf, nous montre la prise en charge des vecteurs IA au sein même des bases de données SQL :

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

Etape 0 – Rappel des prérequis :

Afin de faire nos tests sur le base de données Azure SQL pour < comprendre le fonctionnement des vecteurs, nous allons avoir besoin de :

Un tenant Microsoft active
Une souscription Azure valide

Commençons par créer la base de données SQL depuis le portail Azure.

Etape I – Création de la base de données Azure SQL :

Depuis le portail Azure, commencez par rechercher le service de bases de données SQL :

Renseignez les informations de base, comme la souscription Azure et le groupe de ressources :

Cliquez-ici pour également créer un serveur SQL hébergeant notre base de données :

Renseignez un nom unique pour votre serveur SQL, indiquez un compte administrateur à ce dernier, puis cliquez sur OK :

Conservez l’option de base pour la puissance votre serveur SQL, la réplication sur LRS, puis cliquez sur Suivant :

Conservez l’accès public pour nos tests, ajoutez-y votre adresse IP publique, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources :

Attendez environ 5 minutes, puis cliquez-ici pour accéder aux ressources créées :

Copiez les éléments de connexion à cette base de données présents l’onglet ci-dessous, puis conservez cette valeur par la suite dans un éditeur de texte :

Utilisez un outil de gestion de base de données, comme SQL Server Management Studio (SSMS), ou Azure Data Studio, disponible lui sur cette page :

Acceptez les conditions d’utilisations, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Cliquez sur Terminer :

Ouvrez Azure Data Studio, puis cliquez-ici pour créer une nouvelle connexion :

Collez les informations de connexion de votre base SQL précédemment copiées, renseignez le mot de passe de votre administrateur, puis cliquez sur Connecter :

Saisissez la commande SQL suivante afin de créer la table liée au stockage des données et de leurs vecteurs :

CREATE TABLE dbo.demo
(
    id INT PRIMARY KEY,
    filename VARCHAR(50),
    vectors VECTOR(1024) NOT NULL
)

Exécutez la commande, puis obtenez la confirmation suivante :

Notre base de données, encore vide en enregistrements et en vecteurs est maintenant prête.

Nous allons maintenant créer un le service d’intelligence artificielle sur Azure afin de créer calculer les vecteurs de nos futures données.

Etape II – Création du service d’IA Computer Vision :

Toujours sur le portail Azure, recherchez le service d’IA suivant :

Cliquez-ici pour créer un nouveau service :

Renseignez toutes les informations, en privilégiant un déploiement dans les régions East US ou West Europe, conservez le modèle de prix F0 (suffisant pour nos tests), puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources :

Une fois le déploiement terminé, cliquez-ici :

Copiez les 2 informations suivantes dans votre bloc-notes afin de vous y connecter plus tard à via API :

Afin d’envoyer différentes requêtes via API à notre service d’IA, utilisez un service dédié, comme par exemple Postman, disponible ici (créez un compte gratuit si nécessaire) :

Notre environnement manuel est maintenant prêt pour être testé.

La prochaine étape consiste à générer manuellement des vecteurs via notre service d’IA afin de les stocker dans votre base de données SQL.

Etape III – Chargement des vecteurs d’images dans la DB SQL :

Une fois connecté sur votre console Postman, cliquez-ici pour utiliser le service :

Notre premier objectif est de convertir les données d’une image en vecteur. Pour cela, choisissez la méthode de type POST, puis saisissez l’URL composée de la façon suivante :

Point de terminaison de votre service Computer Vision
Service API de vectorisation d’images proposé par Computer Vision

Cela donne l’URL suivante :

https://your-endpoint/computervision/retrieval:vectorizeImage?api-version=2024-02-01&model-version=2023-04-15

Rendez-vous dans l’onglet Headers afin de rajouter en valeur la clef de votre service IA Computer Vision sous la clef Ocp-Apim-Subscription-Key :

Rendez-vous dans l’onglet Body afin de rajouter en RAW l’URL publique d’une image en exemple :

{
    "url": "https://raw.githubusercontent.com/alex-wolf-ps/ai-image-search/refs/heads/azure-sql-vector/wwwroot/images/salad-house.jpg"
}

Cliquez ensuite sur Envoyer, puis changez le format de sortie des vecteurs calculés en RAW :

Copiez tous les vecteurs présents entre les 2 crochets :

Retournez sur Azure Data Studio, puis coller la requête SQL suivante afin de créer 3 enregistrements :

INSERT INTO dbo.demo (id, filename, vectors) VALUES
(1, 'latte.jpg', '[]'),
(2, 'cake.jpg', '[]'),
(3, 'salad.jpg', '[]')

Entre les crochets de la ligne correspondante à l’image, collez les vecteurs précédemment copiés :

Recommencez la même opération de calcul des vecteurs sous Postman pour les 2 autres fichiers :

latte
cake

Cela donne la requête SQL finale suivante :

Exécutez la commande suivante, puis constatez le succès de celle-ci :

Contrôlez le résultat du chargement dans la base de données SQL via la requête suivante :

SELECT * FROM dbo.demo

Notre base de données Azure SQL a bien stocké les vecteurs calculés par le service d’intelligence artificielle. La prochaine étape consiste à calculer la distance entre les vecteurs des images et les vecteur d’un mot-clef.

Etape IV – Calcul de distance entre les images et le mot-clef :

Retournez sur le service d’appel API Postman, puis créez un nouvel onglet de requête :

Choisissez à nouveau une méthode de type POST, puis l’URL composée de la façon suivante :

Point de terminaison de votre service Computer Vision
Service API de vectorisation de texte proposé par Computer Vision

Cela donne l’URL suivante :

https://your-endpoint/computervision/retrieval:vectorizeText?api-version=2024-02-01&model-version=2023-04-15

Rendez-vous dans l’onglet Headers afin de rajouter à nouveau en valeur la clef de votre service Computer Vision sous la clef Ocp-Apim-Subscription-Key :

Rendez-vous dans l’onglet Body afin de rajouter en RAW le mot-clef :

{
    "text":"café"
}

Cliquez ensuite sur Envoyer, changez le format de sortie des vecteurs calculés en RAW, puis copiez tous les vecteurs présents entre les 2 crochets :

Retournez sur Azure Data Studio, puis commencez par coller la requête SQL suivante afin de créer une variable qui stockera les vecteurs de notre mot-clef :

DECLARE @searchVector VECTOR(1024) = '[]'

Entre les 2 crochets de la déclaration de variable, collez les vecteurs du mot-clef précédemment copiés :

Ajoutez en dessous la requête SQL basée sur la fonction VECTOR_DISTANCE :

SELECT TOP(10) id, filename, VECTOR_DISTANCE('cosine', @searchVector, vectors)
AS Distance from demo ORDER BY Distance

Puis exécutez l’ensemble afin de constater le résultat de distance entre le mot-clef et les 3 images :

Ces différents tests nous démontrent la possibilité de stockage des vecteurs et la recherche de résultats basés sur la distance entre ces derniers, le tout dans une base de données SQL.

Toutes ces étapes de génération de vecteurs et de recherche sur les distances sont facilement intégrables dans une application, comme celle justement proposée par Alex Wolf.

Etape V – Automatisation de l’importation des vecteur :

Retournez sur Azure Data Studio afin de créer une seconde table dédiée à notre application :

CREATE TABLE dbo.images
(
    id INT PRIMARY KEY,
    name VARCHAR(50),
    vectors VECTOR(1024) NOT NULL
)

Rendez-vous sur la page GitHub suivante afin de télécharger l’application au format ZIP :

Décompressez l’archivage dans le dossier local de votre choix :

Ouvrez l’application Visual Studio Code, puis ouvrez le dossier correspondant à votre application :

Ouvrez le fichier Program.cs pour y renseigner votre le point de terminaison, ainsi que la clef de votre service Computer vision, puis Sauvegardez :

Ouvrez le fichier AzureBectorDatabaseService.cs pour y renseigner les informations de connexion de votre base SQL précédemment copiées avec le bon mot de passe, puis Sauvegardez :

Démarrez l’application via la commande .NET suivante :

dotnet run

Quelques secondes plus tard, l’application est démarrée, l’URL et le port exposé s’affichent :

Collez cette URL dans un navigateur internet pour ouvrir l’application, puis cliquez sur le bouton ci-dessous pour charger une ou des images au format JPG :

Sélectionnez-le ou les fichiers images de votre choix, puis cliquez sur Ouvrir :

Cliquez-ici pour téléversé le ou les fichiers :

Constatez l’apparition de la vignette de vos images téléversées :

Effectuez la même opération avec d’autres images plus ou moins variées :

Retournez sur Azure Data Studio, puis lancez la requête SQL suivante pour voir le chargement de des données et des vecteurs dans la seconde table créée :

SELECT * FROM dbo.images

Notre application contient maintenant des fichiers images, avec leurs vecteurs dans notre base de données SQL grâce à notre service d’IA Computer Vision.

Il nous reste maintenant qu’à rechercher via un mot-clef, transposé lui-aussi en vecteurs via l’IA, à des images dont les vecteurs lui seraient proches.

Etape VI – Automatisation du calcul de distance vectorielle :

Retournez sur la page web de votre application, saisissez un mot-clef dans la zone prévue à cet effet, puis cliquez sur Rechercher afin de constater la pertinence des résultats :

Refaites d’autres tests en jouant également avec les 3 niveaux du seuil de confiance :

Les résultats retournés varient selon le niveau du seuil de confiance :

La faible quantité d’images chargées et le niveau de confiance réglé sur moyen donne des résultats trop larges :

Cette approximation peut se corriger avec un niveau de confiance élevé :

Conclusion

En conclusion, l’intégration native du type de données vector dans Azure SQL Database marque une avancée majeure pour les développeurs souhaitant exploiter l’intelligence artificielle directement au sein de leur SGBD.

Cette fonctionnalité permet de stocker et d’interroger des vecteurs de manière optimisée, simplifiant ainsi l’architecture des applications en éliminant le besoin d’une base de données vectorielle externe.

En adoptant ces outils, les équipes peuvent désormais transformer et analyser leurs données de façon plus intuitive et sécurisée, tout en tirant parti de l’écosystème SQL existant. C’est un pas décisif vers une intégration plus fluide de l’IA et la modernisation d’environnements traditionnels.