Nextcloud Talk : configurer le High Performance Backend

Une réunion à trois personnes fonctionne, mais les appels deviennent instables dès que l'équipe grandit. Le Nextcloud Talk High Performance Backend, souvent abrégé HPB, déplace la signalisation et la distribution des flux vers des composants dédiés. Il réduit ainsi la charge réseau des postes et prépare Talk aux réunions plus nombreuses.

Ce guide traite la mise en service technique du HPB avec le conteneur officiel utilisé par Nextcloud All-in-One. Il couvre les secrets, le proxy WebSocket, le raccordement dans Talk, TURN et les contrôles à effectuer avant un usage réel. Pour les fonctions de chat, d'appel et de modération, consultez d'abord le guide Nextcloud Talk.

À quoi sert le High Performance Backend de Nextcloud Talk ?

Sans HPB, un appel vidéo peut fonctionner en pair à pair. Chaque participant envoie alors un flux à chaque autre participant. La documentation de Talk donne un ordre de grandeur d'environ 1 Mbit/s par flux vidéo. Dans un appel à cinq, chaque poste peut donc devoir envoyer et recevoir environ 4 Mbit/s, tout en décodant quatre flux.

Le High Performance Backend ajoute deux fonctions principales :

• un serveur de signalisation autonome, qui gère les connexions et les messages nécessaires à l'établissement des appels ;
• une unité de transfert sélectif, ou SFU, qui reçoit un flux par participant et le redistribue aux autres.

Nextcloud indique que le HPB devient déjà utile avec trois participants, car il peut réduire de moitié le débit montant requis. Sa documentation évoque généralement 30 à 50 participants actifs, voire davantage selon l'infrastructure, ainsi que des centaines de participants passifs pour un usage de diffusion. Ces nombres ne constituent pas une capacité garantie. Le nombre de caméras, la résolution, le partage d'écran, le débit disponible et le dimensionnement de la SFU changent le résultat.

Quelle méthode d'installation choisir ?

Nextcloud présente plusieurs voies. Nextcloud All-in-One inclut déjà un HPB et un serveur TURN prêts à être raccordés. Des paquets pour Ubuntu, Debian et Red Hat Enterprise Linux, ainsi qu'une documentation pour les architectures de grande taille, sont accessibles avec une souscription Nextcloud Talk. Pour une instance existante, la documentation publique propose aussi le conteneur ghcr.io/nextcloud-releases/aio-talk:latest.

Ce guide retient ce dernier chemin. Il évite de reconstruire séparément le serveur de signalisation, NATS et la passerelle WebRTC. Une installation manuelle reste possible depuis le dépôt nextcloud-spreed-signaling, mais elle demande de configurer chaque composant, leurs secrets et leur cycle de mise à jour.

Avant de commencer, vérifiez les prérequis suivants :

1. une instance Nextcloud fonctionnelle et accessible en HTTPS ;
2. l'application Talk installée et compatible avec la version du serveur ;
3. un moteur Docker opérationnel ;
4. un nom DNS séparé pour le HPB, par exemple signaling.cloud.exemple.fr ;
5. un reverse proxy capable de conserver les connexions WebSocket ;
6. des ports média et TURN définis selon votre architecture ;
7. une sauvegarde de la configuration avant toute modification.

Le guide complet de Nextcloud replace Talk dans l'ensemble Files, Office, Groupware et applications. Si votre instance se trouve derrière plusieurs intermédiaires, le guide du reverse proxy Nextcloud aide à inventorier DNS, certificats et en-têtes avant d'ajouter un second service.

Comment créer les secrets et démarrer le conteneur officiel ?

Le conteneur AIO Talk demande trois secrets distincts : TURN_SECRET, SIGNALING_SECRET et INTERNAL_SECRET. La documentation suggère de générer chaque valeur avec OpenSSL. Exécutez la commande trois fois et conservez les résultats dans un gestionnaire de secrets :

openssl rand --hex 32

N'utilisez pas les valeurs d'exemple de la documentation. Ne placez pas les secrets dans l'historique d'un dépôt Git, une capture d'écran ou un ticket public. Le secret de signalisation devra être recopié dans les réglages d'administration de Talk. Une différence d'un caractère suffit à faire échouer le contrôle de connexion.

Adaptez ensuite la commande officielle à votre DNS, à votre port local et à vos secrets :

docker run \
  --name=nextcloud-talk-hpb \
  --restart=always \
  --detach \
  -e NC_DOMAIN=cloud.exemple.fr \
  -e TALK_PORT=3478 \
  -e TURN_SECRET="VOTRE_SECRET_TURN" \
  -e SIGNALING_SECRET="VOTRE_SECRET_SIGNALING" \
  -e INTERNAL_SECRET="VOTRE_SECRET_INTERNE" \
  -p 127.0.0.1:8080:8081 \
  ghcr.io/nextcloud-releases/aio-talk:latest

La liaison 127.0.0.1:8080:8081 garde ici le port applicatif sur l'interface locale. Le reverse proxy devient le seul point public en HTTPS. Si Docker et le proxy ne se trouvent pas sur la même machine, remplacez cette topologie par un réseau privé filtré. N'exposez pas un port d'administration au monde entier pour contourner un problème de proxy.

Contrôlez immédiatement l'état et les journaux :

docker ps --filter name=nextcloud-talk-hpb
docker logs --tail 100 nextcloud-talk-hpb
curl http://127.0.0.1:8080/api/v1/welcome

L'endpoint d'accueil doit renvoyer un objet JSON contenant nextcloud-spreed-signaling et la version. Il prouve que le service HTTP local répond. Il ne valide pas encore le certificat, le WebSocket public, le secret partagé ni le chemin média.

Comment configurer le reverse proxy et les WebSocket ?

Publiez le HPB derrière un nom dédié avec un certificat TLS valide. Le proxy doit transmettre les requêtes HTTP normales et autoriser la montée de connexion WebSocket utilisée par la signalisation. Le dépôt officiel fournit des exemples Nginx et Apache. Adaptez-les au chemin réellement exposé, sans supprimer les en-têtes de mise à niveau.

Pour un déploiement où le domaine public du HPB pointe directement vers son service local, la logique Nginx minimale ressemble à ceci :

upstream talk_hpb {
    server 127.0.0.1:8080;
}

location / {
    proxy_pass http://talk_hpb;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
}

Le bloc exact dépend de votre frontal, de son chemin et de la présence éventuelle d'un répartiteur de charge. Vérifiez la configuration puis rechargez le service sans couper les autres hôtes :

sudo nginx -t
sudo systemctl reload nginx
curl https://signaling.cloud.exemple.fr/api/v1/welcome

La réponse publique doit correspondre au service local. Testez également depuis un réseau extérieur, car une résolution DNS interne, un pare-feu ou un certificat incomplet peut masquer le défaut depuis le serveur.

Comment raccorder le HPB dans l'administration de Talk ?

Ouvrez Paramètres d'administration > Talk. Dans la section du High Performance Backend, saisissez :

• l'URL HTTPS publique du service, par exemple le sous-domaine signaling.cloud.exemple.fr ;
• le contenu exact de SIGNALING_SECRET dans le champ du secret partagé.

Lancez le contrôle de connexion et exigez sa validation avant de poursuivre. Si le test échoue, comparez l'URL, le certificat, le DNS et le secret, puis consultez simultanément les journaux du conteneur et du reverse proxy. Évitez de modifier plusieurs couches à la fois, sinon vous ne saurez pas quelle correction a produit l'effet observé.

Créez ensuite une conversation de test avec au moins trois comptes. Connectez-les depuis des réseaux différents, par exemple une connexion fixe, un partage mobile et un réseau d'entreprise. Testez successivement :

1. l'entrée dans le salon ;
2. le micro et la caméra ;
3. l'activation simultanée de plusieurs vidéos ;
4. le partage d'écran ;
5. la reconnexion après une coupure courte ;
6. la sortie puis le retour d'un participant ;
7. les clients web, bureau et mobiles réellement utilisés.

Le client Nextcloud Talk Desktop doit être vérifié séparément des navigateurs. Une réussite dans Chrome sur le réseau local ne prouve pas que l'application mobile passera un pare-feu restrictif.

Pourquoi faut-il encore configurer TURN ?

WebRTC tente d'abord une connexion directe, utilise STUN pour découvrir les adresses publiques, puis recourt à TURN lorsque le chemin direct reste impossible. Selon la documentation Nextcloud, le HPB utilise par défaut une plage média de ports 20000 à 40000. Un client placé derrière un pare-feu qui n'autorise que le port 443 peut donc avoir besoin d'un relais TURN sur ce port.

Si le HPB et TURN doivent tous les deux écouter publiquement sur 443, prévoyez deux adresses IP ou deux serveurs. Une autre architecture peut publier TURN sur 3478 en UDP et TCP, mais elle offre moins de chances de traverser certains réseaux filtrés. Le choix doit être testé depuis les environnements de vos utilisateurs.

Le conteneur AIO Talk peut aussi exposer TURN. La documentation ajoute alors TALK_HOST, ainsi que les publications TCP et UDP du port 3478. Dans Talk, l'adresse TURN est saisie sans préfixe http://, https://, turn: ou turns:, puis le protocole est choisi dans l'interface.

Consultez le guide de configuration TURN pour Nextcloud Talk avant d'ouvrir les ports. Vérifiez ensuite l'accès en UDP et en TCP depuis l'extérieur, puis effectuez un appel depuis un réseau connu pour bloquer le pair à pair.

Comment diagnostiquer un HPB qui ne fonctionne pas ?

Commencez par l'étape qui échoue, sans conclure trop vite à un manque de ressources.

Pour chaque test, notez l'heure, le compte, le client, le réseau et l'action précise. Corrélez cette heure dans les journaux. Surveillez aussi CPU, mémoire, débit entrant et sortant, erreurs du proxy et redémarrages Docker. Le guide de monitoring Nextcloud avec Prometheus donne une méthode pour réunir les signaux de l'instance et du serveur, même si le HPB exige ses propres contrôles de disponibilité et de réseau.

Avant une mise à jour, relevez l'image actuellement utilisée et lisez les notes de version des composants concernés. Une étiquette latest facilite le démarrage initial, mais elle ne remplace pas une procédure : sauvegarde de la configuration, mise à jour sur un pilote, appel de recette, surveillance puis retour arrière documenté.

Quelle recette valider avant la production ?

Une recette utile doit reproduire le pic prévu, pas seulement ouvrir un salon vide. Faites rejoindre progressivement le nombre de participants actifs attendu, avec la proportion réelle de caméras et de partages d'écran. Mesurez le serveur et demandez aux participants de signaler les coupures, le retard audio et la dégradation vidéo.

Validez au minimum :

• le DNS et le certificat du domaine de signalisation ;
• l'endpoint public api/v1/welcome ;
• le contrôle HPB dans l'administration Talk ;
• les connexions WebSocket à travers le proxy ;
• l'appel depuis plusieurs réseaux externes ;
• le relais TURN en UDP et en TCP ;
• le redémarrage du conteneur avec les mêmes secrets ;
• les alertes sur arrêt, saturation et certificat proche de l'expiration ;
• une procédure de retour au mode précédent si le HPB devient indisponible.

Le High Performance Backend ne transforme pas une liaison saturée en réseau fiable. Il change la distribution des flux et déplace une partie de la charge vers une infrastructure à administrer. Dimensionnez cette infrastructure à partir d'un test représentatif, puis recommencez la recette après une modification du proxy, de TURN ou de la version du conteneur.

Conclusion

Configurer le High Performance Backend de Nextcloud Talk demande cinq résultats vérifiables : un conteneur stable, des secrets persistants, un domaine HTTPS qui transmet les WebSocket, un contrôle vert dans Talk et des appels réussis depuis plusieurs réseaux. TURN reste à tester séparément pour les environnements restrictifs. Une fois ce socle validé, la capacité dépend du dimensionnement et de la charge réelle, pas d'un nombre universel de participants.

Découvrir l'offre Nextcloud GaprodTalk, stockage et collaboration sur une instance gérée

Sources officielles

• Nextcloud Talk : installation rapide du High Performance Backend
• Nextcloud Talk : scalabilité et rôle de la SFU
• Nextcloud Talk : configuration d'un serveur TURN
• Dépôt du serveur de signalisation standalone
• Conteneur Talk de Nextcloud All-in-One