> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/fr/services-avances-entreprise/virtual-desktop-infrastructure/vdi-explainer/core-concepts.md). # Concepts fondamentaux ### Modes d’optimisation du module d’extension #### L’application Zoom Workplace VDI prend en charge trois modes de fonctionnement pour le traitement des médias en temps réel : optimisé direct, optimisé par canal et mode de secours Dans le contexte de l’application Zoom Workplace VDI, le traitement des médias en temps réel fait référence au relais et au rendu des médias en temps réel entre le cloud Zoom, l’application Zoom Workplace VDI et/ou le module d’extension. Pour prendre en charge une variété de cas d’usage VDI, l’application Zoom Workplace VDI prend en charge trois modes de fonctionnement distincts pour le traitement et l’optimisation des médias : le mode optimisé direct, le mode optimisé par canal et le mode de secours. Ceux-ci sont abordés dans les sections suivantes. #### Mode optimisé direct : lorsque l’application Zoom Workplace VDI et le module d’extension reçoivent des flux de données indépendants du cloud Zoom Le mode optimisé direct est le mode d’optimisation par défaut pour l’application Zoom Workplace VDI et le module d’extension. Dans ce mode, le cloud Zoom maintient deux flux de données distincts pour un utilisateur VDI optimisé : un pour l’application Zoom Workplace VDI et un autre pour le module d’extension. Cette configuration permet au client distant de l’utilisateur (équipé du module d’extension VDI) de communiquer directement avec le cloud Zoom pour les transferts de données média en temps réel, éliminant la nécessité de faire transiter la plupart du trafic média en temps réel par le bureau virtuel ou via le canal virtuel. Lors du fonctionnement en mode optimisé direct, les éléments suivants se produisent : 1. Le module d’extension reçoit directement du cloud des flux de données pour la vidéo et l’audio. 2. L’application Zoom Workplace VDI gère les données générales de la réunion, telles que les informations sur les participants, les messages de chat ou les Fonctionnalités AI Companion, en les affichant dans l’espace réservé de l’application Workplace, tout en gérant également le partage d'écran entrant en le transférant au module d’extension et en téléversant le contenu local de partage d'écran depuis le bureau virtuel lorsqu’il est actif. 3. Le module d’extension et le bureau VDI utilisent la connexion virtuelle du fournisseur VDI pour communiquer et déterminer le placement et le rendu des médias à l’écran entre les deux couches.

Schéma illustrant comment le cloud Zoom transmet les données à deux destinations distinctes lors de l’utilisation du mode optimisé direct.

#### Mode optimisé par canal : lorsque le module d’extension reçoit des données renvoyées via le bureau virtuel L’optimisation par canal est similaire à l’expérience d’optimisation directe, où le module d’extension continue à restituer les médias de la réunion (comme indiqué dans l’image ci-dessus), mais via un chemin réseau différent. Dans ce mode, les éléments suivants se produisent : 1. Tous les médias de la réunion sont d’abord remis au serveur VDI depuis le cloud Zoom. 2. Le serveur VDI transfère les médias au module d’extension soit par une connexion UDP hors bande, soit via le canal virtuel VDI existant si la connexion UDP ne peut pas être établie. Cette méthode peut être préférée par les organisations qui n’Activent pas l’accès direct à Internet pour les clients légers (ou autres appareils distants), ou qui préfèrent faire transiter les données par leur réseau, mais peut *potentiellement* entraîner une expérience moins bonne que l’optimisation directe si les conditions de routage réseau sont sous-optimales. L’image ci-dessous montre le flux de données de l’optimisation UDP/canal.

Schéma illustrant comment les données sont transmises au bureau VDI et au client distant via une connexion renvoyée.

#### Mode de secours : lorsque tous les médias de la réunion sont acheminés vers le bureau virtuel et traités directement sur celui-ci Le mode de secours représente une expérience VDI totalement non optimisée. Dans ce mode, aucune optimisation des médias ni aucun module d’extension n’est utilisé, et toute la communication s’effectue directement entre le serveur VDI et le cloud Zoom, avec tout le traitement effectué exclusivement sur le serveur VDI. Cette méthode impose une charge de traitement importante sur les ressources du serveur VDI, ce qui entraîne souvent de mauvaises performances, notamment de la lenteur, une vidéo saccadée et un audio déformé. Ainsi, le mode de secours est l’option la moins recommandée et ne doit être utilisé qu’en dernier recours ou lorsque les modules d’extension ne sont pas disponibles. {% hint style="danger" %} **Avertissement** Le mode de secours doit être évité lorsque cela est possible afin de maintenir les performances du serveur. {% endhint %} #### Résumé des modes de connexion L’application Zoom Workplace VDI prend en charge trois modes de connexion distincts, chacun étant adapté à différents besoins opérationnels et de sécurité. Le mode par défaut et le plus efficace est le mode optimisé direct, dans lequel l’application Zoom Workplace VDI et le module d’extension établissent des connexions distinctes au cloud Zoom, en gérant indépendamment leurs parties respectives d’une réunion Zoom afin d’offrir une expérience fluide et optimisée. En plus du mode optimisé direct, l’application Zoom Workplace VDI peut fonctionner dans des configurations alternatives, notamment le mode optimisé par canal et le mode de secours. Ces modes peuvent aider à répondre à des contraintes spécifiques de flux de travail ou de réseau, telles qu’un accès Internet restreint pour les appareils distants, le routage des données pour des préoccupations de confidentialité, ou l’absence de modules d’extension. Le tableau suivant résume les principales différences entre ces modes. | | **Déport des médias** | **Accès direct au cloud depuis le module d’extension** | | ---------------------- | --------------------- | ------------------------------------------------------ | | **Optimisé direct** | ✔ | ✔ | | **Optimisé par canal** | ✔ | | | **Mode de secours** | | | ### Déport des médias WebRTC #### Vue d’ensemble Zoom fournit un client WebRTC basé sur un navigateur via l’ [application Web Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064261) qui peut déporter le traitement audio vers l’Appareil local de l’utilisateur lorsqu’il s’exécute dans un environnement de bureau virtuel. Cela fonctionne sans nécessiter de modules d’extension spécifiques à Zoom, car la plateforme VDI fournit son propre moteur WebRTC local et une infrastructure de redirection qui relie l’application Web Zoom à ce moteur. {% hint style="danger" %} **Avertissement** Le déport des médias WebRTC est actuellement limité à l’audio et ne prend pas en charge l’optimisation vidéo. {% endhint %} Cette Fonctionnalités prend en charge les produits et canaux suivants depuis l’application Web Zoom : * Zoom Phone * Centre de contact Zoom * Connecteur CTI du centre de contact Zoom Cette fonctionnalité est actuellement prise en charge par les plateformes de bureau virtuel suivantes : * Citrix * Omnissa Horizon Consultez le centre d’assistance de Zoom pour plus d’informations sur [la configuration de Zoom VDI pour prendre en charge la redirection WebRTC pour l’application Web Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0083142). #### L’application Web Zoom déporte l’audio WebRTC VDI vers l’Appareil local Lorsque l’application Web Zoom à l’intérieur du bureau virtuel tente d’initialiser l’audio WebRTC, ses requêtes sont interceptées avant que le bureau virtuel n’essaie de capturer ou de traiter l’Audio. Au lieu d’activer la pile média WebRTC intégrée du navigateur dans la session hébergée, la plateforme VDI traduit la signalisation liée à l’audio en messages de contrôle légers. Ces messages sont envoyés via le canal virtuel du fournisseur VDI vers la machine locale de l’utilisateur, redirigeant le trafic audio en temps réel depuis le cloud Zoom directement vers la machine locale de l’utilisateur. Sur la machine locale, le moteur WebRTC natif inclus avec le client VDI (par exemple, Citrix, Omnissa Horizon) reçoit ces messages et devient responsable de toute la capture audio, de l’encodage, du décodage et de la lecture. Le moteur utilise le micro du système local, les haut-parleurs et les ressources de traitement, ce qui contribue à garantir que l’audio ne transite pas par le serveur du bureau virtuel. Le schéma suivant illustre comment les données sont acheminées lors de l’utilisation du déport des médias WebRTC avec l’application Web Zoom et un agent virtuel pris en charge.
Diagram illustrating the Zoom cloud connecting to two different components, with audio going to the Remote Client and Presence, Meeting Data, Video, and Screen Sharing routing to the VDI Desktop

Schéma illustrant comment les médias sont répartis entre le bureau virtuel et l’Appareil du client distant.

#### Interaction entre l’application Web Zoom et la machine locale Du point de vue de l’application Web Zoom, l’expérience ressemble toujours à une session WebRTC Standard. La signalisation entre l’application Web Zoom et l’infrastructure de Zoom est relayée via le bureau virtuel, et le moteur WebRTC local reflète les paramètres de session négociés. L’application de bureau virtuel continue de présenter l’interface Zoom — commandes, statut de la réunion et indicateurs — tandis que l’audio réel en temps réel est produit et consommé par la machine locale. Comme seuls les messages de signalisation traversent le canal virtuel, la surcharge de bande passante est faible et constante, même dans les environnements multi-utilisateurs. #### Pourquoi aucun module d’extension n’est requis L’élément clé est que le client VDI (par exemple, Citrix, Omnissa Horizon) inclut déjà un moteur média WebRTC complet capable de gérer l’audio en temps réel. Étant donné que la couche de redirection fait apparaître ce moteur à l’application Web Zoom comme son implémentation WebRTC sous-jacente, Zoom n’a pas besoin de fournir ni de maintenir un module d’extension distinct. La logique de redirection mappe les appels API WebRTC, l’accès aux appareils et la négociation de session depuis le navigateur à l’intérieur du bureau virtuel vers le moteur natif sur la machine locale. #### Résultat Cette approche permet à l’expérience WebRTC basée sur un navigateur de Zoom de fonctionner efficacement dans les environnements VDI avec une optimisation audio complète. L’interface s’exécute à l’intérieur du bureau virtuel, mais l’audio en temps réel est capturé et traité localement, offrant aux utilisateurs une expérience de conférence réactive et évolutive sans nécessiter de logiciel Zoom supplémentaire sur la machine locale ni de charges de traitement provenant du serveur du bureau virtuel. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://library.zoom.com/technical-library/fr/services-avances-entreprise/virtual-desktop-infrastructure/vdi-explainer/core-concepts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.