Web callback ou WebRTC : deux parcours voix, deux architectures

Web callback ou WebRTC : la réponse courte

Choisissez le web callback lorsque le visiteur doit être joint sur son téléphone et que l’entreprise veut utiliser ses numéros d’agents, ses horaires et son routage. Choisissez WebRTC lorsque le navigateur doit devenir le terminal audio et que la conversation doit rester dans l’application web.

Le web callback est un parcours de mise en relation ; WebRTC est un ensemble d’API et de protocoles de communication en temps réel. Ils peuvent répondre au même besoin de voix depuis un site, mais ils ne se situent pas exactement au même niveau technique. Une architecture hybride peut aussi relier un terminal WebRTC à la téléphonie au moyen d’une passerelle.

Il n’existe donc pas de vainqueur universel. Le routage, les horaires, l’historique ou la disponibilité d’une équipe sont des fonctions applicatives : ils ne sont fournis automatiquement ni par le standard WebRTC, ni par tous les services de callback. Ce guide compare les parcours réels et signale explicitement ce qui appartient à Click2Call.

Pourquoi la comparaison est-elle imparfaite ?

Le web callback décrit un parcours

Dans un service de rappel web, le visiteur transmet un numéro et sollicite un appel. Le service peut appeler l’entreprise puis le visiteur, faire l’inverse ou lancer les deux branches en parallèle. L’Office québécois de la langue française définit le service de rappel Web comme un service permettant à l’internaute de demander qu’un représentant le rappelle. Les détails d’ordre, de routage et de suivi dépendent ensuite de chaque produit.

Pour approfondir cette catégorie sans la confondre avec la présente comparaison, consultez le guide du web callback. Le guide du click-to-call distingue de son côté le rappel, le lien tel:, l’appel depuis le navigateur et le click-to-dial.

WebRTC décrit des capacités de communication temps réel

La recommandation WebRTC du W3C définit des API permettant d’envoyer et de recevoir des médias ou des données entre un navigateur et un autre appareil compatible. Elle ne livre pas à elle seule un centre d’appels, une file d’attente, une interface agent ou un protocole métier de qualification. L’application doit fournir son expérience, son mécanisme de signalisation et son exploitation.

Pour un appel audio dans le navigateur, l’application obtient un flux microphone avec les API Media Capture. La spécification Media Capture and Streams encadre la demande de permission, les périphériques, les erreurs et les indicateurs de confidentialité. Cette permission technique ne remplace ni l’information du visiteur sur le traitement de ses données, ni les obligations propres au contexte du service.

Comment fonctionne chaque parcours ?

Et dans une architecture hybride ?

Un navigateur WebRTC peut communiquer avec un correspondant téléphonique au moyen d’une passerelle. L’aperçu de l’architecture WebRTC de l’IETF, RFC 8825, décrit la possibilité de construire une passerelle de signalisation entre SIP et la négociation média WebRTC. Une telle architecture ajoute des responsabilités de traduction, d’exploitation et d’interopérabilité ; elle ne constitue pas une fonctionnalité de Click2Call actuellement documentée.

Matrice factuelle : quelles différences vérifier ?

Les transports WebRTC doivent prendre en charge ICE et la configuration de serveurs STUN/TURN, comme le précise la RFC 8835. TURN sert de relais lorsque le chemin direct ne convient pas ; son fonctionnement est normalisé par la RFC 8656. Ces mécanismes expliquent pourquoi « WebRTC égale toujours pair-à-pair » serait une affirmation incorrecte.

Quand choisir le web callback ?

Le callback est cohérent lorsque le visiteur souhaite être joint sur son téléphone, que l’équipe répond déjà sur des numéros opérationnels et que le site veut déclencher la voix sans devenir lui-même un terminal audio. Ce parcours convient aussi lorsque l’entreprise veut vérifier sa disponibilité avant d’appeler le visiteur, à condition que le produit choisi implémente réellement ce contrôle.

Click2Call applique par défaut un ordre agent-first : il appelle un agent disponible, puis appelle le visiteur si l’agent répond et raccorde les deux branches. Il peut sélectionner les agents par priorité, rotation ou sonnerie simultanée. Ces faits sont propres au produit et sont détaillés dans le fonctionnement de Click2Call et dans sa documentation de routage.

Click2Call V1 accepte les numéros français validés et ne programme pas automatiquement un appel futur lorsqu’une demande est déposée hors horaires. L’équipe reçoit alors une demande à traiter manuellement. Pour vérifier l’intégration, les formats flottant et intégré ainsi que les origines autorisées, consultez le widget de rappel téléphonique.

Quand choisir WebRTC ?

WebRTC est pertinent lorsque l’expérience vocale doit rester dans une application web : espace client, outil collaboratif, assistance embarquée ou interface agent. Le produit peut contrôler les périphériques, afficher les états de la session et relier plusieurs fonctions temps réel sans demander au visiteur de quitter l’application pour son téléphone.

Ce choix suppose toutefois de concevoir plus que l’accès au microphone. Il faut prévoir la signalisation, l’authentification des participants, la connectivité, les relais, l’observabilité, les erreurs de périphériques et l’expérience en cas de permission refusée. Si le correspondant final utilise un téléphone ou un standard SIP, il faut également évaluer la passerelle et ses responsabilités opérationnelles.

WebRTC ne doit pas être présenté comme moins fiable ou moins sûr par nature. La qualité et la sécurité dépendent de l’architecture, de la configuration et de l’exploitation. Inversement, la présence de WebRTC ne prouve ni la disponibilité d’un agent, ni une file d’attente, ni un historique exploitable.

Comment comparer les coûts sans faux raccourci ?

Comparez un coût total sur le même périmètre et la même période. Pour le callback, documentez l’abonnement, les communications, les éventuels dépassements, l’intégration et le support opérationnel. Pour WebRTC, documentez le développement de l’application, la signalisation, les serveurs STUN/TURN ou services gérés, l’observabilité, le support des navigateurs et la passerelle téléphonique éventuelle.

Un coût par minute ne suffit pas à départager les parcours. Il faut aussi mesurer les demandes abandonnées, les permissions refusées, les échecs de connexion, les conversations réellement établies et le temps d’exploitation. Aucun chiffre universel n’est proposé ici : il dépendrait d’un volume, d’un pays, d’une architecture et de contrats datés.

Checklist de décision en dix questions

1. 1. Quel terminal doit porter la voix ? Le téléphone du visiteur ou son navigateur ?
2. 2. Le visiteur peut-il accorder une permission microphone ? Prévoyez le refus, l’absence de périphérique et les appareils partagés.
3. 3. Le navigateur doit-il rester actif ? Testez le comportement attendu sur mobile et en arrière-plan.
4. 4. L’équipe utilise-t-elle déjà des numéros ou un standard ? Identifiez la passerelle ou le fournisseur nécessaire.
5. 5. Qui vérifie la disponibilité ? Écrivez le comportement hors horaires et en cas de non-réponse.
6. 6. Quel routage est nécessaire ? Priorité, rotation, compétences, sonnerie groupée ou autre règle prouvée.
7. 7. Quelles données sont traitées ? Numéro, microphone, page source, identifiants et événements techniques.
8. 8. Qui exploite la connectivité ? Téléphonie, signalisation, ICE, TURN, passerelles et alertes.
9. 9. Quels états seront mesurés ? Demande, tentative, réponse, connexion, échec et fin.
10. 10. Quel coût total compare-t-on ? Utilisez la même période, les mêmes volumes et les mêmes responsabilités.

Comment tester avant de choisir ?

Construisez un protocole reproductible avec les appareils, navigateurs et réseaux réellement utilisés. Pour WebRTC, testez au minimum la permission accordée, refusée et révoquée, le microphone occupé, le changement de réseau et le recours à un relais. Pour le callback, testez un agent disponible, aucun agent disponible, le hors-horaires, la non-réponse du visiteur et une erreur téléphonique.

Définissez les mêmes résultats observables : parcours commencé, conversation établie, délai, abandon, échec compris par l’utilisateur et reprise possible. Publiez la période, les versions, les volumes et les limites. Un test de laboratoire documenté est plus utile qu’une promesse générale de qualité ou de conversion.

Pour un parcours de callback, vérifiez aussi le script, la politique de sécurité du contenu, les origines et les états accessibles. La page API click-to-call pour développeurs présente les points d’intégration Click2Call, tandis que la page sécurité et confidentialité documente les contrôles produit disponibles.

Choisir un parcours, pas seulement une technologie

Le web callback privilégie une demande initiée sur le web puis une conversation sur le téléphone. WebRTC garde le navigateur au centre de la session audio. Le premier peut s’ajouter à une organisation téléphonique existante ; le second permet une expérience voix profondément intégrée à l’application. Une passerelle peut les rapprocher, avec une complexité supplémentaire à assumer.

Commencez par le terminal attendu et les responsabilités que votre équipe veut exploiter. Vérifiez ensuite les permissions, le réseau, le routage, les données et le coût total dans un test représentatif. Si votre besoin est de rappeler un visiteur seulement lorsqu’un agent est prêt, examinez le parcours agent-first de Click2Call sans l’étendre à des fonctions WebRTC que le produit ne revendique pas.

Sources techniques

• W3C, WebRTC: Real-Time Communication in Browsers, recommandation consultée le 27 août 2026.
• W3C, Media Capture and Streams, spécification consultée le 27 août 2026.
• IETF, RFC 8825, Overview: Real-Time Protocols for Browser-Based Applications.
• IETF, RFC 8835, Transports for WebRTC.
• IETF, RFC 8656, Traversal Using Relays around NAT.
• OQLF, service de rappel Web, fiche terminologique consultée le 27 août 2026.