1. PROBLÉMATIQUE
Le poste de travail : l’angle mort historique de l’architecture
Quand je discute architecture avec des équipes Cloud, le même schéma revient souvent
On parle beaucoup des backends : sécurité, réseau, identité, résilience, Zero Trust.
C’est normal, c’est là que se concentrent les enjeux critiques… et les décisions structurantes.
Mais très souvent, tout ce qui concerne l’exécution côté utilisateur arrive après.
Parfois trop tard.
Et je ne parle pas uniquement de postes de travail.
Je parle aussi des fermes RDS, des serveurs de sessions, des applications publiées via Citrix,
de tout ce qui permet aux utilisateurs d’accéder réellement au SI au quotidien.
Dans beaucoup d’environnements, cette couche a grandi par empilement :
un peu de RDS ici, une ferme Citrix là, des règles spécifiques, des exceptions,
jusqu’à devenir difficile à faire évoluer sans risque.
C’est généralement à ce moment-là que la question se pose :
est-ce qu’on continue à maintenir cette complexité,
ou est-ce qu’on repense l’environnement d’exécution comme une brique d’architecture à part entière ?
Quelques symptômes bien connus :
- 💻 Des données critiques qui vivent sur des disques locaux
- 🔓 Un laptop volé = un incident de sécurité potentiel
- 📉 Une UX qui s’effondre dès que l’utilisateur sort du réseau interne
Le VDI on-prem (RDS, Citrix) a essayé de répondre à ça.
Mais soyons honnêtes : à quel prix ?
- Une infra lourde
- Des licences complexes
- Un control plane à maintenir 24/7
- Une dette opérationnelle énorme
👉 Résultat : on passait plus de temps à maintenir la plateforme qu’à servir les métiers.
Le Cloud a déplacé la vraie question.
🔴 “Comment je déploie mon VDI ?”
🟢 “Qu’est-ce que je veux encore gérer, et qu’est-ce que je délègue ?”
C’est exactement là que AVD change la donne.
2. HISTORIQUE
AVD n’est pas né dans un slide marketing.
C’est l’aboutissement de 20+ ans d’itérations, parfois douloureuses, sur l’accès distant chez Microsoft
| Année | Étape | Lecture terrain |
|---|---|---|
| 1998 | Windows NT Terminal Server | Rustique, mais révolutionnaire à l’époque |
| 2008 | RDS | Le VDI on-prem s’industrialise… et se complexifie |
| 2019 | Windows Virtual Desktop | 💥 Rupture : Microsoft reprend le control plane |
| 2021 | AVD & Windows 365 | PaaS vs SaaS : deux visions, deux usages |
💡 Le vrai tournant, ce n’est pas le nom.
C’est le passage d’un produit à une plateforme.
On ne parle plus seulement de VDI.
On parle de Desktop-as-a-Service (DaaS).
Et ça change complètement la façon de concevoir, sécuriser et exploiter la solution.
3. AVD = RESPONSABILITÉ PARTAGÉE 🤝
Exactement comme tout service PaaS sérieux
C’est probablement le point le plus mal compris d’AVD.
👉 AVD n’est pas un RDS managé
👉 AVD est un service PaaS à responsabilité partagée
Ce que Microsoft prend en charge (le Control Plane)

Et c’est là que la magie opère ✨
Microsoft gère pour toi :
- le Broker
- la Gateway
- le Web Access
- la résilience globale
- la montée en charge
- la sécurité d’exposition Internet
Concrètement :
- 🔴 plus de ports RDP exposés
- 🔴 plus de brokers en HA à maintenir
- 🔴 plus de gateway à patcher à 3h du matin
🟢 Mon retour terrain :
C’est LA valeur numéro 1 d’AVD.
Moins d’opérations, moins de stress, plus de focus sur la valeur métier.
Ce qui reste pleinement sous ta responsabilité (et ce n’est pas optionnel)
Et là, on entre dans la vraie architecture.
| Domaine | Réalité terrain |
|---|---|
| Session Hosts | Mauvais sizing = coûts explosés |
| Images | Une golden image mal pensée = plateforme instable |
| Identité | MFA & accès conditionnel : non négociable |
| Réseau | AVD est dans ton VNet, pas chez Microsoft |
| Profils | FSLogix mal configuré = UX catastrophique |
| Coûts | Sans autoscaling, la facture pique vite |
⚠️ Erreur classique que je vois encore trop souvent :
“C’est managé, donc on verra plus tard.”
Non.
👉 AVD pardonne très mal les erreurs de design
4. AVD vs Windows 365 ⚖️

Ce n’est pas une bataille, c’est un arbitrage
| AVD | Windows 365 | |
|---|---|---|
| Modèle | PaaS | SaaS |
| Mutualisation | 🟢 Multi-session | 🔴 Dédié |
| Contrôle | Total | Très limité |
| Coûts | Optimisables | Prévisibles |
| Public | Organisations matures | Usage standardisé |
Ma position d’architecte
- Windows 365 : parfait pour des besoins simples, homogènes, rapides à déployer
- AVD : incontournable dès que tu veux :
- optimiser les coûts
- mutualiser
- publier des RemoteApps
- intégrer finement ton SI
📉 Retour réel :
J’ai vu des clients diviser leurs coûts VDI par 2 à 3 en passant sur AVD bien designé.
🔴 Mauvaise question : “Lequel est le meilleur ?”
🟢 Bonne question : “Quel est mon niveau de maturité et mon besoin réel ?”
👉 La vraie stratégie, dans beaucoup d’organisations, c’est la combinaison des deux
5. CONCLUSION
Microsoft te retire une énorme complexité en prenant en charge le control plane.
Mais tout ce qui fait la qualité réelle de l’expérience: stabilité, sécurité, coûts, performance
dépend encore de tes choix d’architecture.
Une image mal pensée, un réseau mal segmenté ou une stratégie de scaling absente,
et AVD devient vite instable… ou hors de prix.
👉 AVD récompense les designs rigoureux.
Il expose très vite les compromis mal assumés.
PROCHAIN ARTICLE
👉 La Partie 2 sera dédiée aux composants fondamentaux d’AVD
On rentrera dans le concret :
- Host Pools
- Workspaces
- Application Groups
- logiques de publication Desktop vs RemoteApp
Objectif : poser des bases solides avant d’aller plus loin
Parce que dans AVD, tout se joue dès le design initial
À très vite 👋