Sommaire
Faire passer vos agents du softphone installé au navigateur supprime les installations, les mises à jour et la moitié des tickets support. Mais WebRTC déplace la difficulté plutôt qu'il ne la supprime : elle passe du poste de travail au réseau et au certificat.
Ce que WebRTC change concrètement
Un softphone classique — X-Lite, Zoiper, eyeBeam — est un logiciel installé sur le poste. Il parle SIP directement à votre IPBX, sur les ports habituels, et envoie la voix en RTP.
WebRTC déplace le téléphone dans le navigateur. La signalisation passe par un WebSocket sécurisé, la voix est chiffrée de bout en bout, et l'agent n'installe rien : il ouvre une page et il est joignable.
Les conséquences opérationnelles sont immédiates :
- Plus de déploiement. Un nouvel agent est opérationnel en quelques minutes, sans passer par l'informatique.
- Plus de versions divergentes. Tout le monde utilise la même interface, mise à jour côté serveur.
- Télétravail natif. Un navigateur et une connexion suffisent, sans VPN à configurer.
- Chiffrement obligatoire. WebRTC impose le chiffrement de la voix — ce que peu de déploiements SIP classiques font réellement.
Les trois prérequis incontournables
WebRTC ne tolère aucun approximation sur trois points. Les ignorer, c'est garantir des semaines de dépannage.
Un certificat TLS valide. Les navigateurs refusent l'accès au microphone sur une page non sécurisée. Il faut un certificat reconnu, pas un auto-signé, et il doit couvrir le nom exact utilisé par les agents. Un certificat expiré, c'est un plateau entier hors service en quelques minutes — prévoyez le renouvellement automatique et surveillez-le.
Un WebSocket sécurisé accessible. La signalisation passe par un port dédié, distinct du SIP habituel. Ce port doit être ouvert et l'URL déclarée côté serveur doit correspondre exactement à ce que le navigateur appelle. Une erreur fréquente : oublier le chemin final de l'URL, ce qui produit une connexion qui échoue sans message clair.
Une plage RTP ouverte. La voix circule sur une large plage de ports UDP. Si un pare-feu — sur l'hébergeur, sur l'hyperviseur, ou chez l'agent — bloque cette plage, l'appel s'établit, sonne, décroche… et reste muet. C'est de loin le symptôme le plus courant, et le plus mal diagnostiqué.
Le diagnostic du « ça sonne mais on n'entend rien »
Quand un appel WebRTC aboutit sans audio, la signalisation fonctionne et c'est le média qui ne passe pas. La cause est presque toujours réseau.
Une méthode fiable consiste à remonter la chaîne dans l'ordre :
- Vérifier l'enregistrement de l'agent côté serveur : s'il apparaît bien, avec quelle adresse et quel port.
- Écouter l'enregistrement de l'appel. S'il existe et qu'il est silencieux — pas juste calme, mais un silence numérique parfait — aucun paquet n'est arrivé. Le problème est en amont du serveur.
- Comparer avec un autre poste sur une autre connexion. Si un seul agent est touché, c'est son réseau local ou son navigateur ; si tout le plateau l'est, c'est le serveur ou le pare-feu.
- Contrôler la plage RTP sur chaque équipement traversé, y compris l'hyperviseur si le serveur est virtualisé. Une règle trop restrictive sur l'hôte coupe le média sans toucher à la signalisation.
Ce dernier point mérite insistance : sur une infrastructure virtualisée, le pare-feu de l'hyperviseur est invisible depuis la machine invitée. On peut passer des heures à vérifier une configuration parfaitement correcte pendant que le blocage est un étage plus haut.
Casque, navigateur, poste de travail
Le maillon le plus négligé est le matériel de l'agent.
Le casque. Un casque USB avec annulation d'écho est un investissement, pas une dépense. Les micros intégrés aux portables captent la pièce entière et provoquent de l'écho que aucun réglage serveur ne corrigera.
Le navigateur. Les moteurs récents gèrent tous WebRTC correctement, mais les extensions peuvent interférer avec l'accès au microphone. Sur un plateau, un profil navigateur dédié évite bien des surprises.
Les permissions. L'autorisation microphone doit être accordée une fois et mémorisée pour le domaine. Sur les postes partagés, une stratégie qui pré-autorise le domaine évite que chaque agent redemande l'accès au premier appel.
La machine. WebRTC encode et décode l'audio en continu. Sur un poste saturé par ailleurs, la voix se dégrade avant tout le reste. Les symptômes ressemblent à un problème réseau alors qu'ils viennent du processeur.
Ce que le réseau doit tenir
Un agent en télétravail derrière une connexion grand public partagée avec une famille en visioconférence ne tiendra pas la qualité, quel que soit votre serveur.
Les seuils à surveiller sont les mêmes que pour n'importe quelle VoIP : latence, gigue et perte de paquets. Le chiffrement de WebRTC ajoute une charge marginale, mais ne change pas les ordres de grandeur. Notre article sur la qualité VoIP détaille les valeurs cibles et la méthode de mesure.
Un point spécifique au télétravail : demandez aux agents de privilégier le câble Ethernet. Le Wi-Fi ajoute de la gigue de façon imprévisible, et c'est la première cause de plainte sur un plateau distant.
Comment basculer sans casser la production
La migration se fait rarement d'un bloc. Une approche qui fonctionne :
- Monter WebRTC en parallèle du SIP existant, sur les mêmes comptes. Les deux modes peuvent coexister.
- Tester avec deux ou trois agents volontaires pendant une semaine complète, sur des créneaux réels et pas en conditions de laboratoire.
- Mesurer : durée moyenne de conversation, plaintes qualité, tickets support. Si les trois sont stables, la bascule est saine.
- Étendre par vagues, en gardant le softphone installé comme solution de repli le temps d'une ou deux semaines.
Gardez à l'esprit que le gain principal n'est pas la qualité audio — elle sera équivalente — mais la disparition du déploiement, des mises à jour et de la moitié des tickets poste de travail. C'est sur ce terrain que la bascule se justifie.