Comment tester un VPN pour Teams, Zoom ou Meet ? Le Speedtest m’avait donné le mauvais gagnant

Vendredi soir, j’avais terminé mon comparatif. Du moins, je le croyais.

J’avais connecté plusieurs VPN sur la même fibre, choisi à chaque fois une route proche et lancé les tests habituels. Téléchargement. Envoi. Ping. Encore une fois pour vérifier.

Le grand fournisseur que j’utilisais déjà conservait la plus grosse part de mon débit.

Très bien.

J’avais même noté le résultat dans un tableau avant de fermer l’ordinateur. Lundi, je devais travailler à distance et participer à une présentation client sur Teams. Si le VPN pouvait encore déplacer plusieurs centaines de mégabits par seconde, je ne voyais pas ce qu’une visioconférence allait pouvoir lui reprocher.

Lundi matin, j’ai rejoint une répétition avec un collègue. Pendant les premières minutes, rien à signaler. Puis j’ai partagé mon écran.

« Attends… tu peux répéter ? »

J’ai recommencé ma phrase. Même réaction.

Chez moi, sa voix était normale. Chez lui, la mienne arrivait par morceaux. Ma caméra s’est figée deux fois, puis le partage d’écran a pris plusieurs secondes de retard.

J’ai arrêté le partage. La conversation est redevenue presque normale. Mon premier réflexe a été de relancer un Speedtest. Le débit était toujours excellent.

Et c’est précisément là que mon classement du vendredi a cessé d’avoir beaucoup de sens.

Une réunion n’a pas besoin de gagner un Speedtest

Le problème est devenu assez banal en France parce que la visioconférence n’est plus réservée à quelques télétravailleurs permanents.

France Travail indiquait en avril 2026 que le télétravail concernait 31 % des établissements de plus de dix salariés, les deux tiers privilégiant une organisation hybride d’un ou deux jours par semaine.

Autrement dit, Teams, Zoom ou Meet sont désormais utilisés exactement dans les situations où un VPN peut aussi rester connecté : à la maison, sur un réseau partagé, pendant un déplacement ou simplement durant une journée de télétravail.

Et une réunion ne demande pas à la connexion la même chose qu’un gros téléchargement.

Un Speedtest répond surtout à une question :

combien de données cette connexion peut-elle transporter rapidement ?

Une visioconférence en pose une autre :

est-ce que les petits morceaux de voix et de vidéo vont arriver régulièrement, sans retard brutal ni trous ?

C’est la différence entre une autoroute très large et une route fluide.

Une autoroute peut laisser passer énormément de voitures sur une minute. Si elles avancent pourtant par à-coups, ce n’est pas agréable pour quelqu’un qui essaie de garder une conversation naturelle.

Pour une réunion, trois chiffres deviennent donc plus intéressants que le débit maximal : la latence, la gigue — le jitter — et les pertes de paquets.

Microsoft les utilise justement dans son évaluation de la qualité réseau pour Teams.

C’étaient les chiffres que je n’avais jamais regardés.

Teams m’a montré ce que mon tableau avait raté

J’ai relancé la réunion et ouvert Paramètres → Santé de l’appel dans Teams.

Les données évoluent pendant l’appel. Microsoft y affiche notamment le temps aller-retour et les pertes de paquets reçus ; son aide considère comme typiques un aller-retour inférieur à 200 ms et moins de 2 % de pertes reçues.

Je ne cherchais pas à obtenir des chiffres parfaits.

Je voulais voir ce qui changeait au moment exact où mon collègue cessait de bien m’entendre.

Caméra seule : correctement. J’ai parlé pendant quelques minutes. Puis j’ai partagé une fenêtre. Les irrégularités sont revenues.

Cette fois, je pouvais relier quelque chose de très concret — « tu peux répéter ? » — à ce que faisait réellement la connexion pendant une réunion chargée.

Une discussion publiée en mars 2026 sur r/MicrosoftTeams montre d’ailleurs à quel point le diagnostic peut être trompeur : son auteur décrivait une image saccadée et un son coupé alors que ses tests de vitesse et ses autres applications semblaient normaux ; Ethernet améliorait la situation, tandis que le problème se manifestait également avec le VPN.

Ce qui m’intéressait dans ce témoignage n’était pas de reproduire son cas exactement. C’était l’erreur de départ, familière :

« mon débit est bon, donc mon réseau va bien. »

Pour une réunion, ce raccourci ne tient pas toujours. J’ai donc fait le test le plus simple. J’ai coupé le VPN et rejoint de nouveau l’appel. C’était mieux.

Microsoft recommande justement, dans les environnements professionnels adaptés, d’éviter de faire effectuer au trafic temps réel de Teams un détour VPN inutile ; l’entreprise cite notamment la latence, le jitter et la bonne prise en charge d’UDP.

J’aurais pu m’arrêter là et mettre Teams en split tunneling. Mais ce n’était pas vraiment la réponse que je cherchais.

Si je teste un VPN pour travailler, j’ai envie de savoir s’il peut rester actif pendant la réunion — pas seulement si Teams fonctionne une fois que je l’ai contourné.

Ma question était donc devenue beaucoup plus utile :

quel tunnel reste discret quand la voix, la caméra et le partage d’écran fonctionnent en même temps ?

J’ai refait le test avec la réunion comme benchmark

C’est à ce moment-là que j’ai essayé OnlydogVPN. Je n’ai pas relancé le Speedtest. J’ai connecté le service avec son mode automatique, puis rejoint Teams. Caméra. Conversation normale pendant plusieurs minutes. Partage d’écran.

Ensuite, j’ai ouvert un document assez lourd dans le navigateur pour ajouter un peu de trafic en arrière-plan.

Et j’ai continué à parler.

Mon collègue n’a pas eu besoin de me demander de répéter. Le partage d’écran est resté lisible et, pendant ce test, je n’ai pas retrouvé les mêmes épisodes de voix hachée qui avaient fait échouer ma première route.

À cet instant, le débit maximal ne m’intéressait pratiquement plus. Le VPN venait de réussir le test que j’aurais dû faire dès le vendredi.

La raison technique est assez cohérente avec ce comportement. Le service utilise un transport basé sur HTTP/3, lui-même construit sur QUIC. Sans entrer dans toute la plomberie réseau, QUIC est notamment conçu pour mieux gérer plusieurs flux et pour conserver une connexion lorsque le chemin réseau change.

La façon la plus simple de l’imaginer est celle-ci : au lieu qu’un ralentissement sur une file fasse attendre tout le monde derrière, le protocole essaie de mieux isoler ce qui peut continuer à circuler.

Cela ne transforme évidemment pas une mauvaise connexion Internet en fibre parfaite.

Mais pour ce que je voulais réellement mesurer — parler, envoyer de la vidéo et partager un écran sans entendre le tunnel dans la conversation — le résultat était nettement plus convaincant que le gagnant de mon Speedtest.

Il me restait cependant une question.

Est-ce que j’avais simplement trouvé une combinaison qui convenait bien à Teams ?

Zoom et Meet m’ont empêché de tricher avec mon propre test

J’ai donc reproduit la même situation dans Zoom. Pas un benchmark compliqué. Une vraie réunion. Caméra active, quelques minutes de conversation, puis partage d’écran.

Zoom possède un avantage pratique pour ce genre de test : son panneau Statistics affiche directement la latence, le jitter et les pertes de paquets pour l’audio, la vidéo et le partage d’écran.

Je regardais surtout si les valeurs restaient régulières lorsque j’ajoutais de la charge.

La voix changeait-elle ? Les pertes grimpaient-elles soudainement ? Le délai devenait-il perceptible dès que l’écran était partagé ?

C’est beaucoup plus instructif que de comparer 510 Mb/s à 430 Mb/s sur deux captures d’écran.

Puis j’ai fait la même chose avec Meet.

Google recommande lui aussi de ne pas s’arrêter à une mesure instantanée de débit : pour un appel vidéo, la bande passante et la latence doivent rester suffisamment stables dans le temps. Sa documentation rappelle également qu’un VPN peut ajouter une étape supplémentaire sur le trajet réseau vers Meet.

À ce moment-là, ma méthode de test était devenue étonnamment courte. Je lance la vraie application. J’active la caméra. Je parle. Je partage mon écran. Je laisse un peu de trafic se produire en arrière-plan. Et je regarde surtout si la réunion reste naturelle.

Quand l’application expose ses statistiques, je garde un œil sur la latence, la gigue et les pertes.

Pas besoin d’un laboratoire.

Il suffit de reproduire la journée pour laquelle on envisage réellement de garder le VPN connecté.

C’est aussi là que la hiérarchie entre les services peut s’inverser.

Un VPN qui affiche moins de mégabits sur un serveur de test mais conserve une route régulière pendant vingt minutes peut être beaucoup plus agréable pour Teams qu’un VPN qui écrase le Speedtest avant de hacher une phrase dès que le partage d’écran démarre.

J’ai ajouté un dernier test après avoir déjà choisi

À ce stade, la réunion fonctionnait. J’aurais pu arrêter là.

Mais un dernier détail me préoccupait parce qu’il ressemblait davantage à mes vraies journées qu’à n’importe quel benchmark : que se passe-t-il lorsque le réseau change ?

Une box redémarre. Le Wi-Fi devient mauvais dans une autre pièce.

On bascule sur le partage de connexion du téléphone cinq minutes avant une réunion.

J’ai donc rejoint une dernière réunion de test, puis désactivé volontairement le Wi-Fi de l’ordinateur et basculé sur la connexion du téléphone.

L’appel a hésité un instant. Puis il est revenu.

Je n’ai pas eu à rouvrir l’application VPN, sélectionner une nouvelle route ou relancer manuellement la connexion.

Ce n’était plus le test principal. Le principal était déjà réussi : la réunion était restée confortable avec le tunnel actif.

Mais cette reprise m’a donné une raison supplémentaire de conserver l’application, parce qu’elle répondait à un autre problème très concret : le réseau réel ne reste pas toujours identique pendant toute une journée de travail.

Le compromis, lui, reste facile à identifier.

Ce service plus petit propose moins de régions de serveurs que les grands fournisseurs établis. Si mon travail exigeait régulièrement une ville ou un pays très précis, je regarderais attentivement cette différence.

Pour Teams, Zoom et Meet, ce n’était pas ce qui décidait si mon collègue entendait la fin de ma phrase.

Le vendredi, j’avais choisi un VPN en regardant combien de données il pouvait déplacer pendant quelques secondes.

Le lundi, une répétition Teams m’a montré que j’avais simplement mesuré la mauvaise qualité.

Depuis, je commence par une vraie réunion : voix, caméra, partage d’écran, un peu de trafic en parallèle et, si la connexion est vraiment importante, un changement de réseau volontaire.

Le Speedtest reste utile. Il me dit si le tuyau est assez large.

Mais pour une présentation client, je préfère le VPN qui laisse passer une phrase entière quand l’écran est partagé à celui qui gagne une course de trente secondes vers un serveur de test.