> 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/espace-admin/architecture-and-design/bcdr-whitepaper.md).

# Livre blanc sur la continuité des Affaires et la reprise après sinistre

## **Introduction**

Zoom fournit des Communications unifiées en tant que service (UCaaS) et un Centre de contact en tant que service (CCaaS) axés sur l’IA via une plateforme unique et intégrée. Ce document détaille les innovations et l’architecture qui sous-tendent les services et produits de premier ordre de Zoom, en expliquant comment nous offrons une expérience cohérente, sécurisée et facile à gérer aux utilisateurs finaux et à l’informatique dans l’ensemble de l’UCaaS et du CCaaS.

## **Conçu à partir de l’expérience**

La vision cloud-first de Zoom aide les organisations à dépasser le coût et la complexité des systèmes hérités sur site. Plutôt que d’ajouter des fonctionnalités à des piles vieillissantes, nous avons investi dans une ingénierie full-stack pour les clients, les services média et les systèmes de salle afin d’optimiser la qualité, la résilience et la facilité d’utilisation de bout en bout en tant que plateforme cohésive unique — fondée sur une stratégie à client unique avec une base de code commune sur les différentes plateformes, qui tire parti de l’UX native de chaque SYSTÈME D'EXPLOITATION.

Cette approche cloud-first se retrouve dans l’application Zoom Workplace : une application unique et moderne qui donne aux utilisateurs un accès centralisé à Réunions, Chat, Téléphone, Centre de contact, Événements, Webinaires, Salles, Tableau blanc, Canvas et plus encore. Access est régi par les licences, afin que l’informatique puisse activer ou désactiver des produits et des fonctionnalités sans déployer un ensemble disparate d’installateurs séparés ni gérer des versions de client incompatibles.

Pour l’informatique, ce modèle réduit la surcharge — moins de serveurs à acheter, à mettre en rack et à corriger ; moins d’intégrations sur mesure à maintenir ; et plus besoin d’équipes entières dédiées au maintien de l’infrastructure sur site en fonctionnement. La capacité, les mises à jour et les améliorations de sécurité sont fournies depuis le cloud, de sorte que les administrateurs peuvent se concentrer sur les politiques, l’adoption et les résultats plutôt que sur la maintenance.

## Architecture des médias en temps réel et résilience

Les sections suivantes présentent l’approche de conception de Zoom visant à permettre une expérience multimédia en temps réel de premier ordre.

### Zoom Meetings, Webinaires et Événements

L’architecture de base de notre système repose sur une couche de transport intelligente qui choisit le meilleur chemin en fonction des conditions réelles du réseau et des politiques. UDP est utilisé lorsqu’il est disponible, avec un repli transparent vers TCP/TLS (y compris HTTPS/443) dans les environnements plus restrictifs. Le partage d'écran utilise Reliable UDP pour garantir des mouvements fluides chaque fois que possible, avec un repli automatique si nécessaire. Lors de la connexion à une réunion, un webinaire ou un événement, l’application Zoom Workplace est orientée par géolocalisation vers les ressources disponibles les plus proches afin de réduire la latence. Lorsque les politiques de l’organisation ou les performances l’exigent, le trafic peut emprunter le backbone mondial de Zoom via des liaisons dédiées vers différents centres de données.

<div data-with-frame="true"><figure><img src="https://4108585137-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FnFxtmNHVYydGwOrYTGFv%2F226B9D5D-5C3B-422D-91F5-A157C60A67BD.png?alt=media&amp;token=ee2ef06d-f83a-490c-9fba-e52f4dbe29b3" alt="Diagram detailing how the Zoom App maintains active-active connectivity to failover data centers, zone controllers, and multi-media routers." width="563"><figcaption><p>Vue d’ensemble de l’architecture et de la conception actif-actif des réunions, des webinaires et des événements de Zoom.</p></figcaption></figure></div>

La couche suivante est une couche réactive de qualité de service qui s’adapte aux conditions réseau et Appareil en temps réel. Elle surveille la bande passante, la perte de paquets, la latence et le jitter, et collecte aussi l’utilisation locale du CPU, la mémoire et les E/S réseau. Ces signaux informent les couches supérieures afin qu’elles prennent les actions adaptatives appropriées pour maintenir la qualité et la fiabilité.

Le codec personnalisé et adaptatif de Zoom, au niveau de la session, est réglé pour des performances en temps réel. Les algorithmes environnants optimisent en continu la fréquence d’images et la résolution pour correspondre aux conditions de l’Appareil et du réseau. Pour offrir la meilleure expérience possible selon ce que les conditions Autoriser, Zoom utilise plusieurs flux en Simultanée, et l’application Zoom Workplace sélectionne dynamiquement la couche la plus appropriée. Grâce à une compression efficace, les sessions restent utilisables avec une perte de paquets allant jusqu’à \~45 % ; dans ces cas, l’audio est priorisé par rapport à la vidéo pour garder les conversations claires. L’approche multi-flux ajuste également la bande passante à la capacité de chaque participant à envoyer et recevoir de l’audio et de la vidéo.

La couche de conférence distribuée de Zoom utilise une commutation basée sur l’abonnement sans transcodage ni mixage côté serveur. Les services traditionnels transcodent et mixent souvent les flux, ce qui ajoute une charge CPU et mémoire ; notre approche de commutation est conçue pour réduire l’utilisation des ressources et évoluer efficacement. Les Participants sont acheminés par géolocalisation vers le data center le plus proche et attribués au serveur le moins chargé ; lorsque les participants sont co-localisés, ils peuvent être regroupés sur le même serveur pour plus d’efficacité. L’architecture prend en charge des déploiements sur site et hybrides flexibles et fournit des chemins de trafic en cascade pour les grandes organisations.

Le Serveur de réunion est notre MMR (routeur multimédia), et chaque MMR est regroupé dans une « Zone de réunion ». Les Contrôleurs de zone gèrent tous les MMR et rapportent leur état au Contrôleur cloud global pour chaque Zone de réunion. Les Zones de réunion sont dupliquées pour chaque data center avec exactement la même architecture, et nous pouvons facilement ajouter d’autres zones à la volée pour augmenter la capacité dans chaque région. Les trois couches (le MMR, le Contrôleur Zoom et le Contrôleur cloud global) servent à équilibrer les ressources dans différents emplacements. Si seulement deux participants sont dans une réunion, Zoom peut utiliser des connexions pair à pair pour une excellente vitesse et fiabilité. Tout cela contribue à Autoriser Zoom à maintenir la disponibilité des services de réunion à 99,9 % et à fournir une expérience de visioconférence fiable.

### Zoom Phone

Zoom Phone a été conçu dans le cloud et pour le cloud, en utilisant les adaptations éprouvées de qualité audio déjà Disponible dans nos produits Zoom Meetings et webinaires. L’architecture de Zoom intègre dès le départ la redondance et la résilience, ce qui donne une solution hautement disponible capable de s’adapter pour répondre aux besoins de la plus grande organisation.

Zoom Phone utilise des mécanismes de transport intelligents pour une connectivité fiable dans divers environnements réseau. Pour les médias, il utilise SRTP sur UDP lorsque c’est Disponible, avec un repli transparent vers TCP/TLS, ainsi qu’un débit binaire adaptatif et une atténuation des pertes de paquets pour préserver la qualité audio dans de mauvaises conditions. Pour la connectivité, les appels sont acheminés vers la zone SIP Disponible la plus proche afin de minimiser la latence, avec un basculement automatique entre les data center lorsque cela est nécessaire.

<div data-with-frame="true"><figure><img src="https://4108585137-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2Fc7qphWNnzClbmFTFUBJt%2F39E3A87C-8C89-457C-BDA5-305F26CDFA27.png?alt=media&amp;token=44860c84-cd37-450d-a10e-846c73b8ca48" alt="Diagram showing a Zoom Phone device connected to a primary data center, with a secondary connection to an additional data center for failover events." width="563"><figcaption><p>L’architecture Actif-actif de Zoom Phone</p></figcaption></figure></div>

Zoom dispose de contrôleurs de bordure de session (SBC) redondants dans chacun de ses data center, qui sécurisent les communications client et opérateur. Ces SBC de niveau opérateur facilitent Access pour un large éventail d’organisation, des plus petits Clients aux grandes entreprises mondiales. Des répartiteurs de charge redirigent les communications basées sur SIP vers les commutateurs d’appel de Zoom afin de répartir uniformément le volume d’appel. Cette répartition permet une expérience fluide pour les utilisateurs, même pendant les périodes de inscription de pointe et les heures d’appel Occupé.

Les commutateurs d’appel constituent le contrôle d’appel central de Zoom Phone. Ces composants évolutifs offrent non seulement l’Assistance à la fonctionnalité PBX de base, mais facilitent également les données de télémétrie vers le Tableau de bord Zoom Phone et permettent d’Activer des fonctionnalités telles que la migration des appels Zoom Phone vers Zoom Meetings.

<div data-with-frame="true"><figure><img src="https://4108585137-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FzpgEaRrGK5oT6NQfmFRp%2FB9547F0B-E921-4EFD-B16D-B03FD320F31B.png?alt=media&amp;token=e10984d8-d5e4-4ee2-a9e2-82e612353d5f" alt="A diagram showing the active-active architecture for hardware and SIP zones hosted within a data center" width="563"><figcaption><p>Architecture Actif-actif pour le matériel et les zones SIP hébergées au sein d’un data center</p></figcaption></figure></div>

L’application Zoom Workplace utilise une logique propriétaire pour surveiller la bande passante, la perte de paquets, la latence et la gigue de l’application, tout en collectant également l’utilisation du processeur, la mémoire et les E/S réseau de l’application. Cette technologie surveille activement les appels et effectue des ajustements en temps réel pour surmonter les mauvaises conditions réseau afin d’offrir une qualité d’appel et une fiabilité supérieures dans divers environnements réseau et sur différents appareils.

Le Tableau de bord Zoom Phone capture les données de Qualité de service (QoS) en temps réel et historiques, ainsi que les indicateurs d’utilisation et d’adoption, les journaux d’appels et les indicateurs liés aux services d’urgence nomades. Zoom évalue automatiquement chaque appel avec une note moyenne d'opinion (MOC) (MOS), ce qui permet aux administrateurs informatiques de suivre les performances de tous les appels transitant sur le réseau et d’isoler les problèmes potentiels liés au réseau.<br>

### Zoom centre de contact

À l'instar de Zoom Phone, l'architecture actif-actif du centre de contact Zoom aide à offrir résilience et redondance dans son environnement omnicanal. S'appuyant sur les architectures éprouvées de Zoom Meetings et des services Zoom Phone, le centre de contact intègre de manière transparente des capacités de communication en temps réel avec des fonctionnalités web, créant une interface intuitive qui profite à la fois à votre équipe d'agents et à vos Clients.

Chaque data center dispose de deux zones SIP (Session Initiation Protocol) identiques et interconnectées. Les zones SIP Autoriser que des appels vocaux soient passés et reçus via Internet, et chaque zone est équipée de matériel et de services dédiés pour une durabilité indépendante. Au sein d’un data center, un répartiteur de charge distribue équitablement les appels entre les deux zones SIP. Les appels sont répartis entre un cluster de commutateurs d’appel, qui sont responsables de diverses fonctions telles que le routage des appels, l’établissement et la libération.

Depuis les commutateurs d'appel, les appels se connectent à un SBC au sein de chaque zone, lequel se connecte soit au réseau sous-jacent de fournisseurs de Zoom, soit à un opérateur fourni par le client pour le routage RTC jusqu'à ce que l'appel atteigne sa destination finale. Les SBC, les équilibreurs de charge et les commutateurs d'appel sont complétés par du matériel redondant en veille pour la résilience.

La voix dans le centre de contact Zoom bénéficie de la même adaptation client et du même comportement de transport que Zoom Phone — en utilisant UDP lorsque disponible avec repli vers TCP/TLS —, ainsi l'audio reste clair même sur des réseaux contraints. Pour la vidéo et les canaux numériques, le service exploite l’infrastructure média temps réel de Zoom et la résilience cloud pour une qualité constante et un basculement de secours.

#### Cobrowse

Le service Cobrowse de Zoom centre de contact s’exécute sur une infrastructure distincte du service principal Zoom centre de contact. Lorsqu’une session commence, le kit de développement logiciel (SDK) établit une connexion WebSocket persistante au serveur Cobrowsing hub (CHS) pour une communication bidirectionnelle, le trafic étant acheminé par géolocalisation vers le data center disponible le plus proche afin de réduire la latence. Le service utilise une architecture sans état et distribuée avec un équilibrage de charge dynamique entre les nœuds CHS pour prendre en charge une mise à l’échelle élastique sur les modèles de déploiement cloud, hybrides et sur site.

Pour aider à maintenir la continuité de session, le SDK se reconnecte automatiquement aux nœuds CHS sains si la connectivité est interrompue et peut basculer entre les centres de données avec un minimum de perturbations. Associée à une surveillance continue de l’état de santé et à l’approche de résilience Actif-actif de Zoom, cette architecture est conçue pour offrir des performances de cobrowsing fiables et évolutives pour les environnements Entreprise.

<div data-with-frame="true"><figure><img src="https://4108585137-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FqgrjZ7zNepHGpbyeVtdB%2F2bbf10_uubksQ_iRI6klG25EenQ5w_260403-Cobrowse-SDK-Diagram-1-v2.png?alt=media&amp;token=a734884a-1888-47f3-a03f-f7d896eda153" alt="" width="563"><figcaption><p>Architecture actif-actif pour les zones du SDK Cobrowse hébergées dans un data center</p></figcaption></figure></div>

## **Zoom Node pour les déploiements hybrides et sur site**

[Zoom Node](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer) est une plateforme hybride gérée dans le cloud, qui relie les ressources de votre data center au cloud Zoom, permettant de déployer les modules de service Zoom (workloads) sur site et de les gérer depuis le portail Web Zoom. Deux modules se distinguent par leur résilience : Zoom Meetings Hybrid et Zoom Phone Local Survivability (ZPLS).

[Zoom Meetings hybride](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-meetings-hybrid) achemine les médias en temps réel pour les participants internes via votre Node local, tandis que la signalisation, l’admin et les politiques restent dans le cloud Zoom, et inclut une option de survivabilité locale si les centres de données Zoom deviennent injoignables. Les utilisateurs internes bénéficient de chemins à faible latence et d’une sortie Internet réduite, tandis que les participants externes peuvent se joindre via le cloud comme d’habitude. Les comptes peuvent aussi faire l’ajout de Connecteur d’enregistrement pour une capture locale lorsque nécessaire, avec basculement automatique vers le cloud si la capacité locale n’est pas disponible.

<div data-with-frame="true"><figure><img src="https://4108585137-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FC0GcdeoEhnCKSkpoLPeD%2FC5C3B116-A2C7-46B9-963B-5BDA9FCAFB8B.png?alt=media&amp;token=751a33a1-7c01-4ed3-b6f0-81a036a0887c" alt="Zoom Meetings Hybrid Module shows how users in a local network connect to the Hybrid MMR, cascading to the cloud." width="563"><figcaption><p>Le module Zoom Meetings Hybrid montre comment les utilisateurs d’un réseau local se connectent au MMR hybride, avec cascade vers le cloud.</p></figcaption></figure></div>

[Survivabilité locale de Zoom Phone](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-phone-local-survivability) (ZPLS) maintient les appels principaux disponibles sur un site si le WAN ou le chemin du fournisseur tombe en panne. Les téléphones s’enregistrent localement, les appels d’extension internes continuent et, lorsqu’il est configuré, les appels sortants critiques peuvent être maintenus via un chemin RTC sur site. Lorsque la connectivité revient, le service reprend automatiquement son fonctionnement normal dans le cloud.

<div data-with-frame="true"><figure><img src="https://4108585137-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FUsoAHP6CgWryBUz2JjOz%2FC3998DFD-40AC-4CD0-A76D-32AC5898BE41.png?alt=media&amp;token=7e0b4233-6ab2-4409-801f-961728bb6814" alt="Diagram showing how the ZPLS module supports PSTN, intra-site, and cross-site survivability." width="563"><figcaption><p>Zoom Phone Local Surviability prend en charge plusieurs scénarios de retour en arrière pour la RTC et la connectivité inter-sites en cas d’événement ayant un impact sur le service.</p></figcaption></figure></div>

## **Centres de données distribués à l’échelle mondiale et redondance**

Zoom dispose de brokers et de serveurs de communication répartis entre plusieurs centres de données interconnectés à travers le globe. Nous évaluons en permanence nos centres de données et nos fournisseurs d’accès Internet (FAI) afin d’optimiser les performances pour nos clients en matière de bande passante, de latence et d’isolation pour la reprise après sinistre. Nos centres de données sont situés dans des installations de colocation sécurisées, neutres vis-à-vis des opérateurs et offrant une sécurité physique, une alimentation redondante et un accès simultané aux FAI de premier plan et aux partenaires de peering. Nous avons également certains déploiements chez des fournisseurs de cloud public lorsque les exigences régionales ou de capacité le justifient. Nos installations de colocation sont conçues avec une architecture tolérante aux pannes, une redondance complète et une capacité de basculement rapide. Zoom répartit dynamiquement la charge des serveurs de communication afin de déplacer automatiquement les nouvelles sessions vers le data center qui a le meilleur temps de réponse.

Ces installations sont également conçues pour la résilience au niveau physique. Chaque installation de colocation est construite avec une redondance N+1 et un ensemble complet de contrôles environnementaux destinés à maintenir l’installation opérationnelle en cas de défaillance de composants et de risques physiques :

* Contrôles de température et d’humidité
* Des systèmes d'alimentation entièrement redondants et dimensionnés pour prendre en charge la défaillance d'un composant
* Éclairage de secours résilient
* Protection incendie
* Protection contre les dégâts des eaux

Les data center comprennent des modèles de redondance d'alimentation sans interruption (UPS) tels que N, N+1 ou 2N, ainsi qu'une redondance des générateurs selon une conception N+1, la maintenance de l'alimentation et les tests étant pris en charge par le fournisseur de data center applicable. Lorsque Zoom utilise AWS pour faire office d'hôte d'une partie de son infrastructure cloud, l'existence et le fonctionnement des contrôles AWS sont examinés chaque année par l'équipe Sécurité de Zoom au moyen de rapports d'auditeur de services externes ; toute exception identifiée est discutée avec AWS et, lorsqu'elles sont susceptibles de présenter un risque pour les systèmes ou les données de Zoom, elles sont remontées à la direction de Zoom.

<div data-with-frame="true"><figure><img src="https://4108585137-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FI74U4hZkRltHhURZmGZz%2FDB57E664-C00F-4E57-B8CD-A2A98C9FBBFD.png?alt=media&amp;token=4f3a6c81-c583-4f68-9d65-3e0443d2d9eb" alt="" width="563"><figcaption><p>Emplacements des data center commerciaux de Zoom dans le monde (novembre 2024)</p></figcaption></figure></div>

## **capacité**

Zoom maintient 50 % de capacité excédentaire dans tous les aspects de notre infrastructure afin d'accompagner la croissance de notre activité et de répondre aux exigences d'utilisation de pointe. Nous sommes confiants dans notre capacité à fournir le service et à évoluer en fonction des besoins actuels et futurs de nos clients.

## **Continuité des Affaires et reprise après sinistre**

La fiabilité dans des conditions normales n'est qu'une partie de l'histoire ; tout aussi important est la manière dont la plateforme se comporte lorsque quelque chose tourne mal. Les perturbations — telles que les catastrophes naturelles, les pannes d'alimentation ou d'installation, les incidents cyber, les pannes de réseau et les défaillances du matériel — sont une réalité inévitable pour tout service mondial, et la résilience de Zoom tient à la manière dont il s'y prépare, y résiste et s'en remet. Cette résilience repose sur quatre couches distinctes mais liées, chacune intervenant à un moment différent avant, pendant et après une perturbation :

* **Haute disponibilité** — la couche architecturale qui réduit la probabilité et l'impact des défaillances avant qu'elles ne se produisent, en éliminant les points de défaillance uniques.
* **Continuité des Affaires** — la couche opérationnelle qui maintient le fonctionnement des fonctions métier essentielles lorsqu'une perturbation se produit.
* **Reprise après sinistre** — la couche de restauration qui remet les systèmes et services technologiques concernés à un fonctionnement normal après un événement perturbateur.
* **Tests** — la couche de validation qui confirme que ces pratiques fonctionnent et fait ressortir les enseignements pour une amélioration continue.

Ces couches s'appuient les unes sur les autres : la haute disponibilité réduit la fréquence à laquelle une reprise est nécessaire, la continuité des Affaires régit ce qui reste en fonctionnement pendant ce temps, la reprise après sinistre restaure ce qui a été affecté, et les tests valident l'ensemble. L'architecture décrite tout au long de ce document — des data centers Actif-Actif, du routage basé sur la géolocalisation, un basculement automatique et un déploiement N+1 — constitue en pratique la couche de haute disponibilité. Les sections ci-dessous décrivent les trois restantes.

### Haute disponibilité

La haute disponibilité désigne une conception des systèmes et des services destinée à assurer un fonctionnement continu et un temps d'arrêt minimal, et elle est intégrée aux systèmes de Zoom dans le but de minimiser ou d'éliminer les points critiques de défaillance. Les services sont conçus pour résister à des pannes complètes de data center, et des processus automatisés déplacent le trafic hors d'une zone affectée lorsqu'une défaillance se produit. Les applications de base sont déployées selon un Standard N+1, de sorte que si un data center devient indisponible, une capacité suffisante reste disponible pour équilibrer le trafic entre les sites survivants. Cette philosophie de conception couvre l'ensemble des systèmes dont dépend une plateforme de communication — installations redondantes, infrastructure de téléphonie, connectivité Internet et LAN, infrastructure de sécurité, systèmes de bases de données relationnelles, stockage de masse, sauvegardes, matériel, ainsi que les pratiques associées de gestion de la capacité et de maintenance — afin que la défaillance d'un composant, système ou installation unique n'entraîne pas de perte de service.

### Continuité des Affaires

La planification de la continuité des Affaires de Zoom est conçue pour minimiser l'impact des perturbations sur les opérations, protéger les actifs et maintenir les services essentiels pour les Clients et les parties prenantes. Elle identifie les fonctions d'Affaires qui doivent être préservées ou rétablies en premier, les personnes, la technologie, les fournisseurs et les ressources du lieu de travail dont ces fonctions dépendent, ainsi que l'impact potentiel si ces dépendances sont perturbées. Cela fournit à Zoom une base structurée pour coordonner la réponse et le rétablissement lorsque les opérations normales sont affectées, en particulier lorsque plusieurs fonctions ou ressources nécessitent une attention en même temps.

À la base de cette planification se trouve une analyse d'impact des Affaires (BIA), le processus systématique que Zoom utilise pour identifier et évaluer les effets potentiels des perturbations sur les fonctions critiques d'Affaires. Zoom réalise une BIA pour les fonctions critiques au moins une fois par an, ou lorsqu'un changez important est apporté à un processus critique d'Affaires. L'analyse couvre quatre éléments clés :

1. **Identification des fonctions critiques d'Affaires** — documenter les principaux processus essentiels aux opérations de Zoom et déterminer les dépendances et interdépendances entre eux.
2. **Évaluation de l'impact** — évaluer l'impact potentiel des perturbations sur chaque fonction, en tenant compte des pertes financières, des temps d'arrêt opérationnels, des implications juridiques et réglementaires, ainsi que des atteintes à la réputation.
3. **Exigences en matière de ressources** — identifier le personnel, la technologie, les installations et les services tiers nécessaires pour soutenir le rétablissement, et évaluer leur disponibilité et leur adéquation.
4. **Priorisation des efforts de rétablissement** — ordonner le rétablissement des fonctions critiques en fonction de leur impact et des objectifs de rétablissement établis, afin que les fonctions les plus critiques soient rétablies en premier.

### Reprise après sinistre

Zoom valide régulièrement ses capacités de reprise après sinistre au moyen de tests annuels sur l’ensemble de ses produits. L’entreprise maintient un Plan de reprise après sinistre (DRP) formel et documenté, qui définit les procédures de restauration des systèmes et services critiques à la suite d’une interruption, notamment les stratégies de reprise, les rôles et responsabilités, ainsi que les protocoles de communication. Le DRP de Zoom est conçu pour traiter divers scénarios de sinistre pouvant inclure un ou plusieurs des éléments suivants : pannes de courant, perte de connectivité réseau, défaillances matérielles, catastrophes naturelles et autres événements perturbateurs, jusqu’à et y compris la défaillance totale du site. Les normes de sécurité de l’information régissant la reprise après sinistre sont documentées, approuvées, communiquées et réexaminées au moins une fois par an.

Plutôt que de maintenir un site de reprise à chaud dédié pour les services cloud, Zoom s’appuie sur une architecture redondante, des data centers répartis sur plusieurs sites et plusieurs fournisseurs cloud, dont AWS, OCI et GCP, afin d’assurer la continuité. Au niveau de la plateforme, le schéma de reprise diffère selon le type de service :

* **Cluster web et communications non en temps réel** utilisent une infrastructure AWS à haute disponibilité dans une configuration Actif-Actif multirégion, s’appuient sur des enregistrements DNS pour Activer le basculement entre les data centers, et incluent plusieurs composants dotés de capacités de réplication au sein de chaque data center.
* **Data centers régionaux et communications en temps réel** fonctionnent dans une configuration Actif-Actif à travers des fournisseurs de niveau 3 et supérieur géographiquement dispersés, avec des composants et une connectivité redondants et résilients au sein de chaque data center régional, divers opérateurs prenant en charge la connectivité, et un basculement entre régions nécessitant une reconnexion.

Les stratégies de reprise documentées de Zoom comprennent le basculement de région, qui déplace le trafic ou les services hors d’une région affectée, ainsi qu’un retour arrière via un déploiement blue-green, qui rétablit les services dans un environnement ou un état de déploiement précédemment reconnu comme sain afin de se remettre de problèmes liés au logiciel ou au déploiement.

Ces stratégies sont mesurées au regard d’objectifs de reprise définis. L’objectif de temps de reprise (RTO) — le délai cible pour rétablir le service après une interruption — vise moins de cinq minutes. L’objectif de point de reprise (RPO) — la quantité cible de perte de données tolérable — vise zéro perte de données, grâce à la réplication des données stockées dans le cloud sur plusieurs zones de disponibilité. Ces objectifs guident la conception et les tests de Zoom plutôt que de constituer des garanties de service.

La sauvegarde et la restauration efficaces des données constituent un élément central de cette approche, protégeant les informations critiques afin qu’elles puissent être restaurées en cas d’interruption pour maintenir la continuité des Affaires. Zoom ne partage pas à l’extérieur son plan complet de reprise après sinistre ni les résultats détaillés des tests, car ces documents contiennent des informations internes, sensibles et confidentielles d’Affaires. Se référer à [Centre de confiance de Zoom](https://www.zoom.com/en/trust/legal-compliance/) pour plus d’informations sur la documentation Disponible publiquement.&#x20;

### Tests

Zoom valide ses pratiques de reprise au moyen de tests annuels sur table et de basculement réalisés par des auditeurs tiers. Ces tests confirment que les processus de réponse et de reprise fonctionnent comme prévu, identifient les lacunes et favorisent l’amélioration continue grâce aux enseignements tirés. Les tests ont couvert un large éventail de produits et de domaines de service sur l’ensemble de la plateforme, notamment Zoom Meetings, Zoom Phone, Zoom Centre de contact, Zoom Virtual Agent, Zoom Rooms, Zoom Events, Tableau blanc, réservation d’espace de travail, ainsi que les passerelles RTC et de téléphonie, entre autres. Associée à l’architecture redondante actif-actif décrite tout au long de ce document, cette approche à plusieurs niveaux est conçue pour maintenir les services de Zoom Disponible et récupérables dans un large éventail de conditions perturbatrices.

## **Conclusion**

La fiabilité de Zoom repose sur une architecture à plusieurs niveaux qui combine une conception de services axée sur le cloud, un routage multimédia adaptatif, une infrastructure mondiale redondante, la planification de la capacité, ainsi que des pratiques formelles de continuité des Affaires et de reprise après sinistre. Dans les domaines de Meetings, Phone, Centre de contact, Zoom Node, des centres de données mondiaux et des services associés, la plateforme de Zoom est conçue pour prendre en charge des communications cohérentes sur divers réseaux, régions, appareils et modèles de déploiement.

Les mêmes principes de conception qui favorisent la qualité de service au quotidien soutiennent également la résilience à grande échelle. L’architecture actif-actif, le routage intelligent, le transport adaptatif, les installations redondantes, la planification de la reprise, les pratiques de sauvegarde et les tests réguliers fonctionnent ensemble pour contribuer au maintien des services essentiels et à la reprise lors d’événements opérationnels.

Pour les Clients et les équipes informatiques, cette approche fournit une plateforme conçue pour des communications fiables, une continuité opérationnelle et un déploiement d’Entreprise gérable dans les environnements UCaaS et CCaaS.

*Rédigé par Jakob Ganschow et Sam Azimipour*


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://library.zoom.com/technical-library/fr/espace-admin/architecture-and-design/bcdr-whitepaper.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
