Pourquoi une microcoupure d’une seconde fait tomber FortiClient ou RDP alors que la vidéo continue : le buffer m’avait caché la panne

La vidéo continuait parfaitement sur mon deuxième écran. C’est ce qui m’a convaincu, pendant plusieurs jours, que ma connexion Internet n’avait aucun problème. Pourtant, au milieu d’une session de travail, le curseur de mon bureau distant s’est figé. Quelques secondes plus tard, RDP affichait sa tentative de reconnexion. Derrière lui, FortiClient n’était plus connecté non plus. J’ai regardé la vidéo : toujours en lecture.

J’ai donc accusé le VPN professionnel, puis Windows, puis le serveur distant. Ce n’est qu’en chronométrant une minuscule interruption du réseau que j’ai compris ce qui se passait : la vidéo n’était pas la preuve que la microcoupure n’existait pas. Elle avait simplement suffisamment d’avance pour me la cacher.

Mon erreur était de considérer la vidéo comme un test de stabilité

J’avais déjà fait tout ce qu’on fait lorsqu’on pense qu’Internet est innocent. Un Speedtest donnait plusieurs centaines de mégabits. Les pages Web apparaissaient instantanément.

La vidéo 1080p ne s’arrêtait jamais. Même lorsque FortiClient tombait, le téléphone à côté de moi semblait continuer à utiliser Internet normalement. Alors comment une connexion suffisamment bonne pour transporter une vidéo pouvait-elle être trop mauvaise pour afficher un bureau distant presque immobile ?

Parce que ces deux usages ne demandent pas la même chose au réseau.

Un service de streaming peut télécharger du contenu avant que je le regarde. HTTP Live Streaming, par exemple, découpe la vidéo en segments que le lecteur peut mettre en réserve avant leur lecture.

Si quelques secondes sont déjà stockées, une panne d’une seconde peut passer totalement inaperçue. L’image continue. Le son continue.

Et moi, je conclus que le réseau n’a jamais coupé. RDP, lui, ne peut pas télécharger à l’avance les mouvements de souris que je n’ai pas encore faits. C’est là que la vidéo avait commencé à me mentir sans réellement mentir.

Le bureau distant n’a pas de réserve du futur

Lorsque je déplace une fenêtre sur le bureau distant, le client et le serveur doivent continuer à échanger maintenant. Lorsque je tape une commande, elle n’existe pas encore quelque part dans un buffer prêt à être joué. La session vit en temps réel.

Une interruption très courte devient donc beaucoup plus visible sur une application interactive que sur une vidéo.

Microsoft prévoit d’ailleurs explicitement ce type de situation. RDP possède un mécanisme de reconnexion automatique permettant au client de retrouver une session après une interruption réseau temporaire.

Mais « pouvoir se reconnecter » n’est pas la même chose que « n’avoir jamais été interrompu ». Le curseur se fige. La connexion disparaît.

Le réseau revient. Le client tente de retrouver la session. Puis le bureau réapparaît.

Microsoft continue encore à travailler sur cette récupération dans Azure Virtual Desktop : son mécanisme Auto-Reconnect se déclenche précisément lorsque le transport est rompu, par exemple après une coupure TCP, un timeout de keep-alive ou la disparition temporaire de l’interface réseau.

Une seconde de panne peut donc produire plusieurs secondes de gêne. Et dans mon cas, RDP n’était même pas seul.

Avec FortiClient devant RDP, deux sessions devaient se remettre debout

Mon bureau distant ne circulait pas directement sur Internet. Le chemin ressemblait plutôt à ceci : ordinateur → FortiClient → passerelle de l’entreprise → RDP → poste distant.

Si FortiClient perd son tunnel, RDP perd en même temps la route sur laquelle il circulait. Le VPN doit d’abord retrouver sa passerelle. Ensuite seulement RDP peut retrouver sa session.

Je regardais donc parfois un écran RDP en reconnexion alors que l’événement initial s’était produit une couche plus bas.

Fortinet prévoit lui aussi ce problème. Le mode « Always Up » peut maintenir le VPN actif et tenter automatiquement une reconnexion après une perte liée au réseau.

Sur les configurations IPsec compatibles, la reprise de session IKEv2 sert également à éviter de repartir de zéro après certaines interruptions ou changements de réseau.

Ce détail m’a fait changer de perspective. La capacité à revenir proprement après la panne n’était pas un bonus. Dans mon usage, elle faisait partie de la qualité réelle du VPN.

Et pendant ce temps-là, je continuais à mesurer seulement le débit.

Un témoignage m’a fait arrêter de demander si « Internet fonctionnait »

Une discussion publique décrivait un FortiClient instable en Wi-Fi pendant l’utilisation de RDP, alors que le comportement devenait beaucoup plus stable en Ethernet.

Ce qui m’intéressait n’était pas de conclure que le Wi-Fi était coupable. C’était de voir à quel point deux connexions capables d’afficher exactement les mêmes pages pouvaient avoir une qualité de continuité très différente. J’ai donc arrêté le Speedtest.

À la place, j’ai surveillé les moments précis où FortiClient ou RDP perdaient leur session. Puis le motif est apparu. Une interruption très brève.

Le Web revenait presque immédiatement. La vidéo n’avait même pas fini de consommer ce qu’elle avait déjà mis de côté. Mais FortiClient, lui, avait vu la coupure.

Et RDP attendait derrière. Je n’avais pas une connexion « lente ». J’avais une connexion qui, de temps en temps, disparaissait juste assez longtemps pour casser une chaîne de sessions interactives.

C’était un problème complètement différent.

Le bon critère n’était plus la vitesse, mais ce qu’une seconde me coûtait

Au début, j’aurais comparé deux connexions ainsi : 650 Mb/s contre 400 Mb/s. Ou deux VPN ainsi :

lequel affiche le meilleur débit ? À ce stade, le chiffre intéressant était devenu :

combien de travail dois-je recommencer après une seconde de panne ?

Une vidéo peut répondre : rien. RDP peut répondre : quelques secondes de reconnexion. Un VPN professionnel peut ajouter sa propre récupération avant même que RDP ait la possibilité de revenir.

Et soudain, une connexion à 650 Mb/s qui cassait régulièrement mes sessions ne me semblait plus automatiquement meilleure qu’une connexion un peu moins rapide mais plus stable.

Je n’avais pas besoin de davantage de vitesse. J’avais besoin que la microcoupure reste petite.

J’ai utilisé un deuxième VPN comme témoin, pas comme remplacement de FortiClient

Je voulais ensuite vérifier si tous les tunnels se comportaient de la même façon sur ce réseau. Je n’ai pas empilé un VPN commercial sous FortiClient. Cela aurait seulement ajouté une couche et brouillé le diagnostic. J’ai terminé ma session professionnelle, puis lancé OnlydogVPN^↗ pour mon trafic Internet normal.

Même ordinateur. Même réseau. J’ai démarré un transfert, ouvert plusieurs pages et laissé une vidéo tourner.

Lorsque le réseau a de nouveau eu l’une de ses petites hésitations, le trafic s’est brièvement immobilisé. Puis il est reparti. Je n’ai pas eu à rouvrir l’application.

Je n’ai pas eu à relancer la connexion. Et c’est là que le test est devenu beaucoup plus parlant que prévu. Le petit service ne faisait pas disparaître la microcoupure.

Il l’empêchait simplement de devenir mon problème.

C’était exactement ce que j’attendais d’un VPN utilisé tous les jours : le réseau peut tousser sans que le tunnel transforme chaque toux en nouvelle procédure de connexion.

HTTP/3 a cessé d’être une ligne technique abstraite

Le petit service utilise un transport basé sur HTTP/3 et QUIC. Avant cette panne, j’aurais probablement lu cette phrase puis continué. Après avoir observé les microcoupures, elle prenait un sens très concret.

QUIC intègre ses propres mécanismes de récupération et peut maintenir une connexion à travers certains changements de chemin réseau au lieu de considérer chaque variation comme une rupture définitive.

L’image que j’en ai gardée est simple. Un tunnel traditionnel peut parfois se comporter comme quelqu’un qui perd son interlocuteur dès que la ligne change. QUIC essaie davantage de reconnaître que c’est toujours la même conversation, même si le chemin vient de bouger.

Il ne peut pas transporter des données pendant la seconde où Internet est réellement absent. Mais lorsque la connexion revient, la différence se joue dans la façon dont le tunnel repart. Dans mon test, le petit service reprenait sans me demander d’intervenir.

Et après plusieurs interruptions de travail, ce comportement avait beaucoup plus de valeur pour moi que quelques dizaines de mégabits supplémentaires dans un benchmark.

FortiClient restait indispensable pour mon travail

Je n’ai évidemment pas remplacé FortiClient. Le petit VPN n’a ni les certificats ni les routes internes de mon entreprise. Pour accéder au bureau distant professionnel, FortiClient restait donc le bon outil.

Mais mon diagnostic avait changé. Au lieu de dire à l’IT : « Internet marche, puisque la vidéo continue »,

je pouvais expliquer : « j’ai de très brèves interruptions ; le streaming les absorbe, mais FortiClient perd son tunnel et RDP doit ensuite reconstruire sa session ».

À partir de là, les journaux de déconnexion, le comportement Always Up, la reprise IKEv2 ou la stabilité du réseau local devenaient beaucoup plus utiles à examiner.

Et pour mon trafic personnel, je n’avais plus envie d’accepter qu’une microcoupure se transforme automatiquement en reconnexion manuelle.

C’est pour cela que le petit service est resté installé. Il ne remplaçait pas mon VPN professionnel. Il me montrait surtout à quoi ressemble un tunnel qui sait mieux vivre avec un réseau imparfait.

Maintenant, quand une vidéo continue, je ne conclus plus que le réseau n’a pas coupé

Je regarde d’abord ce que chaque application est capable de masquer. La vidéo possède quelques secondes d’avance. RDP doit vivre dans le présent.

FortiClient doit maintenir le chemin jusqu’au réseau de l’entreprise. Et un VPN moderne peut soit transformer une petite rupture en événement visible, soit reprendre assez proprement pour que je l’oublie presque. Ce sont des comportements différents face à la même seconde de silence.

Le débit compte encore lorsque je télécharge un gros fichier. Mais ce n’était pas le chiffre qui expliquait mes journées interrompues. Ce qui comptait était la distance entre la microcoupure et le moment où je pouvais recommencer à travailler.

La vidéo avait quelques secondes en réserve ; FortiClient et RDP, eux, devaient survivre à la seconde où le réseau disparaissait vraiment.