Une application de contact tracing, dans sa version la plus simple, nécessite de mesurer la distance et le temps passé entre les individus pour pouvoir établir qu'il y a eu un contact, appliquer un modèle mathématique permettant de convertir cette liste de contacts en score d'exposition, et finalement notifier les personnes les plus exposées. Etant donné que les patients sont potentiellement contagieux plusieurs jours avant de s'être faits tester, il est nécessaire de pouvoir mettre à jour le score d'exposition des différents contacts passés et présents, ce qui implique donc qu'une synchronisation entre contacts soit faite une fois le patient ayant été testé positif.

Ce protocole conduit l'application à devoir récupérer et stocker plusieurs informations sensibles sur son utilisateur et ses contacts :

• La liste de contacts horodaté de l'utilisateur de l'application
• Le statut de santé de ses contacts (contagieux / non-contagieux)
• Le niveau d'exposition de l'utilisateur

Il implique, par ailleurs, qu'un serveur fasse le relais ou le croisement de ces informations pour que les utilisateurs concernés puissent être notifiés.

De toute évidence, ces applications de contact tracing peuvent devenir très intrusives, car il n'est pas désirable que l'entourage des patients puissent connaître leur état de santé, tout comme il n'est pas désirable qu'un serveur ne connaisse le statut de santé des individus, ce qu'ils ont fait, où ils étaient ou encore la liste des personnes qui se sont croisés.

Il faut néanmoins signaler que plusieurs équipes de recherche se sont mobilisés pour proposer des architectures qui minimisent les risques concernant la confidentialité des utilisateurs, tout en permettant aux applications de contact tracing de fonctionner. Parmi les propositions, deux en particulier se dégagent : DP3T, proposée par un consortium de chercheurs Européens, et ROBERT, proposée par l'INRIA et le Fraunhofer Institute.

La décentralisation avec DP3T, la centralisation avec ROBERT

Dans le cas de DP3T, tout est géré de manière décentralisée, c'est à dire sans qu'un serveur central ne soit impliqué dans le calcul du risque d'exposition ou dans la notification. Le seul rôle du serveur est de fournir aux applications une liste d'identifiants anonymes ayant été testé positifs, pour que les applications puissent les comparer aux identifiants des contacts stockés localement. La notification est ensuite faite localement par l'application. Cette architecture est intéressante car elle permet d'éviter qu'un serveur central n'apprenne quoi que ce soit sur les utilisateurs : leur état de santé, leur niveau d'exposition ou encore la liste de leurs contacts. Le risque cependant est qu'un utilisateur puisse désanonymiser ses contacts et donc savoir qui a contracté la maladie.

Dans le cas de ROBERT, c'est un serveur central qui s'occupe de calculer les scores d'exposition et de notifier les utilisateurs. En revanche, le protocole ne permet pas de connaître la liste de contacts d'un individu, ni le résultat de ses tests. Les seules informations que le serveur a sur les utilisateur est le score d'exposition et le fait qu'ils doivent se confiner ou non. Cette architecture a l'avantage de permettre à l'organisme qui gère le serveur de pouvoir contrôler plus finement l'épidémie, en sachant exactement qui est plus ou moins à risque. Cela permet par exemple de pouvoir paramétrer les notifications pour relâcher les mesures ou au contraire les renforcer si l'épidémie reprend. Cette approche permet aussi de garantir plus fortement que les contacts d'un patient positif ne puisse découvrir son état de santé.

L'Etat choisit la centralisation mais ne sort-il pas de son rôle ?

En cybersécurité, lorsqu'on veut déterminer le niveau de protection qu'offre un protocole, on doit définir un modèle d'attaque, c'est à dire identifier qui est impliqué dans le protocole, et comment ces acteurs pourraient abuser du système. Dans le cadre du contact tracing, on peut identifier au moins 2 acteurs : l'Etat, et les utilisateurs de l'application. ROBERT propose une solution qui part du principe qu'on peut faire confiance à l'Etat, mais pas aux utilisateurs. DP3T serait plutôt l'inverse, considérant que l'Etat a un pouvoir de nuisance trop élevé par rapport aux utilisateurs de l'application. La question du choix de protocole reviens donc à décider en qui on a le plus confiance : l'Etat ou notre entourage ?

Ce choix n'est pas simple, car il s'inscrit dans un contexte sanitaire, économique et culturel particulier. Ce qui est acceptable en France ne l'est peut être pas en Chine, et vice versa. Malgré les efforts de la France et de l'Allemagne sur le protocole ROBERT, les GAFAs et une grande partie des chercheurs ont déjà adopté le protocole DP3T ou similaires, créant de facto un standard interopérable au moins entre tous les utilisateurs d'iOS et Android.

Rappelons, par ailleurs, que même avec la meilleure volonté du monde, le contact tracing implique:

• Un risque technologique, si l'application n'est pas adopté ou ne marche pas
• Un risque sur notre vie privée, en cas d'attaque ou de fuite
• Un risque de surveillance de masse, en inscrivant un précédent technique et légal
• Un risque de perte de souveraineté vis à vis des GAFAs
• Un risque de dérive d'utilisation par la population

Dans ce contexte, est-ce vraiment à l'Etat de faire un choix ? De, à la fois, endosser une technologie à risque, la faire adopter par des millions de français ET trancher un débat qui n'est pas encore stabilisé dans la communauté technique et scientifique ? Ne doit-il pas plutôt préserver sa légitimité en tant que tiers neutre, capable de réguler et d'éviter les abus et les dérives potentielles de cette technologie ? Une chose est certaine : en choisissant la centralisation, le gouvernement tranche pour un modèle qui nous demande de faire plus confiance en l'Etat qu'en notre entourage, devenant ainsi juge et partie.