Les trois erreurs qui plombent l’application StopCovid  

Approuvée par l’Assemblée nationale, l’application StopCovid devrait être disponible dès le 2 juin. Mais chaque jour s’alimente la chronique d’un fiasco annoncé, et il y a fort à parier que bien peu de Français, au départ favorables à l’initiative, installeront StopCovid sur leur smartphone — pour autant que l’application fonctionne… Comment un projet au départ tout à fait louable — armer la stratégie de déconfinement « test and trace » d’un bras numérique — s’est-il, en quelques semaines seulement, écrasé en rase campagne alors que tous les feux étaient au vert et que, chez nos voisins, des applications similaires ont été déployées sans difficulté ?

Retour sur les trois erreurs majeures qui plombent StopCovid.

Première erreur : le « design par comité » #

Si vous voulez offrir un enterrement de première classe à un projet, confiez son pilotage à un comité suffisamment étendu, et la nature humaine fera le reste. C’est la première erreur, en forme de pêché originel : « Officiellement, le gouvernement avance sur un projet piloté par l’institut de recherche publique Inria, en lien avec le comité Care nommé par l’Élysée pour faire face à l’épidémie. La Direction interministérielle du numérique (Dinum) et l’Agence nationale de sécurité informatique (Anssi) s’attellent au codage et à la protection de la future application, parfois en écoutant quelques start-up. Par exemple, Unspread (une émanation de l’agence Fabernovel) a fait des propositions sur le design de l’application. »

À cette ribambelle d’instituts, de comités, de commissions et d’agences s’ajoutent les inévitables usual suspects chargés d’apporter leurs bras et leur expertise au développement de StopCovid : Orange, CapGemini, Dassault Systèmes, Sopra-Steria et Sia Partners.

Un couple constitué d’une seule de ces émanations de l’État et d’un acteur privé unique aurait sans doute pu « sortir » un projet d’application en quelques semaines voire quelques jours. Mais, pour des raisons qu’on imagine plus politiques que techniques, on a préféré embarquer tout le monde, ou presque. Cela fait beaucoup de participants autour de la table pour un projet assez limité et surtout très urgent.

Outre la lenteur qu’elle induit dans les prises de décision, les risques de cette approche, caricaturée sous le nom de « design par comité », sont bien connus : choix techniques contre-productifs, déresponsabilisation à tous les étages et quasi-impossibilité de changer son fusil d’épaule en cas de pépin, façon Titanic à l’approche de l’iceberg.

Comme on va le voir, s’agissant de StopCovid, ils se sont tous réalisés.

Deuxième erreur : l’entêtement dans un mauvais choix d’architecture #

Dans une déclaration surprenante, le secrétaire d’État chargé du numérique, Cédric O, a révélé la deuxième erreur, celle qui plombe certainement le plus StopCovid : « Apple aurait pu nous aider à faire en sorte que cela marche encore mieux sur les iPhones. Ils n’ont pas souhaité le faire, pour une raison d’ailleurs que je ne m’explique guère, a commenté le ministre. Qu’une grande entreprise qui ne s’est jamais aussi bien portée en termes économiques n’aide pas un gouvernement à lutter contre la crise, il faudra s’en souvenir le moment venu. »

Pour comprendre de quoi il retourne, il faut revenir un instant aux fondamentaux de l’informatique. Tout système d’information, qu’il s’agisse du réseau informatique d’une PME, d’une application mobile ou d’un traitement massif de données de santé, repose sur ce que l’on appelle une architecture. Ce terme n’est pas emprunté par hasard au monde de la construction : comme pour la conception d’un édifice, le premier et le plus important des choix à effectuer est celui de l’ossature du système. En matière informatique, deux grands modes d’organisation sont envisageables : une architecture centralisée, dans laquelle les données transitent par un serveur central, qui réalise lui-même les traitements ; ou bien une architecture décentralisée, c’est-à-dire sans serveur central, dans laquelle les données sont directement traitées sur les terminaux des utilisateurs (ici, nos téléphones mobiles).

Chaque type d’architecture présente des avantages et des inconvénients. Parce que les données sont stockées sur un serveur « maître », une architecture centralisée permet théoriquement de réaliser des traitements plus riches qu’une architecture décentralisée. Mais, pour la même raison, les architectures décentralisées sont considérées comme plus sûres que les architectures centralisées : lorsque les données ne sont pas réunies en un même lieu mais dispersées sur des milliers voire des millions de terminaux, même le plus chevronné des pirates aura du mal à mettre la main sur la base tout entière.

Dans le cas de StopCovid, Cédric O a annoncé que la France privilégierait une architecture centralisée, mieux adaptée selon lui aux finalités du contact tracing et aux impératifs de la souveraineté numérique française.

Ce choix s’est rapidement révélé catastrophique : d’une part parce qu’il a placé la France en ultra-minorité parmi ses partenaires européens, écartant ainsi toute perspective d’interopérabilité ; d’autre part et surtout parce qu’il ne correspond pas à l’option prise par Apple et Google, qui ont joint leurs forces pour fournir gratuitement aux États un kit de contact tracing « clés en main » (une « API » dans le jargon informatique) reposant, pour les raisons de sécurité exposées plus haut, sur une architecture… décentralisée.

À ce stade de la compétition, la France aurait pu faire œuvre de pragmatisme, abandonner ses plans centralistes, et rentrer dans le rang européen. StopCovid serait opérationnelle depuis au moins une semaine, et tous les doutes auraient été levés sur son niveau de sécurité.

Mais, peut-être parce que les parties prenantes étaient trop nombreuses et que personne n’avait franchement envie de réviser sa copie ( cf. première erreur) ; peut-être aussi, et c’est moins avouable encore, par un soupçon de chauvinisme ( cf. troisième erreur, nous y reviendrons), la France s’est arcboutée sur sa position, fustigeant Apple (mais pas Google, bizarrement) pour son refus d’aménager, pour l’État français et lui seul, une voie royale et unique au monde vers le contenu intime des iPhones.

Troisième erreur : une communication d’un autre temps #

Quand bien même StopCovid devait sortir de l’ornière, de moins en moins de Français risquent de l’installer sur leur mobile. La troisième erreur relève de la communication : « En fait, il n’y a même pas de données : personne n’aura accès à qui est contaminé, et personne ne sera capable de retracer qui a contaminé qui. »

Deux ans presque jour pour jour après l’entrée en vigueur du RGPD, experts et régulateurs débattent encore des qualités et des défauts du fameux règlement européen sur la protection des données personnelles : est-il trop ou pas assez contraignant ? facile ou difficile à interpréter ? bien ou mal adapté aux futurs défis de l’intelligence artificielle, etc. Il y a un point, en revanche, sur lequel tous s’accordent : le RGPD a consacré la protection des données personnelles comme enjeu de société.

En Europe, aux États-Unis et même en Asie, les piratages de données personnelles, les failles de sécurité ou encore les pratiques peu recommandables de certaines plateformes ne passent plus comme des lettres à la poste. Les citoyens ont pris conscience que leurs données font partie de leur patrimoine, qu’elles ont une valeur, et ils demandent des garanties quant à leur protection.

De la part de Cédric O, dire « il n’y aura même pas de données » est une erreur de communication majeure, non seulement parce que c’est faux, mais surtout parce que personne, pas seulement les spécialistes, ne peut y croire une seconde. Bien sûr qu’il « y aura des données », et c’est tout à fait normal ; la question est de savoir lesquelles, et comment elles seront protégées. Et là : « On a demandé à des communautés de hackers d’attaquer pour tester la robustesse. Personne n’a réussi à cracker le système. »

En plus de créer de la défiance, cette stratégie de communication, appliquée ci-dessus par Stéphane Richard, sonne comme un défi lancé à une population qui ne vit que de cela : les pirates informatiques. Ce n’est pas la meilleure idée lorsqu’on a fait le choix d’une architecture centralisée et donc plus perméable, par définition, aux piratages.

Conclusion : à quelques jours de sa date de lancement, non seulement les doutes subsistent sur la sécurité des choix techniques opérés et sur l’utilisation qui sera faite des données, mais personne n’est capable de dire si et comment StopCovid fonctionnera sur nos smartphones. Pas étonnant que de moins en moins de Français envisagent de l’utiliser…

Considérée individuellement, chacune de ces trois erreurs — design par comité, entêtement dans des choix intenables, communication ratée — s’explique, se justifie et aurait même pu être surmontée. Mais prises ensemble, elles ont toutes les chances d’expédier StopCovid au cimetière des fiascos technologiques français. Quel gâchis !