Sommaire
- Qu’est-ce que le BYOC et que change-t-il concrètement ?
- Comment fonctionne une architecture BYOC ?
- BYOC, trunk SIP, ligne SIP et VoIP : quelles différences ?
- Dans quels cas le BYOC est-il pertinent ?
- BYOC, téléphonie cloud ou trunk SIP : que choisir ?
- Quels prérequis vérifier ?
- Comment migrer vers le BYOC ?
- Quels avantages et quelles limites anticiper ?
- Comment Ringover peut-il s’intégrer à une architecture BYOC ?
- FAQ sur le BYOC
- Mentions
Une entreprise peut vouloir moderniser les outils de ses équipes sans transférer tous ses numéros ni renégocier immédiatement son contrat télécom. Le BYOC répond précisément à ce cas de figure : il dissocie la connectivité opérateur de la couche applicative utilisée pour passer, recevoir et superviser les appels.
Cette souplesse s’accompagne toutefois d’une contrepartie. Lorsqu’un incident survient, l’opérateur, la plateforme cloud, le réseau de l’entreprise et sa configuration peuvent être impliqués. Le choix du BYOC doit donc reposer sur une architecture documentée, pas uniquement sur la seule volonté de conserver un fournisseur.
Qu’est-ce que le BYOC et que change-t-il concrètement ?
BYOC signifie Bring Your Own Carrier, soit « apportez votre propre opérateur ». Ce modèle permet de raccorder l’infrastructure téléphonique d’un opérateur existant à une plateforme cloud, tout en conservant les numéros associés[1].
Votre entreprise répartit alors les fonctions entre deux couches :
- L’opérateur fournit les numéros, la connectivité téléphonique et l’accès au réseau téléphonique public.
- La plateforme cloud fournit l’interface des utilisateurs, les règles de distribution des appels et les fonctions de suivi prévues dans son offre.
Prenons le cas d’un service client qui utilise depuis plusieurs années un numéro publié sur son site, ses factures et ses contrats. Avec une configuration BYOC compatible, l’entreprise peut conserver ce numéro chez son opérateur et déployer une nouvelle interface pour ses agents. Elle évite ainsi d’associer systématiquement le changement d’outil à une portabilité.
Le BYOC ne garantit cependant ni une économie, ni une amélioration automatique de la qualité des appels. Ces résultats dépendent des contrats, du réseau, de la capacité du trunk et du périmètre pris en charge par chaque fournisseur.
Dans certains contextes informatiques, BYOC signifie Bring Your Own Cloud. Le présent article traite uniquement du modèle télécom Bring Your Own Carrier.
Comment fonctionne une architecture BYOC ?
Le trunk SIP assure généralement la liaison entre l’opérateur et la plateforme. Il permet de faire transiter plusieurs communications entre un système téléphonique IP et le réseau public.
SIP, pour Session Initiation Protocol, est le protocole de signalisation utilisé pour établir, modifier et terminer une session de communication[2]. Il ne transporte pas nécessairement la voix lui-même : il organise la session, tandis que d’autres protocoles peuvent acheminer les flux audio.
Le rôle de chaque intervenant
Votre entreprise choisit les fournisseurs, inventorie les numéros concernés et définit les règles de routage. Elle doit également préciser les droits d’administration, les contacts de support et la procédure de retour arrière.
L’opérateur gère les éléments couverts par son service : numéros, capacité d’appel, accès au réseau public et paramètres de son trunk SIP.
La plateforme cloud gère les fonctions prévues dans son offre : comptes utilisateurs, interface d’appel, serveur vocal, files d’attente, routage, statistiques ou intégrations métier.
Cette répartition doit être consignée dans une matrice de responsabilités. Par exemple, un numéro inaccessible, une règle horaire incorrecte et un utilisateur incapable de se connecter ne relèvent pas nécessairement du même support.
Le parcours d’un appel entrant
Dans une configuration courante, l’appel suit ce parcours :
- Un correspondant compose un numéro détenu chez votre opérateur.
- L’opérateur reçoit l’appel depuis le réseau téléphonique public.
- Le trunk SIP transmet la communication à la plateforme cloud.
- La plateforme applique la règle associée au numéro : serveur vocal, file d’attente, groupe ou routage horaire.
- L’appel est présenté à l’utilisateur concerné.
- Les informations prévues par la plateforme sont ajoutées au journal d’appels.
Pour un appel sortant, le parcours s’effectue en sens inverse. L’utilisateur compose depuis la plateforme, qui applique les règles de numérotation avant de transmettre l’appel à l’opérateur.
Ce schéma est utile lors d’un incident. Si l’appel atteint la plateforme mais suit une mauvaise file d’attente, examinez d’abord la configuration applicative. S’il n’est jamais présenté au point d’interconnexion, l’analyse doit plutôt porter sur le trunk ou l’acheminement opérateur.
BYOC, trunk SIP, ligne SIP et VoIP : quelles différences ?
Ces notions ne désignent pas le même niveau de l’architecture.
| Notion | Ce qu’elle désigne | Question à poser |
|---|---|---|
| BYOC | Un modèle dans lequel vous raccordez un opérateur choisi à une plateforme | Pouvons-nous conserver notre opérateur et nos numéros ? |
| Trunk SIP | La liaison entre un système téléphonique IP et un opérateur | Combien d’appels simultanés la liaison peut-elle gérer ? |
| SIP | Le protocole de signalisation des sessions | Quels transports, paramètres et méthodes d’authentification sont compatibles ? |
| VoIP | Le transport de la voix sur un réseau IP | Quelles exigences réseau faut-il respecter ? |
| Ligne SIP | Une appellation dont le contenu dépend du fournisseur | S’agit-il d’un numéro, d’un compte, d’un canal ou d’un trunk ? |
| Portabilité | Le transfert d’un numéro vers un autre opérateur | Le numéro doit-il réellement changer d’opérateur ? |
L’expression « compte SIP » est parfois employée commercialement pour parler d’un trunk. Ne considérez toutefois pas ces termes comme parfaitement interchangeables sans lire les conditions de l’offre.
Demandez notamment au fournisseur de préciser :
- le nombre de communications simultanées ;
- les numéros associés ;
- les flux entrants et sortants autorisés ;
- le mode d’authentification ;
- les codecs et transports pris en charge ;
- les règles de présentation du numéro ;
- le périmètre du support.
Cette vérification évite, par exemple, d’acheter une liaison SIP en pensant obtenir également une interface complète pour les utilisateurs.
Dans quels cas le BYOC est-il pertinent ?
Vous devez préserver des numéros déjà diffusés
Un numéro présent dans les signatures, les campagnes publicitaires, les documents contractuels et le CRM est coûteux à remplacer sur le plan opérationnel, même lorsque la portabilité reste techniquement possible.
Le BYOC peut vous permettre de laisser ce numéro chez son opérateur et de modifier uniquement son raccordement à la plateforme. Vous réduisez ainsi le nombre de changements simultanés à coordonner.
Votre contrat couvre plusieurs sites ou entités
Un contrat-cadre peut regrouper les achats, la facturation et le support télécom de plusieurs établissements. Le conserver peut être pertinent si votre projet porte d’abord sur les outils des utilisateurs.
Vous devez néanmoins comparer le coût complet de l’architecture : contrat opérateur, trunk, plateforme, éventuels add-ons et ressources consacrées au support. Le maintien d’un contrat existant n’est pas nécessairement l’option la moins coûteuse.
Vous gérez une numérotation internationale
Une entreprise présente dans plusieurs pays peut disposer de numéros locaux chez différents opérateurs. Une couche applicative commune peut alors harmoniser les usages des équipes sans imposer immédiatement un changement d’opérateur dans chaque marché.
La compatibilité reste à valider numéro par numéro et pays par pays. Vérifiez notamment les restrictions locales, la présentation de l’identité d’appelant, les appels d’urgence et les conditions d’utilisation de la numérotation.
Vous souhaitez avancer par périmètre
Le BYOC peut faciliter une migration progressive : une équipe ou une plage de numéros est raccordée en premier, puis le périmètre est étendu après validation.
Choisissez un pilote représentatif. Un simple numéro peu utilisé ne permettra pas de tester les files d’attente, les transferts, les horaires, les débordements et les appels sortants dont dépendront les autres équipes.
BYOC, téléphonie cloud ou trunk SIP : que choisir ?
| Critère | BYOC | Téléphonie cloud avec opérateur intégré | Trunk SIP pour IPBX |
|---|---|---|---|
| Opérateur | Conservé ou choisi séparément | Généralement inclus dans l’offre | Choisi pour raccorder l’IPBX |
| Numéros | Peuvent rester chez l’opérateur actuel | Conservés par portabilité ou remplacés | Gérés selon le contrat opérateur |
| Interface utilisateur | Fournie par la plateforme cloud | Fournie par la solution cloud | Fournie par l’IPBX ou un outil associé |
| Routage | Configuré dans la plateforme | Configuré dans la solution cloud | Configuré dans l’IPBX |
| Infrastructure interne | Pas nécessairement d’IPBX local | Généralement aucune | IPBX à maintenir |
| Support | Réparti entre plusieurs acteurs | Plus centralisé selon le contrat | Réparti entre IPBX, réseau et opérateur |
| Coûts | Plateforme, opérateur et interconnexion | Abonnement à la solution | Trunk, IPBX, maintenance et réseau |
| Cas d’usage principal | Conserver l’opérateur tout en changeant d’outil | Confier téléphonie et logiciel à un même fournisseur | Raccorder un IPBX existant au réseau public |
Choisissez le BYOC si la conservation de l’opérateur ou de certains numéros constitue une contrainte structurante. Une offre cloud avec opérateur intégré sera souvent plus lisible si vous cherchez d’abord à réduire le nombre d’intervenants.
Le trunk SIP seul correspond à un autre besoin : raccorder un IPBX au réseau public. Il ne remplace ni l’IPBX ni l’interface utilisée par les collaborateurs.
Quels prérequis vérifier ?
Compatibilité et paramètres techniques
Commencez par transmettre une même checklist à l’opérateur et à la plateforme :
- Le trunk peut-il émettre et recevoir du trafic vers la plateforme retenue ?
- Quels transports sont acceptés : UDP, TCP ou TLS ?
- L’authentification repose-t-elle sur des identifiants, des adresses IP ou une autre méthode ?
- Quels codecs sont compatibles ?
- Des préfixes ou en-têtes SIP spécifiques sont-ils nécessaires ?
- Combien de communications simultanées sont autorisées ?
- Quels mécanismes de redondance sont disponibles ?
La procédure Ringover, par exemple, demande notamment le nom du trunk, les identifiants opérateur, les préfixes SIP, les éventuels en-têtes personnalisés, le transport et l’adresse IP de l’opérateur [3].
Inventaire des numéros
Créez un registre comportant, pour chaque numéro :
- l’opérateur et le contrat associés ;
- l’équipe utilisatrice ;
- le routage entrant ;
- le numéro présenté en sortie ;
- les horaires ;
- le débordement prévu ;
- les dépendances avec un CRM, un serveur vocal ou une campagne ;
- le responsable métier.
Vous identifierez ainsi les numéros qui peuvent rejoindre le pilote et ceux qui exigent une validation réglementaire ou contractuelle supplémentaire.
Support et supervision
Attribuez chaque type d’incident avant la bascule :
| Incident | Premier intervenant à solliciter |
|---|---|
| Utilisateur sans accès | Administrateur de la plateforme |
| Mauvaise file d’attente | Responsable du routage applicatif |
| Numéro non joignable | Opérateur, puis plateforme selon les traces |
| Appels hachés ou interrompus | Équipe réseau et fournisseurs concernés |
| Numéro incorrect présenté en sortie | Opérateur et administrateur de la plateforme |
| Incident transversal | Coordinateur désigné par l’entreprise |
Précisez aussi quelles données joindre à un ticket : heure de l’appel, numéro appelant, numéro appelé, sens du flux, utilisateur concerné et identifiant disponible dans les journaux.
Comment migrer vers le BYOC ?
1. Cartographier l’existant
Inventoriez les numéros, les usages, les sites, les contrats, les appels simultanés et les règles de routage. Distinguez les numéros conservés de ceux qui feront l’objet d’une portabilité séparée.
2. Confirmer la compatibilité
Faites valider le schéma par les deux fournisseurs. Une mention commerciale « compatible SIP » ne suffit pas : les méthodes d’authentification, transports, codecs et règles d’acheminement doivent être compatibles.
3. Configurer un pilote
Sélectionnez quelques numéros couvrant plusieurs scénarios : appel direct, serveur vocal, groupe, transfert et sortie avec présentation du numéro.
4. Tester les flux réels
Le plan de recette doit couvrir au minimum :
- les appels entrants et sortants ;
- les transferts internes et externes ;
- les horaires d’ouverture et de fermeture ;
- les débordements ;
- la présentation des numéros ;
- les appels simultanés ;
- les journaux et statistiques attendus ;
- les intégrations métier utilisées par l’équipe.
Consignez le résultat, l’heure du test et l’intervenant chargé de chaque correction.
5. Basculer progressivement
Procédez par équipe, site ou groupe de numéros. Conservez une fenêtre d’observation avant d’étendre le périmètre et définissez les conditions déclenchant un retour arrière.
6. Stabiliser l’exploitation
Après la mise en service, surveillez les appels non aboutis, les erreurs de routage et les sollicitations du support. Mettez à jour la documentation à partir de la configuration réellement déployée.
Quels avantages et quelles limites anticiper ?
Le principal intérêt du BYOC est de découpler deux décisions : le choix de la connectivité téléphonique et celui de l’outil utilisé par les équipes.
Vous pouvez ainsi :
- préserver certains contrats ou numéros ;
- déployer une interface commune auprès de plusieurs équipes ;
- faire évoluer le routage sans remplacer immédiatement l’opérateur ;
- organiser une migration par étapes.
Les limites sont tout aussi concrètes :
- la compatibilité doit être confirmée par les deux fournisseurs ;
- le diagnostic peut mobiliser plusieurs supports ;
- la qualité dépend de l’ensemble du parcours réseau ;
- la redondance ne doit pas être supposée ;
- certaines règles liées aux numéros restent propres au pays concerné ;
- la somme des contrats et options peut compliquer le suivi des coûts.
Avant de décider, comparez donc le coût total, le nombre d’intervenants et le délai de résolution attendu en cas d’incident. Le BYOC apporte de la flexibilité architecturale, mais demande une gouvernance plus explicite.
Comment Ringover peut-il s’intégrer à une architecture BYOC ?
Dans une architecture BYOC, les responsabilités sont réparties entre deux acteurs :
- Votre opérateur conserve vos numéros et assure leur connexion au réseau téléphonique.
- Ringover fournit l’interface depuis laquelle vos collaborateurs gèrent leurs appels, ainsi que les fonctions applicatives de routage, de suivi et d’intégration avec les outils métier.
Cette connexion nécessite que l’opérateur soit compatible avec le dispositif technique prévu par Ringover où le BYOC est présenté sous la forme d’un add-on. Vous pouvez accéder à l'ensemble des informations techniques dans notre article de support dédié au BYOC.
Avant de planifier votre déploiement, rapprochez-vous de nos experts afin d’évaluer les possibilités et la compatibilité avec votre opérateur actuel.
FAQ sur le BYOC
Le BYOC permet-il toujours de conserver ses numéros ?
Il est conçu pour raccorder des numéros conservés chez un opérateur externe. Leur utilisation reste néanmoins soumise à la compatibilité de l’opérateur, de la plateforme et des règles applicables dans chaque pays.
Faut-il disposer d’un trunk SIP ?
Une interconnexion BYOC repose généralement sur un trunk ou une liaison SIP. Vérifiez la méthode exacte exigée par la plateforme, car la simple possession d’identifiants SIP ne garantit pas la compatibilité.
Le BYOC remplace-t-il la portabilité ?
Non. La portabilité transfère un numéro vers un nouvel opérateur. Le BYOC cherche au contraire à utiliser le numéro tout en le maintenant chez son opérateur actuel.
Qui est responsable de la qualité des appels ?
La responsabilité dépend de l’origine de l’incident. Le réseau de l’utilisateur, la plateforme, l’interconnexion et l’opérateur peuvent tous intervenir. Votre matrice de support doit indiquer qui réalise le premier diagnostic et qui coordonne les fournisseurs.
Le BYOC est-il nécessairement moins cher ?
Non. Comparez le coût cumulé de l’opérateur, de la plateforme, des options, de l’interconnexion et du support. Le BYOC répond d’abord à un besoin de conservation ou de contrôle, pas à une promesse automatique d’économie.
Mentions
- [1] https://docs.cloud.google.com/contact-center/ccai-platform/docs/byoc
- [2] https://www.rfc-editor.org/rfc/rfc3261.html
- [3] https://support.ringover.com/hc/fr/articles/32780047351313-BYOC-Bring-your-own-carrier
Publié le 1 septembre 2026.
