Visioconférence sans coupure : pourquoi le Hot Failover ne suffit pas à lui seul

Quand on veut sécuriser une visioconférence, on pense d'abord à la panne totale : une pelleteuse, une coupure de courant, un incident chez l'opérateur. Dans la pratique, c'est le cas le plus rare. Ce qui ruine réellement une transmission en cours, ce sont la perte de paquets et les variations de latence sur une ligne qui reste formellement « up ».

L'ordre de grandeur aide à comprendre. Pour l'émission d'un flux 1080p, Zoom indique environ 3,8 Mbit/s en upload ; un partage de présentation en parallèle ajoute environ 50 à 150 kbit/s, le canal audio 60 à 80 kbit/s. Un poste de diffusion professionnel a donc besoin d'environ 4 Mbit/s en upload — sur un accès disposant de 40 ou 300 Mbit/s en upload, c'est une erreur d'arrondi.

C'est exactement là que réside l'erreur de raisonnement de nombreux concepts de sécurisation : la bande passante n'est pas le problème. Le problème, c'est la régularité de la distribution. Un codec temps réel ne peut pas redemander un paquet perdu et attendre — la lecture continue. S'il manque un paquet, un artefact apparaît ; s'il en manque plusieurs à la suite, l'image se fige ou le son se coupe. Deux pour cent de perte de paquets sur une ligne à 300 Mbit/s sont invisibles pour un téléchargement de fichier et nettement audibles pour une transmission en direct.

Il en découle l'exigence réelle : il ne s'agit pas d'avoir une ligne de secours. Il s'agit de faire en sorte qu'une erreur sur la ligne active n'arrive pas jusqu'au destinataire.

Le Hot Failover est un mode de fonctionnement du tunnel SpeedFusion. Le tunnel est établi sur toutes les connexions WAN concernées et maintenu actif sur toutes ; à chaque instant, seul le chemin ayant la priorité la plus élevée transporte toutefois le trafic utile. S'il tombe, le suivant prend le relais.

L'avantage décisif par rapport à un failover classique sans tunnel : la session reste établie. Comme le trafic circule dans le tunnel et que l'extrémité distante conserve la même adresse, l'application ne remarque aucun changement d'adresse. Il n'y a pas de nouvelle authentification, pas de reconnexion, pas d'exclusion de la réunion. Pour un système de conférence, cela fait une grande différence par rapport à un routeur qui change simplement de route par défaut.

Et voici la faille dont on parle rarement dans les offres : la commutation ne commence que lorsque la panne est détectée. Elle est détectée par la surveillance des lignes et par les keepalives du tunnel. La rapidité de ce processus résulte du produit de l'intervalle de contrôle et du nombre de répétitions avant qu'une ligne soit considérée comme morte — plus le temps nécessaire à la commutation elle-même.

Pendant cette fenêtre, le son est absent. Que ce soit trois, cinq ou quinze secondes dépend de l'agressivité avec laquelle la surveillance a été configurée ; les valeurs du graphique ci-dessus sont un ordre de grandeur typique issu de la pratique et non une valeur de fiche technique de Peplink. Des réglages agressifs raccourcissent la fenêtre, mais augmentent le risque de déclenchements erronés lors d'un bref pic de latence.

Plus important encore : le cas d'erreur le plus fréquent n'est pas du tout traité par le Hot Failover. Une ligne présentant deux pour cent de perte de paquets n'est pas en panne. Elle satisfait à chaque contrôle, reste active et fournit en permanence une mauvaise image.

WAN Smoothing résout le même problème par l'autre bout. Au lieu de choisir une ligne et d'en changer en cas de panne, le tunnel envoie les mêmes paquets simultanément sur plusieurs lignes. L'extrémité distante retient la copie qui arrive la première et rejette les doublons.

Cela a trois conséquences qui correspondent exactement à une transmission en direct :

• Il n'y a aucune commutation. Si une ligne tombe au milieu d'une phrase, le paquet est arrivé depuis longtemps par l'autre. Aucune fenêtre de détection, aucun trou — pas même les trois secondes.
• La perte de paquets sur une ligne devient invisible, tant que les deux chemins ne perdent pas le même paquet en même temps. C'est peu probable avec des lignes technologiquement indépendantes.
• La latence descend à celle du chemin le plus rapide. Comme c'est toujours la première copie qui gagne, on n'obtient pas la moyenne des deux lignes, mais le minimum. Une deuxième ligne lente ne dégrade donc pas la connexion — elle ne peut que l'améliorer.

Le prix, c'est de la bande passante, et de façon planifiable par paliers. Le niveau Normal double le volume de trafic, Medium le triple, High le quadruple ; Maximum dépend du nombre de paires de connexions actives. Pour notre poste de diffusion avec 4 Mbit/s de charge utile, le niveau Normal signifie donc 8 Mbit/s sur l'accès — une bagatelle sur une ligne professionnelle.

Le point de référence est important : le trafic supplémentaire ne concerne que le trafic qui circule dans le tunnel lissé. Qui active le smoothing globalement pour toute la maison double aussi chaque téléchargement et chaque sauvegarde. C'est précisément pour cela qu'il appartient à un sous-tunnel dédié.

Entre « ne rien faire » et « tout envoyer en double » se situe la Forward Error Correction. Au lieu de transmettre des copies complètes, la FEC complète le flux de données par des informations de correction à partir desquelles l'extrémité distante peut reconstruire les paquets perdus sans les redemander.

Le trafic supplémentaire est ainsi nettement plus faible. Les niveaux statiques se situent autour de 13 pour cent et de 27 pour cent ; la variante adaptative se règle dynamiquement entre environ 7 et 20 pour cent, en fonction de la perte mesurée. Au lieu d'un doublement, on paie donc un supplément situé dans le bas de la plage à deux chiffres en pourcentage.

En contrepartie, une restriction s'applique : la FEC reconstruit tant que l'information de correction suffit. En cas de panne de ligne franche ou d'une longue rafale de pertes, elle ne suffit pas — le paquet reste alors manquant. La FEC est donc le bon choix lorsque la bande passante est limitée ou que le chemin ne va que dans un seul sens, par exemple pour un livestream vers une plateforme. Pour une conférence bidirectionnelle exigeant une sécurité de fonctionnement maximale, le smoothing reste l'outil le plus puissant — et les deux procédés peuvent fonctionner en parallèle sur des sous-tunnels séparés.

Les cahiers des charges contiennent souvent une formulation du type : sécurisation par Hot Failover, en cas de besoin complétée par WAN Smoothing. Cela paraît raisonnable et n'est pas réalisable techniquement, du moins pas de la manière dont c'est entendu.

WAN Smoothing est un réglage fixe dans le profil du tunnel, pas une boucle de régulation. Il n'existe aucun automatisme qui l'activerait de lui-même lorsque la latence augmente ou que la perte de paquets s'accroît. Qui planifie « en cas de besoin » doit donc définir lui-même ce cas de besoin — et il n'existe exactement que trois réponses solides :

1. Actif en permanence pour le sous-tunnel critique. Le trafic supplémentaire est connu et faible, le bénéfice est toujours là. C'est la bonne réponse dans presque tous les cas.
2. Piloté par horaire, en liant la règle qui dirige le trafic vers le tunnel lissé à un profil temporel. Judicieux lorsque le volume est limité et que les heures de diffusion sont fixées.
3. FEC en permanence, avec le smoothing uniquement pour des événements définis. Le compromis pour les lignes limitées.

Le constat inconfortable qui se cache derrière : une sécurisation qui n'intervient qu'après la détection d'un problème ne peut jamais empêcher la première occurrence de ce problème. Pour une transmission en direct, c'est justement cette première occurrence qui constitue le dommage.

La solution propre sépare le trafic critique du reste au lieu de doubler tout le réseau. Peplink a introduit les sous-tunnels à cet effet avec le firmware 8.0.1 : un lien SpeedFusion peut porter plusieurs sous-tunnels — la documentation en indique jusqu'à cinq — et chacun avec son propre profil. Un tunnel, plusieurs comportements.

La configuration dans la pratique :

1. Le poste de diffusion reçoit une adresse fixe via une réservation DHCP et se trouve dans un VLAN dédié. Sans adresse stable, aucune règle n'est fiable.
2. Créer un sous-tunnel avec WAN Smoothing, niveau Normal comme point de départ.
3. Une règle de trafic dirige le trafic de cet unique ordinateur vers ce sous-tunnel — l'affectation par adresse source est plus robuste qu'une règle portant sur les ports, car elle fonctionne indépendamment des ports que le logiciel de conférence utilisera à la prochaine mise à jour.
4. Tout le reste passe directement par les lignes ou par un deuxième sous-tunnel en mode Hot Failover. Les sauvegardes et les gros téléversements reçoivent en plus une limitation de bande passante, afin qu'ils n'évincent pas le poste de diffusion.

Deux points sur lesquels cela échoue dans la pratique. Premièrement, un tunnel SpeedFusion a toujours besoin d'un point distant — un deuxième appareil Peplink, un FusionHub ou le service hébergé SpeedFusion Connect. Sans extrémité distante, il n'y a pas de smoothing, seulement de la répartition de charge. Deuxièmement, cela ne va pas de soi côté volume de données : ce que le tunnel lissé transmet en double compte aussi en double au point distant. Nous avons détaillé ce calcul dans un article dédié.

Et la phrase la plus importante pour finir, parce qu'elle n'apparaît pas sur le schéma réseau : la redondance des lignes protège contre les défauts de lignes. Elle ne protège pas contre un poste de diffusion planté, un adaptateur d'acquisition bloqué ou un incident chez le fournisseur de conférence. Qui veut réellement sécuriser une transmission place aussi l'ordinateur et l'écran sur l'onduleur et tient un deuxième ordinateur prêt comme co-animateur.

Cet article a été documenté et rédigé avec l'assistance de l'IA, puis vérifié avant sa publication par les techniciens certifiés Peplink d'Ascend.