Les points essentiels à retenir avant de passer à l’action
- En 2026, la page publique d’OVHcloud affiche un frais d’installation de 9,99 € HT et deux modèles par canal, à 4 € HT/mois à l’usage ou 19,99 € HT/mois en illimité.
- Les appels entrants sont inclus dans les deux cas, et l’offre monte jusqu’à 100 canaux, ce qui couvre déjà beaucoup de PME et de services clients.
- Le service fonctionne avec la majorité des IPBX compatibles SIP, notamment 3CX, Asterisk, FreePBX, Wazo, XiVO, FusionPBX et FreeSWITCH.
- Pour une qualité stable, je recommande de viser G.711 ou G.722, une latence inférieure à 150 ms, une gigue sous 30 ms et une vraie QoS sur le réseau.
- Si vous gardez vos numéros existants, la portabilité est possible, avec des délais qui dépendent du type de numéro et de la qualité du dossier.
- Le bon choix dépend surtout du volume d’appels sortants, du nombre de canaux simultanés et de la maturité de votre IPBX.
Ce qu’est un trunk SIP et pourquoi les entreprises l’emploient
Un trunk SIP est, en pratique, un lien opérateur qui connecte votre IPBX au réseau téléphonique public via Internet. C’est cette brique qui remplace les anciennes liaisons physiques et permet de faire circuler les appels entrants et sortants sur une architecture VoIP centralisée. Autrement dit, on ne parle pas d’un simple téléphone IP posé sur un bureau, mais d’un point d’accès télécom pensé pour un standard, une équipe ou un site complet.
Je distingue toujours le trunk SIP d’une ligne SIP individuelle. Une ligne SIP est rattachée à un appareil ou à un softphone, alors qu’un trunk sert à absorber plusieurs communications simultanées et à les distribuer vers un IPBX, un environnement UC ou un SBC. UC veut dire unified communications, donc un environnement qui regroupe voix, messagerie et collaboration. SBC signifie Session Border Controller, c’est la couche qui aide à sécuriser et normaliser les flux SIP entre deux réseaux.C’est le bon choix quand vous avez besoin de centraliser les appels, de mieux piloter les numéros, ou de faire évoluer la téléphonie sans refaire le câblage. Je le vois souvent dans trois cas très concrets : une PME qui veut professionnaliser son standard, un service commercial qui monte en charge, ou une entreprise multi-sites qui veut garder une logique de téléphonie unifiée. La suite logique, c’est de voir comment ce service s’insère réellement dans votre architecture.
Comment le service s’insère dans une architecture télécom
Dans une architecture classique, le schéma est assez simple : les numéros publics arrivent sur le trunk, le trunk remet les appels à l’IPBX, puis l’IPBX distribue vers les postes internes, les groupes d’appel ou le SVI. À l’inverse, quand un collaborateur émet un appel, l’IPBX le renvoie vers le trunk, qui l’achemine vers le réseau téléphonique public. C’est ce double sens, entrant et sortant, qui donne au système sa souplesse.Sur le plan fonctionnel, les numéros sont souvent gérés en DDI ou en alias, c’est-à-dire des numéros directs qui peuvent être rattachés à une destination précise. Un même trunk peut donc servir à plusieurs usages, par exemple un numéro principal pour le standard, un autre pour le commercial et un troisième pour le support. OVHcloud indique aussi que les appels sont transmis au format international, ce qui évite pas mal de surprises dans les règles de routage si l’on sait le prendre en compte dès le départ.
J’aime bien raisonner en trois blocs. D’abord le bloc opérateur, qui fournit la connectivité téléphonique. Ensuite l’IPBX, qui fait la logique métier, les files, les transferts et les horaires. Enfin le réseau local, qui doit garantir des flux stables et une bonne qualité audio. Si l’un de ces trois blocs est mal réglé, le problème finit presque toujours par apparaître au téléphone. C’est exactement pour cela que le sujet du coût ne doit jamais être isolé du sujet technique.
Combien ça coûte et quel modèle choisir
Sur la page publique d’OVHcloud, deux modes de consommation sont proposés pour le trunk SIP. Le premier est pensé pour la flexibilité, le second pour la visibilité budgétaire. Le bon choix n’est pas une affaire de goût, mais de profil d’usage. Je préfère le dire clairement, parce que c’est là que beaucoup d’équipes se trompent en comparant seulement le prix facial.
| Modèle | Prix public | Appels sortants | Pour qui | Point de vigilance |
|---|---|---|---|---|
| Facturation à l’usage | 4 € HT/mois par canal | Facturés selon la consommation | Sites à trafic variable, activités surtout entrantes, équipes qui veulent garder de la souplesse | Le coût grimpe si les appels sortants deviennent fréquents ou si le nombre de canaux augmente |
| Forfait appels illimités | 19,99 € HT/mois par canal | Fixes et mobiles inclus | Équipes commerciales, centres d’appels, volumes sortants récurrents | Le tarif reste par canal, donc il faut quand même dimensionner correctement le nombre de canaux |
Dans les deux cas, OVHcloud affiche un frais d’installation de 9,99 € HT et annonce jusqu’à 100 canaux. Il y a aussi un élément à ne pas négliger : la tarification est présentée comme dégressive, donc sur un volume sérieux, il vaut mieux vérifier le chiffrage réel plutôt que de multiplier mécaniquement le prix unitaire. En clair, le meilleur modèle n’est pas celui qui paraît le moins cher à l’instant T, mais celui qui colle le mieux au rythme de vos appels pendant plusieurs mois.
Ma règle simple est la suivante : si vos appels sortants sont rares ou très irréguliers, le modèle à l’usage reste logique. Si les appels sortants font partie du quotidien, surtout vers des fixes et des mobiles en France, le forfait illimité devient vite plus lisible. Une fois le budget cadré, il faut regarder le réseau, parce que c’est là que se joue la qualité réelle.
Préparer le réseau et l’IPBX pour éviter les appels hachés
Le point technique le plus sous-estimé, c’est le réseau local. Un trunk SIP fonctionne très bien sur une connexion propre, mais il devient vite pénible si la latence, la gigue ou le pare-feu sabotent les flux audio. La documentation OVHcloud rappelle des valeurs très concrètes : avec G.711, il faut compter environ 80 à 100 kbps par appel simultané en montée et en descente, viser au moins 100 kbps montant par appel, garder une latence inférieure à 150 ms et une gigue idéalement sous 30 ms.
| Point à vérifier | Ce que je recommande | Pourquoi c’est important |
|---|---|---|
| Codec | G.711 a-law en base, G.722 si le matériel le permet, G.711 en secours | Le codec influence la qualité et la bande passante consommée |
| Bande passante | Au moins 100 kbps montant par appel simultané, avec marge | Évite la saturation pendant les pics d’activité |
| Latence | Inférieure à 150 ms | Réduit l’effet d’écho et les conversations saccadées |
| Gigue | Idéalement sous 30 ms | Protège la stabilité audio |
| Pare-feu | UDP 5060, UDP 30000 à 45000, TCP 80 et 443, UDP 123 | Permet la signalisation, la voix, le provisioning et la synchronisation horaire |
| Routeur | QoS activée, SIP ALG désactivé, lien filaire privilégié | Évite les coupures, l’audio unidirectionnel et les défauts d’enregistrement |
Sur le plan sécurité, je conseille de partir du principe qu’un trunk SIP doit rester proprement cloisonné. Si votre architecture le permet, limitez les accès aux seuls équipements légitimes, choisissez des mots de passe solides et surveillez la consommation. Pour la couche de chiffrement, je reste prudent : la documentation publique met surtout en avant le SIP standard, donc si vous avez une exigence stricte en TLS ou en SRTP, mieux vaut valider le cas exact avec votre IPBX avant de le considérer comme un acquis.
Quand le réseau est prêt, la partie qui reste est souvent la plus concrète pour l’utilisateur final, à savoir la gestion des numéros et du routage entrant.
Configurer les numéros, la portabilité et le routage entrant
Le trunk n’est pas utile tout seul, il devient utile quand les numéros et les règles de routage sont correctement pensés. OVHcloud permet de choisir des numéros locaux ou nationaux selon les pays couverts par l’offre, avec une présence annoncée en France, en Belgique, en Suisse et au Royaume-Uni. Pour une entreprise, ce détail change beaucoup de choses, parce qu’un bon plan de numérotation améliore à la fois la lisibilité interne et la perception côté client.
Si vous avez déjà des numéros en service, la portabilité est souvent le vrai sujet. Le délai dépend du type de numéro, mais la base opérationnelle reste simple : pour un fixe isolé, comptez environ 7 jours ouvrés après acceptation du dossier par l’opérateur donneur, et pour une tranche SDA, plutôt environ 30 jours ouvrés. Je préfère insister sur un point : la majorité des retards ne viennent pas de la technique, mais d’un dossier mal préparé, d’un RIO erroné ou d’un titulaire incohérent.
Pour le routage entrant, le principe est toujours le même. D’abord, le numéro alias doit pointer vers le trunk dans l’espace client. Ensuite, dans l’IPBX, il faut créer une règle de routage entrant qui envoie l’appel vers le bon poste, le bon groupe ou le SVI. Si vous gérez plusieurs numéros, chaque DID peut être associé à un destinataire différent. C’est ce qui permet, par exemple, de séparer proprement les appels commerciaux, les appels support et les appels du standard sans bricolage.
Sur un 3CX, OVHcloud publie des gabarits de configuration, ce qui simplifie énormément la mise en route. Sur Asterisk ou FreePBX, la configuration reste manuelle mais le modèle est classique : serveur SIP fourni par l’opérateur, identifiant, mot de passe, numéro principal et codec. Le vrai enjeu n’est pas de cliquer vite, mais de vérifier le sens des flux et la cohérence des numéros affichés à l’extérieur. C’est justement là que beaucoup de déploiements se compliquent inutilement.
Les erreurs que je vois le plus souvent
La première erreur, c’est de dimensionner le trunk sur le nombre de postes et non sur le nombre d’appels simultanés. Un plateau de 20 personnes ne veut pas dire 20 canaux nécessaires, et inversement une petite équipe commerciale peut saturer un trunk beaucoup plus vite qu’on ne le croit. Le bon réflexe consiste à regarder les heures de pointe, pas le simple effectif.
La deuxième erreur, c’est d’ignorer le réseau local. J’ai vu des déploiements impeccables sur le papier, puis ruiné par un SIP ALG activé dans un routeur, un Wi-Fi trop instable ou une QoS absente. Le téléphone semble alors “buguer”, alors que le vrai problème est souvent ailleurs. Si vous entendez un audio haché, un écho ou un appel sans voix dans un sens, commencez par la couche réseau avant de soupçonner l’opérateur.
La troisième erreur, c’est d’oublier que l’identité de l’appelant sortant compte autant que le numéro entrant. Quand les DDI, les alias et la présentation du numéro ne sont pas pensés ensemble, les utilisateurs finissent avec des appels mal identifiés ou des retours clients difficiles à exploiter. En téléphonie pro, la cohérence du numéro affiché n’est pas un détail cosmétique, c’est un vrai sujet de crédibilité.
La quatrième erreur, enfin, c’est de croire qu’un IPBX standard se configure de la même façon partout. Les bases SIP sont communes, mais les menus, les tests de routage, les scénarios de secours et les règles d’appel diffèrent beaucoup d’un environnement à l’autre. Mon conseil est simple : testez toujours les appels entrants et sortants avant la mise en production, puis vérifiez le comportement en cas de pic de trafic. Cela évite les mauvaises surprises le lundi matin.
Quand regarder le Carrier SIP Trunk plutôt que l’offre standard
Il existe un cas où l’offre standard n’est pas le bon angle, et c’est quand on parle d’interconnexion opérateur ou de très gros volumes. OVHcloud propose aussi un Carrier SIP Trunk, réservé aux opérateurs référencés à l’ARCEP et/ou à l’IBPT. Là, on change d’échelle et de logique : l’authentification se fait par IP, les routes sont premium, et l’infrastructure est pensée pour de la classe 4 avec des exigences de disponibilité plus fortes.
| Critère | Offre SIP Trunk standard | Carrier SIP Trunk |
|---|---|---|
| Cible | Entreprises, PME, services clients, IPBX d’entreprise | Opérateurs télécoms |
| Authentification | Paramètres SIP classiques, avec identifiant et mot de passe | Authentification par IP |
| Usage | Centralisation des appels entrants et sortants | Interconnexion directe à fort volume |
| Objectif principal | Souplesse, simplicité, maîtrise du budget | Haute disponibilité, routes premium, gestion de volumes massifs |
Je ne conseille pas de basculer vers le Carrier SIP Trunk par réflexe. Pour une entreprise classique, c’est souvent surdimensionné. En revanche, si vous êtes opérateur, intégrateur télécom ou que vous gérez des flux lourds avec une exigence de continuité très élevée, c’est la bonne piste à étudier. Dans les autres cas, l’offre standard suffit largement, à condition de la dimensionner correctement.
Les vérifications qui valent une heure gagnée avant le go-live
Avant d’ouvrir le trafic en production, je fais toujours la même vérification mentale. Le nombre de canaux correspond-il à la réalité des appels simultanés ? Les numéros entrants pointent-ils vers les bonnes destinations ? Le codec de référence est-il bien compatible avec tous les postes ? Le pare-feu laisse-t-il passer les flux nécessaires ? Et, surtout, les tests ont-ils été faits dans les deux sens, entrant et sortant ?
Si vous avez un besoin variable, commencez sobrement avec la facturation à l’usage. Si vos appels sortants sont réguliers, surtout vers fixes et mobiles, le forfait illimité devient vite plus lisible. Si votre réseau est propre, votre IPBX bien réglé et votre routage entrant clair, le trunk SIP d’OVHcloud fait exactement ce qu’on attend de lui, sans imposer une architecture lourde. C’est pour cela que je le considère comme une solution intéressante pour les entreprises qui veulent une téléphonie pro plus souple, mais pas plus compliquée que nécessaire.
Le vrai gain n’est pas seulement économique. C’est la capacité à faire évoluer la téléphonie au rythme de l’activité, sans multiplier les migrations ni reconstruire le standard à chaque changement d’équipe ou de site.