Blog

Teams est devenu le poste de téléphonie de facto dans les organisations. Sa téléphonie reste toutefois ancrée dans le cloud Microsoft : pour les secteurs régulés, le Direct Routing avec SBC on-premise transforme cette dépendance en architecture maîtrisée.

Le problème que personne ne pose à l'achat

Quand la DSI déploie Teams Phone, elle coche une case confortable. Puis le RSSI découvre trois réalités :

1. Les médias traversent le cloud Microsoft : dans la configuration Calling Plans / Operator Connect, les flux audio RTP transitent par les datacenters Microsoft — y compris hors UE selon le scénario. Vos conversations clientes deviennent des données traitées par un fournisseur US, avec tout ce que cela implique (Patriot Act, CLOUD Act, FISA).
2. L'enregistrement des conversations : les centres de contact Teams reposent sur des offres SaaS tierces dont le périmètre PCI-DSS est aussi large que flou.
3. La résilience : Teams téléphonie sans accès internet, c'est une téléphonie morte — un point délicat à justifier dans un dossier DORA.

Aucune de ces réalités n'apparaît dans les slides du distributeur. Toutes sont exigibles par votre DPO ou votre RSSI.

Direct Routing : la téléphonie reprend la main

Le Direct Routing connecte Teams à votre téléphonie via un SBC (Session Border Controller) que vous contrôlez :

Trunk SIP opérateur ──► SBC on-premise ──► Teams (signalisation)
                              │
                        médias RTP locaux (option Media Bypass)

Avec le Media Bypass activé, le flux vocal ne quitte pas votre réseau : la signalisation passe par Teams, mais la voix reste sur votre infrastructure. C'est la différence entre « Teams comme opérateur » et « Teams comme terminal de votre opérateur ».

Ce que la souveraineté change concrètement

Le centre de contact Teams, sans le cloud US

La vraie question des directions de la relation client : « nos agents sont sur Teams, notre téléphonie doit-elle fuiter vers un tiers pour enregistrer et analyser ? » Non :

• Enregistrement : le SBC on-premise enregistre les flux, stockage sur vos disques, rétention conforme à votre cadre
• Analyse IA : transcription et détection de fraude par notre chaîne vocal temps réel (Whisper + NLPBC on-premise), sans envoyer l'audio chez un fournisseur US
• Coaching temps réel : supervision des conversations avec alerte conformité, en local
• DORA-friendly : l'infrastructure d'analyse vocale n'est pas un fournisseur critique supplémentaire, c'est votre infrastructure

Nos équipes sont formées à cette architecture

Le Direct Routing exige des compétences SIP que Teams ne dispense pas : dimensionnement SBC, plans de numérotation, interopérabilité IPBX↔SBC↔Teams, scénarios de survie. C'est exactement le cœur de notre formation migration trunk SIP et de notre AMO télécom.

Pour aller plus loin

• Serveur WebRTC SFU, le composant médias temps réel on-premise
• Sécurité ToIP et Voice AI, les 5 couches defense-in-depth
• Patriot Act, CLOUD Act, FISA, pourquoi le cloud US est un choix réglementaire

« Ça marche dans notre labo » n'est pas une preuve. Entre le banc de test et la production, se trouvent les codecs que l'opérateur ne négocie pas, les temporisations que l'IPBX n'attend pas, et les numéros que personne n'a testés. Voici comment valider une chaîne SIP avant de mettre vos utilisateurs dessus.

Pourquoi l'interopérabilité SIP est un sport de précision

Le SIP est standard, mais son interprétation est plurielle : chaque constructeur d'IPBX, chaque SBC et chaque opérateur implémente avec ses variantes. Les divergences les plus fréquentes :

• Négociation de codecs : l'opérateur n'accepte que G.711 et G.729, votre IPBX propose Opus en premier — la première sonnerie passe, la voix ne suit pas
• Transmission DTMF : RFC 2833, SIP INFO ou in-band ? Trois mondes qui ne se parlent pas, et un SVI qui ne reçoit plus de touches
• Transfert d'appel : REFER, re-INVITE ou 302 ? Chaque méthode traverse les équipements différemment
• Temporisations : timeout d'établissement, durée de session, keepalive NAT — un NAT UDP de 30 s et un keepalive de 60 s, et la registration meurt silencieusement

Une plateforme certifiée « interopérable » ne garantit rien : seule une matrice de tests exécutée sur vos équipements réels en apporte la preuve.

Le laboratoire avant le terrain

Sur nos déploiements, la chaîne complète est reconstituée en labo avant toute intervention client :

IPBX (version client) ──► SBC ──► simulateur trunk opérateur
            │                             │
        postes + softphones         scénarios de tests automatisés

Le simulateur de trunk rejoue les comportements réels des opérateurs : leurs variantes d'en-têtes, leurs temporisations, leurs rejets de codecs. C'est là que nous détectons l'incompatibilité DTMF ou la boucle de transfert — pas en production un lundi matin.

La matrice de tests d'interopérabilité

La matrice croise les fonctionnalités avec les directions (entrant/sortant) et les équipements. Les tests non négociables :

Établissement et signalisation

• Appel sortant vers mobiles, fixes, RTC restant, international, numéros courts, 112
• Appel entrant sur SDA, sur numéro principal, avec débordement
• Renvoi inconditionnel, sur non-réponse, sur occupation (chaque type, dans les deux sens)
• Transfert d'appel : annoncé, aveugle, avec retour d'appel

Média

• Négociation de codecs par priorité : chaque codec autorisé reçoit un appel réussi
• DTMF : RFC 2833 ET SIP INFO testés séparément (le SVI de la banque ne négocie pas)
• Hold, reprise, musique d'attente : le RTP reprend-il dans les deux sens ?
• Fax T.38 si applicable : établissement, transmission, reprise après erreur

Cas limites

• Appel de plus de 60 minutes (les NAT et les refresh de session)
• Perte du lien WAN pendant un appel (reprise ou coupure propre ?)
• Registration renouvelée sous charge (200 postes qui redémarrent ensemble)
• Reprise après coupure de l'opérateur (bascule second trunk, débordement RTC)

Les enseignements de nos bancs de test

Trois classes de défauts reviennent systématiquement :

1. Le transfert en boucle : un IPBX qui renvoie le REFER vers l'opérateur, qui le renvoie au SBC, qui le renvoie à l'IPBX. Détectable uniquement avec un SIP trace complet (pcap) sur le banc.
2. Le DTMF in-band sur codec compressé : G.729 déforme les tonalités DTMF in-band, le SVI ne reconnaît plus les touches. Le test « appeler le SVI de votre banque » fait partie de nos recettes.
3. Le refresh de session manqué : session-timers non négociés entre IPBX et SBC — les appels tombent à exactement 30 minutes. Le test de 60 minutes le détecte.

Chacun de ces défauts est invisible sur un banc naïf « ça sonne, ça parle », et catastrophique en production.

La recette avant la bascule

Le jour de la migration, la recette est la reprise de cette matrice, exécutée sur le trunk réel :

• Matrice complète rejouée (les résultats du labo ne préjugent pas du trunk réel)
• Mesure QoS de référence prise (Mos, gigue, perte) comme baseline contractuelle
• Période de coexistence RTC + SIP avec le plan de numérotation doublé
• Plan de retour arrière documenté et testé (un rollback jamais répété échoue)

Pour aller plus loin

• Audit d'infrastructure télécom : la checklist 2026, l'état des lieux qui précède
• Maîtriser la migration vers le trunk SIP, notre formation incluant les travaux pratiques d'interop
• Assistance à maîtrise d'ouvrage, nous pilotons vos recettes

Un schéma directeur télécom commence toujours par un état des lieux. La qualité de l'audit détermine celle de tout ce qui suit : un flux oublié dans l'audit, c'est un service mort le jour de la bascule. Voici la checklist que nous déroulons en AMO, secteur par secteur.

Pourquoi l'audit télécom est la moitié du travail

Les projets télécoms n'échouent presque jamais sur la technologie : ils échouent sur l'inventaire incomplet. La ligne fax du service comptabilité oubliée, la ligne d'alarme de la baie serveur, le modem du distributeur automatique : chacun de ces flux RTC oubliés devient une panne au moment où personne ne peut se permettre une panne.

L'audit a trois livrables : la cartographie des flux (qui appelle qui, par quel canal), la matrice des risques (que perd-on si ce flux disparaît), et le plan de trajectoire (quand et comment migrer chaque flux).

Phase 1 — Cartographier les accès et les flux

• Inventaire des accès opérateur : RTC, RNIS (T0/T2), trunk SIP existants, liaisons spécialisées — avec contrats, échéances et clauses de sortie
• Recensement des SDA (Sélection Directe à l'Arrivée) : chaque numéro, quel site, quel usage
• Flux entrants : qui appelle ces numéros ? (clients, fournisseurs, internes) — les numéros à forte valeur (SAV, direction) exigent une attention particulière
• Flux sortants : destinations fréquentes, coûts par destination, détection des numéros spéciaux
• Interconnexion des sites : liaisons inter-sites, VPN, MPLS — le trunk SIP privé a-t-il déjà une route ?

Phase 2 — Chasser les applications cachées

C'est ici que les audits amateurs s'arrêtent et que les migrations échouent :

• Fax : combien, où, quelle criticité ? (T.38 ou passage en passerelle analogique)
• Alarmes et télésurveillance : lignes dédiées des centrales d'alarme, ascenseurs (norme EN 81-28)
• Modems legacy : télémétrie, comptage, terminaux de paiement (TPV dial-up, de plus en plus rares mais encore là)
• Interphonie : portail d'immeuble, interphonie de site — la télécommande analogique
• Lignes bancaires dédiées : certains systèmes de transaction utilisent encore des canaux RTC
• Autoradio et diffusion : postes de site, radios PMR interconnectées

Chaque flux caché identifié doit recevoir un plan de traitement explicite : migrer, remplacer (IP), ou décommissionner. « On verra » n'est pas un plan.

Phase 3 — Évaluer la qualité de l'existant

• Mesure QoS de référence : Mos, gigue, perte sur les liens actuels (voir notre article QoS ToIP)
• Dimensionnement Erlang : canaux simultanés réels (mesurés, pas estimés) par site et par tranche horaire
• Qualité des liens WAN : débit, latence, pertes — le trunk SIP exigera mieux que le RTC
• Redondance : que se passe-t-il si le lien tombe ? (routage de secours, numéros de débordement)

Phase 4 — Auditer la sécurité voix

• PABX/IPBX : version, mots de passe par défaut, interfaces admin exposées
• SBC : y en a-t-il un ? (la frontière SIP sans SBC est une porte d'attaque)
• Fraude télécom : surveillance des appels sortants anormaux (les fraudes « premium » coûtent des millions par an)
• Enregistrement des conversations : obligation réglementaire selon votre secteur, rétention documentée
• Conformité réglementaire : registre des communications, RGPD pour les enregistrements, AI Act si IA vocale en production

Phase 5 — Projeter la trajectoire

• Classification des flux : critère = criticité × complexité de migration
• Scénarios de migration : par site, par service, hybride RTC/SIP transitoire
• CAPEX/OPEX : coût de la bascule vs coût du maintien RTC (qui monte chaque année)
• Préparation Voice AI : le trunk SIP est la porte d'entrée de l'agent vocal, prévoyez le raccordement maintenant

Livrables d'un audit DalonCorp

Notre état des lieux produit trois documents opposables :

1. La cartographie des flux (schéma + tableaux), validée avec vos équipes
2. La matrice des risques : chaque flux classé par criticité et par échéance de fin RTC
3. Le plan de trajectoire chiffré : scénarios de migration, budget, planning, avec les sources

C'est ce plan qui alimente le schéma directeur, et chaque décision reste opposable : rien ne se décide « à l'intuition ».

Pour aller plus loin

• Assistance à maîtrise d'ouvrage, la méthodologie AMO complète
• Checklist migration RTC → trunk SIP 2026, le volet migration détaillé
• Formation migration trunk SIP, monter vos équipes en compétence

La qualité vocale n'est pas une impression : c'est une série de mesures que vous pouvez instrumenter, contracter avec votre opérateur et alerter avant que l'utilisateur ne s'en plaigne. Voici ce que nous surveillons sur nos déploiements.

Les quatre indicateurs qui font la qualité

La qualité perçue d'un appel ToIP se décompose en quatre mesures physiques, mesurables de bout en bout :

Ces chiffres sont ceux que vous pouvez exiger contractuellement de votre opérateur trunk SIP : un SLA qui ne mentionne pas de cible Mos, gigue ou perte n'est pas un SLA voix, c'est un SLA transport.

Mesure passive vs sonde active

Deux approches se complètent :

Mesure passive : analyser les flux RTP réels des appels en production. Chaque paquet porte des en-têtes RTCP avec la perte, la gigue et le délai. C'est gratuit (les données existent), mais ne détecte la dégradation que pendant les appels.

Sonde active : générer périodiquement des flux de test RTP entre vos sites et vers l'opérateur, jour et nuit, même sans appel. C'est ce qui détecte la dégradation d'un lien WAN à 3h du matin, avant la première réclamation utilisateur. Les bureaux d'études spécialisés l'ont bien compris : la mesure active est le cœur de tout audit QoS sérieux.

Notre position : la mesure passive est intégrée à nos déploiements (rTPengine et métriques natives), la sonde active est un script Go que nous fournissons — pas besoin d'un boîtier propriétaire par site. Nous avons par ailleurs aidé à développer une plateforme d'assurance de réseau mobile (Numodata) : tests de charge, analyses des métriques radio et cœur, cartographie de couverture, indicateurs contractuels. Ces savoir-faire de test et de mesure irriguent directement nos déploiements voix fixe.

Au-delà du trunk SIP : IMS, VoLTE, VoNR

La voix évolue au-delà du trunk SIP des entreprises, et la mesure QoS avec elle :

• VoLTE (Voix sur LTE) : la voix transite dans l'IMS (IP Multimedia Subsystem) avec des profils de QoS dédiés (QCI 1 pour la voix, bearer dédié). Un appel VoLTE dégradé se diagnostique dans l'ordre : couverture radio (RSRP/RSRQ), établissement de bearer dédié, puis qualité RTP. Une mauvaise voix mobile n'est presque jamais « un problème de codec ».
• VoNR (Voix sur 5G NR) : même architecture IMS, plus d'exigences de latence radio. Le handover inter-cellules pendant un appel est le point critique à instrumenter.
• Interconnexion fixe ↔ mobile : les appels entre un trunk SIP d'entreprise et un mobile VoLTE traversent deux mondes de mesure ; le Mos global se dégrade au maillon le plus faible, souvent à l'interconnexion.

C'est une expertise que peu d'intégrateurs ToIP peuvent revendiquer : nous mesurons la voix de l'extrémité radio jusqu'au poste IP, en passant par l'IMS. Notre participation au développement de la plateforme d'assurance réseau mobile de Numodata nous a donné la maîtrise des campagnes de tests de charge et des analyses de métriques sur réseau opérateur — le même socle méthodologique que pour un audit QoS fixe.

Le pipeline de supervision Prometheus

Sur nos plateformes, la chaîne QoS se branche dans le monitoring existant :

Flux RTP ──► collecteur (rtpengine / Homer) ──► exporteur Prometheus
                                                     │
                     alertes Grafana ◄───────────────┘
                     (Mos < 3,5 pendant 5 min → alerte)

Les métriques à surveiller en priorité :

• rtp_mos_avg par opérateur et par site — la dégradation progressive d'un trunk est invisible à l'oreille tant qu'un seuil n'est pas franchi
• rtp_packet_loss_pct par direction (entrant/sortant) — une perte unidirectionnelle pointe le lien WAN, une perte bidirectionnelle pointe l'opérateur
• sip_response_time_p95 — la latence de signalisation (INVITE → 200 OK) dégrade l'expérience post-composition avant même la voix

Les pièges classiques

1. Mesurer uniquement dans le datacenter : la qualité se dégrade au bord (Wi-Fi, VPN, sites distants). Placez une sonde au plus près des utilisateurs.
2. Confondre MOS calculé et MOS perçu : le Mos E-model intègre le jitter buffer et les pertes, pas l'écho acoustique du combiné. Un Mos 4,2 avec un écho de 40 ms reste pénible.
3. Oublier le T.38 fax et les alarmes : ces flux tolèrent encore moins la perte que la voix ; mesurez-les séparément.
4. Ne pas contracter : sans cibles Mos/gigue/perte dans le contrat opérateur, vos graphes Grafana ne sont que des constats.

Et l'IA vocale dans tout ça ?

Une voix synthétique est plus exigeante que la voix humaine : le moindre trou de 200 ms dans le flux crée un blanc que l'interlocuteur interprète comme un plantage de l'IA. Sur un déploiement avec agent vocal, nous surveillons la QoS par appel d'agent : un trunk qui passe sous Mos 3,8 est mis en quiescence et le trafic bascule sur l'opérateur de secours, sans intervention.

Pour aller plus loin

• Maîtriser la migration vers le trunk SIP, notre formation avec module QoS et travaux pratiques
• Serveur WebRTC SFU, le composant temps réel de la plateforme
• Assurance de réseau mobile Numodata, plateforme que nous avons aidé à développer : VoLTE/VoNR, tests de charge, métriques radio et cœur