Le vrai besoin : livrer une expérience de travail, pas simplement une machine virtuelle

Le bon point de départ est la tâche de l’utilisateur : bureau complet, application unique, accès occasionnel ou environnement personnel permanent. Un comptable qui utilise huit heures par jour plusieurs logiciels, un technicien qui consulte ponctuellement une application patrimoniale et un prestataire qui doit accéder à un projet pendant trois mois n’ont pas le même profil. Leur imposer une architecture unique peut augmenter le coût ou dégrader l’expérience.

Décrivez d’abord les applications, les données, les périphériques et les lieux de connexion. Certaines applications exigent une proximité réseau avec une base de données. D’autres doivent interagir avec un scanner, une imprimante d’étiquettes, un lecteur de carte ou un équipement USB. La visioconférence sollicite l’audio et la vidéo en temps réel. Un simple test de connexion au bureau ne couvre donc pas la journée de travail.

Ajoutez le modèle opérationnel. Qui construit les images Windows ? Qui applique les mises à jour ? Qui surveille la saturation ? Qui traite une panne de profil ? Qui gère les licences, la capacité et la sécurité ? La page Windows 365 de GVISION présente le Cloud PC comme un poste géré avec Microsoft Intune. Ce comparatif va plus loin : il détermine quand cette simplicité suffit et quand une infrastructure AVD ou RDS reste plus logique.

Windows 365, AVD et RDS : où se situe la responsabilité ?

Les trois solutions diffusent une expérience Windows à distance, mais elles ne délèguent pas les mêmes couches à Microsoft. Windows 365 se rapproche d’un poste SaaS. AVD fournit un plan de contrôle géré et laisse les ressources de session dans Azure. RDS est un ensemble de rôles Windows Server que l’organisation ou son prestataire déploie et maintient.

Windows 365 : un Cloud PC attribué à un utilisateur

Microsoft décrit Windows 365 Enterprise comme un service qui crée des Cloud PC, gérés avec Intune, Entra ID et la connectivité AVD. Le résultat ressemble à un poste personnel : capacité choisie, applications, paramètres et session persistante.

Ce modèle convient lorsque l’organisation veut standardiser rapidement un poste pour des utilisateurs réguliers sans dimensionner des pools de machines virtuelles. La facturation fixe par taille facilite la prévision, mais une ressource dédiée peut être peu efficiente si elle reste inutilisée une grande partie du temps. Microsoft propose aussi des déclinaisons Flex et Reserve ; leur adéquation, leur disponibilité et leurs conditions doivent être vérifiées au moment du projet.

Azure Virtual Desktop : une plateforme de bureaux et d’applications

AVD est un service de virtualisation sur Azure. Il fournit bureaux complets et RemoteApps, en session unique ou multiple. Microsoft précise que la capacité dépend des ressources, applications et charges : un ratio universel serait trompeur.

L’organisation choisit les hôtes, les images, les profils, le stockage, le réseau, les groupes d’hôtes et la stratégie de mise à l’échelle. Cette flexibilité peut améliorer l’efficacité pour des usages simultanés prévisibles ou saisonniers. Elle introduit aussi une exploitation Azure : capacité, coûts variables, images, profils, supervision et reprise doivent être conçus.

Remote Desktop Services : publier depuis Windows Server

RDS s’appuie sur plusieurs rôles Windows Server : Session Host, Connection Broker, Gateway, Web Access et Licensing. Ils exécutent les sessions, distribuent les connexions et sécurisent l’accès. Une architecture résiliente traite certificats, haute disponibilité, sauvegarde et mises à niveau.

RDS reste pertinent pour certaines applications conçues pour Windows Server, des dépendances très locales ou un investissement existant maîtrisé. Il ne faut toutefois pas le conserver par inertie. Les CAL RDS, les versions supportées et les composants d’infrastructure font partie du coût et du risque. Une migration vers AVD peut simplifier certaines couches, mais elle ne répare pas une application lente ou non supportée.

Comparatif complet : quel modèle correspond à votre organisation ?

Il n’existe pas de gagnant absolu : Windows 365 optimise la simplicité, AVD la flexibilité et RDS le contrôle d’un environnement Windows Server. Une organisation peut d’ailleurs combiner les modèles, par exemple Cloud PC pour les utilisateurs permanents et RemoteApp AVD pour une application spécialisée.

Comparer le coût total sans fabriquer un prix par utilisateur

Un comparatif financier sérieux part des profils, des heures d’usage et des responsabilités, pas d’un tarif isolé trouvé en ligne. Les prix, devises, remises, licences éligibles et conditions évoluent. Cette analyse n’affiche donc pas de montant non vérifié. Elle propose une méthode reproductible.

Pour Windows 365, comptez les Cloud PC par taille, les licences requises, le réseau, la sauvegarde applicative et le support. Le surdimensionnement coûte pendant toute l’attribution ; le sous-dimensionnement dégrade l’expérience.

Pour AVD, additionnez machines virtuelles actives, disques, stockage de profils, réseau, images, sauvegarde, supervision et temps d’administration. Modélisez séparément les heures de pointe, les soirées et les week-ends. L’autoscale peut réduire les périodes inutiles, mais seulement si les seuils et la capacité minimale protègent la connexion des utilisateurs.

Pour RDS, comptez hôtes de session, broker, passerelle, Web Access, serveur de licences, certificats, stockage, sauvegarde et haute disponibilité. Ajoutez Windows Server et les CAL RDS applicables. Un environnement amorti n’est pas gratuit : renouvellement matériel, énergie, datacenter, correctifs et astreinte subsistent.

Présentez trois scénarios — normal, pointe et dégradé — sur la même période. Comptez le temps IT, les interruptions et l’onboarding. Un abonnement supérieur peut être rationnel s’il retire une charge réelle ; une plateforme flexible peut gagner si l’équipe sait l’optimiser.

Sécurité : centraliser les données ne suffit pas

Le poste distant réduit certaines copies locales, mais sa sécurité dépend toujours de l’identité, du terminal, de la session et des administrateurs. Exigez l’authentification multifacteur adaptée, l’accès conditionnel, des rôles séparés, des comptes d’urgence protégés et des journaux exploitables. Bloquez l’authentification ancienne et limitez les comptes privilégiés.

Décidez ce que la session peut rediriger : presse-papiers, disques locaux, imprimantes, microphones, caméras et périphériques USB. Une interdiction générale peut rendre l’outil inutilisable ; une autorisation générale peut faciliter l’exfiltration. Appliquez des règles par profil et testez les exceptions métier.

Pour Windows 365, la gestion dans Intune rapproche les Cloud PC des autres terminaux administrés. Pour AVD, il faut aussi durcir les hôtes, protéger les images, gérer les profils, sécuriser le réseau Azure et surveiller la capacité. Pour RDS, la passerelle, les certificats, les correctifs et l’exposition réseau requièrent une attention continue. Ne publiez pas directement un hôte de session sur Internet.

Vérifiez la localisation et les traitements dans les régions et contrats choisis. Le RGPD ne se résume pas au datacenter : finalité, accès, conservation, sous-traitants, journaux et incidents comptent. Documentez aussi la continuité si Internet, Azure, l’identité ou l’application devient indisponible.

La page GVISION consacrée aux bureaux virtuels VDI aide à cadrer hébergement, accès, applications et support. Elle doit convertir une fois le profil retenu ; le présent guide reste volontairement comparatif.

Cinq scénarios belges pour raisonner par profil

La taille de l’organisation compte moins que la stabilité de l’usage, la diversité applicative et l’expertise disponible.

Cabinet avec collaborateurs permanents

Les utilisateurs travaillent chaque jour dans Microsoft 365 et quelques applications Windows. Ils veulent retrouver le même bureau depuis le cabinet, le domicile ou un site client. Windows 365 facilite l’affectation individuelle et le budget. Le pilote doit valider impression, scanner, signature, Teams et performances de l’application métier.

Groupe multi-sites avec équipes en horaires

Plusieurs personnes utilisent les mêmes applications à des moments différents. AVD multi-session peut mutualiser les ressources si les applications supportent ce mode et si la concurrence réelle est mesurée. Le calcul doit inclure pics de connexion, image, profils FSLogix, réseau et assistance en début de poste.

École ou centre de formation

Les apprenants ont besoin d’un environnement standard pendant des plages précises. AVD peut publier un bureau ou une application à une cohorte et arrêter une partie de la capacité hors cours. Windows 365 reste pertinent pour le personnel permanent ou certains laboratoires personnels. Les licences éducation et conditions d’accès doivent être vérifiées.

Organisation avec une application serveur patrimoniale

L’éditeur certifie son logiciel sur Windows Server et la base reste sur le réseau local. Un RDS correctement maintenu peut être la décision la moins risquée à court terme. Elle doit être accompagnée d’un calendrier de support, d’une haute disponibilité proportionnée et d’une étude de modernisation, afin que la contrainte ne devienne pas permanente par défaut.

Administration ou établissement de santé

Les rôles, données et périphériques varient fortement. Évitez un déploiement uniforme. Un poste personnel peut convenir aux fonctions administratives ; une RemoteApp peut limiter l’accès à une application ; un environnement local peut rester nécessaire pour une dépendance technique. DPO, sécurité, responsables métiers et support doivent valider les profils et les usages interdits.

Arbre de décision : quatre questions avant l’appel d’offres

La persistance, la mutualisation, la publication d’applications et les dépendances locales départagent les options plus sûrement que la marque. Utilisez l’arbre comme filtre initial, puis confirmez par un pilote.

1. Chaque personne a-t-elle besoin d’un poste persistant et régulier ? Évaluez Windows 365.
2. Faut-il partager la capacité, publier une application ou adapter fortement l’environnement ? Évaluez AVD.
3. Une application exige-t-elle Windows Server ou une proximité locale ? Évaluez RDS et un plan de modernisation.
4. Les profils divergent-ils ? Séparez-les au lieu de forcer une seule solution.

Tester le poste distant en six étapes

Un pilote utile reproduit une journée de travail et produit des preuves, pas seulement une connexion réussie.

1. Segmenter les utilisateurs

Créez des profils : permanent, occasionnel, externe, mobile, application lourde et application unique. Relevez horaires, simultanéité, données, périphériques et niveau de support. Choisissez cinq à quinze testeurs représentatifs plutôt que uniquement l’équipe IT.

2. Inventorier les applications

Pour chaque logiciel, documentez éditeur, version, système supporté, base, ports, latence, impression, mises à jour et licence. Testez les composants qui semblent secondaires : plug-ins Outlook, macros, pilotes, signatures et exports vers des partages.

3. Construire le modèle de coûts

Comparez trois tailles ou capacités réalistes. Ajoutez licences, stockage, réseau, sauvegarde, supervision et exploitation. Pour AVD et RDS, mesurez le nombre réel de sessions simultanées ; pour Windows 365, suivez l’usage des tailles attribuées.

4. Tester l’expérience

Mesurez temps de connexion, ouverture d’application, saisie, impression, audio et reconnexion. Testez au bureau, à domicile et sur une connexion moins stable. Notez les incidents avec heure, utilisateur, réseau, hôte et application pour éviter les impressions vagues.

5. Valider sécurité et exploitation

Vérifiez MFA, accès conditionnel, redirections, rôles, journaux, correctifs, images, sauvegarde et restauration. Simulez un utilisateur bloqué, un profil corrompu, un hôte indisponible et une saturation. Écrivez qui intervient et avec quel délai.

6. Décider par profil

Comparez expérience, coût total, risque et charge d’administration. La décision peut être mixte. Documentez aussi les conditions qui imposeraient une révision : croissance, nouvel éditeur, fin de support, changement de licence ou nouvelle exigence de localisation.

Dix erreurs fréquentes

Les erreurs les plus coûteuses viennent d’hypothèses non testées sur la simultanéité, les applications et l’exploitation.

1. Choisir par taille d’entreprise. Les profils d’usage sont plus déterminants.
2. Comparer uniquement les licences. Le temps d’administration et l’infrastructure changent le total.
3. Supposer un ratio fixe d’utilisateurs par hôte. Microsoft recommande de valider selon ressources et charges.
4. Ignorer les périphériques. Impression, scanner, audio et USB peuvent bloquer le projet.
5. Tester sur un réseau parfait. Le domicile et les sites distants révèlent latence et perte.
6. Mettre tous les utilisateurs sur la même taille. Les profils lourds et légers doivent être séparés.
7. Oublier les images et profils. Ils déterminent les mises à jour et la stabilité d’AVD/RDS.
8. Exposer RDS directement. Utilisez une architecture sécurisée avec passerelle et contrôle d’accès.
9. Promettre des économies avant le pilote. Elles dépendent du taux d’usage et de l’exploitation.
10. Ne pas prévoir de sortie. Documentez données, profils, applications et migration future.