Les logiciels de collaboration auto-hébergés prennent-ils en charge les appels audio et vidéo ? Liste de contrôle de la préparation du réseau

Commencez par définir les appels dont votre équipe a réellement besoin

La mention « prend en charge les appels » ne constitue pas une exigence de déploiement complète. Avant de comparer les options d’hébergement, définissez qui appellera qui, quels clients seront utilisés et d’où ces personnes se connecteront. Une équipe dont les membres partagent le même réseau de bureau peut être confrontée à des contraintes différentes de celles d’une équipe accueillant des invités externes et comptant des utilisateurs sur des connexions domestiques ou mobiles.

Confirmez également les fonctionnalités qui vous importent. La voix, la vidéo, le partage d’écran et les appels avec des participants externes peuvent avoir des exigences de prise en charge ou de configuration différentes. Le [guide de déploiement de Calls de Mattermost](https://docs.mattermost.com/deployment-guide/calls/calls-deployment-guide) décrit Calls comme une fonctionnalité auto-hébergée permettant les appels audio et le partage d’écran. Cette description des fonctionnalités ne permet pas, à elle seule, d’établir que tous les clients ou réseaux d’utilisateurs fonctionneront dans votre environnement.

• Dressez la liste des fonctionnalités d’appel, des types de participants et des types de clients nécessaires, par exemple un navigateur ou une application native.
• Incluez les réseaux que les personnes utiliseront : bureau, domicile, mobile, ainsi que les réseaux d’invités ou de partenaires.
• Déterminez quels échecs sont acceptables. Par exemple, le repli sur l’audio suffit-il si la vidéo ne peut pas se connecter ?

Distinguez l’accès Web, la signalisation et les flux multimédias

Pour commencer, consultez la documentation officielle de déploiement à jour de l’application et répartissez ses exigences entre des chemins distincts. L’interface Web est celle que les utilisateurs chargent ; la signalisation correspond aux échanges qui servent à établir ou à gérer un appel ; les flux multimédias transportent l’audio et la vidéo. La documentation de l’application peut décrire ces chemins séparément ou employer une terminologie différente.

Pouvoir se connecter dans un navigateur confirme l’accès Web, mais ne garantit pas nécessairement que l’établissement de l’appel ou la transmission audio et vidéo dans les deux sens fonctionnera. Consignez les exigences documentées pour chaque chemin au lieu de supposer qu’un site Web opérationnel prouve que les appels sont prêts à fonctionner.

La [présentation de Talk par Nextcloud](https://nextcloud.com/blog/nextcloud-talk-open-source-online-video-conferencing-software/) le décrit comme un logiciel open source de visioconférence en ligne prenant en charge les conversations, les appels, les webinaires et la diffusion. Cette description permet de cerner le périmètre du produit, mais ne précise pas à elle seule la configuration réseau nécessaire pour vos utilisateurs.

• Trouvez la documentation de déploiement du fournisseur correspondant à l’application exacte et au modèle de déploiement envisagé.
• Notez séparément les exigences documentées pour l’interface Web, la signalisation des appels et les flux multimédias.
• Vérifiez si les exigences varient selon le client, la fonctionnalité ou le composant de déploiement ; ne comblez pas les lacunes par des suppositions.

Vérifiez les protocoles, les ports, les pare-feu, le NAT et les relais

Utilisez la documentation officielle pour établir la liste des modifications réseau nécessaires. Notez les protocoles et les ports indiqués, si les connexions doivent être autorisées en entrée, en sortie ou dans les deux sens, ainsi que les systèmes ou points de terminaison concernés. Ne reprenez pas une liste générique de ports provenant d’un autre produit de collaboration : les exigences peuvent varier, et les descriptions de produits disponibles ne précisent pas de valeurs particulières de ports ou de règles de pare-feu.

Recherchez le comportement documenté lorsque les participants se trouvent derrière un NAT ou un pare-feu restrictif. Vérifiez notamment si les connexions multimédias directes sont censées fonctionner, si un relais TURN est pris en charge ou requis dans certaines circonstances, et qui exploite ce relais. Si la documentation ne répond pas à ces questions, considérez-les comme des points de déploiement à clarifier et posez la question au fournisseur de l’application ou de l’hébergement avant le déploiement.

Un relais peut constituer une dépendance plutôt qu’un détail facultatif. Déterminez s’il doit être déployé, être joignable, être configuré dans l’application ou être géré séparément ; confirmez ces points dans la documentation du produit au lieu de les supposer. Le [guide de déploiement de Calls de Mattermost](https://docs.mattermost.com/deployment-guide/calls/calls-deployment-guide) est une source primaire pour commencer avec Mattermost, mais les informations disponibles sur les fonctionnalités ne précisent pas les exigences particulières en matière de ports, de NAT ou de relais.

• Créez un tableau indiquant, pour chaque protocole et port documenté, le sens du trafic, la destination et la fonction.
• Demandez aux administrateurs réseau de vérifier que le trafic nécessaire est autorisé sur les réseaux de bureau et distants concernés.
• Confirmez le comportement documenté pour le franchissement du NAT et l’utilisation de TURN, notamment qui possède le relais et en assume la responsabilité opérationnelle.
• Signalez toute exigence non documentée comme non vérifiée ; ne considérez pas une connexion réussie comme la preuve que le trafic multimédia est autorisé.

Vérifiez TLS, les noms de domaine et les hypothèses concernant le proxy inverse

Vérifiez comment l’application attend la configuration de son domaine public, de la terminaison TLS et de tout proxy inverse. Identifiez le composant qui gère chaque connexion et vérifiez si la documentation officielle indique des exigences supplémentaires pour les appels, au-delà de l’interface Web. Ne supposez pas qu’une configuration de proxy ou de TLS donnée est prise en charge pour toutes les fonctionnalités d’appel, à moins que la documentation de l’application ne le précise.

Une page HTTPS valide ne constitue pas un test complet du chemin d’appel. Elle peut confirmer que le point de terminaison Web est joignable sans pour autant tester les exigences relatives à la signalisation ou aux flux multimédias. Si votre architecture place un proxy devant l’application, comparez l’architecture d’appel documentée au routage et à la configuration des certificats réels, et résolvez toute ambiguïté avant d’inviter les utilisateurs à compter sur les appels.

Les [informations produit d’Airbip](https://airbip.com) décrivent le routage automatisé et les certificats TLS via Traefik et Let’s Encrypt, ainsi que la prise en charge d’un sous-domaine Airbip ou d’un domaine personnalisé compatible. Ces fonctionnalités décrivent la configuration de l’hébergement Web ; à elles seules, elles ne permettent pas d’établir que les fonctions d’appel ou les chemins multimédias d’une application donnée sont pris en charge sur tous les réseaux.

• Confirmez le domaine public requis et le comportement TLS dans la documentation de déploiement de l’application.
• Faites correspondre l’architecture documentée à votre configuration réelle de proxy, de DNS et de certificats.
• Demandez au fournisseur ou au vendeur concerné de clarifier toute exigence relative au proxy ou à TLS pour les appels qui ne serait pas documentée.

Testez avec des utilisateurs représentatifs, pas uniquement avec l’équipe serveur

Une fois la configuration documentée mise en place, effectuez des tests depuis les réseaux que vos utilisateurs utiliseront réellement. Un test réalisé depuis le même bureau ou le même environnement serveur peut ne pas révéler les restrictions présentes sur les réseaux domestiques, mobiles, d’invités ou de partenaires. Incluez au moins un réseau restrictif si ces utilisateurs font partie du public visé.

Suivez une liste de contrôle reproductible : les participants peuvent-ils démarrer et rejoindre un appel, s’entendre dans les deux sens, voir la vidéo si nécessaire et partager le contenu voulu ? Testez ensuite le comportement après l’interruption puis le rétablissement d’une connexion. Si l’application indique qu’un relais est utilisé, consignez le résultat ; ne déduisez pas le comportement du relais de la seule qualité de l’appel.

Un test réussi montre que la configuration testée a fonctionné pour les utilisateurs et les réseaux concernés à ce moment-là. Il ne garantit pas que le réseau, l’appareil ou les modifications ultérieures de réseau de chaque participant se comporteront de façon identique. Les descriptions des produits citées ci-dessus ne prescrivent pas de procédure de test sur des réseaux représentatifs ; considérez donc cette liste comme des conseils généraux de déploiement et non comme une garantie produit.

• Testez chaque type de client nécessaire et les fonctionnalités d’appel que l’équipe prévoit d’utiliser.
• Testez les participants sur les réseaux de bureau, de domicile, mobiles et autres réseaux pertinents, y compris dans des environnements restrictifs lorsque cela est possible.
• Consignez l’établissement de l’appel, l’audio dans les deux sens, la vidéo, le partage d’écran si nécessaire, la reconnexion et le comportement documenté du relais.
• Notez la date, le type de client, le contexte réseau et le résultat afin de pouvoir comparer les résultats après des modifications.

Choisissez un modèle de déploiement en fonction des exigences vérifiées

Ne comparez les options d’hébergement qu’après avoir obtenu les exigences documentées de l’application et vérifié les contrôles réseau dont vous pouvez disposer. Déterminez si vous pouvez configurer les règles de pare-feu nécessaires, exploiter ou obtenir tout service de relais requis et examiner les problèmes rencontrés par les utilisateurs sur leurs différents réseaux.

Un déploiement d’application géré peut prendre en charge certaines parties de l’infrastructure entourant une application, mais cela ne prouve pas automatiquement la prise en charge de toutes les fonctionnalités d’appel ou de tous les chemins réseau. Les [informations produit d’Airbip](https://airbip.com) décrivent des instances d’applications exécutées sous forme de charges de travail Docker sur ses serveurs cloud, ainsi que la gestion du cycle de vie des services, les vérifications DNS et des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Évaluez ces fonctionnalités en complément — et non à la place — des exigences propres aux appels confirmées dans la documentation de l’application.

Si votre équipe ne peut pas mettre en place un contrôle réseau ou un relais requis, ou ne peut pas prendre en charge la diversité des réseaux utilisés par les utilisateurs, un autre modèle de déploiement ou un service conçu pour ce cas d’usage peut être plus adapté. Prenez cette décision en fonction des exigences vérifiées, et non de la présence d’un bouton d’appel ou d’une connexion Web réussie.

• Attribuez chaque exigence documentée à un responsable : votre équipe, le fournisseur d’hébergement ou le vendeur de l’application.
• Confirmez les dépendances relatives aux relais et aux contrôles réseau avant de vous engager dans un déploiement.
• Choisissez un autre modèle si une fonctionnalité requise ou une responsabilité opérationnelle ne peut pas être prise en charge.

Consignez les responsabilités et refaites les tests après les changements

Conservez une trace concise de l’architecture, des protocoles et ports documentés, de la configuration DNS et TLS, du proxy, des dépendances relatives aux relais et du responsable de chaque changement. Prévoyez un processus de dépannage afin que les utilisateurs sachent où signaler les problèmes et que les administrateurs puissent distinguer les problèmes d’accès Web de ceux liés à l’établissement de l’appel ou aux flux multimédias.

Prévoyez de répéter les tests représentatifs après toute modification de l’application, de l’hébergement, du proxy, du pare-feu, du relais ou du réseau utilisateur. Une vérification documentée et reproductible est plus utile que de considérer une réunion réussie comme une garantie permanente.

• Consignez les sources documentaires et la date de vérification, ainsi que toute question restée sans réponse.
• Désignez des responsables pour les changements de pare-feu, l’exploitation du relais, la configuration de l’application et l’assistance aux utilisateurs.
• Refaites les tests après toute modification importante de l’infrastructure ou du réseau et mettez le dossier à jour.