Téléphonie Microsoft Teams choisir et déployer

Une entreprise ouvre Microsoft Teams le matin pour ses réunions, ses messages et ses documents. Quelques minutes plus tard, un client appelle le standard, un fournisseur compose un numéro fixe et un collaborateur décroche son mobile. La collaboration est centralisée, la téléphonie reste ailleurs. C'est ce décalage qui rend la téléphonie Microsoft Teams intéressante, à condition de ne pas la réduire à un bouton d'appel dans une application.

Table des matières

• Pourquoi intégrer la téléphonie à Microsoft Teams

  • Ce que l'intégration doit réellement résoudre

• Teams, téléphonie et PBX sont trois briques distinctes

  • Teams et Teams Phone

  • Le rôle propre du PBX

• Comparer les trois options de téléphonie Microsoft Teams

  • Microsoft Phone System et forfaits d'appels

  • Operator Connect

  • Direct Routing

• Licences et composants à prévoir

  • Le socle Microsoft

  • Les composants hors licence utilisateur

• Intégrer un cloud PBX comme Voxbi

  • Trois scénarios à ne pas confondre

• SIP, WebRTC, sécurité et qualité réseau

  • SIP, WebRTC et SBC

  • Sécurité et chiffrement

  • Qualité de bout en bout

• Numérotation et continuité d'accès

  • Construire l'inventaire

  • Normaliser en E.164

  • Tester la non-régression

• Checklist de déploiement et guide de décision

  • Checklist avant déploiement

Pourquoi intégrer la téléphonie à Microsoft Teams

Une PME multi-sites connaît bien cette scène. L'accueil transfère un appel depuis un poste fixe, le service commercial rappelle depuis un mobile, puis l'équipe poursuit la conversation dans Teams. Personne ne voit le parcours complet. Les numéros présentés changent, les files d'attente vivent dans l'ancien système et la supervision reste séparée des outils quotidiens.

Le contexte français explique la pression. Selon l'étude Cavell Enterprise Insights de 2022 relayée sur la téléphonie Teams en France, 53 % des entreprises françaises utilisent Teams comme principale solution de collaboration, tandis que 59 % considèrent le téléphone comme leur canal préféré pour échanger avec les clients, devant l'e-mail. Autrement dit, l'outil de travail principal et le canal client principal ne coïncident pas encore.

Ce que l'intégration doit réellement résoudre

L'objectif n'est pas seulement de téléphoner depuis Teams. Il s'agit de relier Teams au réseau téléphonique public, pour joindre les fixes, les mobiles, les clients et les fournisseurs, tout en conservant les numéros connus. Sans ce raccordement, Teams gère bien les échanges internes, mais l'entreprise conserve une frontière artificielle entre collègues et correspondants externes.

Le second enjeu concerne le service rendu à l'appelant. Un standard qui sonne dans le vide, une file d'attente sans débordement ou un horaire de fermeture mal géré coûtent plus cher qu'une interface peu élégante. L'intégration doit donc préserver la joignabilité, la distribution des appels et la continuité entre sites.

La bonne question de départ n'est pas de savoir si Teams peut passer un appel. Elle consiste à vérifier si chaque appel important arrive à la bonne personne, au bon moment, avec le bon numéro affiché.

Pour une ETI, l'enjeu devient aussi organisationnel. Une règle unique peut convenir au siège, mais rarement à un dépôt, un hôtel ou un service d'accueil local. Le projet doit donc arbitrer entre homogénéité pour l'utilisateur et règles locales pour l'exploitation.

Teams, téléphonie et PBX sont trois briques distinctes

Une analogie aide à éviter la confusion la plus fréquente. Teams correspond au poste de travail, l'endroit où l'utilisateur lit, parle et clique. La téléphonie correspond aux routes, qui transportent l'appel vers un numéro interne ou externe. Le PBX correspond au règlement de circulation, qui décide qui répond, dans quel ordre et ce qui se passe en cas d'absence.

Teams et Teams Phone

Teams fournit l'interface, la présence, les réunions et les appels entre utilisateurs. Teams Phone ajoute les fonctions téléphoniques dans cet environnement, notamment l'accès au réseau public lorsqu'un mode de raccordement est choisi. Cela ne signifie pas que toutes les règles d'un standard d'entreprise y sont automatiquement reproduites avec le même niveau de finesse.

Les usages restent d'ailleurs hybrides. Selon l'enquête Infopro Digital Études auprès de 582 répondants, 73 % utilisent Teams pour les appels audio ou vidéo, mais seulement 56 % déclarent passer plus de la moitié de leurs appels sur Teams. Le mobile et le fixe continuent donc de porter une part réelle des conversations professionnelles.

Le rôle propre du PBX

Un PBX, sur site ou dans le cloud, organise les règles collectives. Standard automatique à plusieurs niveaux, files d'attente, débordement, horaires exceptionnels, supervision en temps réel et routage multi-sites relèvent de cette logique. Un appel individuel réussi ne prouve rien sur ces fonctions.

• Appel interne : un collègue joint un autre collègue, souvent sans sortir vers le réseau public.

• Appel externe : un client compose le numéro public de l'entreprise, ou l'inverse.

• Appel de service : l'appel entre dans une file, suit un horaire, déborde vers un autre groupe ou aboutit à une messagerie partagée.

Règle de lecture : Teams peut devenir l'interface unique sans devenir, à lui seul, le moteur de toutes les règles téléphoniques.

Quatre critères permettent ensuite de juger chaque architecture. Le contrôle opérationnel indique qui modifie les règles. La continuité décrit le comportement en cas d'incident. L'intégration mesure la fluidité pour l'utilisateur. La souveraineté précise où résident les données et qui peut y accéder.

Comparer les trois options de téléphonie Microsoft Teams

Trois chemins relient Teams au réseau téléphonique. Ils ne se distinguent pas seulement par leur prix ou leur simplicité apparente. La vraie différence porte sur la répartition des responsabilités entre Microsoft, l'opérateur, l'intégrateur et le PBX existant.

Microsoft Phone System et forfaits d'appels

Dans ce scénario, Microsoft occupe la place centrale. L'entreprise reste dans l'écosystème Microsoft 365 pour la fonction téléphonique et le raccordement public associé, selon les offres disponibles. L'administration paraît homogène, car les utilisateurs, les politiques et les numéros se gèrent dans un univers connu de la DSI.

La contrepartie tient au périmètre. Les besoins avancés de standard, les règles locales complexes et certaines exigences de continuité doivent être vérifiés fonction par fonction. Ce chemin convient surtout aux organisations dont les flux d'appels sont simples et standardisables.

Operator Connect

Operator Connect relie Teams à un opérateur compatible par une intégration encadrée par Microsoft. L'opérateur fournit l'accès au réseau public, tandis que l'affectation des numéros et une partie de la gestion restent proches de l'administration Teams. Pour l'entreprise, la mise en service peut être plus directe qu'une interconnexion entièrement construite sur mesure.

Le niveau de personnalisation dépend alors de l'opérateur et du cadre du programme. Les routages très spécifiques, la coexistence avec un PBX ou les politiques propres à chaque site exigent une qualification précise avant signature.

Direct Routing

Direct Routing connecte Teams à un SBC, un contrôleur de session en bordure de réseau, puis à un trunk SIP, un opérateur ou un cloud PBX. C'est l'option la plus ouverte. Elle permet de conserver des numéros, des règles de routage et des fonctions de PBX tout en utilisant Teams comme terminal logiciel.

Cette liberté a un coût technique. Le SBC, les certificats, les plans de numérotation et la supervision doivent être conçus, testés et exploités. Un intégrateur compétent devient alors un acteur central, pas un simple installateur.

Le choix ne devrait jamais partir du nom de l'option. Il part des flux réels, accueil, ventes, support, astreinte et appels d'urgence, puis remonte vers l'architecture capable de les porter sans contournement permanent.

Licences et composants à prévoir

Une erreur classique consiste à budgéter une licence par utilisateur, puis à découvrir le reste en cours de projet. La téléphonie Microsoft Teams repose sur une chaîne de dépendances. Chaque maillon doit être nommé, attribué à un fournisseur et vérifié dans les conditions en vigueur au moment du devis.

Le socle Microsoft

Le point de départ comprend l'environnement Microsoft 365, les comptes utilisateurs et les licences Teams Phone adaptées au scénario retenu. Certains profils partagent un poste, d'autres travaillent dans une file d'attente, d'autres encore n'ont besoin que d'appels internes. Une licence uniforme pour tous paraît simple, mais elle peut suréquiper certains usages et en oublier d'autres, comme les salles ou les postes d'accueil.

Les noms de plans, les prérequis et les droits associés évoluent. Aucun tableau figé ne remplace une vérification dans la documentation contractuelle Microsoft et auprès du partenaire de licences. Cette prudence vaut aussi pour les fonctions d'enregistrement, de transcription ou d'analyse, qui peuvent relever d'options distinctes.

Les composants hors licence utilisateur

Le raccordement public ajoute ses propres éléments, selon l'architecture. Un devis complet distingue les frais opérateur, le trunk SIP, le SBC ou le service qui en tient lieu, la portabilité des numéros, les terminaux éventuels et la supervision. La comparaison entre le trunk SIP et le BYOC pour relier un opérateur aide à situer qui fournit la connectivité et qui conserve la main sur le routage.

• Licences Microsoft : utilisateurs, ressources de standard et fonctions Teams Phone requises.

• Connectivité PSTN : forfait Microsoft, opérateur Operator Connect ou trunk en Direct Routing.

• Interconnexion : SBC, certificats, règles de normalisation et politiques d'appels.

• Exploitation : portabilité, tests, formation, supervision et support.

La compétence de l'assembleur compte autant que la liste. Selon l'observatoire du channel IT sur les offres intégrées à Teams, deux tiers des prestataires IT interrogés déclarent être capables de proposer une offre fixe ou mobile intégrée à Teams. La DSI a donc intérêt à demander des preuves, références d'architecture, méthode de test et répartition claire des responsabilités, plutôt qu'une simple ligne de licence.

Intégrer un cloud PBX comme Voxbi

Prenons une ETI de quatre sites. Ses équipes veulent appeler depuis Teams, mais son accueil repose sur des horaires différents selon les agences, une file prioritaire pour les clients grands comptes et un débordement vers un secrétariat externalisé en soirée. Ces règles existent déjà, elles fonctionnent, et les reconstruire ailleurs coûte cher. C'est le cas de figure où garder un cloud PBX derrière Teams a du sens.

La distinction tient en une image, celle du restaurant qui rénove sa salle sans toucher à sa cuisine. Teams devient la salle, la porte d'entrée quotidienne où l'utilisateur compose, reçoit et transfère dans l'application qu'il connaît. Le cloud PBX reste la cuisine, le moteur qui applique les files d'attente, les menus vocaux, les horaires et les débordements.

Voxbi illustre ce rôle de moteur. Présenté sur le site de Voxbi, ce standard téléphonique cloud est hébergé dans l'Union européenne et se pilote depuis une interface web. Pour une PME ou une ETI européenne, l'hébergement dans l'Union, la conformité au RGPD et la souveraineté européenne des données pèsent dans le choix au même titre que les fonctions d'appel. Dans la santé ou le service public, une organisation multi-sites ne peut pas traiter ce point comme un détail.

L'écran ci-dessous illustre l'interface de gestion d'un standard cloud, côté administration.

Trois scénarios à ne pas confondre

La bonne architecture dépend du point de départ, et confondre les scénarios fausse le dimensionnement.

Le premier scénario est l'intégration étroite. Teams sert de composeur et de point de réception pour les numéros professionnels, pendant que le cloud PBX garde la main sur le routage, les files d'attente, les menus et les plages de service. Ce modèle convient quand l'entreprise veut homogénéiser l'expérience utilisateur sans reconstruire ses flux d'accueil.

Le deuxième est la coexistence organisée. Certains profils restent sur les postes ou applications du PBX : la réception, un entrepôt, un site à contraintes particulières. Les autres passent dans Teams. Ce scénario tient debout si l'annuaire, la numérotation interne et les transferts entre les deux mondes sont testés. Sans ces tests, l'entreprise se retrouve avec deux téléphonies parallèles qui s'ignorent.

Le troisième est le remplacement progressif. Un site pilote migre, les indicateurs d'appels sont observés quelques semaines, puis les autres sites suivent par vagues. Cette prudence protège les organisations à forte réception d'appels, comme l'hôtellerie, la santé ou les collectivités, où un standard indisponible se remarque immédiatement auprès du public.

Un cloud PBX derrière Teams se justifie quand les règles collectives d'appel dépassent ce que l'entreprise accepte de reconstruire ou de simplifier dans Teams seul. Ailleurs, il ajoute une couche sans service rendu.

Avant de trancher, quelques démonstrations valent mieux qu'une plaquette. La correspondance entre comptes Teams et extensions PBX doit être sans ambiguïté, surtout quand un même salarié possède un numéro direct et appartient à une file. La présentation du numéro sortant, la synchronisation des contacts, le comportement des files et le scénario de repli en cas d'indisponibilité de Teams ou du réseau local doivent être montrés en conditions réelles. Et lorsque l'IA intervient, par exemple dans la transcription ou l'assistance aux agents, elle relève du service téléphonique et se gouverne comme telle : elle ne définit ni la catégorie du produit ni sa valeur.

SIP, WebRTC, sécurité et qualité réseau

Une démonstration réussie dans un bureau bien connecté ne prouve pas grand-chose. La qualité d'un appel dépend de toute la chaîne, du casque de l'utilisateur jusqu'au réseau du correspondant. Les choix commerciaux doivent donc être traduits en couches techniques vérifiables.

SIP, WebRTC et SBC

SIP établit et pilote les sessions d'appel entre systèmes téléphoniques. WebRTC permet des communications audio et vidéo dans le navigateur, sans logiciel téléphonique classique. Le SBC se place à la frontière entre réseaux, normalise les échanges, applique des règles de sécurité et relie l'ensemble au PSTN, le réseau téléphonique public.

Ces briques ne sont pas interchangeables. Une architecture peut utiliser SIP entre le PBX et l'opérateur, WebRTC dans une application web et Teams comme client principal. L'intégrateur doit pouvoir dessiner le chemin exact d'un appel entrant, sortant et transféré, sans zone grise.

Sécurité et chiffrement

Le chiffrement de la signalisation et des médias, l'authentification des équipements et la limitation des flux autorisés réduisent l'exposition aux abus. SIP TLS et les mécanismes associés à WebRTC font partie des sujets à vérifier. Leur présence ne suffit pas à déclarer l'ensemble conforme. Les journaux, les enregistrements, les métadonnées et les droits d'administration relèvent aussi de la gouvernance.

Une courte vidéo permet de visualiser le parcours d'un appel IP et les points de contrôle associés.

Qualité de bout en bout

La latence, la gigue et la perte de paquets décrivent ce que l'oreille perçoit comme retard, hachage ou coupure. Le Wi-Fi d'un bâtiment, l'accès Internet d'un site, le trunk de l'opérateur et le réseau mobile du correspondant influencent chacun le résultat. Les repères détaillés dans l'analyse des facteurs de qualité audio en téléphonie IP doivent être mesurés site par site, aux heures réelles d'activité.

Une moyenne nationale ne tient pas lieu d'engagement local. Dans la campagne nationale de l'Arcep sur la qualité des appels mobiles, 90 % des appels Orange, 87 % chez Bouygues Telecom, 85 % chez SFR et 84 % chez Free Mobile ont satisfait le critère de qualité parfaite, défini comme un appel maintenu pendant deux minutes sans perturbation audible. Un bâtiment précis, un sous-sol ou un site rural peuvent raconter une autre histoire.

La supervision doit donc isoler la panne. Teams, le SBC, le trunk SIP et le dernier kilomètre doivent produire des signaux distincts. Sans cette séparation, chaque incident devient un renvoi de responsabilité entre fournisseurs.

Numérotation et continuité d'accès

Changer d'interface est visible. Changer de routage l'est moins, jusqu'au jour où un numéro ne répond plus. Une migration vers la téléphonie Microsoft Teams doit être traitée comme une opération de portabilité et de numérotation, avec inventaire, tests et retour arrière.

Construire l'inventaire

La première étape recense chaque numéro public, chaque SDA, chaque extension interne et chaque usage associé. Certains numéros servent à une personne, d'autres à un service, une alarme métier, un accueil saisonnier ou une ligne publiée dans des documents anciens. Un numéro sans propriétaire identifié ne doit pas être supprimé par défaut.

La correspondance entre utilisateur, site et numéro présenté doit ensuite être arrêtée. Un commercial itinérant, un standard multi-sites et un service d'astreinte n'affichent pas forcément la même identité d'appelant. Ces règles se documentent avant la portabilité, pas après les premières plaintes.

Normaliser en E.164

Le format E.164 donne à chaque numéro une forme internationale univoque, avec indicatif de pays. Selon la page de l'Arcep sur l'interopérabilité de la téléphonie sur Internet, l'interopérabilité avec le réseau téléphonique nécessite l'utilisation de numéros E.164 pour permettre aux terminaux du réseau classique de joindre les abonnés VoIP. Les plans de numérotation Teams et PBX doivent donc traduire proprement les formats composés par les utilisateurs.

Les démarches et délais décrits dans le guide de portabilité d'un numéro de téléphone professionnel s'intègrent au planning de migration, avec une fenêtre de bascule et des responsabilités nommées.

Test décisif : un appel entrant réussi ne valide ni le transfert, ni la présentation du numéro, ni l'appel d'urgence depuis le bon site.

Tester la non-régression

• Appels entrants et sortants : fixes, mobiles, numéros courts et destinations internationales autorisées.

• Transferts et débordements : transfert aveugle, transfert accompagné, débordement de file et messagerie partagée.

• Appels d'urgence : identification du site appelant et règles de sortie locales.

• Scénario de repli : comportement si Teams, le SBC, le trunk ou l'accès Internet du site tombe.

Pour un environnement multi-sites, les trunks peuvent être centralisés tout en conservant des politiques locales. Ce compromis ne fonctionne que si les horaires, les standards et les sorties d'urgence restent rattachés au bon site. La continuité d'accès se prouve par ces tests, site par site.

Checklist de déploiement et guide de décision

La décision devient plus simple lorsque les profils sont nommés. Une PME avec un accueil simple peut privilégier la voie la plus standard. Une ETI multi-sites avec files complexes, astreintes et règles locales a intérêt à évaluer Direct Routing ou un cloud PBX derrière Teams. Un environnement régulé doit d'abord documenter les données vocales, les enregistrements et les accès.

Checklist avant déploiement

Certains signaux doivent arrêter le projet avant engagement. Une incompatibilité de numérotation non résolue, l'absence de scénario de reprise, des tests réseau insuffisants ou un contrat de traitement des données trop vague ne se compensent pas par une formation utilisateurs. Le dispositif décrit dans la démarche d'accompagnement au changement intervient après ces validations, pour préparer les équipes aux nouveaux gestes et aux indicateurs suivis, appels abandonnés, temps d'attente et disponibilité du standard.

La gouvernance des fonctions d'IA suit le même principe de preuve. Selon la FAQ de la Commission européenne sur le calendrier du règlement sur l'IA, les règles générales de maîtrise de l'IA s'appliquent depuis le 2 février 2025, la date générale d'application est fixée au 2 août 2026 et certaines obligations sur les systèmes à haut risque doivent s'appliquer à partir du 2 décembre 2027. Il est donc rigoureux de parler de préparation et de conception compatible, sans présenter une conformité à l'EU AI Act comme acquise.

---

Pour une entreprise qui veut utiliser Teams comme interface tout en conservant un standard téléphonique cloud hébergé dans l'Union européenne, avec files d'attente, menus, routage et administration web, Voxbi présente son offre et ses modalités d'intégration. Les DSI, PME, ETI et intégrateurs peuvent y confronter leurs flux d'appels, leurs sites et leurs exigences de souveraineté européenne avant de choisir leur architecture.