Doctolib incompatible avec le VPN : j’ai arrêté de changer de serveur et réduit l’exception au strict nécessaire

Le créneau était encore disponible.

C’était tout ce qui m’intéressait.

J’avais ouvert Doctolib sur mon téléphone pour déplacer un rendez-vous. Une heure convenable venait d’apparaître et je voulais simplement la réserver avant que quelqu’un d’autre ne le fasse.

J’ai appuyé.

Chargement.

Captcha.

Je l’ai validé.

Nouveau captcha.

Validé encore une fois.

Puis retour au même écran.

J’ai fermé l’application, vérifié ma connexion et recommencé.

Même boucle.

Mon téléphone avait pourtant Internet. Les autres applications fonctionnaient. Le VPN affichait « connecté ».

J’ai donc fait ce qui paraît logique quand un service n’aime pas une adresse VPN : j’ai choisi un autre serveur français.

Aucun changement.

Un troisième.

Toujours le captcha.

Le créneau était encore là.

Je commençais surtout à me demander combien de temps il allait le rester.

Puis j’ai coupé le VPN.

Doctolib s’est ouvert immédiatement.

J’ai validé le rendez-vous.

Confirmation reçue.

À cet instant, l’urgence était réglée.

Mais pas le vrai problème.

Je n’avais aucune envie que « utiliser Doctolib » devienne synonyme de « désactiver le VPN de tout mon téléphone ».

Changer de serveur ne pouvait pas être ma stratégie

J’avais d’abord imaginé un blocage banal d’une mauvaise adresse IP.

Une sortie VPN avait mauvaise réputation.

J’en choisissais une autre.

Fin de l’histoire.

Le centre d’aide de Doctolib, mis à jour le 25 juin 2026, est beaucoup plus clair : la plateforme indique que l’utilisation d’un VPN peut empêcher l’accès parce qu’elle ne peut pas se fier aux adresses IP provenant de groupes VPN, ces adresses étant partagées entre de nombreux utilisateurs.

Ce n’était donc pas seulement mon serveur français qui avait mal choisi sa journée.

Doctolib se méfiait précisément du type d’adresse que je continuais à lui présenter.

Tout à coup, ma petite roulette de serveurs paraissait assez absurde.

Je pouvais peut-être finir par tomber sur une sortie qui passe.

Mais ce n’était pas la bonne manière de résoudre un service qui me disait justement qu’il ne voulait pas de cette route.

Une discussion publique dans la communauté ProtonVPN décrivait d’ailleurs un symptôme presque identique : avec le VPN actif, Doctolib demandait de résoudre un captcha, puis recommençait malgré plusieurs validations.

C’était exactement le genre de panne qui vous fait soupçonner le captcha avant de comprendre que le problème se trouve en dessous.

Couper tout le VPN fonctionnait beaucoup trop bien

C’est ce qui rendait la solution évidente si séduisante.

VPN coupé.

Doctolib fonctionnait.

Je pouvais très bien m’arrêter là.

À chaque rendez-vous :

désactiver ;

ouvrir Doctolib ;

prendre ou déplacer le créneau ;

réactiver.

Quelques secondes.

Sauf que j’utilise justement un VPN pour ne pas avoir à penser à lui application après application.

Sur mon téléphone, d’autres applications restaient ouvertes en arrière-plan. Mon navigateur aussi. Une messagerie synchronisait ses données.

Le problème concernait une seule application.

Couper la route de tout le téléphone pour elle me semblait aussi disproportionné que couper l’électricité de l’appartement pour changer une ampoule.

Je ne voulais donc pas apprendre à désactiver le VPN plus vite.

Je voulais rendre l’exception plus petite.

Android sait déjà séparer les applications

À partir de là, le problème devient beaucoup plus simple.

Sur Android, une application VPN peut créer deux types de règles.

Elle peut choisir quelles applications utilisent le tunnel.

Ou quelles applications n’utilisent pas le tunnel.

La documentation Android est explicite : lorsqu’une application est exclue, elle utilise le réseau normal comme si le VPN n’était pas actif. À l’inverse, avec une liste d’applications autorisées, seules celles qui y figurent passent dans le tunnel.

Je me le représente comme deux files à un péage.

Une voie entre dans le tunnel.

L’autre continue sur la route normale.

Le vrai travail n’est pas de construire un deuxième Internet.

C’est de décider quelle application prend quelle voie.

Dans mon cas, Doctolib venait pratiquement de choisir pour lui-même.

Il voulait la route normale.

La vraie question devenait donc : qu’est-ce qui, sur mon téléphone, avait réellement besoin du VPN ?

Ma première idée était d’exclure uniquement Doctolib

Si l’objectif est de faire passer presque tout le téléphone par le VPN sauf Doctolib, cette logique est parfaitement cohérente.

Une application dehors.

Tout le reste dedans.

Certains VPN disposent de contrôles d’exclusion granulaires qui conviennent très bien à ce besoin.

Mais en regardant ce que je faisais réellement sur mon téléphone, je me suis aperçu que j’avais construit ma règle à l’envers.

Je n’avais pas besoin d’une route VPN particulière pour la calculatrice, l’appareil photo, Doctolib ou la moitié des utilitaires installés.

Je voulais surtout le tunnel pour quelques usages précis.

Mon navigateur.

Certaines applications de communication.

Quelques services que j’utilise régulièrement sur des réseaux auxquels je fais moins confiance.

Je m’apprêtais donc à ajouter une exception à Doctolib dans une règle globale dont je n’avais jamais vraiment eu besoin.

Cette petite différence a changé ma décision.

Au lieu de demander :

comment laisser uniquement Doctolib sortir du VPN ?

je me suis demandé :

quelles applications ont réellement besoin d’y entrer ?

La seconde liste était étonnamment courte.

J’ai réduit le VPN au lieu d’agrandir la liste d’exceptions

C’est à ce moment-là que j’ai ouvert OnlydogVPN sur le téléphone Android utilisé pour le test.

Son contrôle de routage par application permet d’envoyer uniquement les applications sélectionnées dans le tunnel.

J’ai donc arrêté de considérer le téléphone entier comme un seul bloc.

Navigateur : VPN.

Messagerie choisie : VPN.

Les quelques applications pour lesquelles je voulais réellement cette route : VPN.

Doctolib : rien à configurer.

Il restait simplement sur la connexion normale.

J’ai reconnecté le service.

Puis j’ai rouvert Doctolib.

Pas de boucle de captcha.

La page de mes rendez-vous s’est affichée.

J’ai ouvert le rendez-vous que je venais de déplacer.

Détails visibles.

Retour.

Recherche d’un praticien.

Résultats.

J’ai ensuite basculé vers mon navigateur.

Lui continuait à utiliser le tunnel.

Puis ma messagerie.

Même chose.

Je suis revenu sur Doctolib.

Toujours utilisable.

C’était le résultat que j’avais cherché maladroitement en changeant plusieurs fois de serveur :

Doctolib utilisait ma connexion ordinaire, tandis que les applications que j’avais choisi de protéger restaient dans le VPN.

Et cette fois, je n’avais plus rien à couper avant de prendre un rendez-vous.

Le détail important est apparu quand j’ai cessé d’y penser

Le premier test est facile.

On vient de modifier les réglages.

On se souvient de tout.

On vérifie l’icône VPN trois fois.

Le vrai test est arrivé plus tard.

Une notification Doctolib m’a fait rouvrir l’application.

J’ai appuyé sans réfléchir.

La page s’est chargée.

Je n’avais pas commencé par ouvrir le VPN.

Je n’avais pas vérifié quel serveur était actif.

Je n’avais pas désactivé quoi que ce soit.

Doctolib suivait simplement sa route normale, tandis que les applications sélectionnées continuaient à utiliser le tunnel.

C’est là que cette configuration m’a paru plus utile qu’une exception que je devais garder en tête.

Elle restait vraie quand j’arrêtais d’y penser.

Pour Doctolib, la meilleure IP VPN était finalement aucune IP VPN

C’est la partie que j’avais le plus de mal à accepter au début.

J’étais parti du principe qu’un problème rencontré avec un VPN devait se résoudre dans le VPN.

Serveur différent.

Protocole différent.

Nouvelle adresse française.

Peut-être une IP moins chargée.

Mais Doctolib expliquait lui-même le problème : les adresses provenant de groupes VPN ne correspondaient pas à ce qu’il voulait accepter pour l’accès au service.

Je ne devais donc pas trouver la sortie VPN parfaite pour Doctolib.

Je devais arrêter de lui en présenter une.

Une adresse française VPN restait une adresse VPN.

Ma connexion normale était déjà exactement la route dont cette application avait besoin.

À partir de là, le nombre de serveurs disponibles cessait d’être le bon critère pour ce problème.

Cent nouvelles sorties ne valaient pas autant qu’une règle disant simplement :

cette application n’en utilise aucune.

La seule vraie limite était la direction de ma règle

Le réglage que j’ai utilisé est particulièrement naturel sur Android, où le système prévoit explicitement le routage VPN application par application.

Et il correspondait bien à mon usage : seules quelques applications avaient réellement besoin du tunnel.

Si je voulais au contraire placer presque tout le téléphone derrière le VPN et faire sortir uniquement Doctolib, une liste d’exclusion explicite serait plus logique.

Le petit service dispose aussi de moins de régions que les fournisseurs les plus importants et de moins d’années de recul public.

Mais ce n’était pas ce qui me bloquait devant mon créneau médical.

Je n’avais pas besoin d’une centaine de destinations supplémentaires.

J’avais besoin que Doctolib cesse d’utiliser une IP VPN sans que tout le reste de mon téléphone perde le tunnel.

Mon critère a fini par devenir très petit

Au départ, je pensais devoir choisir entre deux situations.

VPN activé : Doctolib inutilisable.

VPN désactivé : Doctolib fonctionne.

C’était un faux choix.

Le téléphone n’avait aucune raison d’être traité comme une seule application géante.

Doctolib pouvait utiliser directement ma connexion normale.

Les applications pour lesquelles je voulais réellement le VPN pouvaient continuer à prendre le tunnel.

Et moi, je pouvais arrêter de faire le gardien de l’interrupteur.

Le premier créneau avait été réservé parce que j’avais coupé tout le VPN dans l’urgence.

Le suivant s’est ouvert sans que j’aie à toucher à quoi que ce soit.

C’est devenu mon nouveau standard pour ce problème : si une seule application refuse les IP VPN, l’exception ne devrait pas être plus grande que l’application qui l’exige.