By Brock McKenna on septembre 30, 2026
L'impression dans un environnement de bureau virtuel consiste à combler un fossé : la session de l'utilisateur s'exécute sur un serveur dans un centre de données, et l'imprimante se trouve sur un réseau différent, généralement près de l'utilisateur. Il faut un intermédiaire pour acheminer la tâche d'impression au‑delà de cette frontière, et un autre pour convertir le document en données compréhensibles par l'imprimante.
Il existe trois manières de procéder, chacune résolvant le problème en déplaçant la difficulté ailleurs. Comprendre laquelle vous utilisez explique la plupart des échecs d'impression que vous avez rencontrés.
Sur le papier, chaque approche paraît simple. En pratique, chacune impose un compromis différent.
Comment fonctionne l'impression dans un bureau virtuel ?
1. Redirection d'imprimante dans AVD, Citrix et RDS
La redirection d'imprimante associe les imprimantes installées sur l'appareil local de l'utilisateur à la session virtuelle. Quand l'utilisateur se connecte, ses imprimantes locales apparaissent dans la liste des imprimantes de la session, et les tâches d'impression lancées dans la session transitent de nouveau par le canal d'affichage à distance (RDP & HTML5 pour AVD, RDP pour RDS et ICA pour Citrix) jusqu'au client, qui les transmet ensuite à l'imprimante.
C'est le comportement par défaut : il ne demande aucune infrastructure supplémentaire, mais il introduit trois défaillances prévisibles.
Incompatibilité des pilotes. L'hôte de session a besoin d'un pilote pour l'imprimante redirigée ; à défaut, il en substitue un générique. Si le pilote n'est pas présent dans l'image, l'imprimante n'apparaît pas ou s'affiche avec des fonctionnalités incorrectes. C'est pourquoi les images de référence accumulent les pilotes d'impression, et pourquoi en supprimer un finit toujours par provoquer un incident.
Les noms d'imprimante changent. Dans les environnements multi‑sessions mutualisés, les noms des imprimantes redirigées reçoivent souvent des suffixes spécifiques à la session. Toute application configurée pour imprimer vers un nom d'imprimante fixe (les ERP métiers en sont l'exemple classique) ne la trouve pas. L'application ne renvoie pas d'erreur utile. Elle n'imprime tout simplement pas.
La tâche d'impression traverse deux fois la frontière de la session. Le document est envoyé dans la session, y est rendu, puis le rendu est renvoyé au client. Les données d'impression après rendu sont beaucoup plus volumineuses que le document source, ce qui consomme la bande passante de la session destinée à l'affichage.
L'approche suivante s'attaque à une autre partie du problème : le nombre de pilotes présents dans la session.
2. Les pilotes d'impression universels dans les environnements de bureau virtuel
Un pilote d'impression universel installe un seul pilote dans la session et prend en charge toutes les imprimantes. Il effectue le rendu des tâches d'impression dans un format intermédiaire qui est ensuite converti côté client ou sur un serveur d'impression.
Cela corrige le gonflement des images : un pilote, pas quarante. En revanche, cela ne résout pas le sujet de la bande passante, puisque la tâche rendue traverse toujours la limite de session ; selon l'implémentation, la consommation de bande passante peut même augmenter.
Il introduit aussi un plafond fonctionnel. Un pilote universel n'expose qu'un sous-ensemble commun de fonctionnalités. La sélection du bac, l'agrafage, la perforation et les codes comptables sont parmi les fonctions qui cessent de fonctionner — et ce sont justement celles dont ont le plus besoin certains utilisateurs : l'équipe financière qui imprime sur papier à en-tête depuis le bac 3, l'équipe juridique qui exige un papier spécifique, etc.
Si ni la redirection ni le pilote universel ne représentent une option intéressante, il existe une solution plus directe : laisser l'hôte de session communiquer directement avec l'imprimante.
3. L'impression IP directe depuis une session de bureau virtuel
L'hôte de session imprime directement sur une imprimante réseau via IP, sans redirection et sans intervention du client.
Propre dans un déploiement monop-site où les hôtes de session et les imprimantes sont sur le même réseau. Partout ailleurs, c'est de moins en moins plausible. Si votre pool d'hôtes Azure Virtual Desktop est hébergé en Europe de l'Ouest et que votre imprimante se trouve dans une succursale à Manchester, « IP directe » signifie une route depuis un sous‑réseau Azure vers un VLAN d'imprimante via un VPN de site à site, et la tâche d'impression fait alors un long détour sur votre réseau pour atteindre un appareil situé à quelques mètres de la personne qui l'a lancée.
Cela implique aussi que chaque imprimante doit être accessible individuellement depuis les hôtes de session — un modèle d'accès réseau sur lequel la plupart des équipes de sécurité ont un avis tranché.
Les trois modèles d'impression VDI en un coup d'œil
Pourquoi l'impression pose-t-elle problème dans AVD, Citrix et RDS ?
Parce que dans les trois cas, le pilote reste à l'intérieur de la session — et c'est le pire endroit où il puisse se trouver.
L'hôte de session est une machine partagée, mutualisée et fréquemment reconstruite, qui exécute un spouleur d'impression et y charge du code tiers issu des pilotes. Chaque pilote présent dans l'image représente un risque d'incompatibilité lors de la prochaine mise à jour de Windows. Chaque conflit de pilotes interrompt l'impression pour tous les utilisateurs de cet hôte, pas pour un seul. Et l'image de référence, que votre équipe a soigneusement allégée pour optimiser le démarrage, embarque une bibliothèque de pilotes d'impression dont la seule raison d'être est que l'imprimante se trouve ailleurs.
Puis vient la dimension sécurité. Le spouleur d'impression côté session présente les mêmes propriétés que n'importe quel autre spouleur : il s'exécute avec les privilèges SYSTEM, accepte les appels RPC et charge du code tiers. Microsoft attribue 9 % des problèmes de sécurité Windows signalés au MSRC à la pile d'impression. Exécuter cela sur un hôte multi‑session accueillant des dizaines d'utilisateurs n'améliore pas la situation par rapport à un serveur d'impression.
Cela soulève une autre question. Plutôt que d'essayer de rendre l'impression dans la session plus facile à gérer, que se passerait-il si le rendu quittait complètement la session ?
Qu'est-ce qui change lorsque le rendu d'impression VDI sort de la session ?
Si le rendu de la tâche d'impression s'effectue en dehors de la session, aucun des trois modèles n'est nécessaire, car le problème qu'ils cherchent à résoudre ne se pose plus.
C'est le changement d'architecture qu'opère ezeep.
Avec ezeep, la tâche d'impression quitte la session sous forme de document. Le document fait l'objet d'un rendu dans le cloud reposant sur une bibliothèque de plus de 6 000 pilotes constructeurs. Le résultat est ensuite acheminé vers le ezeep Hub situé à l'emplacement physique de l'imprimante, via une connexion sortante uniquement, puis imprimé. Il ne transite jamais en retour par le canal RDP ou ICA.
Les conséquences sont concrètes :
- Plus aucun pilote d'impression dans l'image de référence. L'image s'allège et cesse d'être une surface de compatibilité pour les pilotes.
- Aucun trafic d'impression sur le canal de la session. La bande passante allouée à l'expérience utilisateur est utilisée pour l'expérience utilisateur.
- Pas de mappage d'imprimantes à l'ouverture de session. Les imprimantes sont attribuées par identité via Entra ID ou Google Workspace. Un utilisateur voit ses imprimantes en fonction de son identité.
- Aucun spouleur d'impression côté session contenant du code de pilotes tiers. Ce qui signifie aussi que le mode Windows Protected Print n'a rien à bloquer, WPP arrivant sur les hôtes de session Windows Server 2025 et Windows 11 24H2.
ezeep prend en charge Azure Virtual Desktop, Windows 365, Citrix, Parallels et Omnissa Horizon. DMK Group, la plus grande coopérative laitière d'Allemagne, l'utilise sur un parc Azure Virtual Desktop de plus de 4 000 utilisateurs.
Et ce n'est pas un problème qu'ezeep ait découvert récemment.
La lignée ThinPrint compte ici. ezeep is built on ThinPrint technology, qui gère l'impression dans les environnements Terminal Services et Citrix depuis les années 1990. L'approche reflète de très longues années passées à observer l'échec récurrent de ce cas précis.
Tout revient à la même frontière : l'utilisateur est à un endroit, la session ailleurs, et l'imprimante encore ailleurs. La question est simplement de savoir où vous choisissez de gérer cette complexité.
