Cher M. Cédric O

This post is also available in English

Cher M. Cédric O,

Petite parenthèse à l’intention de mes lecteurs habituels: Cédric O est le secrétaire d’état au numérique du gouvernement français. De France. Non, je ne suis pas en train de réduire son nom à une initiale, c’est bien le sien. J’en profite donc pour dire que si on demande la mise en place d’une validation qui exige un nom d’au moins N caractères, la seule solution éthique pour un développeur est de refuser de l’implémenter. Fin de la parenthèse.

D’abord, je vous remercie pour vos récentes interventions, qui me permettent de donner un thème à ce billet que je souhaitais écrire: celui de la lettre ouverte.

Je souhaite donc réagir à la direction que vous voulez faire prendre au projet StopCovid, celle de la confrontation avec Apple. Je confesse volontiers un biais envers Apple, comme le montrent les sujets traités sur ce blog, qui tournent beaucoup autour des technologies Apple, iOS en particulier. Mais j’espère tout de même vous convaincre que aller à la confrontation avec Apple serait futile, quand bien même vous voueriez Apple aux gémonies.

Pourquoi

C’était à la base une excellente idée de démarrer et de développer le projet StopCovid, soyons clair, mais je pense qu’il est utile de développer pourquoi. En effet, certains observateurs (dont des que je respecte beaucoup, comme Bruce Schneier) ont dénoncé ce genre de système informatique de suivi de contacts comme étant du solutionnisme technologique, et cette accusation mérite donc d’être examinée. Il est inutile de rappeler ici le principe et l’importance du suivi de contacts, non seulement pour avertir ceux qu’un individu nouvellement diagnostiqué a pu contaminer à son insu, mais aussi tenter de retrouver l’individu ayant contaminé celui nouvellement diagnostiqué s’il est inconnu, et ainsi potentiellement remonter les chaines de contamination.

Par contre, il est utile de repréciser le cas d’utilisation principal, qui est de contenir des réémergences de l’épidémie, que ce soit en sortie du confinement ou importées de zones endémiques. On peut donc supposer qu’on est dans le cas d’une brêche qu’il faut colmater, et donc par exemple que des moyens peu déployés lors de la phase d’observation, comme les tests sur personnes non symptomatiques, peuvent être subitement largement mobilisés dès la première contamination diagnostiquée. L’un des buts du confinement (avec la diminution de la pression sur les services hospitaliers) est d’ailleurs de se ramener à une situation où le colmatage des brêches redevient gérable, au lieu d’une situation où il y a plus de brêches que de doigts disponibles pour les boucher.

Mais comme on l’a vu dans la recherche du patient zéro dans l’Oise (où il parait qu’on cherche encore; plus de deux mois après, l’utilité me semble limitée), les méthodes actuelles semblent défaillantes dans le cas du Covid-19. Et c’est ce que confirment des recherches venant de l’université d’Oxford, qui suggèrent que les caractéristiques épidémiques supposées du Covid-19 rendent futile l’espoir d’un suivi par les méthodes traditionnelles, confirmant le besoin d’un suivi automatisé dans le cadre d’un dispositif plus général.

Cette précision n’est pas inutile, car aucune application ne sera une panacée, mais plutôt le maillon d’une chaine dont tous les éléments doivent être présents. A commencer par des test massifs (ce que la France semble pouvoir fournir en ce début mai) mais aussi à retour rapide: si le résultat du prélèvement ne revient que trois jours après, qu’on prévient les contacts, et que les tests de ceux-ci ne parviennent que trois jours après cela, il est évident que même si l’application permet de déterminer instantanément les contacts, on se ferait distancer par la maladie. Il faut donc éviter à tout prix la constitution de listes d’attente pour les tests (la PCR elle-même ne prenant que quelques heures), et faire en sorte que les prélèvements puissent être rapidement apportés aux lieux de PCR. Et une application dispense moins que jamais la constitution d’équipes d’enquêteurs, ne serait-ce que pour tracer les contacts non couverts, lorsque l’un des deux ne dispose pas d’un téléphone compatible, ou pas de téléphone du tout, par exemple. C’est d’ailleurs pour tout cela qu’il n’est pas absurde de représenter la capacité de suivi département par département, plutôt que région par région.

Comment: la couche physique

Cela étant dit, on peut maintenant envisager les différentes manières d’enregistrer automatiquement les contacts. Ecartons d’emblée la géolocalisation: c’est à la fois pas assez précis pour les besoins: le GPS n’étant pas disponible partout ou instantanément, les smartphones se basent souvent sur la localisation par émetteur cellulaire ou Wifi, et trop invasif, pour des raisons évidentes. Le Bluetooth, lui, est conçu pour permettre des communications directes entre des appareils numériques, y compris des périphériques, et sa variante basse energie a même été conçue pour supporter des applications très contraintes comme être intégrée dans une étiquette de porte-clés, permettant ainsi d’en déterminer la proximité. Cette notion de proximité est essentielle: pour la recherche de contagions potentielles, on cherche moins à déterminer la distance exacte qu’à réduire le dépistage à une liste de contacts potentiels, quitte à ce qu’il y en ait un peu trop, plutôt que de devoir dépister tout le monde à 100km à la ronde en case de contamination confirmée.

Comment: le traitement des données

OK, donc un contact se déterminera rétrospectivement par le fait que les téléphones portables des intéressés ont été en mesure d’échanger (ou « d’échanger suffisamment fort » par mesure d’intensité du signal entre autres) des données par Bluetooth. Mais comment conserver ces données (et lesquelles), et où faire ce calcul le moment venu?

N’importe quel téléphone portable diffuse déjà des messages Bluetooth à qui veut les entendre pour des raisons diverses (c’est ce qui leur permet d’apparaitre dans la liste des périphériques joignables sur l’écran de sélection d’un ordinateur de bureau, par exemple). Donc une première idée est de mettre en place l’écoute des messages Bluetooth diffusés et stocker localement l’identificateur Bluetooth de l’émetteur. Mais cela montre assez rapidement ses limites: précisément pour des raisons de protection de la vie privée cet identificateur change régulièrement dans les mises en place des versions récentes de la norme, de sorte qu’étant oublié par son propre émetteur, il devient inutile; de plus, beaucoup de téléphones vont limiter si ce n’est arrêter les émissions lorsqu’ils ne sont pas activement utilisés afin d’économiser la batterie, qui n’a jamais cessé d’être une contrainte importante sur la conception des téléphones mobiles.

Donc, il semble indispensable de mettre en place une modification de comportement des deux côtés du contact, ce qui change les données du problème: il faut maintenant que les deux côtés soient modifiés pour que ne serait-ce qu’un côté bénéficie du système. En conséquence, c’est comme pour les masques: si son contaminateur n’avait pas l’application installée, son contaminé ne tirera aucun bénéfice d’avoir installé l’application, il importe donc grandement qu’une densité suffisante de participants soit atteinte. Cela conduirait à envisager la fourniture de montres connectées (qu’il est plus difficile d’oublier chez soi) à ceux qui, comme c’est leur droit, ne disposent pas d’un téléphone portable compatible.

Maintenant que nous avons la liberté de concevoir le logiciel des deux côtés de l’interaction, les possibilité de conception augmentent grandement, trop pour revenir dessus. Cependant, un choix significatif est celui du traitement permettant de déterminer si un contact avec un individu nouvellement diagnostiqué a eu lieu, traitement qui doit donc disposer des données nécessaires à cette détermination: doit-il se faire sur le téléphone (n’importe lequel: les deux étant désormais « hermaphrodites », ce que l’un peut déterminer, symmétriquement l’autre le pourra aussi), ou sur un serveur central?

Dans le deuxième cas, le but étant de prévenir le porteur du téléphone en contact, cela emporte a priori que le serveur dispose du moyen de contacter n’importe quel utilisateur du système (directement ou indirectement: si chaque utilisateur doit, à intervalle régulier, interroger le serveur avec « je suis l’utilisateur avec le pseudonyme x, y a-t’il du nouveau pour moi? Envoyez la réponse à l’addresse IP 192.0.2.42 », c’est équivalent à pouvoir être retrouvé).

Dans le premier cas, par contre, il est impossible d’empêcher l’utilisateur de déterminer à quelle occasion il a été en contact avec une personne nouvellement diagnostiquée (à défaut d’être informé directement de l’identité de celle-ci): quand bien même le traitement de détermination serait une fonction cryptographique difficile à inverser, il lui suffirait de la faire tourner sur des sous-ensembles de sa base de contacts, par dichotomie si besoin, jusqu’à trouver l’évènement unique suffisant pour que le traitement sorte qu’il y a contamination potentielle.

Le système d’Apple et Google

Cela étant établi, examinons maintenant les choix effectués par Apple et Google, ainsi que l’API fournie, par dessus laquelle une application pourra être réalisée.

Pour commencer, « Exposure Notification » est un service du point de vue de Bluetooth Low Energy, c’est-à-dire un protocole utilisant BLE pour la transmission radio des données, comme HTTP est un protocole utilisant TCP pour effectuer la transmission des données sur (généralement) Internet. Il est documenté ici à l’heure où j’écris ces lignes; en tant quel tel, il a été enregistré auprès du consortium gérant Bluetooth, avec son propre identifiant. Le format tel que transmis est simple: outre la trame Bluetooth obligatoire, c’est surtout l’identifiant de proximité en vigueur, mais celui-ci est accompagné par un champ de métadonnées, dont la seule utilité actuellement (outre versionner le protocole, ce qui permet de confirmer que les implémentations sont compatibles) est d’affiner le calcul de perte d’intensité du signal.

Comme son nom l’indique, l’identifiant de proximité en vigueur change à intervalles plus ou moins réguliers: plus ou moins car si le changement était trop régulier, cela faciliterait le pistage et rendrait ces changements inutiles: le changement s’effectue au plus toutes les 10 minutes, et au moins toutes les 20 minutes. Tout cela est décrit plus précisément dans la documentation cryptographique, qui décrit la génération des données envoyées par le protocole ci-dessus, comment sont stockées les données reçues et envoyées, et surtout comment déterminer qu’il y a eu contamination potentielle.

La propriété la plus importante du système « Exposure Notification » est que cette détermination est effectuée localement. Le système suppose la présence d’au moins un serveur, mais celui-ci ne fait que diffuser des données non-nominatives collectées (volontairement) auprès des individus diagnostiqués afin de permettre cette détermination par le récepteur: rien n’est remonté pour les utilisateurs tant qu’ils ne sont pas diagnostiqués positivement. Même les données envoyées révèlent peu, dans la mesure où elles reviennent à révéler les données générées aléatoirement qui ont servi pour l’envoi des identifiants de proximité en vigueur, sans qu’aucune autre donnée personnelle, notamment d’identification, ne soit impliquée.

Le système revendique de manière crédible d’autres propriétés: il semble par exemple impossible de collecter des information émises par d’autres, pour ensuite faire diffuser que ces autres ont été contaminants en faisant passer ces informations pour siennes (il n’y a pas que les innocents qui seront diagnostiqués positifs au Covid-19, il faut supposer que des adversaires le seront aussi, et en conséquence minimiser leur pouvoir de nuisance).

Cela étant, le système ne garantit pas en soi que seuls les individus diagnostiqués positivement pourront envoyer leurs informations: je vois difficilement comment il pourrait contrôler quoi que ce soit dans ce domaine, il repose donc sur les autorités sanitaires pour effectuer ce filtrage.

Cela est manifeste dans le troisième et dernier document, qui décrit l’API qu’une application (ici pour appareil Apple sous iOS) devra utiliser pour servir d’interface au service. L’API gère en coulisses tout ce qui est protocole Bluetooth et stockage des données, mais ne s’occupe d’aucune interaction réseau, l’application devant effectuer ces tâches elle-même: une partie des fonctions de l’API consiste à se faire fournir explicitement ces données, ou fournir les données devant être envoyées; c’est plus explicite dans le documentation d’API pour appareil Google sous OS Android, qui décrit par ailleurs la même API, langage Java mis à part, Android oblige.

Mis à part cela, l’API en général ne présente pas de surprise: c’est de l’Objective-C moderne, avec des blocs utilisés pour que l’application puisse se faire rappeler une fois le traitement des données complété par exemple. Elle semble bien couvrir les modes d’utilisation des futures applications: une classe ENManager pour les interactions avec le système en général comme afficher le statut (autorisé ou pas, principalement) et récupérer les données à envoyer au serveur en cas de diagnostic, et une classe ENExposureDetectionSession à utiliser au moment de vérifier si la dernière fournée d’informations de diagnostic ne déclencherait pas une exposition lorsqu’on les combine avec les données enregistrées en interne. La seule surprise étant l’Objective-C: on se serait plutôt attendu à du Swift vu comme le langage est à la mode chez Apple, mais cela ne change pas la fonctionnalité de l’interface, il est même probable qu’elle puisse être utilisée directement depuis Swift.

L’API révèle une dernière fonctionnalité intéressante, qui est la possibilité de déclarer son risque au système en cas de suspicion de contamination, avant même le diagnostic formel, afin d’avertir en cascade les contacts; avec une intensité moindre, bien entendu. Cela devra tout de même passer par les autorités sanitaires, reste à voir ce qu’elles vont en faire.

Le système d’Apple et Google: les non-dits

Comme on le voit, si la documentation du système mentionne le rôle du serveur, elle reste muette sur combien existent, comment il sera géré ou ils seront gérés, et par qui. Multiplier les serveur serait dommageable dans la mesure où cela obligerait à installer autant d’applications qu’il y aurait de serveurs en vigueur pour bénéficier d’une couverture correcte (tant pour pouvoir récupérer les informations diffusées par chacun de ces serveurs, que pour pouvoir envoyer à chacun de ces serveurs le cas échéant); cela pourrait être acceptable (mais on pourrait s’en dispenser) dans des cas particuliers, comme les travailleurs transfrontaliers, c’est par contre complètement inacceptable pour l’utilisateur moyen.

Les deux compagnies ont indiqué l’intention de sévèrement restreindre l’accès à ces API: je cite leur document commun regroupant les réponses au questions fréquemment posées:

10. Comment les applications obtiendront-elles l’autorisation d’accéder à ce système?

Les applications recevront cette autorisation selon un ensemble déterminé de critères choisis pour s’assurer qu’elles ne seront administrées qu’en relation avec les autorités de santé publiques, atteignent nos exigences de protection de la vie privée, et protègent les données utilisateur.

Ces critères sont spécifiés séparément dans des accords que les développeurs ont à accepter afin d’utiliser les API, et sont organisés autour des principes de fonctionnalité et de protection de la vie privée. Il existera des restrictions sur les données que les applications seront en mesure de collecter lorsqu’elles utiliseront l’API, y compris l’impossibilité d’accéder aux services de localisation, ainsi que des limitations sur l’usage qui pourra être fait des données.

Apple en particulier dispose de mesures de contraintes pour que cela soit appliqué: non seulement une application en général ne peut être distribuée (au-delà d’une poignée d’exemplaires) sans leur aval, mais il est certain qu’une permission pour accéder au service depuis le sandbox (« bas à sable » qui héberge les applications dans iOS, restreignant leur accès au système d’exploitation aux services nécessaires hors passe-droit, reconnu uniquement si signé par Apple) sera nécessaire, avec fort peu d’entités pouvant éventuellement y prétendre (étatiques, principalement); désolé pour ceux qui voudraient jouer avec: com.apple.developer.exposure-notification sera la permission distribuée de manière la plus restrictive de toutes celles disponibles pour l’iPhone… Il y a fort à parier qu’Apple n’hésitera aucunement à invalider une permission qui aurait fuité ou aurait été abusée.

Vu la position d’arbitre d’au moins Apple, l’absence de régle ou même de recommandation sur la multiplication des serveurs m’interroge, donc. Je peux concevoir que ni Apple ni Google ne souhaitent s’exposer plus encore à des accusations de se placer au-dessus des états, mais il serait souhaitable d’avoir confirmation que pas plus d’un serveur ne serait autorisé par pays (défini comme une entité disposant de représentations diplomatiques ou assimilées), sans que cela obère la capacité de chaque pays a avoir plusieurs applications selon les besoins, tant que celles-ci se basent sur le serveur national. J’espère bien sûr que l’UE mettra en place un serveur commun que tous les pays adopteront, et idéalement il en faudrait un seul par continent, mais il semble difficile de désigner pour chaque continent l’entité politique qui pourrait prendre cela en charge (quant à avoir un serveur mondial, si cela était viable tant politiquement que techniquement, Apple et Google s’en seraient déjà chargés).

De plus, la documentation mentionne une deuxième phase où le système pourra être activé « de base » par le système d’exploitation sans aucune application installée, avec suggestion d’installer une des application si le système détermine un contact potentiellement contaminant; or si le système « de base » peut déterminer cela, ça implique la récupération de données depuis un serveur sans qu’une appli n’ait été installée, alors lequel est utilisé?

Et sinon, aucune précision sur le rôle des autorités de santé pour s’assurer de la fiabilité des informations diffusées par leur serveur. Je pense à un incident qui m’a été rapporté lorsque je travaillais dans les télécoms: les réseaux de communications sans fil pour policiers et pompiers ont une fonctionnalité « appel de détresse » que ces clients prennent très au sérieux, on peut comprendre pourquoi. En pratique, c’est un appel vocal, mais avec un drapeau qui déclenche certains traitements spécifiques (de priorité notamment) et soulève des alarmes un peu partout. Et lors d’une première interconnexion avec le système du district venant d’un concurrent, tout ne s’est pas passé comme prévu. En effet, même si la norme d’interconnexion précisait comment faire passer l’information qu’un appel était de détresse, elle laissait beaucoup de liberté sur comment prendre en compte cette information; et il s’avère qu’au moins un des deux systèmes considérait le statut détresse comme sufisamment important pour qu’il doive être mémorisé pour le canal en question, jusqu’à ce que ce statut soit explicitement levé par un superviseur. Ce qui n’est pas absurde en soi, mais si le canal appartient à l’autre système en interconnexion, celui-ci n’ayant pas la même configuration n’envoyait jamais une telle confirmation, de sorte que le canal était dorénavant considéré comme étant perpétuellement en détresse, même pour les appels ordinaires. Assez rapidement, tous les canaux dans ce cas ont fini par passer en détresse sans pouvoir les faire redescendre, et lorsque tous les appels sont de détresse, eh bien plus aucun ne l’est. Il a fallu envoyer une correction en urgence.

Il semble donc risqué d’investir des ressources (d’ingénieurie, validation, etc.) dans la mise en place d’un système sans écarter le risque que cela ne soit pour du beurre s’il finit par donner trop de faux positifs pour rester utilisable. Des règles pour assurer la fiabilité des informations diffusées par le ou les serveurs me semblent indispensables.

Enfin, pour rester dans la question géographique, un risque (soulevé par Moxie Marlinspike) est que la base de données à télécharger pourrait devenir trop grosse (en particulier en cas de reprise de l’épidémie) pour être pratique à télécharger, de sorte qu’il faille la partitionner selon la localisation… et réintroduire de la géolocalisation pour ce faire, ruinant une partie des garanties offertes. Comme pour la multiplication des serveurs, je pense que c’est quelque chose au sujet duquel Apple et Google doivent déclarer leurs intentions.

La confrontation

StopCovid, comme de nombreux autres projets, a été démarré avant la publication de l’initiative d’Apple et Google; le projet est parti sur des principes différents, ce que je respecte en soi; le protocole, appelé ROBERT, est documenté. Le choix a notamment été fait d’une architecture où la détermination de contamination est centralisée, avec les avantages et inconvénients que cela comporte, je ne reviendrai pas dessus.

Déjà, comme pour la question de la multiplication des serveurs, on peut se poser la question de la multiplication des protocoles: faudra-t’il que tout un chacun s’équipe d’une application pour chaque protocole? Mais ce n’est pas là où le bat blesse dans l’immédiat: le protocole ROBERT utilisant, comme attendu, Bluetooth, son implémentation sur iPhone rencontre des restrictions établies de longue date par Apple sur les possibilités d’utilisation du Bluetooth par une application non-active; ces restrictions sont documentées par Apple, même si de manière peu précise; je ne doute pas que la projet ait pu les mesurer par lui-même. Elles ont pour objet la préservation de la batterie et la protection de la vie privée. Elles réduisent drastiquement la viabilité de la solution.

Technologiquement, il était important d’essayer, ne serait-ce que pour être crédible et ne pas dépendre d’un partenaire qui aurait été choisi faute d’alternative. Le projet StopCovid, notamment par les expérimentations de mesure (approximative) de distance par Bluetooth, a déjà accompli des avancées qui serviront plus généralement, et en tant que projet il pourrait continuer dans le cadre d’un protocole plus général, l’adoption d’un autre protocole ne signifiant pas la fin du projet.

Parce que soyons clairs: les médias parlent de systèmes qui pourraient être « rendus compatibles », mais la seule manière que je connaisse de faire communiquer deux systèmes, c’est qu’ils implémentent le même protocole. Il peut s’agir de deux implémentations différentes, mais il doit s’agir du même protocole.

Car le choix que vous avez fait, devant l’existence de ces restrictions qui ne sont pas nouvelles, est celui de la confrontation avec Apple: vous vous étonnez qu’Apple ne lève pas ces restrictions à la demande, et vous insistez pour que le projet puisse arriver en production selon ses principes actuels, invoquant une question de souveraineté technologique.

Une telle confrontation est futile et même nuisible, et ce pour au moins deux raisons.

Futile dans l’immédiat

Au-delà de ces restrictions, Apple a plus généralement établi le pricipe qu’ils contrôlent les logiciels pouvant être distribués sur les appareils mobiles de leur marque. Au fil des années ce contrôle m’a de moins en moins plu, de sorte que je cherche des alternatives, notamment par le web, pour distribuer mon travail personnel. Cela devient viable pour certaines applications, comme le traitement de fichiers, mais dans le cas du Bluetooth il n’y a pas d’alternative au SDK « natif ».

Donc même si j’objecte moi-même à certaines des politiques d’Apple, croyez-vous sérieusement qu’après qu’ils aient passé 12 ans à avoir dicté leurs conditions comme ils l’entendaient pour les logiciels iPhone, sans exception, à part celles dont ils ont eux-même défini les termes (il en existe quelques autres, moins documentées), vous alliez pouvoir les convaincre ou leur forcer la main si rapidement? C’est illusoire.

C’est d’autant plus illusoire que dans d’autres situations où ils étaient autrement plus exposés (je pense notamment à une requète de déchiffrage venant du FBI), Apple a résisté aux pressions visant à les faire céder, et ils en étaient fiers et le sont toujours. C’est entre autres une question de fierté profesionnelle, tant pour ce qui est de la préservation de la batterie que la protction de la vie privée. Croyez-vous que des mouvements de menton vont suffire à leur faire changer d’avis?

Si encore vous vous prévaliez d’arguments, comme les avantages potentiels d’une solution centralisée comme ROBERT sur la protection de la vie privée face à leur solution, c’est quelque chose à laquelle ils pourraient être sensibles. Mais non, il n’est question que de dénoncer leur santé financière (insolente certes, mais quel est le rapport?) ou de souveraineté technologique.

Vous pourriez obtenir gain de cause par l’une ou l’autre contrainte légale, mais il est certain que cela prendra du temps, beaucoup de temps. Défendre la souveraineté technologique de la France pourrait donc avoir du sens… dans d’autres circonstances. Car je ne sais pas si vous avez remarqué, mais il y a une pandémie qui touche actuellement la France. Et la France ne pourra s’en débarasser à terme qu’en ayant l’immunité collective; et je ne sais pas vous, mais je préfèrerais l’acquérir moi-même par un vaccin éventuel, ou le plus tard possible le cas échéant. Or le temps que vous contraigniez Apple par la voie légale, je pense que le vaccin aura été trouvé.

Votre insistance sur la souveraineté technologique m’indique donc que faire valoir celle-ci dès maintenant est pour vous un objectif plus important que d’avoir une solution efficace de suivi des contacts, susceptible de sauver des vies. Ces priorités sont dans le désordre. La souveraineté technologique est importante, mais il sera toujours temps de la faire valoir plus tard, ou autrement.

Il est peut-être injuste que Apple dicte ainsi ses termes. Il devrait peut-être en être autrement. Mais en attendant, là, ici, et maintenant, ils ont les clés du système.

Futile à terme

Supposons maintenant qu’Apple vous donne les clés. Vos ennuis ne sont pas finis. Car les raisons pour lesquelles ils avaient posés ces restrictions à la base n’ont pas disparu, notamment la préservation de la batterie.

Donc, qu’est-ce fera que votre solution ne va pas drainer trop rapidement la batterie? En particulier, il vous sera difficle de trouver des compétences sur le marché des développeurs pour ce qui est d’utiliser raisonnablement le Bluetooth une fois ces restrictions levées: même ceux qui le font déjà sur Android pourront avoir des surprises une fois sur iPhone.

C’est particulièrement important parce que des iPhones restent en activité beaucoup plus lontemps que les appareils Android, avec souvent donc une batterie dégradée. Je n’ai moi-même toujours pas remplacé mon iPhone 5S d’il y a plus de 6 ans qui fonctionne très bien, sauf que son autonomie n’est plus ce qu’elle était, et je pense ne pas être le seul. La question n’est pas juste que je devrai faire plus attention à ma batterie une fois StopCovid installé; la question est comment le public va réagir à une application qui, après installation, va drainer plus rapidement sa batterie, pouvant conduire à son épuisement s’il n’y prend pas garde? Une partie au moins va désactiver l’application. Et on n’avait pas dit qu’une pénétration suffisante était importante pour que le système fonctionne?

Encore une fois, la situation existante compte, et la situation existante est que Apple continue à entretenir de nombreux appareils dans la nature que d’autres considèreraient obsolètes (mais qui sont équipés du Bluetooth Low Energy), et tout changement dans cet équilibre se remarquera. Voulez-vous par exemple vous exposer à des accusations de vouloir encourager le renouvellement prématuré, lorsqu’on s’apercevra du drain de la batterie induit par StopCovid, susceptible de contraindre à un renouvellement d’un matériel auparavant plus fonctionnel?

Vous pourrez me dire qu’Apple eux-mêmes risque de susciter aussi un drain augmenté de la batterie avec l’implémentation de leur système. C’est possible, mais je leur fais plus confiance dans ce domaine qu’aux développeurs de StopCovid, sans vouloir les offenser.

Conclusion

Je refuse la fausse alternative proposée par certains commentateurs, qui voudraient réduire la choix à l’entité à laquelle on accepte de se confier. Avec le bon protocole, la bonne architecture, on peut éviter de devoir faire confiance à quelqu’un plus qu’on le voudrait et concilier des exigence apparemment opposées.

L’Allemagne, après avoir commencé de son côté, a annoncé rejoindre le système de Apple et Google, mais cela ne l’empêchera pas de proposer son application sur la base de ce système. Qu’est-ce qui empêche la France de faire de même? Il est de l’intérêt général d’éviter la balkanisation des solutions, et la France n’est pas ici en position de force.

Leave a Reply

Name *
Email *
Website