Microcoupure Fizz ou VPN professionnel qui décroche ? Le test qui m’a montré lequel tombait en premier

La notification est apparue juste après que mon interlocuteur a cessé de bouger.

VPN reconnecting…

Puis Teams a figé son image.

Plus de voix.

Cinq ou six secondes plus tard, tout est revenu.

Le VPN professionnel affichait de nouveau « Connected ».

J’avais mon coupable.

Enfin, c’est ce que je croyais.

J’ai envoyé une capture à l’équipe IT avec un message assez catégorique : le VPN se coupait pendant mes appels.

Ils ont vérifié la passerelle.

Rien d’évident.

J’ai relancé la connexion.

J’ai fait un Speedtest.

Très bon.

À la réunion suivante, exactement la même chose.

Image figée.

Silence.

Puis bannière de reconnexion du VPN.

Cette fois, avant d’envoyer une deuxième capture au support, je me suis posé une question beaucoup plus simple :

est-ce que le VPN était réellement la première chose à tomber ?

Ou était-il seulement le premier logiciel à me prévenir qu’Internet venait de disparaître sous ses pieds ?

Le message du VPN arrivait après la panne

C’est ce qui m’avait trompé.

Un client VPN professionnel est très visible.

Il affiche :

Reconnecting.

Connection lost.

Restoring session.

Ma connexion Fizz, elle, n’ouvre pas une fenêtre disant :

« Je viens de perdre quatre secondes de trafic. »

Fizz recommande justement aux télétravailleurs qui rencontrent des difficultés avec leur RPV de commencer par retirer le VPN de l’équation : tester Internet sans RPV et vérifier également le comportement sur d’autres appareils.

Ce conseil prend tout son sens quand on regarde l’ordre des événements.

Le VPN repose sur Internet.

Si la connexion disparaît quelques secondes, le tunnel peut tomber juste après puis tenter de se reconstruire.

Cisco documente ce comportement avec Secure Client/AnyConnect : lorsqu’une interruption réseau survient, le client peut tenter de reprendre automatiquement sa session lorsque la connectivité revient.

Autrement dit :

voir le VPN se reconnecter ne prouve pas qu’il a provoqué la coupure.

Il peut simplement être le témoin le plus bavard de ce qui vient d’arriver.

J’ai ajouté un témoin qui ne passait pas par le VPN professionnel

Pour la réunion suivante, je n’ai rien modifié sur mon portable de travail.

Même Wi-Fi Fizz.

Même client professionnel.

Même configuration.

J’ai seulement posé un deuxième ordinateur à côté.

Aucun VPN d’entreprise dessus.

J’y ai lancé un ping continu vers Internet et laissé une page web active.

Je ne cherchais ni le meilleur débit ni une mesure de latence parfaite.

Je voulais une chronologie.

10 h 11.

10 h 18.

10 h 26.

Rien.

Puis, à 10 h 31, la voix de mon collègue a commencé à se découper.

L’écran s’est figé.

Sur le deuxième ordinateur, plusieurs réponses du ping ont disparu pratiquement au même instant.

La page ouverte a cessé de répondre.

Quelques secondes après seulement, le client professionnel a affiché sa notification de reconnexion.

Puis tout est revenu.

Cette fois, l’ordre ne laissait plus beaucoup de place à mon premier diagnostic.

Internet direct avait vacillé avant que le VPN annonce sa reconnexion.

J’avais passé deux jours à accuser le messager.

Toutes les barres Wi-Fi étaient encore là

C’est ce qui m’avait empêché de soupçonner Fizz plus tôt.

Pendant la coupure, Windows continuait à afficher une excellente connexion Wi-Fi.

Toutes les barres.

Toujours connecté.

Mais être connecté au Wi-Fi signifie surtout que le portable voit encore le modem ou le point d’accès.

Cela ne garantit pas que le modem conserve, lui, un chemin fonctionnel vers Internet.

Fizz conseille justement de comparer plusieurs appareils et, lorsque c’est possible, de tester en Ethernet afin de séparer un problème Wi-Fi d’un problème de connexion plus général. Ses guides utilisent également l’état des voyants du modem pour déterminer si l’équipement est en ligne ou en phase de reconnexion.

Je n’allais évidemment pas passer mes réunions à surveiller le modem.

J’ai simplement branché le portable en Ethernet.

Même VPN.

Même deuxième ordinateur comme témoin.

Si tout devenait stable, le Wi-Fi aurait été un suspect très sérieux.

Ce n’est pas ce qui s’est passé.

Lors de la coupure suivante, le portable en Ethernet et l’autre appareil ont perdu Internet presque ensemble.

Quelques secondes plus tard, le VPN professionnel s’est reconnecté.

Le problème venait de descendre d’un étage.

D’autres télétravailleurs Fizz décrivaient la même confusion

Ce scénario n’était pas seulement théorique.

Le 24 août 2026, un utilisateur de la Rive-Sud de Montréal décrivait publiquement plusieurs pertes d’Internet par jour depuis environ deux semaines, notamment pendant des appels de travail. Lui et sa conjointe télétravaillaient tous les deux et finissaient régulièrement par redémarrer le modem pour récupérer une connexion normale.

Dans un autre cas publié en mars 2026 à Laval, Fizz a indiqué qu’une interruption intermittente était liée à des travaux de maintenance dans le secteur et recommandait notamment de surveiller le retour du modem en ligne.

Ces témoignages ne prouvaient évidemment pas que mon adresse rencontrait exactement le même problème.

Ils m’ont surtout montré à quel point une microcoupure résidentielle peut être trompeuse en télétravail.

Elle dure parfois assez peu pour que Netflix ou une page web semblent simplement hésiter.

Mais un tunnel professionnel, lui, doit maintenir une session.

Il perd le réseau.

Il détecte la coupure.

Il tente de revenir.

Et c’est sa fenêtre de reconnexion que je retiens.

Une fois cette logique comprise, je savais enfin quoi noter pour Fizz :

l’heure exacte ;

plusieurs appareils touchés ;

Ethernet également touché ;

et une perte Internet visible même sans dépendre du VPN d’entreprise.

C’était beaucoup plus exploitable que « mon VPN s’est déconnecté trois fois ».

Le test inverse m’a aussi appris quand arrêter d’accuser Fizz

Quelques jours plus tard, le client professionnel a encore affiché « Reconnecting ».

Réflexe immédiat : deuxième écran.

Ping normal.

Page web normale.

Téléphone connecté au Wi-Fi : Internet normal.

Cette fois, rien d’autre n’avait cligné.

Le diagnostic était donc différent.

Quand seul le tunnel professionnel tombe alors que l’accès Internet direct continue normalement, je ne redémarre plus le modem.

Je regarde le client VPN, la passerelle de l’entreprise, la session d’authentification ou les journaux que l’équipe IT peut réellement exploiter.

J’ai fini par retenir une règle beaucoup plus utile que le logo affiché au moment de la panne :

si tout tombe ensemble, je regarde le réseau Fizz ; si seul le tunnel tombe, je regarde le VPN professionnel.

Mais il me restait un problème.

Savoir qui était responsable ne rendait pas ma réunion plus stable.

Mon diagnostic était meilleur, mais l’appel continuait de casser

Sur ma connexion, la microcoupure ne durait parfois que quelques secondes.

Le problème était ce qui venait après.

Internet revenait.

Le VPN professionnel détectait le réseau.

Puis le tunnel devait retrouver sa session.

Certaines ressources internes prenaient encore quelques secondes supplémentaires avant de redevenir utilisables.

Une petite coupure Fizz se transformait donc en interruption de travail beaucoup plus longue.

J’avais déjà OnlydogVPN^↗ installé sur un autre appareil.

Après avoir isolé le problème, j’ai voulu voir comment un tunnel conçu pour récupérer rapidement sur un réseau instable se comporterait face aux mêmes microcoupures.

Je l’ai laissé actif pendant le test suivant.

Fizz a de nouveau vacillé.

La page s’est arrêtée brièvement.

Puis elle est repartie.

Pas de longue séquence de déconnexion, de bouton à relancer ou de session à reconstruire manuellement.

Le réseau avait cligné.

Le tunnel avait repris.

C’est seulement après avoir observé ce résultat que son choix technique m’a intéressé : le service utilise un transport basé sur HTTP/3 et met l’accent sur la récupération lorsque le réseau devient faible ou change.

Il ne peut pas faire circuler des données pendant les secondes où la connexion Fizz n’en transporte aucune.

Mais dans ce test, la microcoupure est restée une microcoupure au lieu de devenir une deuxième panne créée par la reprise du VPN.

C’était beaucoup plus utile pour moi qu’une longue liste de serveurs supplémentaires.

Le vrai test consistait à voir si cette récupération pouvait aider mon travail professionnel

Il restait une difficulté évidente.

Ce service ne remplace pas le VPN de mon employeur.

Il ne possède ni ses certificats ni ses droits d’accès et ne peut pas ouvrir les ressources privées de l’entreprise.

Pour mon travail, le tunnel professionnel restait obligatoire.

En revanche, maintenant que nous savions que certaines interruptions commençaient sur le réseau Fizz, l’équipe IT pouvait tester une autre idée : utiliser, lorsque la politique de l’entreprise l’autorise, un tunnel plus résilient comme chemin extérieur puis lancer le VPN professionnel au-dessus.

Nous l’avons essayé sur une configuration autorisée.

Le premier tunnel s’est établi.

Puis le VPN de l’entreprise.

Connexion normale.

J’ai repris mon appel.

La microcoupure suivante est arrivée.

Une petite cassure dans l’audio.

Puis la conversation a continué.

Le client professionnel n’est pas parti dans la longue séquence de reconnexion que j’avais pris l’habitude de voir.

Pas de nouvelle authentification.

Pas de lecteur réseau à rouvrir.

Le réseau Fizz avait toujours vacillé.

Mais cette fois, son petit accident n’avait pas entraîné tout mon environnement professionnel avec lui.

C’est là que j’ai compris ce que je cherchais réellement.

Je ne pouvais pas supprimer la microcoupure depuis mon portable.

Je pouvais essayer d’empêcher sa récupération de me coûter trente secondes supplémentaires.

C’est aussi la limite que je vérifierais avant de reproduire ce montage

Sur un ordinateur d’entreprise, je ne superposerais pas deux tunnels sans vérifier la politique IT.

Certains employeurs interdisent les VPN personnels et certains clients professionnels imposent leur propre chemin réseau.

Dans ce cas, je garderais simplement la méthode de diagnostic : second appareil, test direct, Ethernet et horaires précis des coupures.

Mais lorsque les deux tunnels sont autorisés à coexister, la capacité du premier à reprendre rapidement sur une connexion instable devient beaucoup plus intéressante que son nombre de régions.

Le service possède d’ailleurs moins de régions et moins de recul public que les grands fournisseurs établis.

Cela aurait compté davantage si je cherchais une destination très précise.

Ici, mon critère était différent.

Je voulais qu’une perte de cinq secondes reste aussi proche que possible de cinq secondes.

Pas qu’elle se transforme en une minute de VPN professionnel à reconstruire.

Maintenant, je regarde ce qui tombe avant le VPN

Quand mon VPN professionnel se déconnecte sur Fizz, je ne commence plus par son message d’erreur.

Je regarde les secondes qui le précèdent.

Le deuxième appareil perd Internet ?

Le trafic direct s’arrête ?

Ethernet est touché comme le Wi-Fi ?

Le modem se reconnecte ?

Alors le tunnel professionnel est probablement en train de subir la microcoupure.

Si Internet direct continue normalement et que seul le VPN d’entreprise tombe, je transmets le problème à l’IT avec beaucoup moins d’ambiguïté.

Et lorsque la coupure vient bien de Fizz, je ne juge plus seulement un VPN sur sa capacité à se connecter.

Je regarde surtout ce qu’il fait quand le réseau disparaît trois secondes puis revient.

C’est ce détail qui a finalement changé mes réunions.

Pour distinguer ma microcoupure Fizz de ma coupure VPN, je n’ai pas chronométré le tunnel qui revenait : j’ai regardé quel appareil avait cessé de répondre juste avant lui — puis combien de temps le VPN mettait à me rendre mon travail.