J’ai publié en mai 2021 un premier audit de Doctolib. J’avais fait cet audit car cette plateforme nous était imposée pour nous faire vacciner contre le Covid. Depuis, Doctolib a changé bon nombre de ses technologies et je souhaite donc faire une mise à jour.

Comme pour le précédent audit, il s’agit ici de quelques points qui me semblent pertinents d’aborder et non un audit exhaustif.

1. Droit d’accès

Doctolib ne respecte toujours pas le droit d’accès aux données personnelles. J’ai fait une demande d’accè à une copie de mes données personnelles début juillet qui n’a pas reçu de réponse. Comme je l’explique dans cette analyse, l’engagement sur l’accès à ses données « à tout moment » (comme il était précédemment indiqué) n’est plus présent dans les engagements de Doctolib.

2. Tracking non-anonyme

Le tracking non-anonyme que j’avais relevé dans le premier audit est toujours présent mais il a changé d’adresse et de technologie. Il s’agit maintenant de l’adresse « events-logs.doctolib.com ». J’ai publié une courte vidéo sur le sujet. Dans cette vidéo, j’ai affirmé que Sentry faisait les requêtes et qu’il était en toute logique destinataire des données. Après une demande d’explication faites sur Twitter le 20 mai 2022, un courriel envoyé au DPO de Doctolib le 27 juillet 2022 fait au titre de l’article 15 du RGPD et d’une vidéo postée sur les réseaux sociaux le 10 août 2022, Doctolib a enfin répondu à certaines de mes questions et m’a notamment indiqué de la société Sentry n’était pas destinataire des données récoltées par « events-logs.doctolib.com ». Je vais ici détailler mon analyse.

Comment j’ai déterminé que Sentry était utilisé ?

Pour déterminer que Sentry était utilisé pour les requêtes « events-logs.doctolib.com », j’ai analysé les traces des requêtes et décortiqué les scripts exécutés par le site Doctolib. J’ai remarqué que ces requêtes pouvaient être initiées par deux scripts. Le premier était un script avec un nom générique dont on ne pouvait pas déduire son utilité. Le second était un script où Sentry était mentionné dans le nom du script et a de nombreuses reprises dans le script. J’ai ainsi déduit que les requêtes initiées par ce script concernait Sentry. Cela était cohérent avec la Politique relative à la protection des données personnelles de Doctolib qui décrit Sentry comme « outil analytique » dans la liste des sous-traitants praticiens et comme outil de surveillance des applications dans la liste des sous-traitants patients. Cela était également cohérent avec ce que propose Sentry en matière de traçage du front-end.

Dans cette première analyse, je n’ai pas interprété ou fait des suppositions sur ce qu’il se passait côté serveur. On aurait pu, par exemple, penser que Doctolib faisait du nettoyage de données et supprimait les identifiants comme il est documenté par Sentry. J’ai estimé cette possibilité comme peu probable dans le sens où il me parait illogique que le site Doctolib prenne le temps d’identifier les données si c’est pour que les serveurs de Doctolib les anonymisent derrière.

Réponse de Doctolib

Malgré le fait que le site Doctolib fasse des requêtes sur « events-logs.doctolib.fr » depuis le script dédié à Sentry, Doctolib m’a répondu que la société Sentry n’est pas destinataire des données. Cela ne peut signifier que deux choses :

1. Soit Doctolib a nommé un de ses scripts « sentry.js » alors qu’il n’est pas dédié à Sentry. J’avais écarté cette hypothèse car elle me parait improbable.
2. Soit Doctolib n’a pas encore (ou n’a plus) utilisé les données de « events-logs.doctolib.com » avec Sentry. Le code serait donc soit obsolète soit pour des fonctionnalités futures. J’avais également écarté cette hypothèse car les requêtes depuis le script Sentry étaient en place, donc le code était déjà utilisé.

Dans mon analyse, j’avais repéré trois adresses liées à Sentry : « events-logs.doctolib.com », « ingest.sentry.io » et « exceptions.doctolib.fr ». Doctolib indique que seul « exceptions.doctolib.fr » est utilisé pour récolter des données pour Sentry via un relai qui anonymise les données (et supprime notamment l’adresse IP). Il semble alors étrange de mentionner la société Sentry comme sous-traitant dans leur Politique relative à la protection des données personnelles si aucune donnée personnelle n’est traitée par ce sous-traitant.

Dans sa réponse, Doctolib reste très lacunaire sur « events-logs.doctolib.com » et ne répond pas à ma question sur la finalité du traitement et la durée de conservation des données. Si on estime qu’il s’agit de la ligne « Utilisation des applications et des appareils » dans la Politique relative à la protection des données personnelles de Doctolib alors l’adresse IP est bien utilisée.

Je souhaite dans la suite de ce point revenir sur quelques éléments et révéler davantage d’informations sur ce qu’une analyse plus poussée permet de découvrir. Il va s’agir ici parfois d’éléments qui par eux-même sont révélateurs mais aussi parfois de spéculations. Il faut donc être prudent sur les conclusions tirées de ces éléments.

Utilisation de Google Tag Manager ?

Il existe en réalité plusieurs routes sous le sous-domaine « events-logs.doctolib.com ». L’une d’entre-elle s’appelle « /gtm_event ». Dans le monde du tracking, les lettres « gtm » font souvent référence à Google Tag Manager. Cependant, on ne peut clairement pas faire de conjecture avec seulement trois lettres.

En se penchant un peut plus sur les requêtes « events-logs.doctolib.com/gtm_event », on peut déjà remarquer que la structure des données est différente avec les requêtes faites à la racine de « events-logs.doctolib.com ». Le script qui initie les requêtes « gtm_event » n’est pas le script « sentry.js » mais le premier script dont le nom n’est composé que de chiffres générés automatiquement. En fouillant davantage dans ce script, on remarque qu’il est fait explicitement référence à Google Tag Manager.

...
const u = () => {
  window.dataLayer = window.dataLayer || [], window.dataLayer.push({
    "gtm.start": (new Date).getTime(),
    event: "gtm.js"
  });
  const e = document.getElementsByTagName("script")[0],
    t = document.createElement("script");
  t.async = !0, t.src = "https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXX", e.parentNode.insertBefore(t, e)
},
...

Ce bout de code ne semble en revanche pas utilisé car je n’ai jamais vu mon navigateur directement charger le script « googletagmanager.com/gtm.js ». D’ailleurs, si on étudie les anciennes version du site Doctolib, on remarquera que Google Tag Manager était utilisé il y a longtemps, en 2019 par exemple, et que le nom des variables à l’œuvre sur « events-logs.doctolib.com/gtm_event » sont resté les même qu’à l’époque où « googletagmanager.com/gtm.js » était chargé.

Doctolib n’a pas signalé Google comme sous-traitants et ne m’a pas indiqué dans sa réponse que Google était destinataire de ces données.

Utilisation de NewRelic ?

Dans la liste des sous-traitants, NewRelic est mentionné mais semble être plus pour de la surveillance des serveurs. On aurait pu croire que les requêtes « events-logs.doctolib.com » servent pour NewRelic mais des références à NewRelic sont faites pour la route qui commence par « api.doctolib.fr/nr_insert_ ». Les données envoyées sur cette route sont beaucoup moins verbeuses mais il s’agit tout de même de l’ensemble de l’historique de navigation sur le site Doctolib et on retrouve l’identifiant du compte utilisateur comme pour les requêtes « events-logs.doctolib.com ». Ces données vont aussi aux Etats-Unis d’après la liste des sous-traitants.

3. Google Captcha

Dans certains cas, l’outil reCAPTCHA de Google peut être chargé par le site Doctolib. L’utilisation du captcha de Google est soumis au consentement (c.f. cet article de blog). Pourtant Doctolib ne demande ni le consentement, ni n’informe les utilisateurs de l’utilisation de cet outil tiers dans leur Politique relative à la protection des données personnelles.

4. Notifications push

D’après leur Politique relative à la protection des données personnelles, Google Firebase Cloud Messaging est utilisé pour les notifications push. Doctolib invite les usagers à désactiver les notifications pour que Google ne traite pas ces données.

5. Localisation précise dans l’URL

Lorsqu’on utilise la fonctionnalité de localisation sur Doctolib, les coordonnées GPS sont en paramètres GET comme on peut le voir sur cet exemple :

https://www.doctolib.fr/medecin-generaliste/paris?latitude=48.85921470482734&longitude=2.334099675723912847

Comme pour les mots de passe, il n’est pas conseillé de mettre cette information (et aussi précise) dans l’URL. Elle se retrouve dans l’historique du navigateur et dans les logs serveur.

6. Export de données personnelles

Lorsqu’on met nos données personnelles sur Doctolib, on peut penser qu’elles restent chez Doctolib. Pourtant, on l’a vu de nombreux sous-traitants sont utilisés. De plus, en étudiant les guides destinés aux professionnels de santé, j’ai découvert que des fonctionnalités permettaient d’exporter les données personnelles des patients.

Export de la base patient

Selon le guide « Exporter l’historique de rendez-vous« , les praticiens peuvent exporter l’intégralité de leur base patient contenant les données personnelles de tous leurs patients. Aucune information sur les praticiens qui exportent vos données ne semble faite.

Export automatique vers des logiciels métiers

D’après le guide « Connecteur avec un logiciel métier« , les praticiens peuvent exporter automatiquement les données des rendez-vous vers un logiciel externe. Là encore les patients ne semblent pas être informés.

Conclusion

Cet audit est, comme le précédent, seulement des observations d’un point de vu patient sans avoir accès au code source de Doctolib. Il est donc bien évidement imparfait. Seule la CNIL peut vérifier ce qu’il se passe côté serveur.

Je souhaite également ici indiquer que je n’appelle pas au boycott de Doctolib, surtout quand on est un patient. Malgré les réserves que l’on peut avoir sur la plateforme, en tant que patient on est obligé de l’utiliser pour prendre un rendez-vous (même en appelant par téléphone ça sera simplement le secrétariat qui renseignera le rendez-vous sur Doctolib). J’estime qu’il serait dangereux de se priver de soin pour des raisons de respect de la vie privée. Personnellement j’essaye d’informer sur les pratiques pour que celles-ci changent. Les médecins ont aussi une très grande part de responsabilité et en tant que patient ça serait plutôt à eux de leur signaler leurs obligations.