Comment fonctionne la Corona-Warn-App
Elle peut vous avertir que vous vous teniez près de quelqu'un déclaré positif ensuite, sans qu'aucun serveur n'apprenne jamais que vous vous teniez près de qui que ce soit. Voici l'architecture qui permet les deux, et pourquoi le code est public.

- Auteur
- Publié
- Temps de lecture
- 4min
- Série
- Logiciels de pandémie Partie 2 sur 5
Le 16 juin 2020, l'Allemagne a publié la Corona-Warn-App, son application officielle de traçage des contacts. En 24 heures, elle avait été téléchargée des millions de fois, ce qui en fait l'une des applications publiques les plus vite adoptées de l'histoire européenne.
En tant qu'éditeur ayant un pied sur le marché allemand, nous avons suivi son développement de près — par curiosité professionnelle, et parce que c'est un cas d'école sur la manière de livrer une application sensible aux données personnelles sous une attention publique énorme. Voici ce que fait l'application, comment elle fonctionne, et pourquoi les choix d'architecture comptent.
Ce que fait la Corona-Warn-App
Le but est simple : si vous avez passé un temps significatif près de quelqu'un qui se révèle ensuite positif au SARS-CoV-2, l'application vous prévient afin que vous puissiez vous faire tester et vous isoler avant d'en contaminer d'autres sans le savoir.
La difficulté est d'y parvenir sans constituer une base centrale de qui a croisé qui.
L'architecture : décentralisée par conception
L'Allemagne a d'abord envisagé un modèle centralisé, où les données de rencontre auraient été envoyées sur un serveur public. Après un débat public impliquant des chercheurs en vie privée, le gouvernement fédéral a basculé en avril 2020 vers une approche décentralisée fondée sur le cadre Exposure Notification d'Apple et de Google. C'est la décision la plus importante concernant cette application.
Le déroulé, en clair :
- Votre téléphone diffuse des identifiants aléatoires. Via Bluetooth basse consommation, l'application émet des identifiants éphémères, générés au hasard, qui changent toutes les quelques minutes. Ils ne contiennent aucune donnée personnelle.
- Votre téléphone note les identifiants qu'il entend. Les téléphones proches équipés de l'application conservent localement les identifiants aléatoires des autres, avec la puissance du signal et la durée, pendant 14 jours.
- Un test positif est vérifié. Si vous êtes positif, vous pouvez partager votre résultat dans l'application. Une étape de vérification — un QR code du laboratoire, ou un code reçu par téléphone — garantit que seuls de vrais résultats sont transmis.
- Seules vos clés quittent votre téléphone. L'application envoie les clés dont vos identifiants aléatoires récents ont été dérivés. Aucune localisation, aucun carnet d'adresses, aucun nom.
- Chaque téléphone vérifie localement. Chaque application télécharge régulièrement la liste des clés publiées et la compare aux identifiants qu'elle a enregistrés. La comparaison se fait sur votre appareil, pas sur un serveur.
- Le risque est calculé sur votre appareil. À partir de la proximité et de la durée, l'application estime votre risque d'exposition et affiche une alerte si un seuil est franchi.
Le serveur n'apprend jamais qui a croisé qui. C'est tout l'objet.
Pourquoi le code ouvert compte
SAP et Deutsche Telekom ont bâti l'application pour le compte de l'État fédéral, et l'intégralité du code source — applications mobiles, backend, serveur de vérification — a été publiée sur GitHub avant le lancement.
Pour un développeur, c'est remarquable. Des milliers de personnes ont relu le code, signalé des problèmes et proposé des correctifs avant que le public ne l'installe. Pour le public, cela signifiait que les promesses de confidentialité étaient vérifiables plutôt que crues sur parole. L'adoption d'une application facultative repose sur la confiance, et le code ouvert est la façon la plus crédible de la mériter.
Des limites qu'il faut connaître
L'application n'est pas une solution miracle.
- Le Bluetooth est une approximation, pas une mesure. La puissance du signal à travers un mur ou un sac est imprécise, d'où des faux positifs comme des faux négatifs.
- Il lui faut de l'adoption. Le bénéfice croît avec le carré du nombre d'utilisateurs ; une alerte ne part que si les deux personnes utilisent l'application.
- Les résultats de test doivent être raccordés. Un résultat positif n'aide que si le laboratoire ou le centre peut le déposer dans l'application avec un QR code vérifié — ce qui demande un travail d'intégration côté laboratoire. Nous nous attendons à ce que cela devienne un sujet majeur à mesure que le dépistage monte en charge.
Ce que les équipes logicielles peuvent en retenir
Trois leçons que nous emportons dans nos propres projets :
- La confidentialité est un choix d'architecture, pas un document de politique. Le modèle décentralisé rend le détournement techniquement impossible plutôt que simplement interdit.
- La transparence bat le marketing. Publier le code a fait plus pour l'adoption qu'aucune campagne n'aurait pu.
- C'est à l'intégration que se joue le logiciel de santé publique. L'application ne vaut que ce que valent les flux de données qui l'alimentent.
Nous reviendrons sur ce dernier point. Chez Daleenda, nous regardons déjà ce qu'il faudrait pour que les structures de dépistage se branchent sur cet écosystème — et la réponse est que l'outillage n'existe pratiquement pas encore.
Sur cette page
Où cela laisse-t-il votre système ?
Un article peut expliquer comment quelque chose fonctionne ; il ne peut pas dire ce que cela signifie pour le système que vous exploitez déjà. Trente minutes avec un ingénieur, pas un commercial, et pas de séquence de relance.
