Proxmox ouvre une vraie voie Horizon VDI

Proxmox Server Solutions a annoncé le 4 septembre 2026 que Proxmox VE a été certifié dans le cadre du programme Omnissa Horizon Ready Hypervisor. Le point important n’est pas le badge en lui-même. C’est le modèle d’exploitation supporté : Horizon peut désormais broker des postes de travail et des applications exécutés sur Proxmox VE en Manual Provisioning Mode, Proxmox renvoyant également vers des configurations certifiées pour l’usage de NVIDIA vGPU.

Pour les banques luxembourgeoises, les gestionnaires de fonds, les AIFM, les PSF et les équipes IT d’entreprise, c’est un signal supplémentaire que la discussion d’architecture post-VMware gagne en maturité. La question n’est plus simplement de savoir si Proxmox peut exécuter des workloads KVM stables. Beaucoup d’équipes savent déjà que c’est le cas. La question au niveau de la direction est de savoir si une virtualisation ouverte peut être intégrée dans une pile end-user computing régulée, supportable et auditable, sans créer un risque opérationnel inacceptable. Cette certification ne résout pas tous les problèmes de conception Horizon, mais elle lève l’un des blocages classiques : une VDI non supportée sur un hyperviseur alternatif.

Impact réglementaire et métier

DORA a changé le ton des décisions d’infrastructure. Une plateforme moins chère n’est pas automatiquement une meilleure plateforme. Un fournisseur plus familier n’est pas automatiquement un fournisseur plus sûr. Selon les orientations DORA de la CSSF, les organes de direction restent responsables de la gestion des risques ICT, de l’allocation budgétaire, de la supervision des tiers et de la stratégie de résilience. Cela signifie que la virtualisation des postes, l’accès à distance et le choix de l’hyperviseur sont désormais des sujets de gouvernance, pas seulement des préférences d’ingénierie.

L’évolution Proxmox-Horizon compte parce que la VDI fait souvent partie de la couche d’accès critique des établissements régulés. Traders, équipes d’opérations sur fonds, analystes risques, administrateurs externes et utilisateurs de support privilégié peuvent tous dépendre de postes virtuels ou d’applications publiées. Si cette couche tombe, l’incident reste rarement cantonné à « l’end-user computing ». Il peut devenir un sujet de continuité d’activité, un sujet d’accès privilégié et, potentiellement, un sujet de notification réglementaire si des services critiques sont perturbés.

Il existe aussi un angle de maîtrise des coûts qu’il ne faut pas écarter. Les entreprises européennes sont sous pression pour rationaliser leurs parcs VMware, réduire la concentration des licences et éviter le verrouillage d’infrastructure. Proxmox VE apporte KVM, LXC, du stockage software-defined et du clustering dans une plateforme open source. Omnissa Horizon reste un plan de contrôle EUC commercial. Ensemble, ils créent une voie intermédiaire possible : conserver une expérience utilisateur Horizon familière tout en déplaçant certains pools de postes vers une base de virtualisation moins coûteuse et plus souveraine.

Mais les directions doivent lire la certification avec attention. Le programme Horizon Ready Hypervisor d’Omnissa concerne explicitement Horizon avec des hyperviseurs tiers en Manual Provisioning Mode. La documentation du programme Omnissa indique que le provisioning natif Horizon et la power policy ne sont pas supportés dans ce mode. En clair : ce n’est pas un remplacement à l’identique d’un environnement Horizon sur vSphere fortement automatisé. C’est une voie supportée pour des workloads pré-provisionnés, des postes persistants et des pools contrôlés dont le cycle de vie est géré en dehors de l’automatisation native d’Horizon.

C’est précisément à cette distinction que commence le travail d’architecture régulée. Si une entreprise veut utiliser Proxmox pour la VDI, elle doit concevoir délibérément la couche d’automatisation manquante. Le cycle de vie des golden images, le provisioning des VM, les fenêtres de patch, la rotation des certificats, l’affectation des utilisateurs, la validation des sauvegardes, l’allocation GPU, la gestion de capacité et le disaster recovery doivent tous produire des preuves. DORA récompense les processus maîtrisés. Il ne récompense pas les raccourcis ingénieux mais non documentés.

Blueprint architectural et opérationnel

Une architecture Proxmox-Horizon crédible doit commencer par la segmentation. Les Horizon Connection Servers et les composants Unified Access Gateway doivent s’inscrire dans un design d’accès strictement contrôlé, avec un placement DMZ clair, une hygiène TLS solide, une intégration MFA et de la journalisation. Dans la finance luxembourgeoise, je m’attendrais à ce que ce chemin de trafic soit traité comme un canal d’accès régulé : contrôles WAF ou reverse proxy lorsque c’est pertinent, patterns F5 ou Nginx pour une entrée maîtrisée, gestion rigoureuse du cycle de vie des certificats, et aucune exposition légère des interfaces de management.

La couche Proxmox doit être construite comme une infrastructure de production, pas comme un îlot d’hyperviseurs bon marché. Cela signifie des nœuds Proxmox VE en cluster, des groupes HA lorsque c’est approprié, une conception de stockage résiliente, une séparation réseau documentée pour les flux de management, de stockage, de migration et de VDI, ainsi qu’une restauration testée via Proxmox Backup Server ou un pattern de sauvegarde entreprise équivalent. Si Ceph est utilisé, l’équipe doit démontrer le comportement en latence et en capacité lors des boot storms de postes et des cycles de patch. Si du stockage local adossé à ZFS est utilisé, l’équipe doit démontrer les procédures en cas de défaillance de nœud et de restauration. Les deux designs peuvent être valides. Aucun ne doit être supposé valide par défaut.

Le Manual Provisioning Mode renvoie la responsabilité du cycle de vie vers l’équipe infrastructure. Cela peut être une force si l’automatisation est correctement conçue. Ansible doit prendre en charge la configuration de base, le durcissement des templates VM, les mises à jour de paquets, les agents de monitoring, les étapes de jonction au domaine le cas échéant, et la validation post-build. Terraform ou des workflows pilotés par API peuvent être utilisés pour le provisioning lorsque le modèle d’exploitation s’y prête. Le point clé est de rendre la création des postes répétable et auditable, sans dépendre de la mémoire d’un ingénieur.

L’observabilité est le second plan de contrôle. Zabbix ou Prometheus peuvent suivre la santé des nœuds, la pression sur le stockage, l’état de la réplication, l’utilisation GPU et la saturation réseau. Grafana doit exposer des indicateurs de service lisibles par la direction : capacité de postes disponible, sessions en échec, latence de connexion, statut des sauvegardes et conformité de patching. Les événements Horizon, les logs d’événements Windows, les journaux de tâches Proxmox et la télémétrie firewall doivent alimenter une couche de preuves interrogeable. Lorsqu’un incident survient, l’équipe ne doit pas passer deux heures à démontrer si le problème vient de l’identité, du broker, de l’hyperviseur, du stockage ou du réseau.

C’est aussi un bon cas d’usage pour de l’AIOps privée. Je n’enverrais pas aveuglément des logs Horizon, des identifiants utilisateur ou de la télémétrie d’infrastructure privilégiée vers un service d’IA public. Pour les entreprises régulées, une petite pile d’inférence locale utilisant vLLM ou Ollama, combinée à Qdrant pour la connaissance incident et la récupération de runbooks, peut aider les ingénieurs à trier les incidents récurrents sans exporter de données opérationnelles sensibles. Des agents de type LangGraph peuvent assister la corrélation et les suggestions de runbooks, mais les points d’approbation doivent rester sous contrôle humain pour les actions de remédiation.

L’architecture de sécurité doit être explicite. Les accès privilégiés Proxmox doivent être séparés de l’administration Horizon. Les comptes break-glass doivent être surveillés. Les tokens API doivent être scopés, rotés et stockés correctement. Les sauvegardes doivent être immuables ou protégées contre une compromission administrative. La VDI avec GPU ajoute une couche supplémentaire : firmware, drivers, guest tools et isolation des workloads doivent faire partie du processus de patching et de gestion des vulnérabilités, et non constituer une exception au motif que « les postes GPU sont spéciaux ».

Ce que cela change concrètement

• La VDI peut entrer dans la roadmap de sortie de VMware. Proxmox n’est plus seulement une option de consolidation serveur ; il peut désormais être évalué pour certains pools de postes Horizon.
• Le Manual Provisioning Mode doit être compris par le management. C’est supporté, mais cela modifie les responsabilités d’automatisation. Les limites du provisioning natif et de la power policy doivent être reflétées dans le modèle d’exploitation.
• Les économies doivent être démontrées. Comparez les licences, le support, le stockage, la sauvegarde, le temps d’ingénierie, l’effort de migration et le risque opérationnel. Ne vendez pas le mouvement sur le seul coût de l’hyperviseur.
• La documentation DORA devient partie intégrante du design. Maintenez les schémas d’architecture, les cartographies de dépendances, les contrôles d’accès, les objectifs de reprise, les résultats de tests et les preuves de support tiers.
• Commencez par des pools bornés. Les postes administrateurs persistants, les environnements développeurs, les pools de test GPU ou les applications internes à moindre risque sont de meilleurs premiers candidats que les workflows de production les plus sensibles au temps.
• Automatisez avant de passer à l’échelle. Si la création d’images, le patching, l’affectation et le rollback sont manuels à 50 postes, ils deviendront une dette opérationnelle à 500.
• Construisez un graphe de preuves d’incident. Corrélez la télémétrie Horizon, Proxmox, identité, firewall, stockage et sauvegarde afin que l’analyse de cause racine soit rapide et défendable.

Comment Ali Run AIOps aborde ce sujet

Chez Ali Run AIOps, j’examine ce type de bascule selon trois axes : résilience, souveraineté et coût d’exploitation. Proxmox peut être une plateforme solide, mais seulement lorsqu’elle est conçue avec la même discipline que celle attendue de la virtualisation d’entreprise traditionnelle : design HA, validation des sauvegardes, monitoring, gouvernance des patchs, contrôle d’accès et reprise documentée. Pour les services financiers, la cible n’est pas « l’open source parce que c’est moins cher ». La cible est une indépendance contrôlée sans affaiblir l’auditabilité.

Notre approche de conseil consiste à construire l’architecture et les preuves opérationnelles ensemble. Cela inclut le design de clusters Proxmox, les patterns d’intégration Horizon, l’automatisation Ansible, l’observabilité Zabbix/Grafana, la conception sécurisée de reverse proxy et d’access gateway, ainsi que des workflows d’AIOps privée pour la réponse à incident. Le résultat doit être une plateforme VDI que la direction financière peut défendre en comité des risques : risque de concentration réduit, structure de coûts plus lisible et contrôle opérationnel renforcé.

Sources

• Proxmox: Proxmox VE achieves Omnissa Horizon Ready Hypervisor Certification
• Omnissa Tech Zone: Horizon Ready Hypervisor programme
• Omnissa Product Interoperability Matrix: Hypervisors
• CSSF: ICT and cyber risk for DORA entities
• CSSF: Updates of circulars related to ICT risk management and ICT outsourcing