À 9 h 12, j’avais déjà deux réponses techniquement correctes et aucune solution. Le médecin me disait : « Doctolib marche quand je ne suis pas connecté au VPN. » Le support répondait : « Désactivez le VPN. »
La DSI répondait : « Impossible, le poste est administré et le VPN d’établissement est obligatoire. »
C’est exactement le genre de ticket qui peut passer une matinée entière d’une équipe à l’autre, parce que chacun décrit correctement son morceau du problème. Le médecin voit une application qui ne charge pas. Le support voit un environnement qu’il ne peut pas garantir. La DSI voit une règle de sécurité qu’elle n’a aucune raison de supprimer sur simple demande.
Et cette semaine-là, accuser trop vite le réseau aurait été particulièrement facile. Le 28 août 2026, Doctolib avait signalé une dégradation de sa solution clinique. Quatre jours plus tard, le 1er septembre, l’Assistant de consultation avait de nouveau été indisponible entre 11 h 38 et 11 h 52 CEST.
Autrement dit, « ça vient peut-être de Doctolib » n’était pas une mauvaise hypothèse.
Mais ce n’était pas encore un diagnostic.
Résumé de l’article et contexte d’usage
Comment diagnostiquer Doctolib Médecin derrière un VPN d’établissement sans opposer support et DSI ?
Commencez par vérifier l’état du service, puis isolez le trajet réseau qui déclenche l’échec en ne changeant qu’une variable à la fois. Un VPN d’établissement peut modifier le routage, le DNS, l’IP publique de sortie et le filtrage. Le bon résultat est un avant/après reproductible que support et DSI peuvent examiner, pas le contournement du tunnel ni l’ajout improvisé d’un second VPN sur un poste clinique.
Ce qu’il faut retenir dans ce contexte
- Premier contrôle : noter l’heure exacte et vérifier la page de statut avant d’accuser le réseau local ou le VPN.
- Diagnostic utile : comparer le même poste, la même version et la même fonction sur des chemins approuvés, en documentant DNS, IP publique de sortie et symptôme précis, sans données patient.
- Pourquoi OnlydogVPN convenait ici : sur un ordinateur de test autorisé, sans session Doctolib ni données médicales, un tunnel différent a servi de témoin pour montrer que le réseau physique pouvait transporter un autre trajet VPN.
- Limite importante : le service n’est pas proposé comme chemin clinique par défaut ; deux VPN peuvent se disputer routes ou DNS et la décision finale appartient à l’établissement et à Doctolib.
Contexte vérifiable : Doctolib publie l’état de ses services ; Microsoft documente les différences de routage entre force tunnel et split tunnel ; site officiel OnlydogVPN.
Le premier test utile n’était même pas un test réseau
J’ai commencé par ouvrir la page de statut.
Ce geste a l’air presque trop simple pour mériter une procédure DSI. Pourtant, il permet d’écarter immédiatement une partie du problème : au moment de notre test, les services Doctolib étaient de nouveau indiqués comme opérationnels.
Nous pouvions donc écrire une première ligne commune dans le ticket : incident global connu au moment du test : non. C’était déjà plus utile que « chez moi ça ne marche pas ».
Les témoignages publics montrent pourquoi cette distinction compte. Sur la communauté Doctolib, une professionnelle décrivait par exemple une application de bureau devenue lente puis blanche, avant de constater que l’accès par Chrome échouait également. Passer du logiciel au navigateur n’est donc pas toujours le test décisif que l’on imagine.
Mon erreur initiale avait été de chercher immédiatement quoi modifier.
Il fallait d’abord établir ce qui changeait exactement quand l’échec apparaissait.
Le mot « VPN » cachait en réalité plusieurs changements
La documentation de Doctolib est assez nette sur ce point : lorsque son logiciel est utilisé derrière un VPN, l’éditeur indique ne pas pouvoir en assurer le bon fonctionnement. La même documentation demande aussi que l’application de bureau et pro.doctolib.frpuissent passer correctement les protections locales.
Présenté comme ça, la conversation avec la DSI change immédiatement.
« Le support nous demande de couper la sécurité » mène presque forcément à une impasse.
« Doctolib ne garantit pas ce fonctionnement lorsque son trafic emprunte notre tunnel ; il faut identifier ce que notre profil modifie » donne en revanche quelque chose à investiguer.
Et les équipes hospitalières ont de bonnes raisons de ne pas désactiver un dispositif de sécurité au hasard. En France, le programme CaRE de l’Agence du Numérique en Santé consacre justement un domaine à la sécurisation des accès distants des personnels et des fournisseurs.
Le problème n’était donc pas support contre sécurité. C’était deux contraintes légitimes qui se rencontraient au mauvais endroit. À partir de là, notre fiche de diagnostic est devenue courte : heure exacte du test et état de la page de statut ;
poste, système et version de l’application concernés ; résultat sur le réseau habituel avec le VPN d’établissement ;
résultat sur le même poste ou sur un poste de test approuvé lorsque ce tunnel n’est pas utilisé ;
DNS et adresse IP publique de sortie ; fonction Doctolib réellement en panne : connexion, dossier clinique, facturation, lecteur ou autre. Aucun nom de patient. Aucun numéro de dossier. Aucun copier-coller de données médicales dans le ticket.
Pour la première fois, le support et la DSI regardaient exactement le même problème.
Ce qui m’a fait changer d’avis : le VPN ne fait pas que « chiffrer Internet »
J’avais encore une représentation trop simple du VPN d’établissement : une couche de protection posée sur la connexion.
En pratique, il peut aussi décider par quelle porte le trafic sort.
Sur un poste en force tunnel, une grande partie du trafic Internet est envoyée dans le tunnel institutionnel. En split tunnel, certaines destinations peuvent continuer à sortir directement tandis que les ressources internes passent par le VPN. Microsoft documente cette différence comme une question de routage.
C’est un peu comme garder le même ordinateur et la même destination, mais changer l’autoroute, le péage et parfois même l’adresse affichée à l’arrivée.
Et cette adresse de sortie peut compter. Doctolib permet aux établissements utilisant ses règles d’accès sécurisées de définir des adresses ou plages IP autorisées. L’IP publique n’était donc plus un détail à laisser hors du ticket.
Nous avons repris le test en ne changeant qu’une variable. Même ordinateur. Même utilisateur. Même version. Même fonction. Avec le tunnel institutionnel : échec reproductible. Depuis l’environnement témoin approuvé, sans ce trajet : la fonction revenait.
Le ticket venait de changer de nature. Ce n’était plus « Doctolib ne fonctionne pas ». C’était : « l’échec apparaît lorsque le trafic emprunte ce chemin réseau précis ». La DSI avait enfin quelque chose de concret à chercher dans ses journaux.
J’ai ensuite failli brouiller tout le diagnostic
Mon premier réflexe a été d’empiler un autre VPN sur le poste et de voir si Doctolib passait mieux.
Mauvaise idée.
Deux clients VPN peuvent se disputer les routes ou le DNS ; la documentation technique consacrée à leur coexistence montre justement qu’il faut éviter qu’ils essaient de diriger le même trafic de façons différentes.
Surtout, faire fonctionner Doctolib derrière un deuxième VPN n’aurait pas répondu à notre question. L’application aurait simplement été placée derrière un autre chemin que celui que nous cherchions à diagnostiquer.
Nous avons donc déplacé ce test sur un ordinateur autorisé, sans session Doctolib ouverte et sans données médicales.
C’est là que OnlydogVPN↗ m’a réellement été utile.
Pas pour « débloquer Doctolib ».
Je voulais répondre à une question beaucoup plus précise : ce réseau physique savait-il transporter correctement un tunnel différent, ou le problème était-il plus bas dans la connexion elle-même ?
J’ai choisi le mode prévu pour les réseaux restrictifs et lancé la connexion. Une page web a chargé. Puis une deuxième. Un transfert de test est passé. Rien de spectaculaire — et c’était justement ce que je voulais.
Le service utilise un transport basé sur HTTP/3 avec une couche supplémentaire d’obfuscation. Dans ce test, ce choix a fourni un chemin suffisamment différent du tunnel institutionnel pour servir de témoin. Mais ce que j’ai surtout apprécié à ce moment-là, c’est de ne pas avoir à fabriquer dix expériences différentes en changeant pays, serveur, port puis protocole.
J’avais une hypothèse. Un mode. Un résultat.
Le réseau de l’établissement était capable de transporter ce tunnel sans reproduire l’échec observé avec le profil institutionnel.
Cela suffisait à éliminer une mauvaise piste : « le Wi-Fi de l’établissement empêche simplement les VPN de fonctionner ».
Le problème devenait beaucoup plus étroit.
Il fallait retourner voir le profil de la DSI.
À partir de là, support et DSI parlaient enfin de la même chose
Le message que nous avons transmis ne ressemblait plus à un appel à l’aide utilisateur.
Il disait en substance :
Doctolib est opérationnel au niveau de sa page de statut. L’échec est reproductible lorsque le profil VPN d’établissement impose son chemin réseau. Il disparaît dans le scénario témoin approuvé. Sur le même accès physique, un autre tunnel fonctionne sur une machine de test. Merci de vérifier le routage, le DNS, le filtrage, l’inspection éventuelle et l’IP de sortie du profil institutionnel, puis de déterminer avec le support Doctolib quel mode d’accès doit être retenu.
La différence est importante. On ne demandait plus à la DSI de « faire marcher Doctolib ». On lui montrait où regarder.
Elle pouvait ensuite comparer les deux chemins et décider de la réponse appropriée : modifier une règle de routage, valider une exception, fournir un accès approuvé qui ne place pas ce trafic dans le tunnel concerné, ou retenir une autre architecture conforme à sa politique de sécurité.
Ce choix appartient à l’établissement et à Doctolib, pas au médecin devant son écran.
C’est précisément ce que notre diagnostic devait permettre.
Le meilleur résultat n’était pas « j’ai trouvé un VPN qui marche »
Le petit service a moins d’historique public et moins d’évaluations indépendantes que plusieurs acteurs VPN installés depuis longtemps. C’est une limite réelle, et je n’en ferais pas pour autant le nouveau chemin par défaut d’un poste clinique.
Mais je l’ai gardé comme outil témoin.
Dans ce cas, son intérêt n’était pas d’ajouter davantage de fonctions au test. C’était exactement l’inverse : me fournir rapidement un deuxième comportement réseau sans m’obliger à transformer l’essai en arbre de décision rempli de serveurs, de pays et de protocoles.
C’est ce qui a finalement mis fin au ping-pong. Le support n’avait plus à répéter « désactivez le VPN ». La DSI n’avait plus à répondre « le VPN est obligatoire ».
Les deux équipes disposaient du même avant/après : une heure, un état de service, un trajet réseau et un résultat reproductible.
Je pensais au départ que notre problème était de choisir entre Doctolib et le VPN de l’établissement.
Ce n’était pas le bon choix.
Dans ce cas précis, isoler le trajet qui déclenchait l’échec était plus important que chercher un VPN supposément “meilleur”. Et le test qui a réellement fait avancer le dossier n’a pas été celui qui ajoutait le plus de réglages : c’était celui qui changeait suffisamment le chemin réseau pour nous montrer, enfin, de quel côté de la porte chercher.