Ceci est une version HTML d'une pièce jointe à la demande d'accès à l'information 'AIPD des outils numériques de lutte contre la COVID'.

link to page 2 link to page 2 link to page 5 link to page 9 link to page 9 link to page 9 link to page 10 link to page 11 link to page 11 link to page 12 link to page 12 link to page 12 link to page 12 link to page 13 link to page 15 link to page 16 link to page 16 link to page 22 link to page 24 link to page 25  
 
 
 
 
 

AIPD de l’Application 
TousAntiCovid 
 
Version mise à jour le 9 septembre 2021  
 
 
 
 
1 
CONTEXTE .................................................................................................................................................................................. 2 
1.1  VUE D'ENSEMBLE ....................................................................................................................................................................... 2 
1.2  DONNÉES, PROCESSUS ET SUPPORTS............................................................................................................................................ 5 
2 
HISTORIQUE DES EVOLUTIONS MAJEURES ....................................................................................................................... 9 
2.1  JUIN 2020 ................................................................................................................................................................................. 9 
2.2  SEPTEMBRE 2020...................................................................................................................................................................... 9 
2.3  NOVEMBRE 2020 .................................................................................................................................................................... 10 
2.4  DECEMBRE 2020..................................................................................................................................................................... 11 
2.5  MAI 2021 ............................................................................................................................................................................... 11 
2.6  JUIN 2021 ............................................................................................................................................................................... 12 
2.7  SEPTEMBRE 2021.................................................................................................................................................................... 12 
3 
PRINCIPES FONDAMENTAUX ............................................................................................................................................. 12 
3.1  REMARQUES LIMINAIRES .......................................................................................................................................................... 12 
3.2  PROPORTIONNALITÉ ET NÉCESSITÉ ........................................................................................................................................... 13 
3.3  MESURES PROTECTRICES DES DROITS........................................................................................................................................ 15 
4 
RISQUES ................................................................................................................................................................................... 16 
4.1  MESURES EXISTANTES OU PRÉVUES........................................................................................................................................... 16 
4.2  ACCÈS ILLÉGITIME À DES DONNÉES ........................................................................................................................................... 22 
4.3  MODIFICATION NON DÉSIRÉES DE DONNÉES .............................................................................................................................. 24 
4.4  DISPARITION DE DONNÉES ........................................................................................................................................................ 25 
 
 
 
AIPD - TousAntiCovid 
 

 

link to page 2 link to page 2 link to page 2  
 
 
 
 
1  Contexte 
1.1  Vue d'ensemble 
1.1.1  Quel est le traitement qui fait l'objet de l'étude ? 
L’AIPD  porte sur l'application TousAntiCovid de « suivi de contacts » (ou « contact tracing ») dont  la responsabilité du 
développement d’une version prototype a été confiée le 8 avril 2020 à Inria par le Gouvernement, sous la supervision du Ministère 
des Solidarités et de la Santé et du Secrétariat d’État au numérique. 
 
Dans ce contexte, le projet StopCovid (développement, modèle, diffusion) a été rendu public le 26 avril 2020  :  il  rassemble des 
acteurs publics (Inria, ANSSI, Inserm, Santé Publique France) et privés (Capgemini, Dassault Systèmes, Lunabee Studio 
Orange, Withings) ainsi qu’un écosystème de contributeurs.  
Le 22 octobre 2020, il  a été décidé de remplacer l’application StopCovid par une nouvelle application baptisée TousAntiCovid 
dont le mode de fonctionnement est assez similaire à StopCovid mais pour laquelle des améliorations, en terme d’information 
et de fonctionnement, ont été apportées. 
 
Comme  le projet s’inscrit dans le cadre d’une stratégie sanitaire globale, le Ministère des Solidarités et de la Santé (MSS) est le 
Responsable de traitement. Du fait de son rôle lors du développement du projet, Inria joue le rôle d’appui à travers un accord-
cadre qui précise son engagement en assistance à la maitrise d’œuvre. 
 
Comme  précisé par la CNIL  dans sa délibération 2020-046 en date du 24 avril 2020,  le traitement serait fondé sur l’exécution 
d’une mission d’intérêt public au sens des articles 6.1.e) du RGPD et 5.5° de la loi  « Informatique et Libertés », dans le cadre 
du plan gouvernemental de lutte contre la pandémie Covid-19. 
 
De nombreuses études épidémiologiques, comme par exemple celles de Christophe Fraser1 à Oxford, montrent l’intérêt pour 
les autorités sanitaires de pouvoir disposer d’applications de « suivi de contacts », en appui au suivi manuel de propagation des 
chaines de transmission.  
 
L’utilisation de telles applications permet en effet de pouvoir alerter, en complément du travail de traçage manuel, avec une 
véritable plus-value envisagée pour d’une part alerter les contacts pseudonymisés, par exemple dans les transports ou dans les 
commerces, et qui représentent un risque non négligeable, et d’autre part, alerter de manière précoce et automatisée les 
contacts, ce qui constitue un gain de temps et de ressources.  
 
Si  le retour d’expériences à partir d’applications déjà déployées ne permet pas à la date de rédaction de cette AIPD d’avoir 
suffisamment de recul sur l’impact des applications de contact tracing dans la gestion de l’épidémie de Covid-19, beaucoup 
d’experts soutiennent l’utilité de cette application dans le cadre de la stratégie de contact tracing.  
 
Les travaux d’un des groupes de travail sur le développement de TousAntiCovid mené par Vittoria Colizza démontrent par le 
biais de simulations numériques l’apport d’une application dès les premiers téléchargements  pour réduire les chaines de 
transmissions. En effet, les résultats des modélisations suggèrent que l’efficacité est faible si l’adoption est limitée, mais elle 
n’est pas nulle, elle sera donc utile même avec une adoption faible.  L’application permettra d’informer de manière précoce les 
personnes ayant été en contact avec une personne diagnostiquée positive (ci-après « contacts à risque ») dès notification du test 
positif par le cas confirmé. Cette précocité et cette réactivité sont essentielles dans le succès de la stratégie d’identification et 
de suivi des contacts puisque la proportion de transmission pré-symptomatique est estimée à 44%. Elle  contribue de ce fait à 
alerter rapidement les individus à la suite d’un contact et de mettre en place plus rapidement les gestes barrières et de les 
informer des conduites à tenir telles que préconisées par le MSS. Les contacts identifiés via l’application TousAntiCovid 
pourront être réintégrés dans le parcours de soins et devront suivre les mesures en termes de dépistage et de quatorzaine telles 
que préconisées par le MSS. 
 
Par ailleurs, le Conseil Scientifique rappelle l’utilité de l’outil numérique comme étant complémentaire et touchant un public 
différent du contact tracing manuel (avis du 20 avril2 et 20  octobre3), et parce qu’elle permet de renforcer l’efficacité du 
contrôle sanitaire de l’épidémie, et également, dans le cadre d’une application interopérable au niveau européen (ce qui est le 
cas de TousAntiCovid), de prendre en considération les cas de transmission transfrontalière. L’Académie de médecine s’est 
également prononcée de manière favorable à l’utilisation d’une application du type TousAntiCovid dans le cadre du 
déconfinement afin de permettre une participation active de la population dans la lutte contre la pandémie tout en respectant 
l’anonymat et la règlementation européenne et nationale du RGPD.  
 
Enfin, l’ECDC  soutient également l’utilisation des application de contact tracing comme outil complémentaire au contact 
tracing manuel puisqu’elle permet d’identifier et d’alerter plus de contacts que via le contact manuel (les contacts inconnus et 
                                              

 Christophe Fraser et al. Modelling  the Covid-19 epidemic and simulating the use  of a contact tracing app in the UK 
2 Sortie progressive de  confinement prérequis et mesures phares : https://solidarites-
sante.gouv.fr/IMG/pdf/avis_conseil_scientifique_20_avril_2020.pdf 
3 Un nouvel ensemble numérique  pour lutter contre le SARS-CoV-2:   https://solidarites-
sante.gouv.fr/IMG/pdf/avis_conseil_scientifique_20_octobre_2020.pdf 
AIPD - TousAntiCovid 
 

 

 
 
 
 
ceux qui sont omis), et permet d’identifier les contacts transfrontaliers. Si l’application ne peut pas remplacer la méthode 
manuelle, pour l’ECDC  il  est également essentiel que les autorités sanitaires soient impliquées dans toutes les étapes de 
développement de l’application et que cette dernière soit utilisée sur une base volontaire. 
 
Les principaux enjeux en matière de respect du RGPD sont de s’appuyer dès la conception de l’application sur l’état de 
l’art des recherches en sécurité et en protection de la vie privée afin de supprimer ou de  réduire au mieux le risque  
  d’identifier les utilisateurs de manière directe ou indirecte ; 
  de les géolocaliser ou tracer leurs parcours ; 
  d’inférer qu'un utilisateur est diagnostiqué ou dépisté positif ; 
  de reconstituer les intéractions sociales ; 
  
Il  est entendu que la réponse à ces enjeux repose sur des hypothèses d’attaque du système qui sont détaillées dans les sections 
4.2, 4.3 et 4.4. 
 
Les finalités du traitement sont : 
1.  D'informer les utilisateurs de l’application qu'il existe un risque qu'ils aient été contaminés par le virus de la Covid-19 
en raison du fait qu'ils se sont trouvés à proximité d'un autre utilisateur de cette application ayant été diagnostiqué 
positif à cette pathologie; 
2.  De sensibiliser utilisateurs de l’application, notamment ceux identifiées comme contacts à risque, sur les symptômes 
de ce virus, les gestes barrières et la conduite à adopter pour lutter contre sa propagation ; 
3.  De recommander aux contacts à risque de s'orienter vers les acteurs de santé compétents aux fins que ceux-ci les 
prennent en charge et leur prescrivent, le cas échéant, un examen de dépistage ; 
4.  De réaliser des analyses statistiques à partir des données issues de l’application afin d’adapter les mesures de gestion 
nécessaires pour faire face à l’épidémie et d’améliorer les performances de l’application ; 
5.  De permettre aux utilisateurs de l’application de stocker des données à caractère personnel sur leur téléphone mobile 
en vue de générer des justificatifs requis par les autorités publiques ; 
6.  D’informer les utilisateurs de l’application sur la situation sanitaire nationale et locale, ainsi que sur des mesures ou 
actions de promotion, de prévention et d’éducation pour la santé ou de les orienter vers des applications ou des sites 
internet mis en œuvre pour la gestion de l’épidémie de la Covid-19 et de leur fournir des informations sur les données 
d’utilisation de l’application ; 
7.  De permettre aux utilisateurs de l’application, sur présentation du statut “contact à risque” dans l’application, de 
bénéficier d’un examen ou test de dépistage dans des conditions de réalisation prioritaire, au même titre que les autres 
personnes à risque d’infection ; 
8.  De permettre aux utilisateurs de l’application de conserver dans le carnet de test numérique les certificats de 
vaccination ou de tests ou ou de rétablissement à la Covid-19 afin que les autorités publiques puissent contrôler ce 
certificat ; 
•  NB :  une AIPD spécifique mais reliée à la présente AIPD a été rédigée pour cette finalité, elle se nomme 
« AIPD TousAntiCovid Pass sanitaire » 
9.  D’informer les utilisateurs de l’application qu’il existe un risque qu’ils aient été contaminés par le virus de la Covid-
19  en raison du fait qu’ils ont fréquenté un lieu dans lequel se trouvait au même moment une personne ayant été 
diagnostiquée ou dépistée positive à la Covid-19. ; 
•  NB :  une AIPD spécifique mais reliée à la présente AIPD a été rédigée pour cette finalité, elle se nomme 
« AIPD du module Signal de TousAntiCovid » 
 
L’application TousAntiCovid est installée librement et gratuitement par un  utilisateur. Il appartient à l’utilisateur 
d’activer ou non la fonctionnalité de l’application permettant de constituer un historique de proximité avec d’autres utilisateurs 
de l’application. En cas de résultat positif à un examen de dépistage au Covid-19, l’utilisateur de l’application est libre de 
notifier ou non ce résultat dans l’application. L’application peut être désinstallée à tout moment et les données collectées sont 
alors immédiatement détruites. 
 
Le périmètre de  cette AIPD concerne l’application mobile, la partie serveur, ainsi que les moyens de communication.  
Les aspects strictement liés aux structures médicales, comme les comptes rendus de test ne sont pas pris en compte dans cette 
AIPD dans la mesure où ils font l’objet de systèmes distincts et séparés du point de vue des informations.  
 
Nous décrivons pour information la partie mise en place pour délivrer des jetons aléatoires temporaires à usage unique qui seront 
joints aux comptes rendus de test au Covid-19 délivrés au patient ou qui pourront aussi être délivrés par un médecin à un patient 
suite à un diagnostic clinique au cours d’une consultation dans son cabinet médical, à domicile ou par téléconsultation.  
 
AIPD - TousAntiCovid 
 

 

link to page 4 link to page 4 link to page 4
 
 
 
 
 
 
1.1.2  Quelles sont les responsabilités liées au traitement ? 
A compter du 7 avril 2020,  le  Gouvernement français a confié à  Inria  le  pilotage opérationnel du projet de recherche et 
développement baptisé « TousAntiCovid » qui réunit l’expertise d’acteurs nationaux, publics comme privés, au sein de cette 
équipe-projet TousAntiCovid qui rassemble : Inria, l’ANSSI, Capgemini, Dassault Systèmes, l’Inserm, Lunabee Studio, Orange, 
Santé Publique France et Withings. 
L’ensemble de ces acteurs contribue aux travaux déjà engagés pour mettre à disposition de tous les Français un outil 
permettant de mieux les protéger contre le Covid-19, dans l’éventualité où une décision politique serait prise pour autoriser le 
déploiement effectif du système. 
 
La Direction Générale de la Santé (DGS) du Ministère des Solidarités et de la Santé (MSS) détermine les finalités et les 
moyens du traitement et est responsable de TousAntiCovid.  
 
Inria exerce un rôle d’appui à la DGS  à travers un accord d’assistance à maitrise d’ouvrage (AMO) de manière à déterminer les 
obligations et rôles respectifs, conformément à l’article 28  du RGPD. 
 
Par ailleurs, un accord de consortium a été signé entre Inria et les acteurs privés du projet StopCovid (renommé en TousAntiCovid) 
afin de préciser les éléments relatifs d’une part à l’exploitation opérationnelle de TousAntiCovid et d’autre part aux projets de 
développement et de R&D afférents. 
 
Les différents niveaux de responsabilité sont les suivants : 
•  Responsable de traitement 
o  La DGS  du Ministère des Solidarités et de la Santé (MSS) 
•  Sous-traitant public / assistance à maitrise d’œuvre (AMO) : 
o  Inria  
•  Sous-traitants privés 
o  3DS Outscale : hébergement de l’infrastructure ; 
o  Inter Mutuelle Assistance (IMA) : assistance téléphonique aux utilisateurs du module Signal et des 
établissements recevant du public et utilisant des QR codes dynamiques ; 
o  In Groupe : éditeur de l’application TousAntiCovid Verif, la plateforme de conversion des certificats du 
format 2D-DOC au format DGC (Digital Covid Certificate) ou International ; 
o  Inter Mutuelle Assistance (IMA) : assistance téléphonique sur l’application TousAntiCovid ; 
o  Lunabee : développement de l’application TouAntiCovid ; 
o  Orange : maintenance et exploitation de l’infrastructure ;  
o  Stonly : Foire aux questions4 (FAQ) de l’application TousAntiCovid ; 
o  Reputation squad: Développement du site web de génération des QR codes de lieu6 affichés à l’entrée ou 
dans les lieux ; 
                                              
4 https://tousanticovid.stonly.com 
5 https://www.reputationsquad.com 
6 https://qrcode.tousanticovid.gouv.fr 
AIPD - TousAntiCovid 
 

 

 
 
 
 
•  Destinataires  
o  Les utilisateurs qui  
  sont notifiés  par l’application comme étant à risque d’avoir contracté le Covid-19 sont destinataires 
de l’information selon laquelle ils ont été à proximité d’au moins un autre utilisateur diagnostiqué 
ou dépisté positif au Covid-19 ; 
  génèrent des attestations de déplacement dérogatoire ; 
  obtiennent des informations sanitaires sur les actualités en lien avec la Covid-19 relativement à un 
lieu d’intérêt 
  obtiennent des conseils relatifs à l’isolement 
o  Les autorités publiques auxquelles attestations de déplacement dérogatoire seront présentées ; 
o  Inria en tant que sous-traitant auprès de la DGS  du MSS. 
1.1.3  Quelles sont les personnes concernées 
La population concernée est toute celle qui est couverte par le plan de maitrise de l’épidémie de l’État. L’application n’est qu’un 
outil au service de ce plan, en complément du traçage manuel. 
L’application est téléchargeable sur les stores applicatifs officiels Google et Apple en France. Les taux d’utilisabilité des versions 
des systèmes Android et iOS sont les suivants : 
  Android : 89,5 % des versions d’Android sont supportées (support à partir d’Android 5) 
  iOS : 94% des versions iOS sont supportés (support à partir de iOS 11.5). 
 
Les mineurs sont inclus dans le dispositif. 
  En application du 1 de l'article 8  du règlement (UE) 2016/679  du 27 avril 2016,  un mineur peut consentir seul à un 
traitement de données à caractère personnel en ce qui concerne l'offre directe de services de la société de l'information 
à compter de l'âge de quinze ans. Lorsque le mineur est âgé de moins de quinze ans, le traitement n'est licite que si le 
consentement est donné conjointement par le mineur concerné et le ou les titulaires de l'autorité parentale à l'égard de 
ce mineur. Toutefois, l’article 8.1 du RGPD précise que les dispositions s’appliquent au traitement entrant dans le champ 
de l’article 6.1.e du RGPD,  donc les traitements fondés sur le consentement, ce qui n’est pas le cas en l’espèce puisque 
TousAntiCovid est fondé sur l’exécution d’une mission d’intérêt public. 
  A l’occasion de la première ouverture de l’application, il est proposé à l’utilisateur de cocher une case pour indiquer 
s’il a moins de 15 ans ou non. Sur cette base déclarative,  il sera alors indiqué à ce mineur de moins de 15 ans qu’il doit 
avertir au moins l’un de ses représentants légaux qu’il souhaite utiliser cette application afin que celui-ci y consente. 
Une deuxième case à cocher dans l’application lui sera alors proposée pour s’assurer qu’il a bien eu le consentement 
d’au-moins l’un de ses représentants légaux. 
1.1.4  Quels sont les référentiels applicables ? 
  Référentiel Général de Sécurité (RGS) 
o  Une homologation au RGS de StopCovid (renommé en TousAntiCovid) a été instruite et a été prononcée par 
la DGS du MSS préalablement à la mise en production de StopCovid. 
o  Une nouvelle décision d’homologation a été prononcée en juin 2021 
  PSSI de l’Etat PSSI-E 
  Référentiel SecNumCloud de l’ANSSI pour la partie infra 
  Hébergement de Données de Santé (HDS) 
1.2  Données, processus et supports 
1.2.1  Quelles sont les données traitées ? 
Données traitées pour le support utilisateurs de l’application 
La société IMA est en charge du support utilisateur et traite les mails envoyés par les utilisateurs de TousAntiCovid à 
xxxxxxx@xxxxxxxxxxxxx.xxxx.xx et xxxxxxx@xxxxxxxxx.xxxx.xx ainsi que les appels au 0800 087 148. 
 
Les données traitées par IMA sont hébergées sur le territoire français 
•  les dossiers ouverts lors de la prise en charge des appels sont hébergées et répliquées dans les différents Data-Centre 
d’IMA sur Niort avec une réplication sécurisée complémentaire chez DARVA à Chauray (à côté de Niort). 
•  Les dispositifs pris en charge par la plateforme médico-sociale et le service médical d’IMA sont hébergés chez 
Claranet (certifié HdS) dont le siège est à Londres et les Data-Centres sont basés en France.   
 
Des clauses RGPD ont été signées entre Inria et IMA. 
Données traitées uniquement dans l’application 
•  Pour l'attestation de déplacement  dérogatoire 
o  Prénom, Nom, Date de naissance, Lieu de naissance, Adresse, Ville. Code postal, Date de sortie, Heure de 
sortie, Motif de déplacement, Signature (représentée par le QR code) 
AIPD - TousAntiCovid 
 

 

 
 
 
 
o  Ces informations saisies dans ce générateur d’attestation de déplacement ne font l’objet d’aucun traitement par 
le  Ministère des Solidarités et de la  Santé. Ces données personnelles sont exclusivement stockées dans le 
téléphone mobile de l’utilisateur afin de lui  permettre de remplir  plus aisément la prochaine attestation de 
déplacement dérogatoire. 
•  Pour l’obtention des informations sanitaires sur les actualités en lien avec la Covid-19  relativement à un lieu 
d’intérêt 
o  Le code postal (lieu d’intérêt) saisi par l’utilisateur de l’application 
o  Cette information  
  est stockée dans l’application mais elle est effaçable 
  n’est pas traitée pas le Ministère des Solidarités et de la Santé 
•  Pour l’obtention des conseils relatifs à l’isolement 
o  Le statut Covid-19 sélectionné par l’utilisateur de l’application 
o  La date de début des symptômes 
o  La date de prélèvement positif 
o  La présence de fièvre après 7 jours 
o  La date de dernier contact (pour les personnes contact) 
o  Le partage du foyer avec un cas COVID-19  
o  La date de fin de symptômes du cas malade 
o  La date de fin de symptômes du cas malade (cas index d’une personne contact) 
•  Pour la conservation des certificats de vaccination ou de test ou de rétablissement à la Covid-19 dans le module Carnet 
o  Ces certificats sont issus de Vaccin Covid ou SI-DEP et reprennent le 2D-Doc (ou le DGC  à partir du 21 juin 
2021) imprimé  sur le certificat de vaccination ou de test remis à l'utilisateur. Ces certificats sont enregistrés 
sous la forme d’un certificat numérique (2D-Doc) et contiennent : Prénoms, Nom, Date de naissance, Genre, 
Code du test, Résultat du test, Date du test 
Données traitées sur le serveur Central pour le contact tracing 
  Données générées par le serveur 
o  Une clé d’au moins 128  bits, partagée entre l’application et le  serveur (ci-après clé partagée) qui sert à 
authentifier les messages de l’application ; 
o  Un identifiant de 40 bits (ci-après  identifiant de l’application),  unique pour chaque application qui 
s’enregistre et généré de façon aléatoire. Cet identifiant est seulement connu du serveur ; 
o  Les pseudonymes aléatoires et temporaires (ci-après pseudonymes) de 64  bits que le  serveur envoie à 
l’application à chaque requête journalière de l’application. Ils sont utilisés pour constituer les historiques de 
proximité définis ci-dessous ; 
o  Les codes pays. 
  Données collectées et enregistrées par l’application  sur le téléphone mobile de  l’utilisateur 
o  Les pseudonymes émis via la  technologie Bluetooth par les applications sur des téléphones mobiles à portée 
radio du téléphone mobile de l’utilisateur.  La durée de vie de ces pseudonymes enregistrés est de 14 jours à 
compter de leur première émission. Ces pseudonymes enregistrés, avec leur horodatage d’émission et les 
niveaux de puissance reçue (RSSI), constituent l’historique de proximité qui est stocké dans l’application ; 
  Données stockées sur le serveur 
o  L’historique de proximité des personnes diagnostiquées ou dépistées positives au virus Covid-19 et qui ont 
consenti à envoyer volontairement leur historique de proximité au serveur ; 
o  Le statut “à risque” de l’identifiant de l’application ; 
o  Le statut « à risque d’avoir contracté le virus Covid-19 » de l’identifiant de l’application ;  
o  La date de dernière notification d’un risque d’exposition par le serveur à un utilisateur notifié d’un risque ; 
o  Le device token et la time zone utilisés pour réveiller les applications sous iOS par un serveur d’Apple appelé 
Apple Push notification service (APNs). Le  device token est généré au moment de l’installation de 
l’application sur un iPhone Il est stocké sur le serveur central qui demande au serveur APNs de notifier les 
applications. 
o  Pour la réalisation de statistiques anonymes qui sont de deux types 
AIPD - TousAntiCovid 
 

 

 
 
 
 
  Statistiques liées à l’identifiant de l’application généré lors de l’activation de l’application et dédié à 
la réalisation de ces statistiques 
•  Configuration matérielle et logicielle du téléphone mobile 
•  Configuration de l’application TousAntiCovid 
•  Rubriques consultées par l’utilisateur et informations et documents générés ou ajoutés par 
l’utilisateur 
•  Désactivation des statistiques par l’utilisateur 
  Statistiques sanitaires agrégées du back-end et  liées à un  identifiant à  usage unique généré 
aléatoirement 
•  Niveau de risque Covid de l'utilisateur 
•  Dates de premier symptôme ou de test Covid , de dernier contact 
•  L’utilisateur s’est déclaré Covid+ dans TousAntiCovid 
•  TousAntiCovid a envoyé une alerte Covid à l’utilisateur 
•  Conversion du certificat de test ou de vaccination Covid  
L’information des patients sur le traitement de ces données sera effectuée comme explicité en Annexe 0. Pour simplifier la 
lecture, ces données seront identifiées par les sigles suivants : 
  Acronyme  
Description 
IDA 
Pseudonyme permanent associé à l’utilisateur A. 
KA 
Clef  partagée entre le serveur et l'application de l'utilisateur A. 
EBID 
Pseudonyme temporaire diffusé en Bluetooth. 
EBIDA,i 
Pseudonyme temporaire diffusé en Bluetooth par l’utilisateur A à la période i. 
ECC 
Code de pays chiffré. 
LEE 
Liste des périodes où l'utilisateur A est indiqué comme exposé sur le serveur. 
UNA 
Variable  binaire stockée sur le serveur indiquant si l'utilisateur A a déjà été notifié d'un risque 
d'exposition. 
SREA 
Variable  stockée sur le serveur indiquant quand l'utilisateur A a envoyé la dernière requête pour 
connaître son statut “à risque” au serveur. 
 
Pour information, il est mis à disposition des personnes diagnostiquées positives ou dépistées, en fonction du type de diagnostic 
(laboratoire ou consultation médicale) deux types de jetons, aléatoires, à usage unique qui ne sont en aucun cas stockés sur le 
serveur : 
  Un code aléatoire de 6 caractères alpha numérique qui est un « mot de passe à usage unique » (One Time Password) à 
durée de vie limitée (1 heure) donné par le médecin traitant à son patient suite à un diagnostic clinique positif au Covid-
19  pour qu’il soit autorisé par le serveur à partager son historique de proximité. 
  Un QR  code qui est un « mot de passe à usage unique » (One Time Password) aléatoire, émis par SI-DEP, avec un 
code et un lien « deeplink ». Il est remis à un patient dépisté lorsque ce dernier vient récupérer un compte rendu de 
laboratoire avec un diagnostic positif au Covid-19. Le patient peut alors le scanner afin d’être en mesure d’autoriser le 
partage de son historique de proximité. Ce QR  code n’est lié ni au patient, ni au test, ni au smartphone, il est à voir 
comme un certificat permettant de confirmer un diagnostic positif dans l’application. 
 
L’utilisation d’un de ces jetons par l’utilisateur lui  permet, après avoir donné son consentement, et sa Date de Début des 
Symptômes (DSS), s’il la connait, d’envoyer son historique de proximité au serveur (uniquement les données collectées 2 jours 
avant la DDS). Cette DDS est une donnée locale au téléphone mobile.  
Des statistiques ou KPI (Key Performance Indicator) sont calculées pour suivre l’évolution de l’épidémie et mieux  adapter les 
paramètres de l’application TousAntiCovid. Voici quelques exemples de ces KPI : 
•  Nombre de nouveaux utilisateurs s'étant enregistrés sur le serveur avec succès (si 1 utilisateur = 1 mobile) 
•  Nombre de nouveaux enregistrements ayant échoué. La cause pouvant être une erreur logicielle ou bien une tentative 
hors application mobile mal effectuée 
•  Nombre de nouveaux enregistrements non effectifs dus à un échec du Captcha Orange 
•  Nombre de demandes de statuts d'exposition à une personne s'étant déclarée positive effectuées avec succès 
AIPD - TousAntiCovid 
 

 


 
 
 
 
•  Nombre de demandes de statuts d'exposition à une personne s'étant déclarée positive en échec. La cause pouvant être 
une erreur logicielle ou bien une tentative hors application mobile mal effectuée 
•  Nombre de demandes de statuts d'exposition à une personne s'étant déclarée positive effectuées par un utilisateur non 
authentifié hors application mobile 
•  Nombre d'utilisateurs ayant été exposés à une personne s'étant déclarée positive, jugés à risque mais pas encore notifiés 
 
Le serveur n’est pas en mesure d’initier une connexion vers une application et donc de la contacter. Le serveur n’a pas pour objet 
de réaliser un suivi ou d’identifier les zones dans lesquelles ces personnes se sont déplacées. 
 
Figure 1 - Schéma des flux de  données 
1.2.2  Comment le cycle de vie des données se déroule-t-il (description fonctionnelle) ? 
  Génération par le serveur 
o  D'une clé partagée entre l’application et le serveur qui sert à authentifier les messages de l’application.  
o  D'un identifiant unique pour chaque application qui s’enregistre, généré de façon aléatoire. Cet identifiant est 
seulement connu du serveur. 
o  De pseudonymes : 
  Aléatoires et temporaires : ils ne correspondent à aucun identifiant connu de la personne. 
  Vérifiables : la clé partagée permet d’authentifier les pseudonymes auprès du serveur. 
  Collecte par l’application de l’historique de proximité. Aucune remontée de cet historique vers le serveur n’est 
effectuée tant que l'utilisateur ne se déclare pas positif au sein de l’application suite à un diagnostic. 
 
  Émission périodique des pseudonymes par l’application afin  que ces pseudonymes soient collectés par  les 
applications voisines pour constituer leur historique de proximité. 
 
  Demande  de statut journalière au serveur afin de savoir si des pseudonymes de l’application sont à risque : 
o  Si le serveur répond par l’affirmative 
  Cela implique que le téléphone de l’utilisateur a été à proximité du téléphone d’au moins une personne 
diagnostiquée positive. 
  L'application émet alors une notification à l’utilisateur du téléphone. 
  Si la personne est diagnostiquée positive, envoi au serveur de son historique de proximité après authentification 
donnée par l’autorité de santé et après consentement de la personne. La date de début de symptôme (DDS) lui  sera 
demandée afin de restreindre l’envoi des contacts à 2 jours avant la DDS.   
AIPD - TousAntiCovid 
 

 

link to page 9  
 
 
 
1.2.3  Quels sont les supports des données ? 
Les supports des données associés à chaque étape du cycle de vie des données sont les suivants :  
  Installation de  l’application : téléphone mobile, serveur, Internet ; 
  Collecte des pseudonymes :  téléphone mobile, Bluetooth ;  
  Envoi des pseudonymes au serveur  : téléphone mobile, serveur, Internet 
 
2  Historique des évolutions majeures 
2.1  Juin 2020 
2.1.1  Arrêt de la remontée de l’historique au serveur Central 
Depuis le 26 juin 2020, il est impossible à toutes les applications TousAntiCovid (anciennement StopCovid) de remonter des 
données au serveur central sans le filtre. En effet, la mise à jour vers la version 1.1 est consécutive à toute ouverture de 
l'application, nécessaire si quelqu'un rentre un code lié à un test positif. 
2.1.2  Arrêt de l’utilisation du reCaptcha Google 
Depuis le 26 juin 2020,  les utilisateurs de l’application TousAntiCovid (anciennement StopCovid) téléchargée depuis les 
stores utilisent le Captcha d’Orange et ne peuvent plus s'enregistrer avec reCaptcha de Google 
De plus les appels au webservice reCaptcha de Google ont été désactivés depuis le le 31 aout 2020 
2.2  Septembre 2020 
2.2.1  Réveil des applications sous iOS par un « Push server » 
Jusqu’au 15 septembre 2020, l’application TousAntiCovid (anciennement StopCovid) pour iOS effectuait en background 
(arrière-plan) de manière erratique les requêtes status vers le serveur en cas de non interaction avec l’utilisateur. Ce 
comportement qui n’avait pas été anticipé est lié au mode « background » et aux algorithmes (non connus) de choix d’iOS sur 
la priorisation des applications fonctionnant en « background », comme le fait TousAntiCovid. 
 
Pour rappel, la requête status permet de récupérer de nouveaux pseudonymes et de savoir si l’utilisateur a été à risque depuis le 
dernier status (dont la fréquence d’appel est paramétrable). Son bon fonctionnement est donc essentiel. 
L’évolution consiste à s’appuyer sur une notification push journalière pour que l’application TousAntiCovid pour iOS se fasse 
réveiller de manière fiable, prédictible et puisse, pendant le temps CPU octroyé par iOS effectuer un status au serveur de 
manière certaine. 
 
Apple propose une solution basée sur un serveur de notifications push nommée APNS7 (Apple Push Notification service) pour 
qu’un serveur puisse envoyer une notification push aux applications. 
L’APNS est décrit comme « un service robuste, sécurisé et très efficace permettant aux développeurs d'applications de 
propager des informations vers iOS » .  
 
Les données transmises sont des données techniques et propres à toutes les applications tournant sous iOS.  
Lors du lancement initial de l’application sur le téléphone mobile d'un utilisateur, le système établit automatiquement une 
connexion IP accréditée, chiffrée et persistante entre l’application et les APNS. Cette connexion permet à l’application 
d'effectuer la configuration pour lui permettre de recevoir des notifications de la part du serveur APNS.  
 
L’information en question, nommée « token » ou jeton, est générée par Apple. Ce token est transmis au provider TAC qui est 
alors en mesure de demander à l’APNS de notifier les applications. Aucune autre donnée que ce token n’est envoyée à 
l’APNS. Il  est à noter que l’APNS peut émettre de nouveaux tokens pour différentes raisons :  
• 
L'utilisateur installe son application sur un nouvel appareil ; 
• 
L'utilisateur restaure le dispositif à partir d'une sauvegarde ; 
• 
L'utilisateur réinstalle le système d'exploitation ; 
• 
Autres événements définis par le système 
 
L’architecture technique réalisée est la suivante : 
 
                                              

https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//
apple_ref/doc/uid/TP40008194-CH8-SW1 
 
AIPD - TousAntiCovid 
 

 

link to page 10 link to page 10
 
 
 
 
 
Figure 2 – Architecture Push Server 
 
Cette solution s’appuie sur les webservices existants (registerstatus et unregister) dans lesquels l’application TousAntiCovid 
iOS  fournit en plus un device token qui correspond à un token de l’application sur cet iPhone, génèré par iOS et Apple Push 
notification service (APNs) au moment de l’installation de l’application. Le device token est une suite de caractères permettant 
à Apple d’identifier une application mobile sur un téléphone mobile donné). 
Et pour bien notifier l’utilisateur pendant des heures en journée (entre 7h et 20h), il  est passé également la timezone de 
l’utilisateur. Et en cas de message visible à l’utilisateur, il est passé la locale du smartphone pour le notifier dans la bonne 
langue. 
 
Le serveur Robert robert-server-ws passe alors le device token au Push Server TousAntiCovid robert-push-notif pour qu’il le 
stocke dans la base de push tokens
 
Ensuite, à une fréquence donnée, une tâche automatisée interne (Smart CRON) parcourt cette base de push tokens afin de 
notifier les téléphones mobiles qui doivent être réveillés à ce moment-là. 
 
Le serveur robert-push-notif demande alors au serveur APNs d’envoyer une notification push aux iPhones correspondant à ces 
push tokens et leur permettre ainsi de réaliser un appel à status
 
Tous ces nouveaux composants « Push server » sont placés dans une zone dédiée, complètement isolée du serveur Robert 
robert-server-ws, et non accessible de l’extérieur, au même titre que le serveur de QR codes. 
2.3  Novembre 2020 
2.3.1  Nouvelle version de StopCovid nommée «TousAntiCovid » 
Dans le cadre du volet numérique de gestion de la crise, la décision a été prise, pour renforcer l’adoption, d’une version 2.0 de 
StopCovid, nommée « TousAntiCovid », plus ancrée dans le champ sanitaire (sa raison d’être), et qui prend en compte de 
nombreux retours d’utilisateurs. 
 
Cette nouvelle version 
•  Est plus dynamique : 
o  un nouveau design graphique, sur un seul écran, qui est plus lisible et éditorialisé. Il a été conçu suite à des 
interactions avec des groupes de tests ; 
o  une insertion dans un ensemble d’outils numériques. En pratique, des liens web dans les rubriques Mes 
conseils Covid8 et Où me faire dépister9, et aussi un lien vers l’observatoire Géodes SPF (taux d’incidence 
                                              
8 https://mesconseilscovid.sante.gouv.fr 
9 https://sante.fr/recherche/trouver/DepistageCovid 
AIPD - TousAntiCovid 
 
10 
 

 
 
 
 
sur carte française) 
•  Donne des informations sur l’épidémie : 
o  Une section Infos a été créée pour informer l’utilisateur avec un fil de brèves et des chiffres clés. S’il y a de 
nouvelles actualités, elles sont envoyées à l’utilisateur. Pourquoi ? Donner à l’utilisateur des informations 
fiables sur l’épidémie. 
•  Montre qu’elle est utile et utilisée : 
o  Une section Chiffres-clés a été rajoutée, ils renseignent 
  sur la situation de l’épidémie (nouveaux cas, Patients en réanimation, Nouveaux patients en 
réanimation, Tension des réanimations, R effectif, taux d’incidence, taux de positivité) 
  sur les métriques de l’application (enregistrements, déclarations de positivité, notifications 
d’expositions au risque)  
o  Ces chiffres clés trouvent leur source sur data.gouv.fr pour la partie épidémiologique, avec un 
rafraîchissement trois fois par jour. Les différentes sources sont détaillées sur cette page web : 
https://bonjour.tousanticovid.gouv.fr/app.html#chiffres 
2.3.2  Génération des attestations de déplacement dérogatoire 
L’utilisateur peut générer et gérer ses attestations dans l’application. 
•  Elles sont conservées dans le téléphone, et à la prochaine ouverture de l’application, l’application supprime 
automatiquement toutes les attestations de plus de 24 heures. L’utilisateur peut aussi les supprimer à tout moment, soit 
une à une, soit toutes les informations dans la section « Paramètres » de l’application ; 
•  Lorsqu’il remplit une attestation l’utilisateur a la possibilité de sauvegarder dans son téléphone mobile son Prénom, 
Nom, Date de naissance, Lieu de naissance, Adresse, Ville, Code postal et le motif de déplacement, pour lui éviter de 
les saisir de nouveau dans les prochaines attestations. Il peut supprimer à tout moment ces données de son téléphone 
dans la section « Paramètres » de l’application.  
•  Ces données ne sont pas remontées au serveur central. 
2.3.3  Obtention des Informations sanitaires par lieu d’intérêt  
L'utilisateur peut saisir dans l’application un lieu d’intérêt sous la forme d’un code postal pour obtenir des indications sanitaires 
par département. 
Cette donnée est stockée uniquement dans l’application (exemple : 73100)  et n'est pas remontée vers le serveur central. 
2.4  Décembre 2020 
2.4.1  Obtention de conseils relatifs à l’isolement 
L’utilisateur peut obtenir des informations sur le recours à l’isolement, en sélectionnant ou en saisissant des données.  
Ces données sont stockées uniquement dans l’application et ne sont pas remontées vers le serveur central. 
Elles sont conservées jusqu’à effacement par l’utilisateur. 
2.5  Mai 2021 
2.5.1  Conservation des certificats de vaccination ou de test ou de rétablissement à la Covid-19 
Le module Carnet de l’application TousAntiCovid permet à l’utilisateur d’enregistrer les certificats de vaccination ou de test ou 
de rétablissement à la Covid-19. Ces certificats sont au format 2D-DOC et proviennent d’un tiers de confiance (Vaccin Covid 
ou SI-DEP). 
Ce module est un des composants du Pass sanitaire donc nous avons détaillé ce module dans l’AIPD Pass sanitaire qui est 
reliée à la présente AIPD. 
2.5.2  Réalisation d’analyses statistiques anonymes sur des données de l’application 
L’élaboration de ces statistiques est prévue dans le décret du 29 mai 2020 et elle est fondée sur l’exécution d'une mission d’intérêt 
public, le consentement de l'utilisateur n’est donc pas requis. 
L'utilisateur peut à tout moment exercer son droit d’opposition à la réalisation de ces statistiques en les désactivant dans les 
paramètres de l'application TousAntiCovid. 
Ces données  sont minimisées pour remplir  cette finalité  de  statistique  avec un identifiant de  l'application spécifique  aux 
statistiques et qui est donc différent de celui utilisé par le protocole Robert . 
Les données utilisées pour réalisées ces analyses statistiques sont agrégées afin de produire des statistiques totalement anonymes.  
L’application remonte au serveur central lors de la requête status et après appel du webservice analytics deux types distincts de 
statistiques anonymes 
                                              
 
AIPD - TousAntiCovid 
 
11 
 

 
 
 
 
•  Statistiques liées à l’identifiant de l’application généré lors de l’activation de l’application et dédié à la réalisation des 
ces  statistiques  (Ex :  configuration matérielle  et logicielle du téléphone mobile, configuration  de l’application 
TousAntiCovid, rubriques consultées par l’utilisateur, etc.)  
•  Statistiques sanitaires agrégées du back-end et liées à un identifiant à usage unique généré aléatoirement  (ex : niveau 
de risque Covid de l'utilisateur, dates de premier symptôme ou de test Covid , etc.) 
Le webservice analytics enregistre ces statistiques sur le serveur central dans un backend dédié. 
Ces statistiques sont à destination des autorités sanitaires. 
2.5.3  Alerte en cas de risque de contamination dans les lieux clos recevant du public 
Le module Signal de l’application TousAntiCovid permet l’enregistrement  et l’alerte des utilisateurs  en cas de risque de 
contamination à la Covid-19 dans un lieu clos recevant du public.  
Ce module est intégré dans l’application TousAntiCovid, mais il  est indépendant des autres fonctionnalités de cette application 
car il  repose sur un protocole spécifique, nous avons donc décidé de rédiger l’AIPD TousAntiCovid Signal spécifique pour ce 
module mais reliée à la présente AIPD.   
2.6  Juin 2021 
2.6.1  Format DCC pour les certificats de vaccination ou de test ou de rétablissement à la Covid-19 

Les personnes concernées ont la possibilité 
•  de télécharger depuis SI_DEP ou VACCIN COVID  leur certificat au format DCC (Digital Covid Certificate) 
•  d’ enregistrer leur certificat DCC dans le module Carnet de l’application TousAntiCovid  
2.6.2  Conversion certificats 2D-DOC vers DCC  
Le module Carnet de l’application TousAntiCovid permet aux utilisateurs de convertir leur certificat du format 2D-DOC vers le 
format DCC. 
2.7  Septembre 2021 
2.7.1   Réduction du risque de ré-identification des personnes via les données remontées pour les statistiques 

Les  actions suivantes de réduction du risque de  ré-identification des personnes via les données remontées par le  module 
statistique ont été mises en place : 
•  Meilleure anonymisation du token analytics coté backend 
o  Le token Jason Web Token (JWT) n’est pas stocké par le serveur central. Actuellement il n’est donc pas 
possible de procéder à des recoupements de données. Cependant, afin d’aller plus loin dans l’approche privacy 
by design, un patch a été développé afin de limiter l’information présente dans le token (suppression du JWT 
ID, timestamps arrondis). Ce changement a pour conséquence que le même token est partagé par de nombreux 
utilisateurs, évitant toute possibilité de recoupement même si ces données étaient stockées (ce qui n’est pas le 
cas) 
•  Suppression de la remontée des 4 événements (ci-dessous)  
o  l'application envoie à l'utilisateur un push suite à une alerte (RiskLevel > 0) 
o  l’utilisateur a ajouté avec succès une preuve (test ou vaccination) 
o  l’utilisateur appuie sur "convertir cette preuve" sur un 2D-DOC et confirme   
o  la conversion de certificat de test ou vaccin a réussi   
•  Arrondi à l’heure des horodatages des « événements » et des « journaux »  
3  Principes fondamentaux 
3.1  Remarques liminaires 
L’utilisation de l’application TousAntiCovid repose sur le volontariat. 
 
Pour les personnes diagnostiquées positives, le partage de l’historique de proximité avec le serveur repose sur le consentement. 
 
Les technologies utilisées reposent sur le Bluetooth et excluent l’usage de toute technologie de géolocalisation. 
AIPD - TousAntiCovid 
 
12 
 

 
 
 
 
3.2  Proportionnalité et nécessité 
3.2.1  Les finalités du traitement sont-elles déterminées, explicites et légitimes ? 

Les données sont générées et collectées pour fournir le service, à savoir  informer une personne du  risque qu’elle a 
encouru les 15 derniers jours.  
La définition de contact à risque donnée par Santé Publique France (SPF) est évolutive. A ce jour, elle est la suivante : 
En l’absence de mesures de protection efficaces pendant toute la durée du contact : 
  séparation physique isolant la personne-contact du cas confirmé en créant deux espaces indépendants (vitre, 
Hygiaphone®); 
  masque  chirurgical  ou  FFP2  ou  grand  public  en  tissu  fabriqué  selon  la  norme  AFNOR SPEC  S76-001de 
catégorie 1ou masque grand public en tissu réutilisable possédant une fenêtre transparente homologué par la 
Direction générale de l’armement,porté par le cas oule contact. 
 Un contact à risque est une personne 
1.  Ayant partagé le même lieu de vie que le cas confirmé ou probable ; 
2.  Ayant eu un contact direct avec un cas, en face à face, à moins de 2 mètres, quelle que soit la durée(ex. conversation, 
repas, contact physique). En revanche, des personnes croisées dans l’espace public de manière fugace, même en 
l’absence de port de masque,ne sont pas considérées comme des personnes-contacts à risque; 
3.  Ayant prodigué ou reçu des actes d’hygiène ou de soins; 
4.  Ayant partagé un espace confiné (bureau ou salle de réunion, véhicule personnel ...)pendant au moins 15 minutes  
consécutives  ou  cumulées  sur  24h  avec un  cas ou  étant resté  en  face  à  face  avec  un  cas  durant plusieurs 
épisodes de toux ou d’éternuement. 
L’application TousAntiCovid vise plus particulièrement les troisième et quatrième types de contact à risque . 
Les données générées et collectées avec l’accord de l’utilisateur ont donc pour  unique but  d’estimer de manière 
statistique des proximités et leur durée. L’usage du Bluetoooth a été retenu et l’usage de toute  technonlogie de 
géolocalisation écartée. 
En  termes de rattachement au parcours de  santé du  sujet contact, à travers le « rattachement du contact TousAntiCovid 
vers/ via les médecins généralistes » : le contact TousAntiCovid sera invité à consulter son médecin traitant, par 
télésurveillance de préférence. Le numéro de la plateforme nationale sera également mis à disposition pour orienter la personne 
vers un service téléphonique lui permettant de trouver un médecin s’il n’a pas de médecin traitant ou n’est pas en mesure de le 
joindre. Le médecin lui indiquera les mesures à suivre telles que préconisées par le MSS. Cette plateforme téléphonique pourra 
également rappeler les messages de conduite à tenir. 
 
3.2.2  Quel(s) est(sont) les fondement(s) qui rend(ent) votre traitement licite ? 
Conformément à l’article 6  e. du RGPD,  le traitement est nécessaire à l'exécution d'une mission d'intérêt public contre 
l’épidémie de la Covid-19 dont est investi le responsable du traitement. Il s’appuie en cela sur le décret n° 2020-650 du 29 mai 
2020 
 
Le traitement des données de santé est fondé sur des motifs d’intérêt public dans le domaine de la santé (article 9 2.i RGPD). 
 
3.2.3  Les données collectées sont-elles adéquates, pertinentes et limitées à ce qui est nécessaire au regard 
des finalités pour lesquelles elles sont traitées (minimisation des données) ? 
En matière d’identification possible, toute l’architecture du dispositif envisagée fait remonter au serveur uniquement les 
pseudonymes aléatoires et temporaires générés par les applications associées aux personnes avec lesquelles un individu 
diagnostiqué positif a été en contact, et non le pseudonyme de ce dernier.  
 
L’information “un pseudonyme est diagnostiqué positif” n’est jamais remontée au serveur, ni stockée par ce dernier, et n’est 
jamais communiquée aux autres applications.  Une personne est informée du risque non pas parce qu’elle reçoit l’information 
de qui est infecté, mais parce que la personne diagnostiquée positive accepte de partager la liste des pseudonymes collectés, et 
qu’elle peut potentiellement s’y trouver. Ce n’est pas le serveur qui notifie une personne : c’est l’application de la personne qui 
interroge le serveur, au cours de la journée et qui alerte la personne de son exposition éventuelle au risque lors des jours 
écoulés. Le serveur n’est pas en mesure de contacter une application.  
 
Nous avons suivi un procédé qui réduit au maximum  le risque de ré-identification de la personne diagnostiquée positive à 
AIPD - TousAntiCovid 
 
13 
 

 
 
 
 
l’origine d’une remontée de ses contacts dans le respect des principes de protection des données personnelles.  
 
3.2.4  Les données sont-elles exactes et tenues à jour ? 
L’application émet et collecte des pseudonymes qui sont  
  aléatoires : ils ne correspondent à aucun identifiant connu de la personne, 
  temporaires : leur durée de vie est de 15 minutes, 
  vérifiables : la  clé partagée permet d’authentifier les pseudonymes auprès du serveur. 
 
Quand une personne est diagnostiquée positive au Covid-19, et après qu’elle ait donné à nouveau son consentement,  son 
historique de proximité  est chargé sur le serveur sécurisé après vérification d’un jeton aléatoire à usage unique (code ou QR 
code, voir supra) donné par l’autorité de santé. Une personne ne peut pas se déclarer « positive elle-même » et ainsi fausser la 
base centralisée., puisqu’elle doit avoir à sa disposition un tel jeton. La base centralisée contient la liste des pseudonymes des 
historiques de proximité  des personnes diagnostiquées positives. Elle  ne  contient pas les pseudonymes des personnes 
diagnostiquées positives. 
  
Sur le plan technique : les données mesurées et enregistrées sont des séries temporelles de paquets échangées entre téléphones 
mobiles, et qui donnent un RSSI (Received Signal Strength Indicator) pour chaque paquet échangé. Le RSSI est une mesure de 
la puissance en réception d'un signal reçu d'une antenne. En Bluetooth, les valeurs usuelles de RSSI pour un terminal varient de 
−60 dBm (niveau élevé de réception) à −90 dBm (niveau minimum permettant d'exploiter le signal). Le RSSI varie selon la 
distance avec l'antenne émettrice. C’est cette corrélation à la distance entre l’émetteur et le récepteur qui permet d’inférer un 
proxy/une classification de la proximité entre les deux terminaux émetteur et récepteur.  
 
Le calibrage, nécessaire pour tenir compte des gains en émission et réception pour le signal Bluetooth et qui dépend des terminaux, 
est réalisé sur le téléphone mobile. Une première classification est également réalisée sur le téléphone mobile à la remontée des 
contacts, notamment à travers la suppression des contacts beaucoup trop courts ou beaucoup trop faibles. Le calcul de risque se 
fait sur le serveur (qui est le seul à pouvoir valider les paquets de type « Hello » et à permettre l’intégration pour une même 
application exposée) à l’aide d’un algorithme de classification statistique qui a été paramétré en fonction de résultats de tests 
terrain (menés aux niveaux européen et français). 
 
Il  n’est pas envisagé, dans la mise en oeuvre de TousAntiCovid, d’introduire des faux positifs dans les notifications transmises 
aux personnes, ce qui aurait permis de limiter les risques de ré-identification dans certains types d’attaques mais présente des 
inconvénients du fait des conséquences sur les personnes recevant des faux positifs. Ce point a été souligné dans la délibération 
2020-046  de la CNIL. 
 
3.2.5  Quelle est la durée de conservation des données ? 
Le traitement est mis en œuvre jusqu’au 31 décembre 2021.  
 
La clé d’authentification partagée et l’identifiant aléatoire permanent sont conservés jusqu’à ce que l’utilisateur se désinscrive 
et désinstalle l’application TousAntiCovid, et au plus tard pour la durée mentionnée au premier alinéa.   
 
Les données de l’historique de proximité enregistrées par l’application sur le téléphone mobile et stockées sur le serveur sont 
conservées au maximum  quatorze jours à compter de leur émission.  
 
Les données mentionnées au 4° de l’article 2 du présent décret ne sont pas conservées dans l’application TousAntiCovid. Elles 
ne sont traitées qu’une seule fois afin que l’utilisateur de l’application soit autorisé par le serveur à partager son historique de 
proximité. 
 
Une purge systématique des pseudonymes périmés stockées à la fois sur les téléphones mobiles et sur le serveur est effectuée 
quotidiennement. Toutes les données, tous les pseudonymes éphémères de proximité qui sont enregistrés dans l’historique de 
proximité  des téléphones mobiles ou qui sont remontés sur le serveur sont effacés au bout de 14 jours à compter de leur date 
d’émission par une application. L’effacement a lieu par une suppression quotidienne du jour le plus ancien. 
 
Il  est nécessaire de borner cette durée pour englober la recommandation de Santé Publique France (SPF) et du MSS :  2  jours 
avant la date de début des symptômes ou 7 jours avant la date de prélèvement à laquelle il faut ajouter la durée d’envoi, la 
réalisation du test, et la durée à recevoir le compte rendu et de choisir de se déclarer. 15 jours étaient aussi la durée admise de 
contagion (14 jours de contagion après le jour où la personne est infectée). 
  
Cette durée devra donc être comprise entre 10 jours et 15 jours, laissant le temps à une personne pour se déclarer dans 
l’application. La durée de 15 jours est retenue. 
  
L’utilisateur de TousAntiCovid peut décider à tout moment dans l’application d’effacer son d’historique de proximité local, ses 
données sur le serveur et ses alertes, ou encore de supprimer l’application. 
 
AIPD - TousAntiCovid 
 
14 
 

 
 
 
 
3.3  Mesures protectrices des droits 
3.3.1  Comment les personnes concernées sont-elles informées à propos du traitement ? 

Quand une personne installe l’application TousAntiCovid, elle est informée du traitement via les mentions d’information 
RGPD  respectant l’article 13 du RGPD  ainsi que le paragraphe 3 de l’article 48  de la Loi Informatique et Libertés. 
 
Par ailleurs, le fonctionnement de l’application TousAntiCovid et le traitement sont présentés sur les supports de 
communication (dont les sites web) de la DGS du MSS. 
 
TousAntiCovid est intégré aux communications sur les gestes barrières à adopter. 
 
Les éléments communiqués à la population sont présentés d’une manière compréhensible et accessible à toutes et à tous 
notamment à travers des infographies permettant de vulgariser les concepts technologiques sous-jacents. 
 
Les écrans de travail en Annexe donnent un exemple de ces mentions d’informations. 
 
3.3.2  Si applicable, comment le consentement des personnes concernées est-il obtenu ? 
Lorsqu’une personne installe l’application TousAntiCovid, elle donne son consentement pour : 
  L’activation du Bluetooth ; 
  La réception des notifications de risque de transmission du virus suite à un contact avec des personnes diagnostiquées 
ou dépistées positives ; 
  L’activation de l’envoi de ses pseudonymes et la mémorisation de ceux de ses voisins (historique de proximité). 
 
Si une personne est diagnostiquée ou dépistée positive : 
  Par un laboratoire : elle scanne le code SI-DEP 
  Communiqué avec les résultats de l’examen par le laboratoire et donne son consentement pour que son historique de 
proximité  soit envoyé au serveur. 
  Par un médecin : elle  saisit sur le serveur le code que lui a communiqué le médecin et donne son consentement pour 
que son historique de proximité soit envoyé au serveur. 
 
3.3.3  Comment les personnes concernées peuvent-elles exercer leurs droits d'accès et droits à la portabilité ? 
En application des articles 11 et 23 i) du règlement (UE) 2016/679 du parlement européen et du conseil du 27 avril 2016 susvisé, 
les droits d’accès, de rectification et de limitation prévus aux articles 15,  16  et 18  de ce même  règlement ne peuvent s’exercer 
auprès du responsable de traitement dès lors que les données traitées sont pseudonymisées, et que l’exercice  de ces droits 
nécessiterait une identification de la personne concernée et pourrait permettre à cette même personne d’identifier des utilisateurs 
diagnostiqués ou dépistés positifs à la Covid-19. Le décret relatif à ce traitement écarte le droit d’accès. 
En outre, un usage détourné du droit d’accès pourrait permettre d’obtenir indirectement des informations et être une manière 
détournée d’identifier des personnes avec lesquelles la personne a été en contact 
Le droit à la portabilité ne peut pas être exercé dans le cadre de l’exécution d’une mission d’intérêt publique.   
 
3.3.4  Comment les personnes concernées peuvent-elles exercer leurs droits de rectification et droits à 
l'effacement (droit à l'oubli) ? 
En application des articles 11 et 23 i) du règlement (UE) 2016/679 du parlement européen et du conseil du 27 avril 2016 susvisé, 
les droits d’accès, de rectification et de limitation prévus aux articles 15,  16  et 18  de ce même  règlement ne peuvent s’exercer 
auprès du responsable de traitement dès lors que les données traitées sont pseudonymisées, et que l’exercice  de ces droits 
nécessiterait une identification de la personne concernée et pourrait permettre à cette même personne d’identifier des utilisateurs 
diagnostiqués ou dépistés positifs à la Covid-19. Le décret relatif à ce traitement écarte le droit de rectification. 
Concernant l’exercice du droit d’effacement, en application  de  l’article 17  paragraphe 3,  le  droit à l’effacement n’est pas 
applicable lorsque le traitement est nécessaire pour exécuter une mission d'intérêt public dont est investi le responsable du 
traitement ou pour des motifs d'intérêt public dans le domaine de la santé publique. Par ailleurs, l’exercice du droit à l’effacement 
auprès du RT aboutirait à la nécessaire réidentification de la personne concernée, ce qui doit être écartée pour les mêmes raisons 
qu’évoquées précédemment.  
La personne concernée peut elle-même procéder à l’effacement de ses données de la manière suivante : 
  Effacer toutes les données stockées sur son téléphone mobile : les pseudonymes des téléphones mobiles qui ont été à 
proximité  du sien et qui sont enregistrés dans l’historique de proximité de son téléphone mobile ; 
  Effacer et/ou désactiver les notifications affichées par l’application ; 
  Effacer toutes les données stockées sur le serveur : les pseudonymes de son téléphone qui ont été enregistrés dans 
l’historique de proximité des téléphones mobiles qui sont passés à proximité du sien et que le ou les utilisateurs ont 
accepté de communiquer au serveur car ils ont été diagnostiqués ou dépisté positif à la Covid-19 ; 
  Effacer les attestations de déplacement dérogatoires ; 
AIPD - TousAntiCovid 
 
15 
 

 
 
 
 
  Modifier ou effacer le lieu d’intérêt ; 
  Supprimer les certificats de vaccination ou de test ou de rétablissement à la Covid -19; 
  Modifier ou effacer le statut Covid-19 sélectionné permettant l’obtention de conseils sur le recours à l’isolement ; 
  Se désinscrire du serveur, cela efface toutes les données sur le serveur y compris les pseudonymes et les autres 
données sur son téléphone mobile. 
 
3.3.5  Comment les personnes concernées peuvent-elles exercer leurs droits de limitation et droits 
d'opposition ? 
En application des articles 11 et 23 i) du règlement (UE) 2016/679 du parlement européen et du conseil du 27 avril 2016 susvisé, 
les droits d’accès, de rectification et de limitation prévus aux articles 15,  16  et 18  de ce même  règlement ne peuvent s’exercer 
auprès du responsable de traitement dès lors que les données traitées sont pseudonymisées, et que l’exercice  de ces droits 
nécessiterait une identification de la personne concernée et pourrait permettre à cette même personne d’identifier des utilisateurs 
diagnostiqués ou dépistés positifs à la Covid-19. Le décret relatif à ce traitement écarte le droit à la limitation. 
Concernant les pseudonymes générés ou collectés sur son téléphone, la personne concernée peut à tout moment arrêter d’utiliser 
l’application donc exercer son droit de d’opposition. Elle peut à tout moment arrêter d’émettre des pseudonymes et/ou désactiver 
le Bluetooth.  
Dans le cas où la personne concernée a envoyé au serveur les pseudonymes temporaires des téléphones mobiles qui sont passés 
à proximité  du sien et qui sont enregistrés dans l’historique de proximité de son téléphone elle ne peut pas exercer son droit de 
d’opposition, car par conception, ces données ne sont rattachées, sur le serveur, à aucun de ses propres pseudonymes temporaires.  
La personne peut décider à tout moment de ne pas être notifiée par l’application du fait qu’elle est à risque car son historique de 
proximité  contient une personne diagnostiquée ou dépistée positive. 
 
3.3.6  Les obligations des sous-traitants sont-elles clairement définies et contractualisées ? 
•  3DS OutScale : hébergement 
o  Pendant la phase de développement du projet une convention a été signée entre Inria et 3DS Outscale pour 
héberger le développement du prototype. Il s’agit de la convention de service SecNumCloud signée entre 3DS 
Outscale et Inria le 29/04/2020,  ainsi que les Conditions Générales d’Utilisation et de vente de 3DS Outscale 
acceptée par Inria le 29/04/2020. 
o  Pour la phase de production,  
  un accord cadre sera signé entre MSS et et Inria  
  un accord de consortium a été signé entre Inria et les partenaires impliqués, dont Outscale 
•  Orange : maintenance et exploitation 
o  Pour la phase de développement, une convention de Sous-traitance est en cours de signature entre Cap Gemini 
et Inria  
o  Pour la phase de production, 
  un accord cadre a été signé entre MSS et et Inria  
  un accord de consortium a été signé entre Inria et les partenaires impliqués, dont Orange 
•  IMA 
o  Des clauses RGPD ont été signées entre Inria et IMA 
 
3.3.7  En cas de transfert de données en dehors de l'Union européenne, les données sont-elles protégées de 
manière équivalente ? 
Il  n’est pas prévu de transférer de données personnelles hors de l’Union Européenne.  
 
4  Risques 
4.1  Mesures existantes ou prévues 
4.1.1  Mesures organisationnelles 
Organisation de la politique de protection de la vie privée 

  Pour l’hébergement, 3DS Outscale : 
o  S’engage depuis le 25 mai  2018  à respecter la conformité au RGPD dans ses services de Cloud computing. 
AIPD - TousAntiCovid 
 
16 
 

 
 
 
 
o  Est également adhérent et respecte les prescriptions du Code de Conduite de l’association Cloud Infrastructure 
Services Provider (CISPE).  
o  Applique des processus certifiés ISO 27001:2013 permettant la mise en œuvre de procédures propres à garantir 
la confidentialité et la protection des données de ses clients. 
  Prise en compte du principe de « Privacy by Design » dès la conception du protocole. 
Gérer la politique de protection de la vie privée 
  La définition et la mise en œuvre de la politique de protection de la vie privée repose sur l’implication de la DPO de 
MSS et l’Inria.  Cette mise en œuvre passe notamment par l’inscription du traitement dans le registre de traitement du 
MSS et d’Inria. 
Gérer les risques 
Durant toute la durée de conception de l’architecture et de l’application  : 

  Mise en œuvre et vérification des bonnes pratiques de la sécurité dans le code ; 
  Vérification automatique via une chaîne Intégration continue / déploiement continu (CI/CD)  des vulnérabilités en 
appliquant le top 10 Open Web Application Security Project (OWASP Zed Attack Proxy) ;  
o  L’intégration continue couvre la première moitié de la chaîne. Elle vise à organiser au mieux et automatiser 
les opérations de développement et leurs transitions.  
o  Le déploiement continu prend la suite : il consiste pour l’équipe infrastructures à scripter et automatiser les 
étapes de déploiement en production afin qu’une version livrée par le  serveur CI puisse sans attendre se 
déployer en production ;  
  Le Top 10 de l'OWASP est un document de sensibilisation standard pour les développeurs et la sécurité des applications 
web ; Broken Authentication. ; Sensitive Data Exposure ; XML External Entities (XXE)  ; Broken Access Control ; 
Security Misconfiguration ; Cross-Site Scripting XSS ; Insecure Deserialization ; Using Components with Known 
Vulnerabilities ; Insufficient Logging & Monitoring.  
Pendant la phase d’exploitation 
  Le Sous-Traitant chargé de la maintenance prendra en charge l’organisation de veille et de gestion des vulnérabilités 
pour maintenir un bon niveau de sécurité de l'application mobile et du serveur durant toute la durée d'utilisation de 
l'application (veille des publications des vulnérabilités par les Internautes / qualification / correction / communication) 
est mise en œuvre.  
Intégrer la protection de la vie privée dans les projets 
La CNIL  a été consultée en amont sur le projet TousAntiCovid et a rendu un premier avis (délibération n°2020-046 du 24 avril 
2020) sur le protocole sous-jacent, le protocole Robert. 
Elle  a rendu un deuxième avis (Délibération n° 2020-056  du 25  mai  2020)  sur le  projet de décret relatif à l’application mobile  
TousAntiCovid. 
Lors de chaque évolution fonctionnelle, des contacts sont pris auprès de la CNIL pour nous assurer de la conformité du traitement 
vis-à-vis du RGPD. 
Gérer les incidents de sécurité et les violations de données 
Les points clés du RGPD que 3DS Outscale s’engage à respecter sont les suivants : 
  Signalement des failles de sécurité, engendrant un risque aux personnes concernées, au RSSI de la DGS, le FSSI ainsi 
que la DPO du ministère 
  Le Sous-traitant s’engage à informer sans délai (et au maximum  dans un délai de 24 heures après en avoir pris 
connaissance) 
o  le RSSI de la DGS, le FSSI ainsi que la DPO du ministère  
o  Inria, dans le cadre de son contrat de sous-traitance en appui à la DGS 
 
Il  est constitué à cette fin une cellule conjointe entre la DGS et Inria impliquant leurs RSSI et DPO respectifs pour un 
traitement efficace et approprié de ce type d’incident impliquant toute violation de données à caractère personnel avérée ou 
supposée, susceptible d’engendrer un risque pour les personnes concernées. 
 
Si  des données à caractères personnelles sont concernées, le référent RGPD du ministère et la DPO sont informés par le RSSI 
de la DGS ou la FSSI MCAS. 
 
L’information du responsable de traitement est accompagnée de toutes les documentations utiles permettant de comprendre 
l’incident, les mesures envisagées et si nécessaire les éléments permettant de notifier à la CNIL  dans les 72 heures une 
violation de données à caractère personnel. 
 
AIPD - TousAntiCovid 
 
17 
 

 
 
 
 
Les dispositions que l’équipe projet de l’applications TousAntiCovid met en œuvre pour répondre aux exigences de sécurité du 
Système d’Information sont décrites dans le Plan d’Assurance Sécurité (PAS) de TousAntiCovid. 
Gestion des personnels 
Les points clés du RGPD que 3DS Outscale et les autres sous-traitants s’engagent à respecter sont les suivants : 
  Formation et sensibilisation du personnel aux exigences de confidentialité et de protection des données personnelles 
  Nomination d’un délégué à la protection des données (DPO) dont la désignation est effective depuis le 25 mai 2018 
  Habilitations des personnes accédant au serveur 
Gestion des tiers accédant aux données 
L’accès aux  systèmes de stockages des données clients de 3DS  Outscale est strictement limité  aux  équipes en charge des 
opérations de la plateforme. Tout accès à ces systèmes est journalisé afin de pouvoir détecter les éventuels accès illégitimes. 
Superviser la protection de la vie privée  
Les points clés du RGPD que 3DS Outscale s’engage à respecter sont les suivants : 
  Audits réguliers et actualisation des stratégies de traitement des données 
  3DS Outscale est certifié ISO 27001  et attesté conforme ISO 27017  et ISO  27018.  Et à ce titre, a mis  en œuvre des 
mesures de sécurité visant à protéger les données personnelles de toutes les parties prenantes en relation avec elle. 
 
4.1.2  Mesure sur les données 
Chiffrement et précisions sur les clés utilisées 

•  Sécurisation du stockage des clés de chiffrement (HSM / Vault en Appliance virtuelle) 
•  Nous avons mis en œuvre le chiffrement des pseudonymes en employant l'algorithme de chiffrement SKINNY-
CIPHER64/192  afin de remplacer 3DES,  comme préconisé dans la délibération 2020-046  de la CNIL.  Mise en œuvre 
du Certificate pinning (offert par l'API Android et sur iOS) sur les applications clientes qui est un mécanisme de sécurité 
qui  protège les sites internet de l'usurpation  d'identité contre les certificats frauduleux émis  par des autorités de 
certification compromises. 
•  Nous avons programmé les applications Android et iOS afin de stocker ou wrapper le secret partagé au moyen des API 
qui permettent l'utilisation du composant crypto du téléphone (secure enclave pour iOS, hardware backed keystore pour 
Android) 
•  Que cela soit pour le serveur backend ou pour les applications mobiles, nous avons utilisé une source d'aléa dont la 
qualité́ permet l'usage pour des opérations cryptographiques. 
Anonymisation 
•  Accès APIs protégé par API Gateway / Reverse proxy 
•  De plus, nous avons nettoyé les méta-données non-utiles au protocole ROBERT (IP, ports, token d'authentification etc.) 
au niveau du frontal web 
•  Une attention particulière est portée sur le fait qu’aucune information relative aux développeurs de l’application ne doit 
être enregistrée dans les journaux en mode « release » (codes erreurs explicites, informations techniques relatives aux 
téléphones mobiles, etc.) 
Cloisonnement 
•  Découpage du système en plusieurs niveaux cloisonnés 
•  Cloisonnement et sécurisation des réseaux (VPC,  VLAN et subnet) 
•  Mise en œuvre de groupes de sécurité, ACL sur les ressources IaaS 
•  L’architecture de  tout le  système intègre un  cloisonnement  entre le  backend de  l'application, le  service de 
génération/validation des QR codes et le service Pro TousAntiCovid. De plus, il est mis en place un filtrage réseau entre 
tous ces services. 
•  Nous avons aussi mis en œuvre, sur un principe similaire, une segmentation du backend de l'application en plusieurs 
zones avec des rôles différents (front-office, middle-office, back-office, alerting/reporting/monitoring, 
développement/déploiement). Là aussi, un filtrage réseau entre ces zones est assuré.  
Contrôle des accès logiques 
•  Mise en œuvre d’un service de gestion des identités et des accès (IAM -- Identity and Access Management) pour les 
administrateurs techniques et les administrateurs fonctionnels 
AIPD - TousAntiCovid 
 
18 
 

link to page 19  
 
 
 
•  Les permissions d’accès sont basées sur RBAC (Role-Based Access Control) 
•  Mise en œuvre de groupes de sécurité, ACL sur les ressources IaaS du Cloud 3DS Outscale 
Journalisation 
Mise en œuvre logging, supervision & monitoring avec des logs chiffrés et des mécanismes d'audit de l'imputabilité et de la 
traçabilité des actions menées sur le système, avec les points suivants : 
•  Existence d’un serveur de journalisation dédié, configuré en écriture seule ; 
•  Des journaux signés et chiffrés (priorité modérée) ; 
•  Accessibilité par une autorité de contrôle. 
Archivage 
  Archivage des sauvegardes / snapshots basé sur les services proposés nativement par le Cloud 3DS Outscale 
  Le Responsable de traitement précisera à 3DS Outscale 
o  La fréquence des archivages, 
o  Le responsable des archivages. 
  Conformément à l’article L.  213-2  du Code du patrimoine, le sort final retenu pour les données à l’issue de la durée 
d’utilité administrative (DUA) est l’élimination. Compte tenu de la durée de conservation courte, il n’est pas prévu de 
processus d’archivage intermédiaire. 
Minimisation des données 
  Mise en œuvre de la pseudonymisation pour limiter la réidentification : les pseudonymes générés et collectés sur les 
téléphones mobiles ainsi que ceux stockés ceux sur le serveur sont des pseudonymes aléatoires et temporaires. 
 
4.1.3  Mesure générale de sécurité du système 
Sécurisation de l'exploitation 

•  Plateforme hébergée par 3DS Outscale en France et qualifiée SecNumCloud, par ailleurs certifiée HdS 
•  IAM pour les administrateurs techniques et les administrateurs fonctionnels 
•  Accès SSH par Bastion pour les administrateurs de la plateforme 
•  Afin de répondre aux recommandations de l’ANSSI, un dispositif de détection des incidents de sécurité est mis en place. 
Le mécanisme prévu se compose de : 
o  Une protection anti-DDoS capable de contrer une attaque massive vis-à-vis du front-office exposé sur 
Internet ; le recours à un service spécialisé a été effectué au travers de l’anti-DDos (Cybersécurité Orange). 
o  Mécanismes Blackhole et anti-DDoS de 3DS Outscale. 
o  API Gateway permettant de mettre en place un rate-limiting (caper les appels APIs pour protéger le middle-
end) 
o  Cela s’accompagne de la minimisation de la surface d'attaque des serveurs centraux en procédant à la 
désactivation de tous les services inutiles.  
  Nous avons basé nos développements en utilisant au maximum  les mécanismes de sécurité offerts par le framework, 
notamment Spring Security, qui est un framework d'authentification et de contrôle d'accès puissant et hautement 
personnalisable pour les applications Java Il s'agit de la norme de facto pour la sécurisation des applications basées 
sur Spring. Ceci comprend notamment l'authentification et l'autorisation ; la protection contre les attaques telles que la 
fixation de session, le "clickjacking", la falsification de demandes de sites croisés, etc. 
Lutte contre les logiciels malveillants 
•  Utilisation du Captcha d’Orange à l’enregistrement pour limiter les attaques de logiciels malveillants / robots.  
•  Anti-DDoS Orange Cyberdéfense 
o  L’architecture applicative  mise en œuvre repose sur l’utilisation d’Internet pour assurer le  routage et la 
transmission des informations. Lors d'une communication entre le téléphone mobile et le  serveur, les flux  de 
données sont encapsulés et transmis par paquets en utilisant le protocole IP.  
Il  apparait nécessaire de mettre en œuvre des protections contre les attaques les plus communes observées. 
Ainsi selon le  document disponible sur le  site de l’ANSSI10,   les attaques par déni de service distribué 
(Distributed Denial of Service ou DDoS) sont aujourd’hui fréquentes, notamment du fait de la relative 
simplicité de leur mise en œuvre, et de leur efficacité contre une cible non préparée. Afin d’éviter l’interruption 
                                              
10 https://www.ssi.gouv.fr/uploads/2015/03/NP_Guide_DDoS.pdf 
AIPD - TousAntiCovid 
 
19 
 

 
 
 
 
de service et anticiper cette menace, le choix a été fait de mettre en œuvre une solution anti-DDoS, pour se 
protéger d’attaques DDoS.  
o  Le dispositif anti-DDOS mis en œuvre pour protéger le serveur central de TousAntiCovid est composé de 2 
phases : 
  en phase de monitoring, la solution anti-DDoS traite des échantillons de paquets IP (1 pour 4000) afin 
d'identifier la nature d'un trafic malveillant ; 
  en phase de protection, le trafic est dévié et analysé en temps réel, à ce stade il existe des solutions 
d'analyse par prélèvement d'échantillons dans un fichier contenant 5000 paquets IP. 
o  Si un paquet IP contient bien les adresses de destination et d’envoi, cet élément n’est pas l’objet du traitement 
qui consiste à vérifier l’éventuelle malveillance des paquets IP. 
•  Nous n’avons pas utilisé de code natif (NDK) ou des bibliothèques natives sur Android 
•  Dans tous les développements, et la liste est disponible en annexe, nous avons veillé et nous nous sommes assurés que 
pour toutes les dépendances externes nous étions à jour et utilisions les dernières versions disponibles. Nous nous 
sommes aussi assurés de choisir des bibliothèques maintenues et respectueuses des présentes recommandations. Nous 
avons aussi appliqué un principe de frugalité, en réduisant au strict nécessaire, l’utilisation bibliothèques externes, pas 
de superflu. 
•  Dans la programmation sur Android, nous avons veillé à supprimer les dépendances au Play Services ainsi que l'usage 
des bibliothèques Google (Cloud, Firebase, Crashlytics, ...) sur Android 
•  Dans tous les développements de l’application mobile, nous avons exporté aucun service, aucune activité à l'exclusion 
de l'activité principale et avons réduit au strict minimum les permissions requises. 
•  Les possibilités de débogage en mode « release » ont été désactivées et nous avons supprimé tout code mort, obsolète, 
ou inaccessible. 
•  Des tests de pénétration ainsi que des audits de code et de configuration doivent être réalisés avant la mise en production. 
Protection des sites web 
  3DS Outscale et le Sous–traitant en charge de la maintenance et de l’exploitation mettrons en œuvre une stratégie de 
détection avec des alarmes reposant sur la collecte des journaux d'événements sur l'infrastructure d'hébergement. 
Sauvegarde des données 
  3DS Outscale garantit l’intégrité des snapshots réalisés par le Responsable de traitement et en assure le backup. 
  Le Responsable de traitement  
o  Réalisera les snapshots de ses volumes s’il souhaite avoir un backup de ses données par 3DS Outscale. 
o  Précisera à 3DS Outscale les fréquences et le responsable de l’activation de ces snapshots. 
  Une procédure et des dispositifs de sauvegarde et de restauration sont mis en œuvre.  
Maintenance 
  Hébergement du  serveur 
o  3DS Outscale est responsable du Maintien en Condition Opérationnelle (MCO) et Maintien en Condition de 
Sécurité (MCS) de la plateforme de IaaS en 24/7 ; 
o  3DS Outscale en tant que fournisseur de IaaS fournit des images systèmes au Responsable de traitement afin 
de pouvoir déployer ses infrastructures. 3DS Outscale est responsable de fournir régulièrement des images à 
jour de ses systèmes d’exploitation et notifiera le Responsable de traitement à chaque fois qu’une mise à jour 
sera réalisée avec l’identifiant de la nouvelle image. A partir du moment où un volume est créé à partir de cette 
image, le Responsable de traitement a la charge du MCO et du MCS du système déployé. 
  Maintenance / exploitation du  serveur : afin de sécuriser les données dans le cadre des opérations de maintenance 
o  Insertion d’une clause de sécurité et de confidentialité dans les contrats de maintenance effectuée par des 
prestataires ; 
o  Enregistrement des interventions de maintenance dans une main courante (contenant notamment les dates, la 
nature des opérations et les noms des Intervenants) ; 
o  Installation des dernières versions applicatives à jour ainsi que des patchs de sécurité. 
o  Les mesures de sécurité seront définies par le Responsable du traitement avec l’aide de se(s) sous-traitant(s) 
désigné(s), sur la base des exigences de l’ANSSI et des standards de sécurité qu’ils jugeront applicables en la 
matière 
  Maintenance de l’application 
o  Correction des failles de sécurité et des bugs autant que de besoin 
AIPD - TousAntiCovid 
 
20 
 

 
 
 
 
o  Si  une faille  de sécurité est découverte, il  est possible d'obliger une application à se mettre  à jour  pour 
fonctionner  
o  Il n’est pas possible de désinstaller l'application mais il est possible de faire passer l'application dans un mode 
où elle est inactive avec désinscription de l'application et effacement de toutes les données 
Contrat de sous-traitance 
•  Pendant la phase de développement du projet une convention a été signée entre Inria et 3DS Outscale pour héberger le 
développement du prototype 
•  Pour la phase de production : 
o  un accord cadre a été signé entre MSS et et Inria  
o  un accord de consortium a été signé entre Inria et les partenaires impliqués, dont Outscale 
Sécurisation des canaux informatiques 
•  Chiffrement (HTTPS, SSL/TLS) de tous les flux échangés entre les applications mobiles et le Back-End 
TousAntiCovid et entre le Back-End ; 
•  L'accès au serveur de QR code par les professionnels de santé est sécurisé en protégeant la couche transport (IPsec de 
préférence) et en authentifiant les accès API entre le serveur de génération de QR codes (pro.tousanticovid.gouv.fr) et 
les postes clients des professionnels de santé ; 
•  Les communications entre le serveur robert-push-notif et APNs sont chiffrées en utilisant un certificat au format 
PKCS#12 
Sécurité physique 
3DS Outscale met en œuvre des datacenters certifiés ISO 27001  localisés en France et assurant un contrôle d’accès conforme 
au référentiel de qualification SecNumCloud de l’ANSSI. 
Traçabilité 
•  L’architecture Back-End TousAntiCovid met en œuvre des solutions d’administration technique et fonctionnelle et 
des outils de supervision & monitoring permettant d’exploiter le système. 
•  Mise en œuvre des mécanismes d'audit de l'imputabilité et de la traçabilité des actions menées sur le système : 
o  Mise en place d’un serveur de journalisation dédié, configuré en écriture seule ; 
o  Accessibilité par une autorité de contrôle. 
•  Ceci s’accompagne de la mise en œuvre d’une collecte centralisée des journaux d'événements de sécurité sur 
l'infrastructure d'hébergement serveurs 
Sécurisation des matériels 
•  L’architecture Back-End TousAntiCovid met en œuvre des solutions d’administration technique et fonctionnelle et 
des outils de supervision & monitoring permettant d’exploiter le système.   
•  Les mécanismes de haute-disponibilité (composants redondés, répartition de charge, tolérance aux pannes), 
l’extensibilité, l’élasticité et les performances des solutions proposées pour le système Back-End TousAntiCovid 
permettent de se conformer au niveau de qualité de service demandé et de garantir la résilience du système en 
conformité avec le Plan de Reprise d'Activité et de Plan de Continuité d'Activité (PRA/PCA).  
•  L’hébergement du système Back-End TousAntiCovid chez le fournisseur de Cloud 3DS Outscale couplé à une 
automatisation de la création des instances et des environnements (Infrastructure as Code) permet d’offrir une 
extensibilité et une élasticité du système Back-End TousAntiCovid. 
Eloignement des sources de risques 
•  Processus d'audit de sécurité (code, architecture, tests d'intrusion) et d'amélioration continue  
•  Sécurisation du stockage des clés de chiffrement 
•  Nous avons, via l’utilisation d’un HSM, restreint l'accès aux éléments cryptographiques au back-office, ainsi que 
l'accès aux éléments cryptographiques au back-office. 
 
Protection contre les sources de risques non humaines 
•  Les acteurs systèmes s’interfaçant avec le système Back-End TousAntiCovid sont les suivants : 
o  Service Génération Code 
  Le service Génération Code (QR Code) est situé dans une zone dédiée hébergée dans Outscale 
(région SecNumCloud). 
  Codes courts 
•  L’accès à l'API de génération de code court par le serveur Pro TousAntiCovid est sécurisé 
par l’API Gateway et utilise un Token JWT généré par l’IAM. Le canal d’échange est 
AIPD - TousAntiCovid 
 
21 
 

link to page 22  
 
 
 
sécurisé HTTPS, SSL/TLS. 
•  Le Back-End TousAntiCovid accède à l’API de vérification de code court par l’API 
Gateway et utilise un Token JWT généré par l’IAM. Le canal d’échange est sécurisé 
HTTPS, SSL/TLS. 
  Codes longs 
•  L’échange entre SI-DEP et le service Génération Code est assuré par la mise à disposition 
quotidienne des codes longs dans un fichier compressé généré par le service Génération 
Code. Le fichier est déposé dans un répertoire sécurisé accessible par SI-DEP au travers de 
multiples couches de sécurité. 
o  Site Web Pro StopCovid (via le service Génération Code) 
  Le site web Pro TousAntiCovid11, est situé dans une zone dédiée hébergée chez Outscale (région 
SecNumCloud). 
  L’accès au site web Pro TousAntiCovid par les médecins nécessite une authentification sur Pro 
Santé Connect (OpenID Connect). Une mire d’authentification fournie par Pro Santé Connect est 
affichée au médecin. Lors de la première connexion du médecin au site web Pro TousAntiCovid 
avec sa carte CPS ou application eCPS, une demande d’autorisation est formulée au médecin pour 
que le site Web Pro TousAntiCovid puisse accéder aux informations basiques de son profil.  
  Dans le cas où le médecin ne s’est pas authentifié au préalable, il est redirigé vers la mire 
d’authentification de Pro Santé Connect. Une fois authentifié, le médecin est redirigé vers le site 
Web Pro TousAntiCovid et fournit le token pour vérification (vérification que le token est valide et 
que le profil de l’utilisateur est bien de profession ‘médecin’) 
o  Service CAPTCHA 
  Solution de protection autonome des sites web contre les attaques par bots utilisant une solution 
proposée par Orange 
4.2  Accès illégitime  à des données 
4.2.1  Quels pourraient être les principaux impacts sur les personnes concernées si le risque se produisait ? 
 Les impacts diffèrent selon les types de données concernées : 
   •  I1 : Informations sur l’état de santé d’une personne (diagnostiquée ou dépistée positive, à risque) : harcèlement, 
stigmatisation, discrimination, difficultés relationnelles, refus de continuer à utiliser l’application. 
  I2 : Informations sur les déplacements des personnes ou sur le motif du  déplacement : sentiment d’atteinte à la 
vie privée sans préjudice irrémédiable, refus de continuer à utiliser l’application. 
  I3 : Information sur le graphe de proximité d’une personne : sentiment d’atteinte à la vie privée sans préjudice 
irrémédiable, refus de continuer à utiliser l’application, installation de difficultés relationnelles (hypochondrie 
agiographie). 
  I4 : Informations sur les données personnels : sentiment d’atteinte à la vie privée sans préjudice irrémédiable, refus 
de continuer à utiliser l’application. 
 
4.2.2  Quelles sont les principales menaces qui pourraient permettre la réalisation du risque ? 
Les menaces peuvent se décliner par type de support ciblé[1] (téléphone mobile, serveur, communications) : 
   •  M1 : Utilisation d’informations disponibles sur le téléphone mobile et résultant d’une utilisation conforme du 
protocole pour avoir des informations sur l’état de santé d’une personne (par exemple, obtention du statut “à risque” 
après avoir utilisé l’application en présence d’une seule personne). Cette information peut être obtenue fortuitement 
(personne qui rencontre peu d’autres personnes) ou de manière délibérée (activation de l’application ou de Bluetooth 
seulement en présence de la personne cible). Ce risque peut difficilement être annihilé puisqu’il peut correspondre à 
une utilisation normale de l’application (fonctionnalité). Cependant, l'utilisateur devient alors « à risque » et ne peut 
pas réitérer cette menace. 
  M2 : Utilisation d’informations disponibles sur le serveur pour construire le réseau d’interactions sociales des 
personnes diagnostiquées positives ou à risque à partir des pseudonymes de leurs contacts (à travers l’analyse des 
listes de contacts et des estampilles temporelles associées).  
  M3 :  Négligence sur le serveur conduisant à une fuite de données ou exploitation de vulnérabilité pour déterminer les 
pseudonymes correspondant à une même personne et son risque d’exposition. 
  M4 :  Observation de communications Bluetooth et recoupement avec des pseudonymes présents sur le serveur (à 
l’aide d’une collusion avec le gestionnaire du serveur ou via une fuite de données M3) pour tracer les parcours 
d’utilisateurs de l’application. 
  M5 : Observation de l'écran de l'utilisateur à son insu ou non, pour y lire les information rentrées ou affichées.  
 
[1]                Notons cependant que certaines menaces peuvent impliquer plusieurs  supports (serveur et communications Bluetooth par exemple). 
                                              
11 https://pro.tousanticovid.gouv.fr 
AIPD - TousAntiCovid 
 
22 
 

 
 
 
 
4.2.3  Quelles sources de risques pourraient-elles en être à l'origine ? 
 Il  faut considérer trois catégories principales de sources de risques : 
   •  S1 : Les utilisateurs de l’application qui peuvent tenter de détecter si une personne est diagnostiquée positive, rendre le 
service indisponible, tromper les mécanismes d’authentification, générer de fausses alertes, de faux contacts, etc. Ils 
peuvent aussi tenter de décompiler l’application et d’en changer le comportement, ou installer une version de 
l’application différente de celle qui figure sur les plateformes officielles (volontairement ou pas)[1]
  S2 :  Le gestionnaire du serveur qui peut accéder à toutes les données stockées sur celui-ci et potentiellement modifier 
son code. Il peut vouloir combiner et corréler toutes les informations obtenues (et d'autres informations publiques), 
par exemple  pour obtenir des informations sur le réseau d’interactions sociales. 
  S3 :  Les tiers malicieux  qui peuvent intercepter ou observer des communications par exemple Bluetooth 
(éventuellement avec une grande antenne pour couvrir une plus grande zone) ou réseau (ISP, faux AP Wifi 
ouvert,…), pour déterminer notamment le pseudonyme utilisé par une application ou tenter d’inférer d’autres 
informations comme l’état d’une personne (à risque, diagnostiquée positive, etc.). Ils peuvent aussi tenter de pénétrer 
dans un système et d’exploiter ses vulnérabilités pour obtenir des informations, les modifier ou les effacer. 
  S4 : Les tiers malicieux ou curieux qui peuvent lire les informations affichées sur un écran qui n'est pas le leur.  
  
On peut distinguer pour chaque catégorie des sources de risques dotées de moyens plus importants (par exemple, utilisateur 
profane ou expert, malicieux  ou simplement curieux) ou agissant de manière individuelle, en groupe (collusions) ou pour le 
compte d’un État (doté de prérogatives spécifiques, par exemple pour exiger certains accès dans le cadre d’enquêtes judiciaires). 
Ces distinctions, qui ont une incidence sur la vraisemblance du risque, sont présentées dans l’Annexe 1. On précise ici pour 
chaque menace les moyens dont doit disposer la source de risque pour la réaliser. 
S’agissant des menaces identifiées dans la partie 4.2.2, elles peuvent être mises en œuvre par les sources de risques suivantes : 
  M1 : S1  
  M2 : S2 
  M3 : S2, S3 
  M4 : collusion entre S2 et S3 (par exemple, une agence de renseignement déployant des antennes Bluetooth et exigeant 
l’accès aux données du serveur) 
  M5 : S4  
 
[1] Le fait qu’un utilisateur modifie son application ou utilise une application qui diffère de la version officielle ne conduit pas à des risques 
nouveaux par rapport aux menaces de rejeu puisque  les seules  actions possibles  de l’application consistent à envoyer des pseudonymes 
(déclarations de positivité ou requêtes) : si ces  pseudonymes sont réels mais proviennent d’autres applications, la menace est identique à celle 
d’un rejeu  ; s’ils sont fabriqués  par l’application, ils ne correspondent à aucune entité existante et ne sont pas reconnus. 
 
4.2.4  Quelles sont les mesures initiales, parmi celles identifiées, qui contribuent à traiter le risque ? 
  C1  :  Les pseudonymes  utilisés par l'application changent  périodiquement afin d'éviter de  tracer le  propriétaire du 
téléphone mobile en observant uniquement les messages diffusés en Bluetooth. 
  C2 : Une publication du code en open source et un audit régulier du serveur peuvent permettre de s’assurer de son bon 
comportement. De plus, un cloisonnement et une segmentation du backend en plusieurs zones avec des rôles différents 
ainsi qu'une information temporelle restreinte liée aux contacts permet de limiter le croisement d’information. En outre, 
les personnes diagnostiquées positives pourraient envoyer de manière anonyme les pseudonymes de leurs contacts 
séparément (un par un) et dans un ordre aléatoire à travers un nœud relais (proxy) pour dissimuler les liens entre ces 
contacts. La sécurité de ce proxy pourrait également être renforcée par l’usage d’un environnement sécurisé (TEE).  
  C3 : Les informations stockées sur le serveur pourraient être chiffrées avec une clef possédée par l’application. Le 
choix d’un hébergeur certifié permet de s’assurer d’une réduction des négligences d’exploitation. 
  C4 : Les données sont enregistrées dans des zones chiffrées (Keychain).  
 
4.2.5  Comment estimez-vous la gravité du risque, notamment en fonction des impacts potentiels et des 
mesures prévues ? 
En prenant comme référence l’échelle de gravité proposée par la CNIL  dans son document « Analyse d’impact relative à la 
protection des données – Les bases de connaissances », on obtient les niveaux de gravité suivants pour les impacts identifiés 
dans la partie 4.2.1 : 
   •  I1 : Informations sur l’état de santé d’une personne : harcèlement, stigmatisation, discrimination, difficultés 
relationnelles. 
Gravité 3 (importante) :  conséquences significatives que les personnes devraient pouvoir surmonter mais avec des 
difficultés réelles et significatives. 
  I2 :  Informations sur les déplacements des personnes : sentiment d’atteinte à la vie privée sans préjudice irrémédiable, 
refus de continuer à utiliser l’application. 
Gravité 2 (limitée) :  désagréments significatifs que les personnes pourront surmonter malgré quelques difficultés. 
  I3 :  Information sur le graphe de proximité d’une personne : sentiment d’atteinte à la vie privée sans préjudice 
irrémédiable, refus de continuer à utiliser l’application 
Gravité 2 (limitée) :  désagréments significatifs que les personnes pourront surmonter malgré quelques difficultés. 
AIPD - TousAntiCovid 
 
23 
 

 
 
 
 
  I4 : Informations sur les données personnels : sentiment d’atteinte à la vie privée sans préjudice irrémédiable, refus 
de continuer à utiliser l’application. 
Gravité 2 (limitée) :  désagréments significatifs que les personnes pourront surmonter malgré quelques difficultés. 
 
4.2.6  Comment estimez-vous la vraisemblance du risque, notamment au regard des menaces, des sources de 
risques et des mesures prévues ? 
 
  I1 : Informations sur l’état de santé d’une personne : harcèlement, stigmatisation, discrimination, difficultés 
relationnelles. 
Vraisemblance 2 (limitée) : Ce risque est lié à la menace M1 qui est simple à mettre en œuvre mais qui comporte des 
inconvénients pour la source de risques (classée « à risque »). Ce risque d’isoler une personne via sa propre application 
est bornée en temps et donc en surface d’impact. 
  I2 :  Informations sur les déplacements des personnes : sentiment d’atteinte à la vie privée sans préjudice irrémédiable, 
refus de continuer à utiliser l’application. 
Vraisemblance 1 (négligeable) : Ce risque est lié à la menace M4 qui requiert une collusion entre S2 et S3 ainsi que des 
moyens importants et n’est possible que dans des contextes très spécifiques. 
  I3 : Information sur le graphe de proximité d’une personne : sentiment d’atteinte à la vie privée sans préjudice 
irrémédiable, refus de continuer à utiliser l’application 
Vraisemblance 1 (négligeable) : Ce risque est lié à la menace M2 qui est possible uniquement si le code du serveur est 
modifié afin de stocker et manipuler plus de données, de plus le résultat est incertain et de faible intérêt pour la source 
de risques. 
  I4 : Informations sur les données personnels : sentiment d’atteinte à la vie privée sans préjudice irrémédiable, refus 
de continuer à utiliser l’application. 
Vraisemblance 2 (limitée) : Ce risque est lié à la menace M5 inhérente à la présentation du passe sanitaire par l’utilisateur 
à des personnes habilitées au contrôle qui pourraient en profiter pour enregistrer le passe sanitaire avec un dispositif 
tiers (caméra, TousAntiCovid, etc.)  
4.3  Modification non désirées de données 
4.3.1  Quels pourraient être les principaux impacts sur les personnes concernées si le risque se produisait ? 

  I4 : Déclenchement d’une fausse alerte : Engendrer éventuellement des troubles psychologiques pour une personne 
ou engendrer des incidences sur ses conditions de vie (personnelle et professionnelle, notamment en réduisant ses 
déplacement, ses contacts) avec la réception d’une notification de conduite à tenir liée à un risque non effectif . 
 
4.3.2  Quelles sont les principales menaces qui pourraient permettre la réalisation du risque ? 
Les principales menaces sont les suivantes 
  M5 :  Rejeux des communications Bluetooth d'une personne diagnostiquée positive. 
  M6 :  Modification des informations d’une personne donnée suite à une intrusion sur le serveur ou à un abus de droits. 
  M7 :  Utilisation du QR code fournit par la  SI-DEP (communiqué aux utilisateurs diagnostiqués positifs afin qu’ils 
puissent s’ils le  souhaitent envoyer leur historique de proximité  au serveur) par une tierce personne et non par la 
personne réellement diagnostiquée positive. 
  M8 : menaces en lien avec l’application : compromission du code source 
4.3.3  Quelles sources de risques pourraient-elles en être à l'origine ? 
On considère les mêmes sources de risques que dans la partie précédente (4.2.3). 
S’agissant des menaces identifiées dans la partie 4.3.2, elles peuvent être mises en oeuvre par les sources de risques suivantes : 
  M5 : S1, S3 
  M6 : S2, S3 
 
M7 : S1, S3 
 
4.3.4  Quelles sont les mesures, parmi celles identifiées, qui contribuent à traiter le risque ? 
  C4 : Durée de vie limitée  des pseudonymes échangés avec d’autres applications et mécanisme anti-rejeux. 
 
C5 : Un QR code ne peut être utilisé qu’une fois et a une durée de vie limitée 
 
C6 : mesures pour s’assurer que les applications qui communiquent avec les serveurs en back end sont bien les 
applications conformes à celle mises en ligne sur les stores 
4.3.5  Comment estimez-vous la gravité du risque, notamment en fonction des impacts potentiels et des 
mesures prévues ? 
   I4 :  Déclenchement d’une fausse alerte :  Rendre anxieux une personne ou engendrer des incidences sur ses conditions 
de vie (personnelle et professionnelle) avec la réception d’une notification de conduite à tenir liée à un risque non 
effectif. 
Gravité 2 (limitée) :  désagréments significatifs que les personnes pourront surmonter malgré quelques difficultés. 
 
AIPD - TousAntiCovid 
 
24 
 

 
 
 
 
4.3.6  Comment estimez-vous la vraisemblance du risque, notamment au regard des menaces, des sources de 
risques et des mesures prévues ? 
  I4 :  Déclenchement d’une fausse alerte : Rendre anxieux une personne ou engendrer des incidences sur ses conditions 
de vie (personnelle et professionnelle) avec la réception d’une notification de conduite à tenir liée à un risque non 
effectif. 
Vraisemblance 2 (limitée)  : Ce risque est lié aux menaces M5 et M6 qui requièrent des moyens importants. La faible 
durée de vie du QR code rend M7 également limité. 
 
4.4  Disparition de données 
4.4.1  Quels pourraient être les principaux impacts sur les personnes concernées si le risque se produisait ? 

  I5 : Absence de notification de  risque :  ne pas prévenir une personne du risque encouru, et perdre par la  même 
l’opportunité éventuelle d’être diagnostiquée le cas échéant de manière anticipée. 
 
4.4.2  Quelles sont les principales menaces qui pourraient permettre la réalisation du risque ?  
  M8 :  Brouillage des communications Bluetooth interdisant à des applications de capturer les pseudonymes diffusés. 
  M9 :  Panne matérielle ou logicielle sur le serveur 
  M10 :  Panne réseau rendant le serveur indisponible 
  M11 :  Attaque par déni de service rendant le serveur indisponible 
  M12 :  Modification ou suppression des informations d’une personne donnée suite à une intrusion sur le serveur ou à un 
abus de droits 
4.4.3  Quelles sources de risques pourraient-elles en être à l'origine ? 
On considère les mêmes sources de risques que dans la partie précédente (4.2.3). 
S’agissant des menaces identifiées dans la partie 4.4.2, elles peuvent être mises en oeuvre par les sources de risques suivantes : 
   •  M8 : S1, S3 
  M9 : S2 
  M10 : S3 
  M11 : S3 
 
M12 : S2, S3 
 
4.4.4  Quelles sont les mesures, parmi celles identifiées, qui contribuent à traiter le risque ? 
  C6 : Redondance des connexions réseau pour traiter le risque de panne réseau rendant le serveur indisponible 
  C7 :  Protection anti DDoS pout traiter le risque d’attaque par déni de service du serveur rendant le serveur indisponible 
  C8 : Mise en place d’une architecture haute-disponibilité pour traiter le risque des pannes matérielle rendant le serveur 
indisponible 
 
4.4.5  Comment estimez-vous la gravité du risque, notamment en fonction des impacts potentiels et des 
mesures prévues ? 
   I5  :  Absence de notification de risque :  ne pas prévenir une personne  du  risque encouru. 
Gravité 2 (limitée) :  désagréments significatifs que les personnes pourront surmonter malgré quelques difficultés. 
 
4.4.6  Comment estimez-vous la vraisemblance du risque, notamment au regard des menaces, des sources de 
risques et des mesures prévues ? 
  I5  :  Absence de notification de risque :  ne pas prévenir une personne du risque encouru. 
Vraisemblance 1 (négligeable) : Ce risque est lié aux menaces M8, M9, M10et M11 qui si-ont traitées par les mesures C6, 
C7 et C8. M12 requière des moyens importants. 
 
AIPD - TousAntiCovid 
 
25 
 

Document Outline