VPN professionnel sur Fizz : quatre tests pour comprendre pourquoi vos sessions tombent plusieurs fois par jour

À 9 h 17, mon VPN professionnel s’est déconnecté.

À 10 h 06, il l’a refait.

La troisième fois, j’étais dans un portail interne en train de valider un dossier. Internet est revenu presque immédiatement, mais le VPN avait perdu sa session et le portail me renvoyait vers l’authentification.

J’ai lancé un test de vitesse.

Plus de 400 Mb/s.

J’ai donc fait ce qui paraît logique: j’ai accusé le VPN de l’entreprise.

Le problème, c’est qu’un test de débit effectué trente secondes après une coupure répond très mal à la question qui m’intéressait. Je n’avais pas besoin de savoir combien de mégabits ma connexion pouvait fournir quand tout allait bien. J’avais besoin de savoir ce qui disparaissait pendant les quelques secondes où ma session professionnelle tombait.

Et sur Fizz, ce matin-là, cette distinction comptait plus que le chiffre du Speedtest.

Deux jours auparavant, les 29 et 30 août 2026, plusieurs abonnés avaient signalé sur le forum Fizz des interruptions à Québec, notamment à Limoilou, Maizerets et Les Saules. Un membre indiquait que le soutien lui avait confirmé qu’un secteur complet était touché. La page d’état de Fizz affichait ensuite de nouveau les services comme fonctionnels.

Cela ne suffisait pas à expliquer mes propres déconnexions. En revanche, cela suffisait à me faire abandonner une idée trop confortable: si la page d’état est verte, alors tout ce qui se passe sous mon VPN doit forcément venir du VPN.

Premier test: j’ai retiré le Wi-Fi de l’équation

Fizz recommande lui-même, lorsqu’un VPN pose problème en télétravail, de vérifier d’abord Internet sans VPN, de tester d’autres appareils et, si nécessaire, de connecter directement l’ordinateur au modem avec un câble Ethernet.

C’était exactement le genre de test dont j’avais besoin.

J’ai donc branché mon ordinateur professionnel directement au modem Fizz.

Wi-Fi désactivé.

VPN de l’entreprise connecté.

Portail interne ouvert.

Puis j’ai continué à travailler.

Un peu avant 11 heures, la session est tombée de nouveau.

Cette seule coupure éliminait déjà une piste importante.

Si le problème avait disparu en Ethernet, j’aurais commencé par regarder la couverture Wi-Fi, les interférences ou le passage entre les bandes sans fil.

Mais il venait de se reproduire sans Wi-Fi.

Je pouvais arrêter de modifier les réglages radio et passer au test suivant.

C’est le premier contrôle que je referais devant des déconnexions répétées sur Fizz: même ordinateur, même VPN, mais Ethernet direct au modem.

Pas pour obtenir un meilleur score.

Pour voir si la session tombe encore.

Quelques secondes peuvent suffire à casser une journée de télétravail

C’est ce qui rend ces incidents trompeurs.

Une page Web supporte assez bien une petite interruption. Le navigateur attend quelques instants, retransmet ce qui manque et continue. Au moment où je regarde l’écran, j’ai parfois l’impression qu’il ne s’est presque rien passé.

Un VPN professionnel, lui, entretient une session entre deux extrémités. Si elles cessent de se voir suffisamment longtemps, le tunnel peut être considéré comme perdu et devoir se reconnecter. Les mécanismes documentés pour IKEv2 prévoient précisément ce genre de perte temporaire de connectivité. Les solutions professionnelles intègrent d’ailleurs des fonctions de reconnexion automatique lorsque le réseau disparaît momentanément.

Je me le représentais désormais comme un appel téléphonique.

Une page Web peut tolérer deux secondes de silence et reprendre la conversation.

Un tunnel professionnel peut, lui, raccrocher et rappeler.

Voilà pourquoi mes 400 Mb/s ne prouvaient presque rien. Le test mesurait l’autoroute une fois la circulation revenue; moi, j’essayais de comprendre ce qui s’était passé pendant les quelques secondes où tout s’était arrêté.

Deuxième test: le même VPN professionnel, mais sans Internet résidentiel Fizz

Il fallait maintenant déplacer une seule pièce sans toucher au reste.

Pas le VPN.

Pas l’ordinateur.

Pas mon compte professionnel.

J’ai débranché l’Ethernet et connecté l’ordinateur au partage de connexion de mon téléphone, avec le téléphone sur son réseau mobile.

Puis j’ai repris exactement le même travail.

VPN professionnel.

Portail interne.

Visioconférence.

Document partagé.

Quarante-cinq minutes ont passé sans déconnexion.

À ce stade, je n’aurais plus commencé par réinstaller le client VPN.

Le même ordinateur et le même tunnel venaient de fonctionner correctement sur un autre accès Internet. Pendant ce temps, la coupure s’était déjà reproduite aussi bien en Wi-Fi qu’en Ethernet sur la connexion résidentielle.

Mon problème devenait beaucoup plus précis.

Je pouvais désormais noter les heures des prochaines interruptions et demander au soutien Fizz de vérifier la ligne et les signaux du modem, plutôt que de leur envoyer simplement « mon VPN décroche ».

Ce type de différence apparaît aussi dans les expériences publiques des abonnés. En janvier 2026, un utilisateur Fizz décrivait par exemple un ordinateur utilisant Zscaler qui fonctionnait mal sur son accès résidentiel alors qu’une autre configuration réseau passait; un redémarrage du modem avait finalement rétabli la situation.

Ce n’était pas une preuve que mon cas avait la même origine. C’était surtout un rappel utile: avant d’accuser le logiciel, il faut voir ce qu’il fait lorsqu’on lui donne un autre chemin vers Internet.

Il me restait pourtant une question.

Que se passerait-il avec un autre tunnel, au même moment, sur cette même connexion Fizz?

Le troisième test n’a pas remplacé mon VPN d’entreprise

Je n’allais pas installer un VPN personnel sur l’ordinateur administré par mon employeur.

Je voulais isoler le problème, pas en créer un nouveau.

J’ai donc pris mon ordinateur personnel, posé juste à côté.

Même modem Fizz.

Même connexion résidentielle.

Sur celui-là, j’ai lancé OnlydogVPN.

C’est ici que sa simplicité m’a réellement servi. Je ne voulais surtout pas transformer mon contrôle en deuxième séance de diagnostic avec quinze serveurs et autant de paramètres. L’application me permettait de lancer rapidement un autre tunnel et de le laisser tourner pendant que je continuais à observer la connexion.

J’ai ensuite maintenu une activité continue sur les deux machines.

Sur l’ordinateur professionnel: le tunnel de l’entreprise et mon portail.

Sur le personnel: le petit VPN et un transfert qui me permettait de voir immédiatement si le trafic s’arrêtait.

À 11 h 32, le portail professionnel s’est figé.

Puis le client VPN a annoncé sa reconnexion.

Sur l’autre ordinateur, le transfert a marqué une courte pause.

Mais je n’ai pas eu à relancer le tunnel personnel. Le trafic est reparti tout seul.

Cette fois, le Speedtest ne m’intéressait même plus.

Deux machines venaient de ressentir une perturbation au même instant.

Le tunnel professionnel avait perdu sa session.

L’autre avait encaissé la coupure et repris.

C’est la récupération, et non le débit maximal, qui a changé mon jugement

Le petit service utilise un transport basé sur HTTP/3, donc sur QUIC.

Je n’avais pas besoin d’en connaître toute la mécanique. Le point utile tient en une idée: QUIC a été conçu pour mieux conserver et reprendre une connexion lorsque le chemin réseau bouge ou subit des pertes, au lieu de traiter chaque changement comme si toute la conversation devait recommencer depuis zéro.

C’est exactement ce que j’avais sous les yeux.

Pendant cette microcoupure, les deux appareils avaient perdu quelque chose.

Mais ils ne l’avaient pas vécu de la même manière.

Le tunnel professionnel s’était reconstruit.

L’autre avait simplement repris.

Cela ne sauvera évidemment pas une connexion Fizz qui reste hors ligne pendant plusieurs minutes. Mais pour les petites hésitations qui durent juste assez longtemps pour casser une session de travail, cette capacité de récupération change beaucoup plus l’expérience que 50 ou 100 Mb/s supplémentaires.

C’est à ce moment-là que mon critère s’est inversé.

Une connexion qui atteint 400 Mb/s entre deux incidents peut rester mauvaise pour un tunnel qui doit tenir huit heures sans me demander de me reconnecter.

Le quatrième test consistait à ne plus toucher à rien

J’avais encore une mauvaise habitude à éliminer: modifier quelque chose après chaque coupure.

Redémarrer le modem.

Changer de Wi-Fi.

Modifier le DNS.

Relancer le VPN.

Puis attendre.

Le problème est qu’après quatre changements, le prochain résultat ne permet plus de savoir ce qui a réellement compté.

J’ai donc gardé exactement le même montage jusqu’à obtenir une deuxième observation.

Quand la session professionnelle est retombée, j’ai noté l’heure.

Même comportement.

Sur l’accès Fizz: perte du VPN d’entreprise.

Sur l’ordinateur personnel utilisant la même connexion: brève interruption, puis reprise du tunnel.

Sur le partage mobile utilisé ensuite avec l’ordinateur professionnel: session stable.

Cette fois, j’avais quelque chose d’utilisable.

Pas:

« Mon VPN ne marche pas. »

Pas:

« Fizz coupe les VPN. »

Mais:

« Le problème se reproduit en Ethernet sur mon accès Fizz. Le même VPN professionnel tient sur un autre accès. Voici les heures exactes auxquelles les déconnexions se produisent. »

C’est une description beaucoup plus exploitable pour le soutien.

Et si j’avais obtenu l’inverse — Internet résidentiel stable, autre tunnel stable, mais VPN professionnel instable aussi bien sur Fizz que sur le réseau mobile — j’aurais cessé de déranger le modem et transmis le problème directement à l’équipe informatique de mon entreprise.

Le tunnel qui récupère mieux ne remplace pas celui de mon entreprise

C’est la limite qu’il ne faut pas perdre de vue.

Le petit service ne me donne pas accès aux ressources privées de mon employeur. Je n’aurais donc aucune raison de remplacer le tunnel professionnel par celui-ci, ni d’empiler les deux sur une machine gérée par l’entreprise sans l’accord de l’IT.

Son utilité était ailleurs.

Sur mon appareil personnel, il devenait un deuxième témoin de ce qui se passait réellement sur la ligne.

Et surtout, pendant les perturbations observées ce jour-là, il récupérait assez proprement pour rendre visible une différence qui m’échappait depuis le matin: Internet pouvait hésiter quelques secondes sans que tous les tunnels réagissent de la même façon.

J’ai finalement passé mon appel client important sur le partage mobile avec le VPN de l’entreprise.

La réunion est allée jusqu’au bout.

Puis j’ai envoyé au soutien les heures précises de mes coupures plutôt qu’une capture d’écran montrant un débit impeccable.

C’est désormais l’ordre dans lequel je testerais une session professionnelle qui tombe plusieurs fois par jour sur Fizz.

D’abord Ethernet, pour sortir le Wi-Fi de l’équation.

Ensuite exactement le même VPN sur un véritable autre accès Internet.

Puis, si j’ai un deuxième appareil, un autre tunnel sur la même connexion Fizz pour observer ce qui survit au même incident.

Et entre deux essais, je laisse les variables tranquilles.

Au début de la matinée, je cherchais un VPN professionnel défectueux.

À midi, ma question était devenue beaucoup plus utile: quand Fizz hésite pendant quelques secondes, est-ce toute ma connexion qui disparaît, ou mon tunnel professionnel qui revient simplement moins bien après la coupure?

Pour une journée de télétravail où la cinquième microcoupure signifie une cinquième authentification, une cinquième interruption de réunion et encore une tâche à reprendre, c’est cette capacité à revenir proprement — pas les 400 Mb/s affichés entre deux incidents — qui détermine si la connexion est réellement supportable.