En UCaaS, la question n'est plus quelle solution, mais qui lit vos communications
Un panorama UCaaS compare des features. Sur le terrain, ce qui décide, c'est la taille, le coût, et surtout ce que la plateforme s'autorise à faire de vos données. RingCentral demande l'accès à vos enregistrements et vos messages privés. Ce client est passé sur du Wazo.
Un panorama UCaaS classe des plateformes, compare des features, aligne des logos et désigne des gagnants. En 2026, la question qu'il traite n'est plus celle que mes clients me posent.
Le client qui m'appelle n'a pas besoin qu'on lui dise quelle UCaaS est la meilleure. Il a besoin qu'on organise sa téléphonie autour des géants, Microsoft en tête, et qu'on la place là où elle a du sens pour sa taille, son budget et ses données. Il ne choisit plus une solution isolée, il compose avec un écosystème déjà installé chez lui.
Trois critères décident vraiment : la taille, le coût et ce qu'on autorise avec la donnée. Le dernier est celui que je ne vois jamais écrit dans un panorama.
| Ce qui décide | Ce que je pose | Pourquoi |
|---|---|---|
| Secret à protéger, donnée sensible | On-prem : Wazo, 3CX, Yeastar | La donnée reste chez le client, en EU, hors Cloud Act |
| Features cloud, contrainte donnée acceptable | RingCentral ou Zoom, du SMB au grand compte | La plateforme suit le besoin et le budget, à toutes les tailles |
| Déjà tout chez Microsoft | On s'intègre à Teams | On s'organise autour du géant, on ne le remplace pas |
Le panorama pose la mauvaise question
Un panorama désigne un gagnant universel, alors qu'il n'y en a plus depuis que Microsoft a pris le centre de gravité. Le client qui a déjà M365 a déjà Teams, et sa question n'est pas « quelle UCaaS » mais « comment j'organise le reste autour de ça ».
L'on-prem n'est pas mort pour autant. Il est minoritaire et il le restera dans les prochaines années, mais minoritaire ne veut pas dire fini. Quand il est une obligation, il ne se pose pas à côté de l'écosystème comme un choix rival, il s'y branche.
Mon métier n'est plus de trancher entre des vendeurs. Il consiste à placer chaque client sur la plateforme qui colle à sa réalité, puis à accrocher le reste aux géants qui sont déjà là.
Le vrai critère, c'est ce qu'on autorise avec la donnée
Un client avec une contrainte de confidentialité réelle m'a demandé de regarder RingCentral. Par défaut, l'éditeur y demande un accès total et systématique aux enregistrements et aux messages privés, un accès qui n'est pas activé au besoin mais accordé d'emblée.
Ce client avait du secret à protéger et il n'a pas signé. Il est passé sur un Wazo self-hosted, où la donnée reste sur son infrastructure à lui, en EU, sans qu'aucun tiers ne la lise et avec les accès sous son contrôle.
Ce n'était pas une question de features, puisque RingCentral en a davantage. C'était une question de qui a le droit de lire, et la réponse d'un éditeur américain ne s'arrête pas à ses conditions commerciales. Il y a le Cloud Act : une plateforme américaine peut être contrainte de livrer la donnée à une autorité américaine, quel que soit le lieu d'hébergement. Garder la donnée en EU, sur une brique qu'on héberge soi-même, c'est sortir de cette portée.
Il y a l'IA, aussi. Chaque éditeur pousse sa brique de transcription, de résumé et d'analyse, entraînée sur les communications elles-mêmes quand les conditions le permettent. Un enregistrement d'appel et un message privé ne sont pas de la donnée comme une autre, et c'est pour ça que je lis les conditions avant de lire la fiche produit.
L'on-prem n'est pas mort, il est minoritaire
Je ne vends pas l'on-prem comme un retour en arrière et il ne redeviendra pas majoritaire, mais il reste la réponse quand la donnée est une obligation plutôt qu'une préférence.
Un Wazo, un 3CX ou un Yeastar font le travail, du SMB à la structure multi-sites, avec une maîtrise totale et des données qui restent en EU. Ce n'est pas une affaire de taille, puisque RingCentral et Zoom savent aussi servir une petite structure. Ce qui fait pencher vers l'on-prem n'est pas le nombre d'utilisateurs mais le secret à garder.
Quand le client est déjà chez Microsoft, l'on-prem ne s'oppose pas à Teams, il s'y intègre. Je pose la brique là où l'utilisateur travaille déjà, comme une application dans son environnement plutôt que comme un silo à part.
Ce que ça change pour l'intégrateur
Le métier a bougé. La valeur consistait à connaître le meilleur produit et à le revendre, alors qu'aujourd'hui le client trouve seul le meilleur produit. Ce qu'il ne trouve pas seul, c'est où placer sa téléphonie pour sa taille, son budget et son secret, et comment l'accrocher à l'écosystème qu'il a déjà.
J'en tire deux réflexes.
Le premier est que je lis des conditions plutôt que de comparer des features. Le classement d'un panorama dit ce qu'une plateforme fait, ses conditions disent ce qu'elle s'autorise à faire de la donnée, et les deux ne racontent pas la même histoire. C'est la seconde qui engage le client.
Le second est que je ne pose pas une solution à côté de Microsoft, je m'organise autour. Le géant est déjà là, et le travail consiste à composer avec lui, à placer chaque brique au bon endroit et à garder la main sur ce qui compte pour le client.
Je ne vends donc pas une UCaaS. Je place une plateforme et je l'organise autour des géants, parce que c'est la question que mes clients me posent aujourd'hui.
Un choix de plateforme UCaaS qui coince sur la donnée, une brique on-prem à intégrer dans un environnement Microsoft, une migration qui doit rester en EU ? Prendre contact.
Note terrain par qaryon
Nicolas Marxer
Architecte solutions en communications d'entreprise, spécialisé dans les déploiements opérateur, intégrateur et B2B.
Besoin d'un avis terrain sur votre architecture de communication ?
Audit, cadrage ou déploiement : j'interviens directement sur UCaaS, CCaaS, IPBX, SBC, automatisation et IA appliquée.
Discuter d'un projet télécomÀ lire aussi
qaryon est officiellement lancé
qaryon est créé, assuré, en production et facture déjà des prestations B2B de conseil télécom et IA pragmatique.
Sur un trunk SIP, la sécurité n'est pas une option de déploiement, c'est une responsabilité contractuelle
Toll fraud, STIR/SHAKEN, mTLS, durcissement du SBC. Ce qui protège un trunk SIP en 2026, couche par couche, avec les configurations et la checklist.
Isoler un datacenter VoIP en journée, sans couper un appel
Intervenir sur un datacenter en journée sans couper un client. Le drain passe par le DNS, pas par le SBC : on retire l'IP, on laisse les sessions finir, on remet en miroir. Le vrai piège, c'est le TTL.