StopCovid: Faut-il s'inspirer du modèle allemand et céder à Apple sur le contact tracing?

Pour faire court et avant de plonger dans ce vaste débat, l'Allemagne a annoncé dimanche 26 avril baser le développement de sa propre application anti-coronavirus de contact tracing sur l'API commune d'Apple et Google alors qu'elle l'avait initialement écartée. Un revirement qui s'explique par le blocage logiciel imposé par Android mais surtout iOS quant à l'activation du Bluetooth en arrière-plan, indispensable au bon fonctionnement des apps de contact tracing et que seule cette API permettrait.

• Lire aussi: Contact tracing: Le vrai problème est le facteur humain, pas les limites techniques

Or, la France, qui elle aussi travaille sur sa propre application StopCovid, refuse de plier au nom de la souveraineté technologique (mais aussi de la sécurité des données) et demande aux GAFA une levée des restrictions logicielles, sans devoir utiliser l'API controversée. Un bras de fer perdu d'avance avec Apple qui a déjà joyeusement envoyé balader le FBI par le passé pour une demande similaire liée à des faits de terrorisme. 

Face à l'impasse technologique évidente, la question se pose: la France doit-elle s'inspirer de l'Allemagne en mettant de côté son orgueil bien gaulois pour éviter que StopCovid ne soit un fiasco total? La réponse n'est pas si simple. Il n'y a pas de méchants ni de gentils dans cette affaire. Mais la balance semble peser en faveur d'une solution décentralisée "à l'allemande" avec Apple et Google. 

Un choix "plus raisonnable du point de vue technique et en termes de comparaison des dangers pour nos données", comme l'explique à AndroidPit Damien Stehlé, professeur en informatique à l'ENS de Lyon et co-signataire d'une lettre ouverte adressée au gouvernement qui alerte sur les risques présentés par les applications de contact tracing.

Laisser ses données à Apple/Google ou à l'Etat: un faux débat

Le point de discorde actuel se centre autour de la question de la méthode choisie par la France pour déployer le contact tracing. On peut grossièrement distinguer deux protocoles: un centralisé ou protocole ROBERT (la solution française) et un décentralisé (la méthode Google/Apple, la DP3T allemande, PACT et bien d'autres). 

"La terminologie centralisé/décentralisé prête à confusion", lance d'emblée Damien Stehlé. "La question n'est pas de savoir si je laisse mes données à Apple/Google ou l'Etat mais si je les laisse à Apple/Google ou Apple/Google ET l'Etat- c'est soit l'un, soit les deux." Il faut s'intéresser à qui traite les données collectées. Dans le cas de ROBERT, ce traitement est fait par l'Etat au niveau du serveur central. 

Le protocole ROBERT, pour (accrochez-vous) ROBust and privacy-presERving proximity Tracing, est une méthode de contact tracing développée par les chercheurs de l’Inria, Institut national de recherche en sciences et technologies du numérique. Les données sont ici collectées et stockées sur un serveur central. 

"L’élément clé du protocole, c'est que les utilisateurs se déclarant infectés via l'application ne sont pas individualisés sur les serveurs de l’Etat. Ainsi, personne ne peut, en théorie, remonter au malade, ni particulier, ni Etat, ni hacker: seul l’hôpital qui conserve des données de santé à cette trace" comme l'explique très bien mon confrère de Numerama, Julien Cadot.

En effet, l'Inria propose de ne jamais désolidariser un ensemble d’identifiants Bluetooth. Si votre smartphone collecte 10 identifiants de personnes avec qui vous êtes entrées en contact pendant votre déplacement, il enverra au serveur central 10 identifiants, et le vôtre. Si l’une des personnes que vous avez croisées se déclare malade, le serveur central va repérer son identifiant et estimer que tous les identifiants transmis sont à risque. Tout le monde recevra donc une notification sans savoir qui est malade. Mais le malade sera malgré tout fiché numériquement par un autre moyen à l’hôpital, avec tous les détails sur son identité réelle

"Dans les autres solutions, appelées décentralisées (l'API d'Apple/Google, entre autres), le traitement pour savoir si on est à risque se fait en local sur le téléphone qui reçoit une liste chiffrée des gens malades, et à partir de ça et des contacts qu'on a eu, le smartphone détermine si on est à risque", explique Damien Stehlé.  

Mais il n'y a pas de solution catégoriquement plus protectrice de nos données que l'autre, selon Damien Stehlé qui nous précise que chaque protocole présente les mêmes dangers, mais dans des proportions différentes. 

Entre la peste et le choléra...

Le seul fait indiscutable dans ce débat, c'est qu'une application de contact tracing centralisée ne peut fonctionner correctement sans l'API de Google/Apple pour lever les restrictions sur l'activation du Bluetooth. L'exemple singapourien l'a bien démontré. 

L'argument d'une meilleure protection de données permise par le protocole ROBERT n'est en revanche pas aussi solide. "Chaque modèle, décentralisé ou centralisé, présente les mêmes trois types de risque, mais pas dans les mêmes proportions", selon Damien Stehlé. Ces risques sont la surveillance de masse, l'espionnage de voisinage et les fausses alertes.

Avec les deux protocoles, le taux de risque de fausses alertes est le même. C'est une faille inhérente à l'imprécision du Bluetooth. Il y aura donc de faux négatifs et des faux positifs (vous êtes notifiés à risque alors que vous n'avez pas eu de contact physique avec une personne malade mais celle-ci était suffisamment proche pour générer un contact via Bluetooth).

"Le modèle décentralisé amène plus de risques d’espionnage de voisinage, je veux savoir qui est malade dans mon immeuble, où je l'ai croisé. L'option centralisée présente un plus grand danger pour ce qui est de la surveillance de masse", détaille notre expert. 

Cette surveillance de masse passe notamment par la collecte et la reproduction du graphe social. En des termes plus profanes Damien Stehlé explique que "dans la solution ROBERT, quand vous êtes malade, vous remontez l'ensemble des contacts Bluetooth que vous avez eu les 14 derniers jours. On retrace avec qui vous avez été en contact et à quelle fréquence pour les notifier. Le graphe social c'est l'ensemble des liens sociaux entre les individus, dans une telle application, le serveur central pourrait permettre de reconstruire une grosse partie de ce graphe social grâce aux données collectées par l'Etat."

Le décentralisé amène donc plus de risques d’espionnage de voisinage et le centralisé plus de risques de surveillance de masse. Mais ces deux risques là ne disparaissent pas dans l'une ou l’autre solution. Et leur gravité dépend surtout du degré de minimisation des données collectées, qui lui-même n'est pas assez précis. 

À titre personnel, Damien Stehlé estime que "le risque de surveillance de masse est bien plus sérieux que le risque d’espionnage de voisinage. Donc s’il faut choisir entre les deux, a priori il vaut mieux choisir le second." En ce sens, le professeur considère qu'en l'état, les solutions décentralisées DP3T ou celle d'Apple/Google sont plus louables  que le protocole Robert, centralisé. "L'Allemagne a fait le choix raisonnable, au moins du point de vue technique et en termes de comparaison des dangers."

Quant à moi, je pense que les limites techniques et la protection des données personnelles ne sont que la partie émergée de l'article. L'élément humain et le volontariat sur lesquels misent ces applications (en conformité avec le RGPD) sont une sérieuse entrave à leur efficacité dans un contexte de méfiance générale envers les GAFA et l'Etat. Mais ces questions ne se poseront de toute façon pas si StopCovid fonctionne mal dès le départ à cause de cette impasse technologique. 

Peut être que pour une fois, on y gagnerait donc à s'inspirer du modèle allemand.