Les systèmes de type IPPBX et les plateformes de services sont par certains côtés de nature très différente, en quelque sorte comme des pommes et des oranges. Tandis que dans la plupart des cas, la plateforme de services opérateur inclut les capacités des IPPBX i.e. traitement d’appels, serveurs vocaux interactifs, couplage téléphonie-informatique, l’inverse n’est pas toujours vrai.

Les technologies des plateformes de services existent depuis la fin du siècle précédent (Linux, Java, Switching logiciel, technologies Web, XML …).  Plus populaire dans les pays anglo-saxons et en Europe du Nord, elles ne se développent en France qu’avec l’avènement de la voix sur IP au début des années 2000, d’abord dans un contexte de transit VoIP puis sur le marché résidentiel, et arrivent enfin à maturité sur le marché entreprise depuis quelques années, après un long apprentissage sur le terrain.

La capacité de gestion multi-entreprises et la densité en termes d’abonnés et d’entreprises

En termes de densité d’abonnés et de gestion multi-entreprises, un IPPBX est conçu pour servir une seule entreprise mono et/ou multi sites voire quelques entreprises en « chainant » des IPPBXs ou en essayant de partitionner le système. La taille de la société peut varier de la simple dizaine jusqu’à plusieurs centaines voire quelques milliers d’abonnés au maximum pour un même IPPBX. Néanmoins les installations dépassant le millier d’abonnés sont assez rares et sont réservées à des produits spécifiques souvent très onéreux.

En revanche, une plateforme de services Opérateur est conçue dès le départ pour gérer plusieurs dizaines à plusieurs centaines de milliers d’abonnés de manière centralisée. Surtout, par conception, les abonnés peuvent appartenir à différentes entreprises, et si la plateforme est bien conçue, elle peut traiter indifféremment 1000 sociétés de 10 abonnés ou 10 sociétés de 1000 abonnés, ce qui lui confère une immense flexibilité. A la différence de certaines solutions Centrex créées en partitionnant artificiellement des gros PABX/IPPBX ou gros Switch d’opérateurs, la plateforme de services permet de configurer des fonctionnalités très différentes entre les entreprises et de bien cloisonner les services et les données de configuration.

En effet, les plans de numérotation internes et externes, les SVIs, les applications CTI, les files d’attente, les ressources vocales … sont configurés de manière centralisée via des interfaces web d’administration mais sans aucune contrainte ni interdépendance d’une entreprise à l’autre. La plateforme de services allie donc gestion centralisée, flexibilité de configuration des services et cloisonnement des données d’une entreprise à l’autre.

La plateforme de services dispose à ce titre de niveaux hiérarchiques d’administration et de gestion opérationnelle dans un contexte multi-entreprises afin de permettre un modèle de distribution « multi-tiers » : niveau gestionnaire de plateforme, niveau fournisseur de services, niveau revendeur, niveau administrateur d’entreprise. A chaque niveau, les administrateurs peuvent travailler sur leur parc avec les droits qui leur ont été alloués par un administrateur de niveau supérieur. On parle d’une structure hiérarchique de domaines administratifs et d’administrateurs.

La flexibilité, l’interopérabilité et l’évolutivité

Un IPPBX, quant à lui, est le plus souvent un système installé par rapport à des besoins précis en termes de parc d’abonnés, de nombre de sites et de fonctionnalités. Toute évolution du besoin de l’entreprise peut conduire à l’obsolescence de l’IPPBX, soit en termes d’effet de seuils sur les ressources (nombre d’abonnés, nombre d’appels simultanés, nombre de boites vocales …), soit en termes de nouvelles fonctionnalités qui nécessitent un serveur dédié séparé par exemple pour les Softphones ou les applis CTI.

Une plateforme de services de type opérateur est un système évolutif en termes de capacité et en termes de fonctionnalités. Comme toute solution logicielle performante, les capacités fonctionnelles et les quantités sont contrôlées par licence puis réparties entre les différents domaines hiérarchiques d’administration. Cette licence peut naturellement être mise à jour à chaud pour augmenter les capacités de la plateforme (fonctionnalités et quantités). D’autre part, lorsque les limites de la configuration matérielle sont atteintes (dans un contexte de serveurs physiques ou de machines virtuelles), il suffit de rajouter au sein de la plateforme un serveur supplémentaire (virtuel ou physique) qui va venir s’intégrer au cœur du même système central d’administration.

La mise à jour d’un parc important d’IPPBX hébergés peut s’avérer, quant à elle, plus fastidieuse voire impacter la disponibilité du service si le système n’a pas prévu des mécanismes particuliers très performants. Certains IPPBXs sont en effet assez lourds dans leurs mises à jour, surtout les majeures qui peuvent prendre jusqu’à 60 minutes et nécessiter plusieurs reboots successifs. D’autres, dans leurs versions virtualisées peuvent nécessiter plusieurs machines virtuelles par entreprise, (par exemple trois), ce qui alourdit encore davantage la procédure de mise à jour du système pour un grand nombre d’entreprises (petites ou grandes).

En termes d’évolutivité et de flexibilité, la plateforme de services a également l’avantage sur les IPPBX au niveau de ses capacités d’interconnexions avec les réseaux fixes et mobiles des opérateurs dans un contexte hétérogène et multi-protocoles (SIP, ISUP, Camel …). En effet, certains services avancés de convergence fixe-mobile ou d’interrogation de l’état des abonnés mobiles peuvent nécessiter de supporter ces différents protocoles et de pouvoir s’adapter à l’évolution du marché et des législations qui obligent progressivement les opérateurs mobiles dominants à ouvrir leur réseau.

La disponibilité du service est un autre facteur décisif dans la sélection de la solution. A ce titre, une gestion de la redondance incluant détection de panne et reprise automatique du service doit être prévue en cas de défaillance d’un module. Ces mécanismes de redondance alliés à une architecture de haute disponibilité permettent de classer la solution ‘Carrier Grade’, c’est-à-dire de qualité opérateur avec des taux de disponibilité élevés (99.99 % par exemple, signifiant que le service fonctionne 99.99 % du temps soit 52 minutes d’indisponibilité par an). En comparaison, les IPPBX ne proposent pas ou que très peu de tels mécanismes de redondance logicielle avec détection de panne et reprise automatique, et leur expérience dans le domaine du logiciel et de la virtualisation est plus récente.

Une plateforme de services convergents basée sur des standards ouverts comme SIP n’est pas liée à un revendeur de terminaux et donc à ce titre permet la gestion de terminaux de marques hétérogènes. Ce qui ne signifie pas que l’on peut faire n’importe quoi et que n’importe quel terminal de n’importe quelle marque peut être déployé sur la plateforme. Certes, les appels simples en SIP pourraient éventuellement fonctionner si on active le profil de terminal SIP générique, mais cela est loin d’être suffisant.

Un partenariat fort est nécessaire entre l’éditeur de la plateforme de services et le fabriquant de poste SIP, afin de réaliser une certification garantissant la mise en œuvre automatisée du poste, le bon fonctionnement de l’ensemble des fonctionnalités nécessaires à la téléphonie d’entreprise et la pérennité de l’interopérabilité avec les nouvelles versions respectives. Mais, dans tous les cas, l’ouverture que garantit l’utilisation du protocole standardisé SIP, permet, sur la même plateforme, de certifier de nouvelles familles de postes et ainsi répondre au mieux aux évolutions du marché.

En comparaison, l’IPPBX des fabricants traditionnels, lui, est en général lié à une marque de terminaux avec une approche de type propriétaire, ce qui force l’intégrateur et donc l’entreprise à un couple figé IPPBX/Terminaux dans son infrastructure. Les différentes tentatives des équipementiers traditionnels annonçant le rajout du support du SIP sur leurs IPPBX, visaient pour la plupart à la fois un effet d’annonce pour casser leur image de fermeture et un effet de dénigrement.

En effet, en réalisant une implémentation basique ou partielle du SIP, cela leur permettait de brancher des postes SIP de base et passer des appels simples, fonctionnalité tout à fait insuffisante pour permettre aux entreprises de déployer d’autres postes que ceux de la marque de l’IPPBX, renforçant ainsi leur discours sur les limitations du SIP. Il faut cependant bien reconnaître, que cette approche des fabricants traditionnels d’IPPBX avait été grandement facilitée pendant de nombreuses années par les premières générations de plateformes de services et de téléphones IP. Elles ne brillaient ni par leur qualité, ni par leur maturité, en termes d’ergonomie, de richesse des fonctionnalités supportées, et enfin en termes de couverture de l’ensemble de la gamme de postes requises, mais ce temps de l’apprentissage est maintenant bien révolu.

Conçu pour être hébergé et administré à distance …

Enfin, la plateforme de services, en raison de sa cible Opérateurs initiale, a été conçue pour être hébergée dans un data center, ce qui implique de gérer les problématiques liées au déploiement à travers le réseau WAN comme la traversée du NAT (translation d’adresse), l’optimisation du routage des flux voix afin de limiter la bande passante requise ainsi que la gestion à distance d’un parc de téléphones potentiellement hétérogènes, sans parler des contraintes liées à la sécurisation de la plateforme en terme d’authentification et de protection vis-à-vis des attaques en déni de services. Ces problématiques sont assez nouvelles pour les IPPBX qui ont été initialement conçus pour être déployés sur le réseau voix (c’est-à-dire non joignable depuis les réseaux informatiques) et sur les sites des entreprises. Il existe bien sûr des solutions dédiées pour protéger une infrastructure VoIP de manière externe, par exemple avec l’utilisation d’un Session Border Controller (SBC), une sorte de Firewall intelligent qui comprend le protocole SIP et masque la topologie réseau vis-à-vis des tiers, mais on ne s’improvise pas expert dans ce domaine, comme l’ont compris de rares équipementiers qui ont racheté des acteurs du monde du SBC d’entreprises.

_________
Bertrand Pourcelot est Directeur Général de Centile Telecom Applications