Bonjour ! Prêt à continuer notre exploration des outils de supervision de la qualité dans Microsoft Teams ?
Introduction
Dans la leçon précédente, nous avons étudié le Call Quality Dashboard (CQD). Vous avez appris à l'utiliser comme un outil stratégique pour analyser des tendances globales et identifier des problèmes de qualité à grande échelle, sur l'ensemble de votre organisation. Le CQD répond à la question : "Comment était la qualité des appels hier, la semaine dernière, ou le mois dernier sur le site de Lyon ?".
Aujourd'hui, nous changeons radicalement d'échelle. Nous passons de la vue macroscopique à la vue microscopique et du passé au temps réel. Cette leçon est consacrée à l'analyse des appels en temps réel (Live Call Analytics). L'objectif est de vous rendre capable d'investiguer un problème de qualité sur une réunion en cours. C'est une compétence essentielle pour tout administrateur ou agent de support, surtout lorsqu'un utilisateur important (comme un membre de la direction) signale un problème et attend une solution immédiate.
Nous allons voir comment accéder à ces données en direct, quelles métriques analyser et comment les interpréter pour poser un diagnostic rapide et précis.
1. Qu'est-ce que l'Analyse en Temps Réel (RTA) ?
L'analyse en temps réel, ou Real-Time Analytics (RTA), est un outil de diagnostic conçu pour les administrateurs et les équipes de support. Contrairement au CQD qui agrège des données sur des milliers d'appels une fois qu'ils sont terminés, le RTA vous donne une vue détaillée de la télémétrie d'une réunion spécifique pendant qu'elle se déroule.
Pour bien comprendre son rôle et son fonctionnement, je vous propose de lire l'introduction et la présentation de la documentation officielle de Microsoft.
Use real-time telemetry to troubleshoot poor meeting quality
L'article "Use real-time telemetry to troubleshoot poor meeting quality" est notre principale référence pour cette leçon. Il définit clairement ce qu'est le RTA et comment il se distingue de l'analyse post-appel.
Veuillez lire les deux premières sections de l'article : La section d'introduction (jusqu'à "What is Real-Time Analytics?") pour comprendre les cas d'usage et les rôles d'administration requis. La section "What is Real-Time Analytics?" pour bien saisir la différence fondamentale avec l'analyse d'appel classique (post-réunion).
Pour résumer, la distinction est simple :
- CQD : Analyse de tendances, historique, agrégée. Pour une approche proactive.
- Analyse post-appel : Analyse détaillée d'un appel terminé. Pour une investigation a posteriori.
- Analyse en temps réel (RTA) : Analyse détaillée d'un appel en cours. Pour un dépannage immédiat et réactif.
2. Accéder à l'interface d'analyse en temps réel
Imaginons le scénario : un utilisateur vous contacte car sa réunion en cours est de très mauvaise qualité. Votre première action est d'accéder aux données de cette réunion.
La procédure est simple et se fait depuis le Teams Admin Center. Le blog de la communauté technique Microsoft l'illustre très bien.
Introducing Microsoft Teams Real-time Call Quality Analytics
Cet article de blog, "Introducing Microsoft Teams Real-time Call Quality Analytics", offre une approche très pratique et visuelle du RTA. Nous allons l'utiliser pour guider nos premières étapes.
Lisez la section intitulée "Using the RTA Dashboard". Elle vous montre, étape par étape, comment naviguer dans le Teams Admin Center pour trouver la réunion en cours d'un utilisateur spécifique. La procédure est la suivante : Allez dans Teams Admin Center > Users > Manage users. Recherchez et sélectionnez l'utilisateur qui a le problème. Allez dans l'onglet "Meetings & calls". La réunion en cours apparaîtra en haut de la liste sous "Recent meetings".
Notez deux points importants mentionnés dans la documentation officielle (LINK, section 2) :
- Licences : Pour les utilisateurs avec une licence Teams Premium, les données sont collectées automatiquement et conservées 7 jours. Pour les utilisateurs standards, la collecte ne commence que lorsque vous, en tant qu'admin, accédez à la page de la réunion, et les données ne sont conservées que 24 heures.
- Rôles : Vous devez avoir l'un des rôles suivants : Teams Administrator, Teams Communications Support Specialist, ou Teams Communications Support Engineer.
3. Étape 1 : Vue des Participants pour un premier tri
Une fois dans la section "Meetings & calls" de l'utilisateur, vous avez deux options : cliquer sur le Meeting ID ou sur le lien sous la colonne Participants.
Si plusieurs personnes se plaignent ou si vous ne savez pas qui est à l'origine du problème, la vue des participants est votre meilleur point de départ.
Introducing Microsoft Teams Real-time Call Quality Analytics
Continuons avec l'article de blog pour comprendre comment utiliser la vue des participants pour un premier diagnostic rapide.
Lisez la section "Participants View". Concentrez-vous sur la manière dont cette vue vous permet de voir rapidement tous les participants, leur type de connexion, et surtout, comment un indicateur de perte de paquets élevée peut immédiatement attirer votre attention sur un utilisateur en difficulté.
Cette vue vous permet de "trier" rapidement les participants et d'identifier le maillon faible. Une fois l'utilisateur suspect identifié, il est temps de plonger dans ses données détaillées en cliquant sur son heure d'arrivée (Join Time).
4. Étape 2 : Analyser les métriques détaillées de l'utilisateur
C'est ici que votre expertise technique, notamment votre expérience en VoIP, entre en jeu. La vue détaillée de l'utilisateur vous présente des graphiques en temps réel pour les flux audio, vidéo et de partage d'application.
Comprendre les métriques clés
La documentation Microsoft fournit une liste exhaustive de toutes les métriques disponibles et, plus important encore, des seuils de "bonne qualité".
Use real-time telemetry to troubleshoot poor meeting quality
Revenons à notre document de référence principal pour un examen détaillé des métriques que vous allez analyser.
Consultez la section "Details and measures available in Real-Time Analytics". Vous n'avez pas besoin de tout mémoriser, mais concentrez-vous sur les tableaux suivants, qui sont les plus critiques pour le dépannage en direct : Connectivity information : Pour identifier le type de réseau (Wi-Fi, Ethernet). Audio : Portez une attention particulière aux seuils de Jitter (< 30 ms), Packet Loss (< 5%), et Round Trip Time (< 500 ms). Ces concepts doivent vous être familiers. Video : Regardez le Frame Rate et le Packet Loss. CPU and Battery Details : Une utilisation élevée du CPU peut aussi dégrader la qualité, même avec un bon réseau.
Interpréter les graphiques et les événements
Les graphiques vous permettent de visualiser ces métriques dans le temps. Un pic soudain est souvent la cause du problème signalé.
La vidéo suivante, bien qu'elle montre l'analyse post-appel, est excellente pour vous familiariser avec l'interprétation de ces métriques. Les principes d'analyse de la gigue, de la perte de paquets et des codecs sont identiques.
Troubleshooting Teams Phone with Call Quality Dashboard and Analytics
Cette vidéo, "Troubleshooting Teams Phone with Call Quality Dashboard and Analytics", vous aidera à visualiser comment lire les données. Gardez à l'esprit que l'interface est celle de l'analyse post-appel, mais les métriques et leur signification sont les mêmes que pour l'analyse en temps réel.
Regardez les deux extraits suivants : De 05:38 à 08:30 : L'intervenant explique en détail la signification de la gigue (Jitter), de la perte de paquets (Packet Loss) et du temps d'aller-retour (RTT). C'est un excellent rappel de ces concepts fondamentaux. De 14:15 à 14:58 : Notez comment des indicateurs visuels (en rouge) mettent en évidence la source du problème (réseau, périphérique, etc.). Ce principe s'applique aussi au RTA.
5. Synthèse pratique : du symptôme au diagnostic
En tant que technicien, votre travail consiste à traduire la plainte de l'utilisateur ("le son est robotique") en un problème mesurable ("pic de gigue sur le flux audio entrant").
Voici un petit guide de dépannage :
| Plainte de l'utilisateur | Ce qu'il faut vérifier dans le RTA | Métriques à surveiller |
|---|---|---|
| "J'entends mal, le son est haché/robotique." | Flux audio entrant (Audio stream details (Inbound)) |
Jitter, Packet Loss |
| "On me dit que ma voix se coupe." | Flux audio sortant (Audio stream details (Outbound)) |
Jitter, Packet Loss, Round Trip Time |
| "La vidéo de mon interlocuteur est figée." | Flux vidéo entrant (disponible via l'analyse de l'autre participant) | Packet Loss, Frame Rate |
| "Mon partage d'écran est lent/saccadé." | Flux de partage d'application (Application Sharing) |
Frame Rate, Packet Loss, Round Trip Time |
| "J'ai été déconnecté brièvement." | Section Connectivité et chronologie des événements | Changement d'IP Address ou de Network type |
| "Tout est lent sur mon PC pendant l'appel." | Section Détails du CPU | System CPU Usage, Teams app CPU Usage |
Enfin, n'oubliez pas que le RTA a certaines limites. Par exemple, il n'est pas disponible pour les appels PSTN 1:1 et il ne conserve les données que pour les 3 dernières heures d'une très longue réunion. Connaître ces limites (LINK, section 6) est aussi une marque d'expertise.
Conclusion
Félicitations ! Vous disposez maintenant d'un outil puissant pour réagir instantanément aux problèmes de qualité des réunions. Vous ne dépendez plus uniquement des analyses post-mortem.
Points clés à retenir :
- L'analyse en temps réel (RTA) est votre outil de dépannage pour les réunions en cours.
- L'accès se fait via le profil de l'utilisateur dans le Teams Admin Center (
Users > Manage users > Meetings & calls). - Commencez par la vue des participants pour un tri rapide, puis plongez dans la vue détaillée de l'utilisateur pour une analyse approfondie.
- Les métriques fondamentales à surveiller sont la gigue (Jitter), la perte de paquets (Packet Loss) et le temps d'aller-retour (RTT), en les comparant aux seuils recommandés par Microsoft.
- Corrélez les plaintes des utilisateurs avec des événements techniques spécifiques (pics de métriques, changement de réseau, utilisation CPU élevée).
Prochaine étape :
Nous avons couvert l'analyse des tendances (CQD) et le dépannage en direct (RTA). Mais que faire si un utilisateur signale un problème sur un appel qui s'est terminé il y a une heure ? Dans la prochaine leçon, nous compléterons notre boîte à outils en apprenant à analyser l'historique des appels d'un utilisateur pour diagnostiquer la cause d'un problème passé. Cela nous permettra de disséquer n'importe quel appel, qu'il soit en cours ou terminé.