Doctolib bloque le VPN : avant de recommencer la réservation, j’ai vérifié une chose plus importante que le serveur

La notification est arrivée au moment où je ne regardais même plus Doctolib.

Un créneau venait de se libérer chez le spécialiste que je cherchais à voir à mon retour en France.

J’étais chez ma sœur à Bruxelles, ordinateur ouvert sur son Wi-Fi, VPN actif depuis le matin. J’ai cliqué immédiatement sur l’alerte.

Le créneau était là.
J’ai choisi l’horaire.
Continuer.
Puis la page a cessé d’avancer.
J’ai actualisé.
Même chose.

Mon premier réflexe a été celui que j’aurais eu devant n’importe quel site français capricieux : changer de sortie VPN.

France.
Actualiser.
Toujours bloqué.
J’avais déjà la souris sur un autre serveur lorsque j’ai regardé l’heure.
Le problème n’était plus seulement de faire fonctionner Doctolib.

Je venais de commencer une réservation. Je ne savais pas si le premier clic avait été enregistré, si le créneau était encore temporairement retenu pour moi ou si j’étais simplement en train de recommencer une opération dont une partie avait déjà réussi.

C’est là que j’ai arrêté de chercher une meilleure IP.

Doctolib ne cache pas vraiment ce qu’il pense des VPN

J’imaginais au départ un blocage occasionnel.
Une adresse IP mal classée.
Un serveur trop utilisé.
Peut-être une autre sortie française qui passerait.

La documentation de Doctolib m’a fait abandonner cette hypothèse assez vite : son aide destinée aux patients indique explicitement que l’utilisation d’un VPN peut empêcher l’accès au service,les adresses IP provenant de groupes VPN étant partagées par de nombreux utilisateurs et ne correspondant pas aux standards de sécurité appliqués par la plateforme.

À partir de là, continuer à changer de serveur aurait été une drôle de stratégie.

Je n’étais pas devant une plateforme vidéo en train de chercher une autre route vers un contenu.

J’étais devant un service qui me disait lui-même que le type de connexion que j’utilisais pouvait être refusé.

La nuance changeait tout.

Je pouvais encore perdre cinq minutes à tester plusieurs sorties et espérer tomber sur une adresse qui passe. Mais pendant une réservation médicale déjà commencée, ce n’était plus le bon problème à résoudre.

Mon objectif n’était pas de gagner contre le contrôle.

Mon objectif était de savoir si j’avais déjà le rendez-vous.

Le chronomètre comptait davantage que mon adresse IP

C’est là que la réservation Doctolib devient particulière.

Lorsque l’on sélectionne un créneau, il est réservé temporairement pendant 15 minutes afin de laisser le temps de terminer la procédure. Sans confirmation dans ce délai, il redevient disponible pour les autres patients.

Dans mon cas, l’urgence était encore plus concrète : le créneau venait d’une liste d’attente.

Lorsqu’un rendez-vous plus tôt se libère, Doctolib peut prévenir plusieurs patients concernés. Les huit premiers peuvent recevoir l’alerte, et le créneau revient à celui qui le réserve en premier.

D’un coup, ma petite roulette de serveurs VPN me paraissait franchement absurde.
France 1.
France 2.
Fermer le navigateur.
Relancer.
Essayer encore.

Pendant ce temps, d’autres personnes pouvaient avoir reçu exactement la même notification.

Je venais de comprendre que chaque tentative de « déblocage » consommait la seule ressource que je ne pouvais pas récupérer : les minutes pendant lesquelles le créneau restait disponible.

Le meilleur diagnostic n’était donc pas le plus sophistiqué.

Il devait être le plus court.

Avant de recommencer, j’ai vérifié si le problème venait vraiment de Doctolib

Il restait une possibilité évidente : et si Doctolib était simplement en panne ?

Depuis avril 2026, la plateforme dispose d’une page de statut permettant de distinguer plus facilement un incident général d’un problème limité à son propre appareil ou à sa connexion.

Je l’ai consultée.

Rien ne m’indiquait une panne générale correspondant à ce que je voyais.

Ce contrôle ne prouvait pas à lui seul que le VPN était responsable. Mais je savais déjà deux choses utiles : Doctolib documentait les problèmes d’accès liés aux VPN, et mon erreur apparaissait justement pendant que le tunnel était actif.

J’en avais assez pour arrêter de bricoler.

Une discussion publique sur la communauté Apple m’a rappelé à quel point le diagnostic peut facilement partir dans tous les sens. Une utilisatrice confrontée à un écran blanc sur Doctolib avait déjà supprimé puis réinstallé l’application ; parmi les pistes évoquées figuraient ensuite le VPN et la comparaison entre Wi-Fi et 4G/5G.

C’était exactement la spirale que je voulais éviter.
Réinstaller.
Effacer.
Changer de serveur.
Changer de navigateur.
Recommencer.

Avec un créneau potentiellement retenu quinze minutes, je n’avais aucune envie de transformer une vérification de trente secondes en séance de dépannage.

Alors j’ai fait le test le plus simple.

Je n’ai pas essayé de rendre mon VPN invisible

J’utilisais la petite application parce que je n’étais pas sur mon propre Wi-Fi et que je voulais garder un tunnel pour le reste de ma navigation.

Jusque-là, elle m’avait justement plu pour sa simplicité : ouvrir, toucher, connecter. Le service est conçu autour de cette logique directe plutôt que d’obliger à parcourir une longue série de réglages avant de se connecter.

Mais Doctolib venait de créer une exception très claire.

Et cette fois, je ne voulais ni serveur supplémentaire, ni mode spécial, ni nouvelle tentative pour savoir si une autre IP serait acceptée.

Je voulais sortir du tunnel.

J’ai donc fait quelque chose que j’aurais auparavant considéré comme un échec du VPN : je l’ai coupé volontairement.

Puis, plutôt que de poursuivre la réservation sur le Wi-Fi qui m’avait déjà laissé dans le doute, j’ai pris mon téléphone.

Wi-Fi désactivé.
5G.
VPN coupé pour cette opération.
Doctolib.
Et avant même de rechercher à nouveau le spécialiste, j’ai ouvert Mes rendez-vous.
Le nouveau créneau n’y figurait pas.
Voilà.

C’était l’information que j’essayais d’obtenir depuis le début.

Ma première tentative n’avait pas abouti.

Je pouvais recommencer sans avoir peur de dupliquer une réservation déjà enregistrée.

La deuxième réservation a duré moins longtemps que mes premiers essais de serveurs

J’ai rouvert l’alerte.
Le créneau était encore disponible.
Je l’ai sélectionné.
Motif.
Consignes.
Confirmer le rendez-vous.
Cette fois, je suis arrivé jusqu’à l’écran de confirmation.

Je suis ensuite retourné dans Mes rendez-vous.

Le rendez-vous apparaissait.

Je n’ai pas recommencé une troisième fois « pour être sûr ». Une réservation correctement finalisée doit apparaître dans l’espace des rendez-vous, et Doctolib utilise également ses notifications et e-mails pour confirmer et rappeler les rendez-vous.

Quelques minutes plus tard, l’e-mail est arrivé.
C’était terminé.
Et c’est seulement à ce moment-là que j’ai rallumé le VPN.
Ce détail a changé la manière dont j’ai jugé la petite application.
Elle n’avait pas « débloqué Doctolib ».

Je lui ai trouvé quelque chose de plus utile dans ce scénario : elle ne transformait pas la déconnexion temporaire en nouvelle opération compliquée. J’avais pu l’écarter pendant les quelques minutes où Doctolib exigeait une connexion directe, terminer la réservation, puis reprendre ma navigation sous VPN immédiatement après.

Sur le Wi-Fi de la maison, j’ai reconnecté le tunnel.

Le rendez-vous, lui, était déjà confirmé.

C’est précisément le cas où je ne demanderais pas à un VPN de gagner

Je ne choisirais donc pas un VPN sur la promesse qu’il va systématiquement forcer le passage face au contrôle de Doctolib.

La plateforme documente elle-même le problème posé par les adresses IP provenant de groupes VPN.

Dans ce contexte, chercher une technique toujours plus agressive pour conserver le tunnel répond à la mauvaise question.

C’est aussi ce qui distingue ce problème d’un simple échec de connexion.

Si un réseau bloque une méthode de transport, changer la manière dont le VPN établit sa connexion peut avoir du sens.

Ici, je voulais prendre un rendez-vous sur un service qui pouvait refuser ma connexion précisément parce qu’elle provenait d’un VPN.

Je n’avais pas besoin d’un VPN plus combatif.

J’avais besoin d’un VPN qui reste pratique même lorsque la bonne décision consiste à le couper trois minutes.

C’est moins spectaculaire qu’une promesse de « déblocage ».

Pour ma réservation, c’était beaucoup plus utile.

La simplicité qui m’avait d’abord semblé presque secondaire devenait soudain la qualité principale : le VPN pouvait rester mon réglage normal sans devenir une contrainte lorsque Doctolib exigeait exceptionnellement autre chose.

Le test prudent tient finalement en trois observations

Je ne recommencerais donc plus immédiatement une réservation Doctolib simplement parce que la page se bloque sous VPN.

Je regarderais d’abord ce qui s’est réellement passé.
Un incident général est-il signalé ?
Le rendez-vous apparaît-il déjà dans Mes rendez-vous ?
Une confirmation est-elle arrivée ?

Si rien ne montre que la réservation a abouti et que le VPN est encore actif, je passerais ensuite à une connexion directe — dans mon cas, les données mobiles — avant de retenter le créneau.

Ce détour paraît plus lent que « changer vite de serveur ».

Il m’a fait gagner du temps parce qu’il a supprimé la pire partie du problème : ne plus savoir si j’étais en train de réparer une connexion ou de recommencer une réservation déjà enregistrée.

J’avais commencé avec une question de VPN :
« Quelle adresse va faire passer Doctolib ? »
J’ai terminé avec une question beaucoup plus utile :
« Est-ce que mon rendez-vous existe déjà ? »

C’est aussi la raison pour laquelle j’ai gardé la petite application après l’avoir volontairement coupée. Pour cette réservation Doctolib, je n’avais pas besoin qu’elle gagne une bataille contre le site : j’avais besoin qu’elle me laisse sortir du tunnel sans friction, prendre mon créneau pendant qu’il était encore là, puis reprendre sa place une fois le rendez-vous réellement confirmé.