Portabilité numéro définition et migration cloud PBX
Portabilité numéro définition claire pour les entreprises françaises : cadre ARCEP, RIO, étapes, délais, coûts et bonnes pratiques pour une migration cloud PBX
30 août 2026
Central téléphonique VoIP pour PME et ETI
Central téléphonique VoIP pour PME et ETI : définition, avantages, sécurité, conformité GDPR et critères de choix pour remplacer un PBX on-prem.
Un mardi matin, l'accueil ne répond plus. Le SVI est muet, les appels entrants tombent dans le vide et personne ne sait si le problème vient du PBX, du lien opérateur ou d'un équipement analogique oublié dans une baie. La DSI découvre alors que la téléphonie n'est pas un simple service administratif. C'est une infrastructure de continuité, avec des dépendances techniques, réglementaires et opérationnelles.
Un central téléphonique VoIP peut réduire cette dépendance au matériel local, mais il ne suffit pas de remplacer un vieux PBX par une application cloud. Il faut vérifier le Trunk SIP, les équipements satellites, la résilience réseau, la localisation des données et le plan de retour arrière. Pour une PME, une ETI, un intégrateur IT ou un revendeur télécom, la bonne décision se prend sur ces preuves concrètes, pas sur une démonstration commerciale.
Table des matières
Pourquoi votre PBX devient un problème stratégique
Une PME industrielle de 80 personnes découvre rarement la fragilité de son standard pendant un comité budgétaire. Elle la découvre lorsque son PBX Alcatel-Lucent tombe en panne un mardi matin. Le SVI et les files d'attente cessent de fonctionner, les factures Orange RTC dérivent, les pièces détachées deviennent difficiles à trouver et le technicien spécialisé facture 480 € la demi-journée.
La panne révèle alors un triple verrouillage. Le matériel arrive en fin de support éditeur, les compétences TDM deviennent difficiles à recruter et l'entreprise reste attachée à un opérateur RTC dont le réseau cuivre doit être fermé progressivement par Orange d'ici 2030, dans le cadre du plan de fermeture du cuivre. La fin du RTC en France n'est donc pas une abstraction technique. Elle oblige les directions à inventorier leurs lignes, leurs usages et leurs équipements dépendants.
Le vrai risque dépasse la panne matérielle
Un PBX on-prem vieillissant concentre plusieurs risques au même endroit. Le serveur, les licences, les cartes téléphoniques, les sauvegardes, les postes et la relation avec l'opérateur doivent tous rester compatibles. Quand un seul maillon n'est plus maintenu, l'entreprise peut perdre son accueil téléphonique, son routage, son historique d'appels et sa capacité à rétablir rapidement le service.
Un central téléphonique VoIP dissocie le terminal du cœur logique. Le terminal peut être un téléphone IP, un softphone ou un combiné DECT compatible. Le cœur logique, lui, réside dans un IPBX hébergé ou dans une plateforme cloud consommée comme un service. Cette séparation simplifie les changements, mais elle transfère une partie de la responsabilité vers le réseau IP, l'opérateur et le fournisseur cloud.
Règle de décision : une migration VoIP ne doit pas être justifiée uniquement par l'obsolescence du PBX. Elle doit réduire un risque identifié, documenter les dépendances et garantir un retour arrière exploitable.
Le sujet devient stratégique pour trois raisons. La première est la continuité d'activité. La deuxième concerne la conformité des journaux, enregistrements et métadonnées. La troisième touche l'organisation du travail, car un standard limité au site principal pénalise le télétravail, les équipes mobiles et les recrutements répartis.
Anatomie d'un central téléphonique VoIP
Un IPBX se comprend mieux avec une analogie domotique. Le contrôleur joue le rôle du cerveau logiciel. Il applique les règles de taxation, présente le SVI, distribue les appels dans les files d'attente, gère les horaires et administre les utilisateurs. Les terminaux sont les points de contact, avec les téléphones IP, les softphones, les combinés DECT et les postes de conférence.
Cette distinction est essentielle, car un remplacement de combinés ne constitue pas une migration complète. Le cœur du service se trouve dans l'IPBX et dans sa connexion au réseau téléphonique public. Une présentation pédagogique de la définition d'un IPBX aide à séparer ces couches avant de rédiger un cahier des charges.
Le Trunk SIP commande la qualité réelle
Le Trunk SIP est le lien de transmission des données entre l'entreprise et l'IPBX hébergé par l'opérateur, comme le précise la documentation consacrée au Trunk SIP en France. Il relie la logique de l'IPBX au réseau public et porte les enjeux de numérotation, de portabilité, de routage et de continuité de service.
La qualité dépend donc moins du téléphone posé sur le bureau que de la stabilité IP, de la capacité du lien et du routage opérateur. Les codecs G.711, G.722 et Opus peuvent être pertinents selon le contexte, mais ils ne compensent pas une congestion persistante. La supervision doit suivre la latence, le jitter, les pertes de paquets et un indicateur de qualité comme le MOS.
Un SBC protège et contrôle la frontière entre le réseau de l'entreprise, le Trunk SIP et les terminaux. Les architectures exigeantes ajoutent un double lien Internet ou un accès MPLS selon la criticité, ainsi qu'une bascule testée. Les passerelles FXS et FXO restent utiles pour les équipements analogiques, tandis que les enregistreurs vocaux et les outils de supervision doivent être intégrés au périmètre dès la conception.
Cloud ou on-prem, le choix porte sur l'exploitation
Un IPBX cloud ressemble à un compteur électrique communicant. Le service est hébergé, administré depuis une interface et mis à jour par l'opérateur. Un IPBX on-prem ressemble davantage à un ancien compteur mécanique. L'entreprise conserve la machine, la baie, les sauvegardes, les licences et la responsabilité des mises à jour.
Le cloud réduit la charge d'exploitation locale, mais crée une dépendance au fournisseur et au réseau. L'on-prem offre une maîtrise directe, mais impose des compétences internes et une stratégie de remplacement. Le choix doit suivre la criticité, les contraintes de souveraineté, la capacité de l'équipe IT et la situation des équipements satellites.
Ce que change vraiment un standard cloud pour une PME
Le cloud transforme d'abord la structure de coût. Un projet on-prem peut nécessiter un CAPEX de 35 à 80 k€ pour le PBX, les licences et le câblage, tandis qu'un standard cloud se facture généralement en OPEX par poste et par mois, avec des contrats pouvant aller de 12 à 36 mois. Ces montants de comparaison doivent être confirmés par un devis détaillé, car le prix apparent masque souvent les communications, les options et le matériel.
Le passage au cloud apporte aussi une mobilité opérationnelle. Un collaborateur peut utiliser un softphone sur PC ou mobile, conserver un numéro unique et travailler sans déployer un VPN voix dédié. La présence unifiée, les règles de routage et les files d'attente réduisent les contournements, à condition que le réseau et les casques soient correctement préparés.
Les gains doivent être vérifiés dans le portail d'administration
L'administration constitue souvent le bénéfice le plus tangible. L'ajout d'un poste peut être réalisé en moins de 10 minutes depuis un portail web, contre une intervention plus lourde sur un PBX local. La maintenance on-prem représente souvent 15 à 20 % du CAPEX annuel, mais ce poste doit être comparé avec le coût total de l'abonnement, du support, des numéros, des appels et des intégrations.
Le cloud facilite aussi le passage d'un site à cinq sans réinvestissement matériel central. Il ne supprime pas les coûts de réseau, de terminaux, de formation ou de secours. Il ne garantit pas non plus une qualité parfaite si la connexion Internet est instable.
| Critère | PBX on-prem | Standard cloud |
| Investissement initial | CAPEX de 35 à 80 k€ selon le périmètre | OPEX par poste et par mois |
| Contrat | Maintenance et licences à renouveler | Contrats de 12 à 36 mois possibles |
| Administration | Intervention dans la baie ou via une équipe spécialisée | Portail web et gestion centralisée |
| Déploiement multi-site | Ajout de capacité matérielle | Extension plus souple, sous réserve du réseau |
| Dépendance principale | Matériel, licences et compétences TDM | Internet, Trunk SIP et fournisseur |
| Mobilité | Souvent limitée par l'architecture locale | Softphone et accès distant natifs |
| Points de vigilance | Obsolescence et pièces détachées | Latence, panne réseau et coût des numéros internationaux |
Le compromis est clair. Le cloud simplifie l'exploitation et accélère les changements, mais il exige une connexion stable, une politique de secours et un contrôle strict du coût marginal des numéros internationaux.
Sécurité, GDPR et hébergement en Europe
Un fournisseur ne peut pas réduire la conformité à la formule « cloud sécurisé ». Trois vérifications s'imposent. Il faut d'abord cadrer le traitement des données, notamment la journalisation des appels, la conservation des enregistrements, l'information des salariés et la base légale. Il faut ensuite établir la localisation effective des données, puis examiner la protection de l'infrastructure et des sous-traitants.
La CNIL recommande de privilégier les fournisseurs qui indiquent clairement les pays hébergeant leurs centres de données. Elle déconseille les services qui ne donnent aucune garantie sur la localisation réelle et les transferts hors de l'Union européenne, comme le rappelle son guide sur le cloud computing. Le nom d'une région commerciale ou la présence annoncée d'un datacenter à Francfort ne suffit pas.
Le dossier fournisseur doit être vérifiable
La CNIL demande de cartographier les données et les traitements hébergés, de contrôler les sites de sauvegarde et d'évaluer le prestataire selon des spécifications reconnues. Pour un standard téléphonique, cette cartographie couvre les enregistrements, les journaux, les annuaires, les métadonnées, les messages vocaux et les données d'administration.
Pour les données de santé, l'hébergeur doit disposer d'une certification HDS, conformément à l'article L1111-8 du Code de la santé publique. Le contrat et l'architecture doivent aussi prévoir le chiffrement des données au repos et en transit, ainsi qu'une gestion appropriée des clés, comme l'indique le guide de sécurité pour les données personnelles.
Une ETI qui traite des données sensibles doit examiner SecNumCloud. La CNIL et l'ANSSI distinguent cette qualification face au risque d'accès par des autorités étrangères. La qualification française comprend un critère de protection contre l'accès par une puissance étrangère. La loi française SREN du 21 mai 2024 prévoit également, pour certains systèmes manipulant des données sensibles pour l'État, des garanties contre l'accès par des autorités de pays tiers non autorisées par le droit européen ou celui d'un État membre, selon les éléments présentés dans les travaux de la CNIL sur les risques cloud en Europe.
Exigence DSI : un hébergement UE doit être démontré par des documents, des clauses contractuelles, une cartographie des sous-traitants et une procédure d'audit. Il ne doit pas rester une promesse commerciale.
L'hébergement exclusivement dans l'EEE peut être retenu dans le cadre de codes de conduite GDPR applicables aux prestataires cloud. Ce choix fournit un critère contractuel utile aux intégrateurs, sans rendre automatiquement le service conforme à tous les usages. La conformité dépend aussi du traitement, des accès, de la conservation et de la répartition des responsabilités.
Postes satellites et continuité de service
La migration échoue souvent sur les équipements qui ne ressemblent pas à des téléphones. Fax, alarmes, ascenseurs, terminaux de paiement et interphones peuvent encore dépendre d'une ligne analogique ou d'un signal spécifique. La fermeture progressive du RTC oblige donc à dresser un inventaire séparé des équipements satellites, avec leur criticité, leur contrat de maintenance et leur méthode de communication.
Une passerelle ATA peut conserver certains usages analogiques, mais elle n'est pas une réponse universelle. Un routeur 4G ou 5G avec secours LTE peut mieux convenir à un site isolé, à condition que la couverture, l'alimentation et les tests de bascule soient documentés. Les équipements SIP natifs sont plus simples à superviser, mais leur remplacement peut coûter davantage à court terme.
La résilience se conçoit avant la panne
Une PME ne doit pas demander uniquement si le standard cloud est disponible. Elle doit demander ce qui se passe lorsque le lien principal tombe, que le site perd son alimentation ou que le Trunk SIP ne répond plus. Les mécanismes pertinents incluent un softclient basculant vers le mobile, un SBC redondé, deux Trunks SIP indépendants et un mode survivable du PBX local lorsque le cloud devient inaccessible.
Une panne voix de 4 heures dans une PME de 50 postes peut provoquer des appels manqués et une perte de chiffre d'affaires directement mesurable. Le montant dépend du secteur, des horaires et de la valeur des appels. Le raisonnement doit partir de ces flux critiques, plutôt que d'un SLA isolé.
| Architecture | Mode de bascule | Coût relatif | Adapté à |
| Lien Internet unique | Aucun secours automatique | Faible | Site peu critique |
| Double accès Internet | Bascule du lien principal vers le secondaire | Moyen | PME avec accueil important |
| Trunk SIP redondé | Routage vers un second opérateur | Moyen à élevé | ETI et centres de relation client |
| Cloud avec secours mobile | Renvoi vers softclient 4G ou 5G | Moyen | Équipes mobiles et sites distants |
| Hybride avec survivabilité locale | Maintien de fonctions locales pendant une panne cloud | Élevé | Santé, industrie et services essentiels |
Un taux affiché de 99,9 % correspond à 8 h 76 de coupure annuelle tolérée, selon la conversion fournie dans le périmètre de référence. Même un SLA attractif ne remplace pas une architecture adaptée. Le contrat mesure une obligation du fournisseur, pas la capacité de chaque site à continuer ses appels.
Les recommandations de haute disponibilité VoIP doivent donc être traduites en scénarios testés, avec critères de déclenchement, responsables nommés et retour documenté.
Cas d'usage sectoriels à forte exigence
Le même central téléphonique VoIP ne convient pas à une clinique, à un hôtel, à une université et à une collectivité. Le catalogue de fonctions ne suffit pas. Le bon archétype dépend du niveau de confidentialité, de la continuité attendue, de la saisonnalité et de la capacité de l'organisation à administrer elle-même l'infrastructure.
Santé
Une clinique ou un EHPAD doit commencer par les données traitées. Si les appels, messages ou enregistrements contiennent des données de santé, la certification HDS de l'hébergeur devient un critère de sélection. La traçabilité des accès, la conservation maîtrisée, le secret médical et le chiffrement priment sur la richesse du catalogue.
Un cloud managé peut convenir si le fournisseur démontre son hébergement, ses sauvegardes et ses responsabilités. Un IPBX on-prem reste envisageable lorsque l'établissement doit conserver une maîtrise locale stricte, mais il devra alors financer les compétences, la redondance et la maintenance.
Hôtellerie
Un hôtel cherche surtout une administration multi-site, un SVI multilingue, une gestion saisonnière et une intégration avec le PMS. Les postes de réception, les réservations, les chambres et les services internes n'ont pas les mêmes règles de routage. La solution doit aussi traiter les ascenseurs, interphones et dispositifs d'urgence sans les confondre avec des extensions ordinaires.
Le cloud managé offre une meilleure souplesse pour les ouvertures et fermetures de sites. La priorité reste toutefois la survivabilité locale et la qualité du réseau dans chaque établissement.
Éducation
Une école ou une université doit absorber les pics d'appels de rentrée, gérer des annuaires métiers et permettre la mobilité des étudiants et des équipes. L'intégration avec Microsoft Teams ou Zoom peut simplifier les usages, mais elle ne doit pas masquer les questions de gouvernance, de droits et de conservation.
Un cloud européen convient souvent aux structures multi-campus. Un IPBX local peut rester pertinent dans un campus où le réseau interne est mieux maîtrisé que les accès intersites.
Collectivités et EPIC
Les collectivités ajoutent la commande publique, l'accessibilité et la continuité du service public. La qualification SecNumCloud peut être exigée selon la sensibilité du système et les règles de l'organisation. Les services doivent aussi documenter le routage des appels d'urgence, la protection des données et l'accessibilité pour les personnes sourdes.
Une solution cloud qualifiée peut répondre aux exigences de gouvernance, tandis qu'un IPBX on-prem peut s'imposer dans un environnement très fermé. L'intégrateur doit produire une matrice de conformité, pas seulement une liste de fonctionnalités.
Critères concrets pour choisir son fournisseur
Un appel d'offres VoIP doit produire des réponses binaires. Le commercial peut présenter une interface fluide, des intégrations et une promesse de déploiement rapide. La DSI doit surtout savoir où résident les données, qui administre le Trunk SIP, comment fonctionne la bascule et comment récupérer les numéros en sortie.
La grille de qualification
| Critère | Question à poser | Rédhibitoire |
| Localisation des données | Quels pays hébergent les données, les sauvegardes et les journaux ? | Réponse vague ou absence de cartographie |
| Sécurité | Quelle certification est détenue, ISO 27001, HDS ou SecNumCloud selon le périmètre ? | Attestation impossible à fournir |
| Trunk SIP | L'interopérabilité est-elle testée, et le BYOC est-il possible ? | Trunk imposé sans procédure de test |
| Disponibilité | Quels indicateurs sont mesurés, et sur quels composants porte le SLA ? | SLA sans méthode de mesure |
| Latence et qualité | Quelle supervision existe pour le jitter, les pertes et la qualité vocale ? | Aucun tableau de suivi exploitable |
| Portabilité | Comment les numéros et les configurations sont-ils exportés ? | Procédure de sortie absente |
| Sous-traitance | Quels prestataires traitent les données et dans quels pays ? | Sous-traitants non identifiés |
La CNIL recommande de vérifier les sites de sauvegarde et les obligations contractuelles. L'entreprise doit donc demander une attestation d'hébergement, le registre des traitements pertinent, le DPA, les certificats disponibles, les résultats d'audit applicables et une référence client vérifiable dans un secteur comparable.
Question qui révèle vite le niveau du fournisseur : « Quelle est la procédure exacte si l'entreprise veut récupérer ses numéros, ses configurations et ses enregistrements ? » Une réponse imprécise signale une dépendance contractuelle mal maîtrisée.
Le Trunk SIP mérite un test indépendant. Un fournisseur qui refuse l'interopérabilité, le BYOC ou une campagne de test avant portabilité doit être écarté. La facturation doit aussi séparer les licences, les communications, les numéros, l'enregistrement, les intégrations, le support et les équipements. Les bundles rendent les comparaisons artificiellement favorables.
Voxbi peut être évalué dans cette grille comme standard téléphonique cloud hébergé dans l'Union européenne, avec administration depuis un navigateur et applications pour les utilisateurs, sans considérer ces éléments comme une preuve automatique de conformité pour chaque organisation. La DSI doit vérifier le périmètre contractuel, les données traitées, les sauvegardes et les exigences propres à son secteur.
Décider et migrer sans interruption
Une migration solide commence par l'audit du parc. Les équipes recensent les postes analogiques, les DECT, les fax, les lignes d'urgence, les ascenseurs, les alarmes, les terminaux de paiement, les numéros SDA et les règles de routage. Aucun équipement connecté à une ancienne ligne ne doit être laissé hors périmètre.
Le projet suit ensuite quatre phases. L'équipe choisit un mode transitoire, généralement une exécution en parallèle avant la bascule, teste la charge du Trunk SIP, puis porte les numéros et bascule progressivement par site ou par service. Le PABX historique reste disponible comme secours pendant les 30 premiers jours, avec un plan de retour arrière écrit et validé.
Le pilote doit porter sur 10 à 20 postes avant la généralisation. Les KPI sont suivis pendant trois mois, avec la qualité vocale, les appels manqués, les incidents, les délais de traitement et l'adoption des softphones. Les erreurs les plus fréquentes sont connues, portabilité mal anticipée, QoS oubliée sur le routeur et formation insuffisante des agents.
La décision finale ne porte donc pas seulement sur le cloud ou l'on-prem. Elle porte sur la capacité à garder le service actif, à prouver où circulent les données et à sortir proprement de la solution. Un fournisseur européen peut répondre à cette exigence, mais la DSI doit encore tester l'architecture et encadrer les responsabilités.
Voxbi propose un standard téléphonique cloud pour les entreprises européennes, avec un hébergement dans l'Union européenne et une administration centralisée des utilisateurs, extensions et flux d'appels. Les PME, ETI et intégrateurs IT peuvent examiner son approche et vérifier son adéquation à leurs contraintes de continuité et de souveraineté sur Voxbi.
