StopCovid : les secrets d'un challenge technique ! On vous dit tout !

Dès la semaine prochaine, les premiers tests de l'app StopCovid vont démarrer, tandis que l'application officielle sortira le 2 juin pour le grand public -sauf si les députés en décident autrement.

Ce programme devrait permettre de savoir (anonymement et de façon volontaire) si vous avez été potentiellement contaminés par le virus, en croisant une personne malade suffisamment longtemps lors de vos déplacements. Bien-sûr, l'enjeu est technique, mais pose aussi des questions relatives à la protection de la vie privée, deux éléments fortement liés. Il est donc intéressant de connaitre le fonctionnement du programme, et les choix qui ont été faits -aussi bien du côté d'Apple que des différents Etats.

Nous n'aborderons pas ici les questions d'ordre sanitaire, comme l'utilité d'une telle app dans la lutte contre la pandémie, des questions qui font encore débat dans le monde. L'idée est plutôt de vous expliquer comment va fonctionner le programme avec un angle technique et quelles sont les différentes approches retenues. Vous comprendrez aussi pourquoi iOS impose autant de restrictions face à Android et également les choix d'Apple et de Google en matière de traçage.

Cet article a été réalisé avec la participation de Mathieu Hausherr, lead-developer chez Virtuo - Location de voiture, un système de location de voitures bien connu en France, qui utilise justement le Bluetooth pour déverrouiller les véhicules. Mathieu donnait à ce propos une conférence en ligne il y a quelques jours sur le sujet, profitant de son expertise et pour en comprendre les enjeux. Merci également à Thomas Jaussoin, de Lunabee, qui participe au projet StopCOVID aux côtés de l’Inria, l’ANSSI, Capgemini, Dassault Systèmes, l’Inserm, Orange, Santé Publique France et Withings.

Pourquoi utiliser le Bluetooth ?

Le bluetooth est sans doute la technologie la plus simple pour faire du contact-tracing de manière anonyme et efficace : il ne s'agit pas ici de tracking localisé (il n'y a pas de données GPS, ou obtenues à partir du WiFi/4G, du moins en occident), l'idée est uniquement de savoir si vous avez croisé une personne infectée, peu importe le lieu.

Le bluetooth est présent sur tous les téléphones depuis des années (iOS 5/Android 4.3) et notamment sous la forme BLE pour Bluetooth Low Energy. Ce système permet de consommer très peu de puissance, jusqu'à six fois moins d'énergie que le WiFi par exemple. Contrairement à ce qui a été écrit ici ou là, même en arrière plan, l'impact sur l'autonomie reste négligeable.

Le Bluetooth offre également une fonction appelée Beacon ou iBeacon chez Apple. A la manière d'un phare, il s'agit d'une balise qui émet un signal tous les X secondes et qui permet de dire "Je suis là" à tous les appareils autour. Utilisé pour la géolocalisation en intérieur (pour savoir, par exemple, où se trouve un tableau dans un musée ou un guichet dans un aéroport, cf ci-dessous), il peut également servir à faire du contact tracing assez facilement, la technologie étant par ailleurs multi-plateforme : il suffit d'écouter les beacons autour de nous pour savoir si des appareils sont proches ou pas. Avec des apps évoluées, on peut ensuite faire discuter les téléphones et échanger des données -ce qui est rarement le cas avec iBeacon, où chaque balise se contente de bipper.




Le Bluetooth permet également d'avoir une idée de la distance entre deux appareil. Grâce à la puissance du signal (en gros), on peut en déduire une mesure approximative avec l'autre appareil.

Ce n'est pas parfait, mais assez précis pour savoir si la personne est à côté de vous ou dans l'appartement du dessus. L'idée de l'utiliser pour du contact-tracing prend alors tout son sens : on peut aisément savoir si l'on a été proche d'un malade et pendant combien de temps.

Les limitations d'iOS

Pour protéger la vie privée de ses utilisateurs, Apple impose quelques restrictions dans iOS :



Sur Android, il y a moins de limitations : une app peut jouer le rôle de Beacon en arrière plan, Android fournit le fameux Tx nécessaire au calcul plus précis de la distance et enfin, depuis Android 9, une autorisation de l'utilisateur est nécessaire pour utiliser le Bluetooth en arrière plan. En gros, une app Android peut facilement transformer un téléphone en mouchard, là où Apple préfère désactiver la fonction dans tous les cas de figure, même pour un usage respectueux de la vie privée ou sanitaire comme ici. C'est d'ailleurs tout l'enjeu de la discussion entre la France et Apple ces dernières semaines, Thierry Breton demandant une exception à Tim Cook pour l'application française -mais la requête a certainement été faite dans la plupart des pays proposant actuellement une applications similaire.

StopCOVID fonctionnera sur iOS, grâce à Android !

La bonne nouvelle, c'est qu'une app type StopCOVID peut fonctionner sur iPhone sans l'aide spécifique d'Apple. Le programme peut en effet scanner les appareils autour de lui et récupérer les informations nécessaires (voir plus bas) en arrière-plan. En revanche, si l'iPhone est en veille, il ne peut pas envoyer de données à quiconque, en jouant le rôle de Beacon -l'iPhone devient alors en quelque sort, indétectable et reste en sommeil.

Pour qu'un iPhone sorte de sa léthargie en présence d'autres appareils (et donc, qu'il puisse échanger des données), il faut que ces derniers jouent le rôle de Beacon : c'est le cas de tous les modèles Android, qu'ils soient en veille ou non. L'iPhone peut aussi se comporter comme un beacon, mais pas en arrière plan -c'est là la principale limitation. En clair, sans un appareil Android autour, les iPhone resteront muets entre-eux.

En pratique, dans des pays comme la France, où Google représente 60 à 80% du marché, il y aura statistiquement presque toujours un appareil Android dans les lieux fréquentés -où l'on est susceptible de croiser un malade que l'on ne connait pas (transports, centres commerciaux, restaurants...). Dans des zones comme l'Australie ou les USA, avec 50% de part de marché, c'est déjà plus gênant, car on pourrait imaginer qu'il n'y ait que des iPhone en veille autour de nous -dans des réunions d'entreprise par exemple. C'est pour cela que certains programmes (comme en Australie justement) envoient régulièrement des notifications aux utilisateurs, pour leur demander de lancer l'app en premier plan.

En utilisant les API d'Apple, ces limitations sautent d'un coup : l'iPhone peut utiliser le bluetooth dans les deux sens en arrière plan et échanger des données sans avoir besoin d'être réveillé. Alors pourquoi ne pas utiliser ces API ? Car pour y avoir accès, il faut obligatoirement utiliser un protocole d'échanges décentralisé et propriétaire, imposé par Apple et Google, ce que certains Etats, dont la France, ont pour le moment refusé.

Mais ce refus n'est pas forcément idéologique, contrairement à ce que rapportent certains médias qui laisseraient croire que la France agit seule contre tous : créer ces apps prend du temps et l'API d'Apple n'est disponible que depuis une grosse semaine à l'heure où nous écrivons ces lignes, alors que les autorités ont souvent déjà développé leurs apps avec d'autres protocoles -comme en France, Australie, UK, Singapour etc. Si certains pays, comme la Suisse, l'Allemagne ou l'Autriche se disent désormais prêts à adopter la solution américaine, c'est sans doute que leur développement n'est pas aussi avancé que les autres ou que la solution choisie (comme en Suisse) est assez proche de ce que propose Apple -et donc, plus facile à implémenter. En la matière, il n'y a donc pas forcément d'exemplarité, plutôt un concours de circonstances.

Mais d'ailleurs, quelle est la meilleure solution ? Centralisée ou non ? C'est justement le sujet de notre seconde partie.

Centralisé ou décentralisé : quelles différences ?

Faut-il une approche centralisée ou non ? Le débat fait rage depuis plusieurs semaines entre partisans de l'un ou de l'autre, avec à la clef, bon nombre d'incompréhensions, surtout parmi les néophytes.

Pour le moment, l'ensemble des pays possédant une app (validée) ont opté pour une approche centralisée, plus facile et rapide à mettre en place et à contrôler. Ça a été le cas à Singapour, en Corée du Sud, en Australie ou encore en Angleterre. La France et l'Allemagne semblaient se diriger sur la même voie, avant que nos amis germaniques décident de faire machine arrière. Entre temps, la Suisse et plusieurs pays européens ont développé un système baptisé DP-3T créé notamment par l'EPFL (à Lausanne), décentralisé et repris depuis dans les grandes lignes par Apple et Google pour leur fameuse API commune. Mais y'a-t-il vraiment un meilleur système ?

Il y a toujours une autorité "centrale" de santé

Comme on va le voir, ces deux approches ne sont pas si différentes : dans tous les cas, les données qui transitent entre les différentes téléphones et l'autorité sanitaire restent anonymes. C'est surtout le moyen de transmission qui change !

Dans le cas de l'approche centralisée comme celle du protocole franco-allemand ROBERT, les échanges d'informations sont très limités avec les autres téléphones (ils s'échangent régulièrement des identifiants éphémères, mais c'est tout, personne ne sait qui est malade). En revanche, on garde un lien permanent avec l'autorité de santé, qui connait les identifiants des personnes qui ont croisé des malades, on se rapproche en fait de la relation que l'on aurait avec son médecin. Pas question pourtant de faire le lien entre un patient et son numéro de sécurité sociale par exemple, on ne le connait que sous un pseudonyme. Sans rentrer dans les détails techniques, cette méthode permet de définir rapidement si vous avez croisé (ou non) des personnes infectées et s'il est nécessaire (par exemple), de vous faire dépister. Et le protocole garantit que cette information n’est jamais sauvegardée, vous êtes le seul informé. L'un des avantage est aussi de pouvoir à chaque instant, changer et adapter la façon de calculer le risque, puisque c'est le serveur qui possèdent l'intelligence du système.

Dans le cas d'une approche décentralisée, comme DP-3T ou celle d'Apple/Google, il y a quand-même un serveur central en jeu, celui de l'autorité sanitaire. Mais ce dernier ne stocke que les identifiants éphémères des malades -on dit qu'ils sont éphémères, car valable uniquement pendant un temps défini et renouvelés ensuite. Ce sont ces derniers qui sont ensuite envoyés à tous les téléphones, qui peuvent alors vérifier de leur côté s'ils correspondent à ceux qui ont été stockés durant la période. En clair, l'association identifiant/malade se fera localement, et non à distance. A l'inverse, tous les téléphones récupèrent tous les identifiants de tous les malades (anonymes) à chaque instant.

Finalement, les deux approchent ont besoin d'un serveur central, c'est ensuite l'échange des identifiants et le calcul du risque qui se fait différemment -par le serveur dans l'approche centralisée, sur les téléphone en approche décentralisée. Par ailleurs, il faut que l'autorité de santé puisse valider qu'un malade... est bien malade : l'auto-diagnostique introduirait trop de risques de faux-malades. Dans tous les cas, l'implication de l'Etat est évidemment indispensable.

Y'a-t-il un système meilleur que l'autre ? Après avoir discuté avec plusieurs spécialistes, il est difficile de trancher : dans le cas d'une approche décentralisée, chacun connait les identifiants de tous les malades. En clair, si vous arrivez à obtenir un identifiant d'une personne que vous connaissez (par exemple, votre voisin, ou le client d'une banque, d'un commerce...), il sera assez facile de savoir a posteriori si cette personne est malade. On pourrait imaginer (cf image ci-dessus) qu'un commerçant, assureur etc. sniffe vos identifiants éphémères et vérifie qu'ils soient dans la liste (on trouve déjà des exemples d'apps, comme ici). A l'inverse, il sera presque impossible de savoir qui est malade dans la population générale avec qui vous n'avez pas été en contact.

Dans l'approche centralisée, le risque est... centralisé. En effet, le serveur stocke beaucoup plus d'informations, et peut même enregistrer des données de connexion permettant de faire le lien entre un malade et son adresse IP par exemple. A l'inverse, il sera plus difficile (voire impossible) à un tiers autour de vous, de savoir si vous êtes malade, car l'échange d'informations est beaucoup plus limité entre les téléphones. Dans le cas du serveur central, il y a aussi moins de données stockées sur chaque téléphone, l'approche décentralisée étant plus verbeuse.

Dans les deux approches, il y a donc des failles, des risques. Certains estiment qu'Apple et Google ont opté pour une approche décentralisée, pour éviter que des Etats totalitaires ou d'éventuels pirates, puissent trop facilement contrôler un serveur central, mais ce n'est qu'une supposition. Pour autant, même en système décentralisé, on pourrait aussi imaginer qu'une autorité décide que son app aille moucharder vos identifiants sur un serveur tiers, par exemple ou y rajoute des données GPS ou d'identité -comme c'est le cas en Chine. Pour éviter ces problèmes, la plupart des Etats démocratiques publient les sources des apps et font auditer les serveurs par des tiers, afin d'offrir des garanties aux populations. Ce sera normalement le cas en France.

Pour conclure

Vous l'avez compris, les solutions techniques sont nombreuses et apportent leurs lots de garanties... et de risques. Outre le volet politique (de faire ou non une app, et de la technologie utilisée), se pose aussi la question de l'interopérabilité : pourquoi ne pas avoir créé une app européenne ? Quid des interactions entre les pays, dans le cas d'échanges de population (notamment durant l'été) ?

Le débat autour de la souveraineté (nationale, européenne) est également intéressant : dans quelle mesure Apple a-t-elle la légitimité de nous imposer son protocole ? Une firme privée peut-être se montrer neutre face à des Etats, pas toujours démocratiques ? Jusqu'à quel point peut-on autoriser des sociétés privées étrangères à verrouiller l'accès à du hardware de masse ? A l'inverse, surtout depuis l'affaire Snowden, certains n'hésitent pas à se montrer frileux envers les autorités de leurs pays, et à justifier la nécessité d'un acteur privé, qu'ils estiment plus neutre, dans le débat.

Dans tous les cas, et même si StopCOVID ne se montre pas forcément utile cette année, réfléchir à une solution efficace pour faire du contact-tracing reste intéressante, histoire d'être prêt pour une prochaine épidémie par exemple ou en cas de nouvelle vague cet hiver.