VoIP ou WebRTC : la question oppose une famille à l’un de ses membres. La VoIP désigne toutes les techniques qui font passer un appel par internet. WebRTC est le standard qui permet à un navigateur de le faire sans rien installer. Un appel lancé depuis Chrome, Edge, Firefox ou Safari est donc un appel VoIP, et la comparaison utile se joue ailleurs : entre le navigateur et le téléphone SIP posé sur le bureau.
Ce guide explique ce que recouvrent les deux mots, puis suit un appel de bout en bout, du micro de votre ordinateur jusqu’au mobile de votre correspondant. Tout ce qui est technique s’appuie sur les textes d’origine du W3C et de l’IETF, lus le 11 novembre 2026 et cités au fil du texte.
VoIP ou WebRTC : quelle différence ?
La différence tient au niveau où l’on se place. La VoIP répond à la question « par où passe la voix ? » : par un réseau de données, découpée en paquets, plutôt que par un circuit téléphonique réservé. WebRTC répond à une question plus étroite : « comment un navigateur peut-il émettre et recevoir cette voix ? ».
Dire « VoIP ou WebRTC » revient donc à dire « véhicule ou voiture électrique ». La seconde est un cas particulier du premier. En pratique, la personne qui pose la question hésite entre deux façons d’équiper ses équipes : des téléphones et des logiciels qui parlent SIP, ou une application qui s’ouvre dans un onglet.
Ces trois dates situent les deux mondes. SIP a plus de vingt ans et fait tourner l’essentiel de la téléphonie d’entreprise. WebRTC est plus jeune, mais il n’est plus expérimental : la documentation MDN de Mozilla indique que son interface centrale est disponible dans les navigateurs depuis septembre 2017, et le W3C l’a publié comme standard officiel le 26 janvier 2021.
- SignalisationTéléphone ou softphone SIPSIP, standardisé (RFC 3261)Navigateur WebRTCLibre : au choix de l’application, souvent SIP sur WebSocket
- Codec audioTéléphone ou softphone SIPG.711 presque toujours, d’autres selon le matérielNavigateur WebRTCOpus et G.711 obligatoires (RFC 7874)
- Chiffrement de la voixTéléphone ou softphone SIPOptionnel : SRTP si le fournisseur l’activeNavigateur WebRTCObligatoire : DTLS-SRTP, voix en clair interdite
- Traversée du pare-feuTéléphone ou softphone SIPRéglages du réseau, parfois un contrôleur de sessionNavigateur WebRTCIntégrée : ICE, avec STUN et relais TURN
- InstallationTéléphone ou softphone SIPUn poste à brancher ou un logiciel à déployerNavigateur WebRTCAucune : une page web et l’autorisation du micro
Sources : RFC 3261 (SIP), RFC 7874 (codecs), RFC 8827 (sécurité), RFC 8835 (transports), RFC 8825 (vue d’ensemble).
Le tableau ci-dessus résume ce qui change réellement d’une pile à l’autre. Sur le chiffrement, le pare-feu et l’installation, le navigateur impose ou intègre ce que la téléphonie SIP laisse en option. Sur la signalisation, c’est l’inverse : SIP est normalisé, WebRTC laisse le choix à chaque application. C’est la marque d’un standard écrit après coup, avec le recul de vingt ans de téléphonie sur IP.
WebRTC ne remplace pas la VoIP. Il remplace le téléphone posé sur le bureau par un onglet de navigateur.
Qu’est-ce que la VoIP, exactement ?
La VoIP, pour Voice over IP, transporte la voix sous forme de paquets de données. Trois briques travaillent ensemble dans tout appel de ce type.
Autour de ces briques, on trouve du matériel et des contrats : des postes IP, des logiciels appelés softphones, un standard hébergé ou installé sur site, et une liaison avec un opérateur. Chaque pièce a son article sur ce site, et nous ne les redétaillons pas ici : la différence entre VoIP et téléphonie classique, le fonctionnement d’un trunk SIP et la définition du softphone.
Retenez seulement ceci pour la suite : dans la VoIP classique, chaque brique est un choix. Le fournisseur choisit ses codecs, active ou non le chiffrement, et le réseau de l’entreprise doit souvent être réglé pour laisser passer les appels.
Qu’est-ce que WebRTC ?
WebRTC, pour Web Real-Time Communication, est un ensemble de standards qui permet à un navigateur d’échanger de l’audio, de la vidéo et des données en temps réel. Deux organismes se partagent le travail. Le W3C définit l’interface que les développeurs utilisent dans la page. L’IETF définit les protocoles qui circulent sur le réseau.
Le résumé de la recommandation du W3C, dans sa version du 13 mars 2025, tient en une phrase : elle définit des interfaces qui permettent d’envoyer et de recevoir des médias vers et depuis un autre navigateur ou appareil qui met en œuvre les protocoles temps réel appropriés. Les mots « ou appareil » comptent : l’autre bout de l’appel n’est pas forcément un navigateur. Ce peut être un serveur de téléphonie.
WebRTC ne vit pas non plus que dans les navigateurs. Le site du projet, webrtc.org, précise que la technologie est disponible dans tous les navigateurs récents et, sous forme de bibliothèque, pour les applications Android et iOS. Une application mobile d’appel peut donc reposer sur le même moteur qu’un onglet de Chrome.
Ce que WebRTC standardise :
Ce que WebRTC ne standardise pas est tout aussi important. La RFC 8825, qui présente l’ensemble, place le choix des protocoles de signalisation hors de son périmètre : entre le navigateur et le serveur, chaque application fait comme elle l’entend, avec un protocole standard ou propriétaire. C’est la raison pour laquelle deux services d’appel dans le navigateur ne sont pas compatibles entre eux, alors que deux téléphones SIP de marques différentes le sont en principe.
WebRTC ou SIP : concurrents ou complémentaires ?
Complémentaires, dans presque tous les cas. La question « WebRTC ou SIP » suppose un choix, alors que les deux travaillent souvent dans le même appel : WebRTC entre le poste et le fournisseur, SIP entre le fournisseur et les opérateurs. On rencontre trois montages.
| Montage | Ce que l'équipe utilise | Ce que cela implique |
|---|---|---|
| Tout SIP | Des postes IP et des softphones installés, reliés à un standard | Du matériel qui peut changer de fournisseur, mais un réseau à régler et un chiffrement à vérifier. |
| WebRTC devant, SIP derrière | Une application dans le navigateur ; la passerelle du fournisseur parle SIP aux opérateurs | Rien à installer et un chiffrement imposé jusqu'à la passerelle, mais une application propre au fournisseur. |
| Mixte | Le navigateur pour la plupart des postes, quelques postes SIP sur le même compte | Chaque poste reçoit l'outil qui lui convient. À vérifier avant de signer : tous les fournisseurs ne l'acceptent pas. |
Le premier montage reste celui des standards d’entreprise avec accueil et postes fixes. Le deuxième est courant dans les logiciels d’appel destinés aux équipes commerciales et au support. Le troisième est le plus souple, et c’est lui que vise la question 7 de la liste à envoyer aux fournisseurs, plus bas.
Dans les trois cas, le correspondant ne voit aucune différence. Son téléphone sonne, affiche un numéro et transmet une voix. Le choix ne concerne que votre côté de l’appel, c’est-à-dire ce qu’il faut acheter, installer, régler et maintenir.
Comment un appel WebRTC rejoint-il un numéro de téléphone ?
C’est le point que la plupart des explications laissent de côté. WebRTC a été conçu pour relier deux navigateurs. Le réseau téléphonique, lui, ne connaît que des numéros et des opérateurs. Entre les deux, il faut un traducteur.
- 01Micro et casqueVotre voixLe navigateur demande l’autorisation du micro, sur une page en HTTPS.
- 02NavigateurWebRTCIl compresse la voix en Opus, la chiffre en DTLS-SRTP et cherche un chemin réseau (ICE).
- 03InternetSTUN et TURNSTUN révèle l’adresse publique. Si le pare-feu bloque, un relais TURN transporte la voix.
- 04PasserelleWebRTC vers SIPElle déchiffre, convertit Opus en G.711 si besoin et traduit la signalisation en SIP.
- 05Réseau téléphoniqueLe numéro appeléL’opérateur achemine l’appel vers le fixe ou le mobile, qui sonne normalement.
Lecture : WebRTC protège la voix entre le navigateur et la passerelle. Sur le réseau téléphonique, la protection dépend des opérateurs traversés.
Voici ce qui se passe à chaque étape, dans l’ordre.
- 01
La page demande le micro.
Au premier appel, le navigateur affiche une demande d’autorisation. La documentation MDN précise que cette demande n’est possible que sur une page sécurisée, chargée en HTTPS, et que l’accord de l’utilisateur est toujours requis. Si la demande est refusée, l’appel ne peut pas partir. - 02
Le navigateur prépare l'appel.
Il annonce au serveur du fournisseur le numéro composé et ce qu’il sait faire : ses codecs, ses adresses réseau possibles, son empreinte de sécurité. C’est la signalisation, et son format dépend du fournisseur. Beaucoup utilisent SIP transporté sur WebSocket, un mode défini par la RFC 7118. - 03
Les deux côtés cherchent un chemin.
Le navigateur et le serveur testent les routes possibles pour la voix. La meilleure qui répond est retenue. Sur un réseau filtré, ce sera un relais. - 04
La passerelle traduit.
C’est la pièce maîtresse. La RFC 8825 définit une passerelle comme un point d’extrémité compatible WebRTC qui fait transiter le trafic vers des entités qui ne le sont pas, et précise qu’une passerelle de signalisation peut être nécessaire pour convertir vers SIP. Elle déchiffre la voix, change de codec si le réseau en face l’exige, et ouvre un appel SIP classique. - 05
L'opérateur fait sonner le téléphone.
L’appel entre sur le réseau téléphonique par une liaison d’opérateur, exactement comme le ferait l’appel d’un standard d’entreprise. Le correspondant voit votre numéro et décroche sur son fixe ou son mobile. Rien ne lui indique que vous appelez depuis un onglet.
Deux conséquences pratiques découlent de ce schéma.
La première : la qualité d’un appel passé depuis un navigateur se joue en deux moitiés. La moitié WebRTC dépend de votre poste et de votre connexion. La moitié téléphonique dépend des opérateurs choisis par votre fournisseur. Un fournisseur sérieux sur la première et négligent sur la seconde donnera des appels médiocres, et l’inverse aussi.
La seconde : le numéro que voit votre correspondant, sa réputation et le pays d’où l’appel semble venir ne dépendent pas de WebRTC. Ils dépendent de la liaison d’opérateur. Pour ce sujet, voyez notre guide du numéro professionnel virtuel et, pour appeler à l’étranger, la liste des indicatifs téléphoniques par pays.
Opus ou G.711 : quel codec porte votre voix ?
La RFC 7874 de l’IETF est sans ambiguïté : un point d’extrémité WebRTC doit mettre en œuvre Opus, ainsi que PCMA et PCMU, les deux variantes de G.711. Elle recommande de proposer Opus avant G.711 dès que l’appareil sait traiter un son plus large que celui du téléphone.
Dans un appel entre deux navigateurs, Opus fait tout le trajet. Dans un appel vers un numéro de téléphone, la passerelle doit souvent convertir Opus en G.711 pour parler à l’opérateur. Cette conversion a deux effets : elle ajoute un petit traitement, et elle ramène la voix à la largeur de bande du téléphone. La belle voix d’Opus ne franchit donc pas toujours la passerelle. Ce n’est pas un défaut du fournisseur, c’est la limite du réseau d’en face.
L’ordre de grandeur à retenir : la voix consomme très peu. Une connexion qui peine à faire tenir un appel ne manque presque jamais de débit. Elle manque de régularité, et c’est ce que mesure notre test de qualité VoIP. Le diagnostic complet d’une voix hachée ou d’un écho fait l’objet d’un guide à part sur la qualité d’appel VoIP.
Un appel WebRTC est-il sécurisé ?
Sur le tronçon qu’il contrôle, oui, et par construction. La RFC 8827, qui décrit l’architecture de sécurité de WebRTC, pose quatre obligations qui n’ont pas d’équivalent imposé dans la téléphonie SIP classique.
Dans la téléphonie SIP, ces protections existent, mais ce sont des options que le fournisseur active ou non, et que le poste prend en charge ou non. C’est la différence la plus nette entre les deux mondes.
Il faut cependant lire cette garantie avec précision.
La sécurité d’une installation téléphonique ne se limite pas au chiffrement. Les fraudes qui coûtent cher exploitent plutôt des identifiants volés ou des appels internationaux non plafonnés. Ce sujet est traité dans notre guide de la sécurité VoIP et de la fraude télécom. Quant à l’enregistrement des appels, il obéit à des règles qui ne dépendent pas de la technologie employée : voyez enregistrer les appels en entreprise et RGPD.
STUN, TURN, ICE : comment l’appel traverse-t-il votre pare-feu ?
Un ordinateur de bureau n’a presque jamais d’adresse publique. Il se trouve derrière un routeur qui partage une adresse entre plusieurs postes, et souvent derrière un pare-feu. Pour qu’un flux de voix arrive jusqu’à lui, il faut découvrir par où passer. WebRTC confie ce travail à trois mécanismes.
La RFC 8835 ajoute deux exigences qui expliquent pourquoi les appels dans le navigateur fonctionnent même sur des réseaux fermés : le navigateur doit savoir joindre un relais TURN en TCP, et aussi en TLS sur TCP. Un réseau qui bloque l’UDP, comme celui de certains hôtels ou de certaines grandes entreprises, laisse en général sortir du TLS. L’appel passe alors par ce chemin, au prix d’un peu de latence en plus.
ICE, défini par la RFC 8445, classe ces chemins du plus direct au plus détourné et retient le premier qui fonctionne.
- Liaison directeLe navigateur et le serveur du fournisseur se joignent sans intermédiaire.
- Directe, avec l’aide de STUNUn serveur STUN indique au poste son adresse publique. La voix circule ensuite en direct.
- Relais TURN en UDPLa voix passe par un relais du fournisseur, qui la retransmet.
- Relais TURN en TCP ou TLSDernier recours : la voix emprunte le même type de connexion qu’une page web sécurisée.
Lecture : plus on descend, plus le trajet s’allonge. Un appel qui passe en relais TLS fonctionne, avec un peu plus de latence. Sources : RFC 8445 (ICE), RFC 8835 (transports WebRTC).
Ce classement explique un constat fréquent : le même ordinateur donne des appels nets à la maison et légèrement décalés au bureau. L’application n’a pas changé. Le réseau du bureau a simplement obligé l’appel à prendre un chemin plus long.
Pour un responsable réseau, trois gestes suffisent en général.
- 01
Demandez la liste des relais.
Votre fournisseur doit pouvoir donner les noms de domaine, les plages d’adresses et les ports de ses serveurs de signalisation et de ses relais. Les ports par défaut sont 3478 pour STUN et TURN, et 5349 pour leurs variantes sur TLS, mais chaque service peut en utiliser d’autres. - 02
Laissez sortir l'UDP vers ces relais.
La voix en UDP est le chemin le plus court. Si votre politique l’interdit, l’appel se rabattra sur TCP ou TLS, avec une qualité plus sensible aux pertes. - 03
Méfiez-vous de l'inspection du trafic chiffré.
Un équipement qui déchiffre et rechiffre tout le trafic sortant peut casser la signalisation ou ralentir la voix. Excluez les domaines du service de cette inspection si des appels échouent sans raison apparente.
Les réseaux privés virtuels méritent une mention à part. Un VPN qui fait transiter tout le trafic par un site central allonge le trajet de la voix. Si vos télétravailleurs se plaignent de décalage, vérifiez d’abord cela.
Ce que WebRTC change pour une entreprise
L’intérêt de l’appel dans le navigateur n’est pas technique. Il est logistique.
Le coût suit la même logique. Un poste IP de bureau s’achète, se configure et se remplace. Un onglet ne coûte rien de plus que l’ordinateur déjà fourni. Il reste un seul achat utile, et il n’est pas négociable : un casque filaire correct. Les critères de choix sont détaillés dans notre guide du casque pour téléphoner.
Pour une équipe commerciale, l’argument décisif est ailleurs : les fonctions qui font gagner du temps (composition automatique, enregistrement, transcription, remontée dans le CRM) sont des fonctions logicielles. Elles arrivent plus vite et plus complètement dans une application web que dans un poste matériel. Le comparatif de la VoIP pour équipes commerciales chiffre ce que cela coûte par commercial.
Quelles sont les limites de l’appel dans le navigateur ?
Un guide honnête doit dire aussi ce que le navigateur fait mal.
Il faut ajouter le Wi-Fi. Le navigateur n’y est pour rien, mais l’appel dans un onglet se pratique surtout sur des ordinateurs portables, donc souvent en Wi-Fi, alors que les postes fixes sont câblés. Une partie des plaintes attribuées à WebRTC vient en réalité de là.
Enfin, les navigateurs ne sont pas rigoureusement identiques. Le standard garantit qu’ils se comprennent, pas que chaque fournisseur a testé son application avec le même soin sur tous. Demandez toujours quels navigateurs sont pris en charge officiellement, et dans quelles versions.
Quand garder un téléphone SIP ou un softphone installé ?
La décision ne se prend pas pour toute l’entreprise d’un coup, mais poste par poste. Dans une petite structure, ce tri rejoint la question du nombre de lignes téléphoniques réellement nécessaires.
| Situation | Le plus adapté | Pourquoi |
|---|---|---|
| Commerciaux et prospection | Navigateur | Les appels partent de la liste de contacts, et chaque appel est consigné sans ressaisie. |
| Télétravail et équipes réparties | Navigateur, plus application mobile | Aucun matériel à expédier, le même numéro partout. |
| Accueil et standard | Poste SIP | Il sonne en permanence, se décroche d'un geste et ne dépend d'aucun ordinateur. |
| Atelier, entrepôt, comptoir | Poste SIP ou combiné sans fil | Pas d'ordinateur à portée, environnement bruyant, mains occupées. |
| Parc verrouillé, navigateur imposé | Softphone installé | Le service informatique maîtrise la version et les droits d'accès au micro. |
| Salle de réunion | Pieuvre de conférence SIP | Un micro conçu pour plusieurs voix fait mieux qu'un ordinateur posé sur la table. |
Trois questions permettent de trancher les cas qui ne figurent pas dans ce tableau.
- 01
Le poste doit-il sonner quand personne n'est connecté ?
Si oui, il faut un appareil toujours allumé : un poste SIP, ou au minimum une application mobile. - 02
La personne travaille-t-elle déjà toute la journée dans un navigateur ?
Si oui, l’appel dans un onglet lui évite un outil de plus. Si elle n’a pas d’ordinateur, la question est réglée. - 03
Qui maîtrise le poste ?
Sur un ordinateur personnel ou peu administré, le navigateur est le chemin le plus simple. Sur un parc très contrôlé, un logiciel installé et paramétré par l’informatique donne moins de surprises.
Pour quelqu’un qui appelle surtout depuis son téléphone, la question se déplace : elle devient celle du numéro professionnel sur un portable personnel.
Les deux mondes cohabitent très bien. Beaucoup d’entreprises gardent quelques postes SIP à l’accueil et dans les salles, et font appeler tout le reste depuis le navigateur ou le mobile. Si vous hésitez entre plusieurs applications, le comparatif des softphones pour commerciaux passe en revue celles qui s’installent et celles qui s’ouvrent dans un onglet.
Comment préparer un poste pour appeler depuis un navigateur ?
Sept vérifications règlent la plupart des problèmes avant qu’ils n’arrivent. Elles prennent dix minutes par poste.
- 01
Branchez un casque filaire.
Le micro et les haut-parleurs intégrés d’un portable provoquent de l’écho et captent le bruit du clavier. Un casque USB ou jack règle les deux d’un coup. - 02
Autorisez le micro pour le bon site.
Dans Chrome, l’aide de Google indique le chemin : paramètres, confidentialité et sécurité, paramètres des sites, puis micro. On y choisit aussi le micro par défaut. Les autres navigateurs ont un réglage équivalent. - 03
Testez le micro et le casque.
Notre test de micro et de casque vérifie en une minute que le bon périphérique capte bien votre voix. - 04
Préférez le câble au Wi-Fi.
Si le câble est impossible, rapprochez-vous de la borne et évitez les réseaux partagés avec des téléchargements lourds. - 05
Mesurez la régularité de la connexion.
Un test de débit ne suffit pas. Ce qui compte, c’est la latence, sa variation et la perte de paquets. Le test de qualité VoIP cité plus haut les mesure. - 06
Allégez le poste pendant les appels.
Fermez les onglets vidéo et reportez les sauvegardes. Gardez le navigateur à jour : c’est lui qui contient le moteur d’appel. - 07
Empêchez la mise en veille.
Réglez l’ordinateur pour qu’il ne s’endorme pas pendant une session d’appels, et ne fermez pas l’onglet de l’application.
Dépannage : cinq pannes typiques de l’appel dans le navigateur
Quand un appel se passe mal, le symptôme indique presque toujours la moitié du trajet en cause.
| Symptôme | Cause la plus probable | Premier geste |
|---|---|---|
| Mon correspondant ne m'entend pas | Autorisation du micro refusée, ou mauvais périphérique sélectionné | Vérifier le micro dans les réglages du site, puis refaire un test |
| Je n'entends rien | Sortie audio envoyée vers un autre appareil que le casque | Choisir le casque comme sortie dans le système et dans l'application |
| L'appel ne se connecte pas du tout | Pare-feu ou inspection du trafic qui bloque la signalisation ou les relais | Essayer depuis un partage de connexion mobile pour confirmer, puis voir le réseau |
| Voix hachée ou métallique | Wi-Fi instable, perte de paquets ou poste saturé | Passer en filaire, fermer les applications lourdes |
| Décalage entre les répliques | Trajet rallongé par un VPN ou par un relais en TCP | Tester sans VPN, puis demander l'ouverture de l'UDP vers les relais |
Un réflexe utile : l’essai depuis un partage de connexion mobile. Si l’appel fonctionne parfaitement sur le réseau du téléphone et mal sur celui du bureau, le poste et l’application sont hors de cause. Le problème est dans le réseau local.
Quelles questions poser à un fournisseur ?
Les fiches commerciales disent « VoIP », « cloud » ou « WebRTC » sans préciser ce qu’il y a derrière. Ce message, à copier tel quel, obtient les réponses qui comptent.
Bonjour, nous étudions votre solution pour une équipe qui appellera depuis le navigateur. Pouvez-vous nous préciser :
Quels navigateurs et quelles versions prenez-vous officiellement en charge ? L’application existe-t-elle aussi en version installée et en version mobile, avec le même compte ? Quels codecs utilisez-vous entre le navigateur et vos serveurs, puis vers les opérateurs ? Jusqu’où la voix est-elle chiffrée, et où vos passerelles sont-elles hébergées ? Quels domaines, adresses et ports devons-nous autoriser sur notre pare-feu, relais compris ? Que se passe-t-il pour un appel en cours si l’onglet se ferme ou si la connexion change ? Peut-on aussi connecter des postes SIP au même compte pour l’accueil ou les salles ? Proposez-vous un essai sur notre propre réseau avant engagement ?
La question 7 révèle beaucoup. Un fournisseur qui accepte à la fois le navigateur et des postes SIP vous laisse équiper chaque poste selon son usage. Un fournisseur qui n’accepte que l’un des deux vous impose son choix.
Quatre idées reçues sur WebRTC
Lexique : quinze mots pour lire une fiche produit
Les pages commerciales empilent les sigles. Voici ceux que vous croiserez, dans l’ordre où un appel les rencontre.
- VoIP : voix sur IP. Tout appel transporté par un réseau de données plutôt que par un circuit téléphonique.
- SIP : le protocole de signalisation le plus répandu. Il établit, modifie et termine l’appel, sans transporter la voix.
- WebRTC : l’ensemble de standards qui permet à un navigateur ou à une application d’échanger de la voix en temps réel.
- Softphone : un logiciel de téléphonie installé sur l’ordinateur ou le mobile, qui parle en général SIP.
- Codec : l’algorithme qui compresse la voix au départ et la reconstitue à l’arrivée.
- Opus : codec adaptatif, obligatoire dans WebRTC, qui restitue une voix plus large que celle du téléphone.
- G.711 : codec historique du réseau téléphonique, à 64 kbit/s, compris par tous les opérateurs.
- RTP : le protocole qui transporte les paquets de voix.
- SRTP : la version chiffrée de RTP.
- DTLS-SRTP : la méthode d’échange des clés de chiffrement imposée par WebRTC.
- ICE : le mécanisme qui teste les chemins réseau possibles et garde le meilleur.
- STUN : le serveur qui indique à un poste son adresse publique.
- TURN : le serveur relais qui transporte la voix quand aucune liaison directe ne passe.
- Passerelle : l’équipement du fournisseur qui traduit entre WebRTC et le réseau téléphonique.
- Trunk SIP : la liaison entre le fournisseur, ou le standard de l’entreprise, et un opérateur.
Un test rapide : si une fiche produit annonce « WebRTC » sans jamais parler de passerelle, d’opérateurs ni de numéros, elle ne décrit que la moitié de l’appel.
Et Skipcall ?
Skipcall est un logiciel de téléphonie pour les équipes qui prospectent par téléphone. On appelle et on envoie des SMS depuis l’application web et mobile, avec le même compte et le même numéro, sans combiné ni boîtier à installer. Chaque utilisateur a son numéro, disponible dans 23 pays. Les appels sont consignés dans HubSpot, Pipedrive, Salesforce ou Attio, et les autres outils se relient par API ou par import CSV.
Si votre équipe appelle surtout pour prospecter, deux comparatifs prolongent ce guide, celui des logiciels de phoning et celui des meilleurs power dialers.
Ce qu’il faut retenir
- La VoIP est la famille, WebRTC en est un membre. Un appel passé depuis un navigateur est un appel VoIP. La comparaison utile oppose le navigateur au téléphone ou au softphone SIP.
- WebRTC s’arrête à la passerelle. Il couvre le trajet entre le navigateur et le premier serveur. Pour joindre un numéro de téléphone, une passerelle traduit vers SIP et remet l’appel à un opérateur.
- Deux codecs obligatoires. Opus, adaptatif et large bande, et G.711, la langue du réseau téléphonique. La conversion de l’un à l’autre se fait à la passerelle.
- Chiffrement imposé, mais pas de bout en bout. La voix est chiffrée entre le navigateur et le serveur, sans option pour l’éviter. La suite dépend des opérateurs.
- Le pare-feu est géré par le standard. ICE cherche un chemin, STUN donne l’adresse publique, TURN relaie quand il le faut, y compris en TLS.
- Choisissez poste par poste. Le navigateur pour les commerciaux, le télétravail et les déploiements rapides. Le poste SIP pour l’accueil, les ateliers et les salles.
- Dix minutes de préparation par poste évitent l’essentiel des appels ratés : casque filaire, autorisation du micro, connexion stable, ordinateur qui ne s’endort pas.
Sources lues le 11 novembre 2026 : recommandation WebRTC du W3C et communiqué du 26 janvier 2021 ; IETF, RFC 8825 (vue d’ensemble), RFC 8827 (sécurité), RFC 8835 (transports), RFC 7874 (codecs audio), RFC 6716 et RFC 7587 (Opus), RFC 3551 (G.711 en RTP), RFC 8445 (ICE), RFC 8489 (STUN), RFC 8656 (TURN), RFC 7118 (SIP sur WebSocket), RFC 3261 (SIP) ; UIT, recommandation G.711 ; webrtc.org, site du projet WebRTC ; MDN, getUserMedia et RTCPeerConnection ; aide de Google Chrome sur le micro.