CADA Communication Applications bancaires biff.pdf

Résumé / synthèse de la position de la CNIL
Le présent rapport constitue un exemple concret des difficultés que peut présenter l’usage
des applications mobiles en matière de protection de la vie privée : l’usage mis en avant au
sein du présent rapport s’inscrit par exemple dans le contexte de recrudescence de la fraude
par  tromperie notamment via les réseaux sociaux ou les appels téléphoniques  (dite
« ingénierie sociale »), contre lesquels les professionnels tentent de lutter au moyen de
nouveaux dispositifs technologiques.
Les banques ont à cet égard de nombreuses obligations en matière de lutte contre la fraude,
dont celles de mettre en place des mesures visant à prévenir ces fraudes. Elles sont par ailleurs
soumises, sauf exception, à l’obligation de rembourser le client victime d’une opération
frauduleuse.
Dans ce contexte, certaines applications bancaires  exigent  des  utilisateurs  qu’ils  donnent
accès aux données de leur téléphone lorsqu’ils sont connectés, ce qui permettrait de détecter
un appel passé simultanément  et ainsi de détecter la présence d’un scénario de fraude
fréquent : la fraude dite « au faux conseiller bancaire ». Les données ainsi recueillies
permettent  à la fois  l’alimentation d’un score de risque pour détecter, en temps réel, une
opération frauduleuse et sont par ailleurs conservées pour gérer les réclamations liées aux
paiements non autorisés ou mal exécutés.
L’accès à ces données  a suscité des réactions des clients des banques ainsi que  l’envoi de
plaintes à la CNIL auprès de la direction de l’exercice des droits et des plaintes au mois de
novembre.
Cette actualité semble justifier que la CNIL se positionne sur cette question, au sein d’un
article à publier sur son site internet.

I.
Rappel du contexte
A. Les permissions dans l’environnement mobile
1. Les permissions sont des dispositifs mis en œuvre par les systèmes d’exploitation (operating
system ou OS) mobiles pour permettre aux utilisateurs de choisir quelles fonctionnalités
sont accessibles aux applications. Aujourd’hui, les applications n’ont, par défaut, qu’un accès
limité à ces fonctionnalités pour des raisons de sécurité et de protection de la vie privée. Le système
d’exploitation met dès lors à leur disposition des API leur permettant d’effectuer des requêtes afin de
se voir autoriser des fonctionnalités additionnelles, sous réserve que l’utilisateur, via une interface
fournie par l’OS, l’accepte.
2. Grâce à ces permissions, l’utilisateur a la possibilité de choisir quelles fonctionnalités il
souhaite utiliser et quelles données sont techniquement accessibles aux applications
mobiles qui en font la demande. Concrètement, il peut permettre ou non aux applications
d’accéder aux capteurs (accéléromètre, localisation, luminosité, objectif photo, microphone, etc.) ou
à la mémoire (stockage de fichiers, photos, vidéos, sons, carnet de contacts, historiques divers, etc.)
de son terminal mobile. Pour le cas des capteurs, leur accès est d’autant plus intrusif qu’ils peuvent
être activés ponctuellement à l’insu de l’utilisateur (ex : localisation activée en permanence en dehors
de l’utilisation de l’application), voire en continu.
3. En acceptant ou en refusant les permissions, l’utilisateur est informé des  données partagées  avec
l’application concernée. Cela lui permet de repérer des demandes excessives ou sans rapport avec la
fonctionnalité souhaitée comme, par exemple,  une  application de lampe torche qui demanderait
l’accès aux contacts. L’utilisateur peut, à tout moment, choisir d’accorder ou non et de retirer une
permission à une application. Ce mécanisme, mis en œuvre et généralisé par les fournisseurs d’OS,
offre à chaque utilisateur un moyen simple et direct de contrôler à quelles données  à caractère
personnel peut accéder chaque éditeur d’application.
4. La recommandation de la CNIL relative aux applications mobiles met en avant le rôle
clef joué par les permissions dans l’information et la maîtrise de l’utilisateur sur ses
données.  Elle  guide  les choix de l’éditeur d’application en matière d’usage des permissions1 et
précise par ailleurs comment articuler permissions et recueil du consentement des utilisateurs au
traitement de leurs données2.
B. La demande d’accès, par certaines applications mobiles bancaires
à certaines métadonnées relatives aux appels téléphoniques dans
un contexte de recrudescence  de la fraude par « ingénierie
sociale »
5. Les applications mobiles de certaines banques demandent l’accès à certaines données des ordiphones
de leurs clients, relatives aux appels en cours. Au sein du système d’exploitation Android, ces données
sont rendues accessibles à travers une permission demandée à l’utilisateur (ci-après, la « permission
« Téléphone »). Cette demande de permission résulte d’une mise à jour de leurs applications mobiles
1 CNIL, Recommandation relative aux applications mobiles, partie 5.5, p. 38
2 CNIL, Recommandation relative aux applications mobiles, partie 6.2.3, p. 52
4

• accéder à des informations contenues dans le téléphone (existence d’un appel et
éventuelle durée de l’appel) lors du déclenchement d’une opération via l’application mobile
afin d’alimenter un score de risque de fraude calculé par chaque banque selon ses propres
modalités ;
• déclencher ou non une conséquence opérationnelle (affichage d’un message d’alerte
au client, refus ou mise en suspens du paiement) en fonction d’un score de risque de fraude
établi sur la base d’un faisceau d’indices (existence d’une communication téléphonique,
montant de l’opération, âge de la victime, surface financière, etc.)6.
• Les conséquences opérationnelles dépendent toutefois des pratiques de chaque établissement
qui définissent les conséquences en fonction du score7.
18. Les opérations de traitement mises en œuvre par les banques sont les suivantes :
a) Collecte d’informations contenues  dans le téléphone du client  concernant l’existence d’un
appel en cours parfois enrichie, en fonction des paramétrages, de la durée de l’appel ;
b) Croisement des  informations collectées dans le téléphone du client avec des informations
détenues par la banque au sujet de son client8 ;
c) Calcul d’un score sur la base des étapes a) et b) ;
d) En fonction du score obtenu au point c), déclenchement d’une conséquence opérationnelle
choisie par le responsable du traitement.
e) Conservation des éléments afin de gérer les demandes de clients concernant des opérations
non autorisées ou mal exécutées.
B. Les finalités des traitements identifiés dans le contexte de l’accès aux
métadonnées relatives aux appels téléphoniques : la lutte contre la
fraude
19. Les opérations de traitement mises en œuvre poursuivent une finalité de lutte contre la
fraude9.
20. L’objectif mis en avant par les professionnels semble être celui de lutter contre la fraude externe, telle
que définie par l’arrêté du 3 novembre 201410 à savoir les « pertes liées à des actes de tiers visant à
commettre une fraude ou un détournement d’actif ou à enfreindre/tourner la loi ».
21. Votre rapporteur ne peut exclure que le dispositif soit également utilisé pour lutter contre la fraude
interne, définie comme les « perte liées à des actes visant à commettre une fraude ou un
10 Arrêté du 3 novembre 2014 relatif au contrôle interne des entreprises du secteur de la banque, des services de
paiement et des services d’investissement soumises au contrôle de l’Autorité de contrôle prudentiel et de
résolution. Disponible ici : https://www.legifrance.gouv.fr/loda/id/JORFTEXT000029700770.
7

33. Toutefois, la sécurisation du service n’apparaît pas uniquement destinée à prévenir les transactions
frauduleuses. En effet, elle l’est également dans le but de conserver des informations qui pourront,
par la suite, être analysées dans le cadre de l’examen par la banque d’une demande de remboursement
par le client afin de voir si une négligence de sa part peut être caractérisée ou non.
34. Dès lors, si le dispositif peut avoir un effet préventif contre la fraude, dans l’intérêt du client, il est
également mis en place dans l’intérêt du responsable du traitement : aussi bien pour empêcher la
réalisation de l’opération frauduleuse que pour démontrer une éventuelle négligence du client et ainsi
l’exonérer de son obligation de remboursement. Il apparaît donc en l’espèce qu’il ne s’agit pas
d’un usage de sécurisation du service  exclusivement  centré sur la protection de
l’utilisateur ni réalisé à sa demande expresse.
 En tout état de cause, les opérations de lecture/écriture ne sont pas
strictement nécessaires à un service demandé par l’utilisateur
35. Les professionnels relèvent  par ailleurs  que  les  prestataires de services de paiement  sont
soumis à certaines exigences en matière de sécurité à destination de l'utilisateur de
services de paiement. Il s’agit notamment de mettre en place des mécanismes de contrôle des
opérations qui leur permettent de déceler les opérations de paiement non autorisées ou frauduleuses
tenant compte des scénarios connus de fraude lors de la prestation de services de paiement20.
37. Sur ce point, votre rapporteur rappelle que la CNIL considère toutefois que la lutte contre la fraude,
bien que répondant à une finalité manifestement légitime,  n’est pas « strictement nécessaire  à la
fourniture d’un service de communication en ligne à la demande expresse de l’utilisateur ». Ainsi,
dans sa FAQ relative aux lignes directrices modificatives et la recommandation
« cookies et autres traceurs », la CNIL indique que les traceurs utilisés à des fins de lutte
contre la fraude, de manière générale, n’entrent pas dans les exemptions prévues par
l’article 82 de la loi21.
38. De  manière générale, la nécessité d’interpréter strictement les textes, rappelée par le rapporteur
public lors d’un contentieux devant le Conseil d’État22 portant sur les lignes directrices relatives aux
« cookies et autres traceurs », confirme l’interprétation stricte de la CNIL sur les exemptions visées à
l’article 82 de la loi de sorte à y intégrer des traceurs qui ne seraient pas « strictement nécessaires à
la fourniture du service ».
39.
21 Question n° 16, voir https://www.cnil.fr/fr/cookies-et-autres-traceurs/regles/cookies/FAQ
22 CE, n° 434684 – Association des agences conseil en communication et autres, 12 juin 2020, conclusions du
rapporteur public
11

45. À titre d’exemple, voici le message affiché sur l’une des applications bancaires lorsque la permission
Téléphone est refusée :
46. L’article 7.4 du RGPD souligne que le fait de conditionner la fourniture d’un service au consentement
à des données qui ne sont pas nécessaires à celui-ci est susceptible de remettre en cause sa liberté. Il
n’en fait pas un principe absolu mais invite à en tenir « le plus grand compte ». Comme l’a souligné
le rapporteur public dans ses conclusions, la clé réside dans l’existence d’alternatives
équivalentes et raisonnables à la disposition de l’utilisateur24. La Cour de justice de l’Union
européenne, dans son arrêt META du 4 juillet 202325, a également consacré la possibilité de proposer
(le cas échéant contre une rémunération appropriée) une alternative équivalente non accompagnée
des opérations de traitement de données nécessitant le consentement.
47. La question réside donc dans le fait de savoir si l’utilisateur qui refuse de consentir au
traitement des métadonnées en lien avec ses appels  et qui  ne peut plus utiliser son
application, dispose d’une alternative équivalente de sorte à ce qu’il puisse avoir accès
aux mêmes informations et réaliser les mêmes opérations que celles disponibles au
sein de son application bancaire.
24 Conclusions du rapporteur public pour la séance du 12 juin 2020 du Conseil d’Etat, concernant l’affaire n°
434684  –  Association des agences conseil en communication. Disponible ici :  https://www.conseil-
etat.fr/fr/arianeweb/CRP/conclusion/2020-06-19/434684?download pdf. Voir notamment, en page 10 : « La
clé nous paraît résider dans la nature du besoin que l’utilisateur cherche à satisfaire et, surtout, dans
l’existence, la disponibilité et l’accessibilité d’alternatives raisonnables permettant d’atteindre un résultat
équivalent »
25
CJUE, arrêt du 4 juillet 2023, C-252-21 (accessible sous ce lien :
https://curia.europa.eu/juris/document/document.jsf?text=&docid=275125&pageIndex=0&doclang=FR&mo
de=req&dir=&occ=first&part=1).
13

70.  Par ailleurs, le retrait technique de la permission au niveau des paramètres du système d’exploitation
n’offre pas un degré de simplicité équivalent à celui prévu pour en accepter l’usage. En effet, cette
solution proposée par le système d’exploitation ne permet aux utilisateurs de revenir sur leur choix,
application par application, qu’au sein des réglages offerts par le système d’exploitation.  Or, il
appartient aux éditeurs d’application se reposant sur cette solution pour recueillir le consentement
des  utilisateurs d’intégrer un mécanisme permettant à ces derniers d’accéder à ces réglages
directement dans l’application concernée (par exemple via un lien menant directement vers la section
appropriée des paramètres du système d’exploitation relatifs aux permissions accordées à
l’application)36.
  Le refus de donner suite au droit d’opposition au traitement subséquent
doit être justifié par l’existence d’un motif légitime impérieux pour le
traitement

72.  Selon l’article 21.1 du RGPD, en cas de recours à la base légale de l’intérêt légitime, la personne doit
en principe pouvoir exercer son droit d’opposition à tout moment. Le responsable du traitement ne
doit plus traiter les données pour cette finalité à défaut de démontrer qu’il existe des motifs légitimes
et impérieux pour le traitement qui prévalent sur les intérêts et les droits et libertés de la personne
concernée.






74.  Comme développé ci-dessus, si l’accès aux données « appel téléphonique en cours » et éventuellement
« durée de l’appel » nécessite le consentement des utilisateurs (avec la possibilité donc, de le retirer à
tout moment), les données consécutives à ces opérations peuvent être traitées sur la base de l’intérêt
légitime. Dans l’hypothèse où l’utilisateur a donné son consentement et que la banque conserve les


19

Conclusion

L’actualité relative à l’accès, par certaines applications mobiles bancaires, aux données du téléphone
des utilisateurs relatives aux appels à des fins de lutte contre la fraude justifie que la CNIL se
positionne sur cette question.

Cet article s’intégrerait dans les diverses actions menées au sujet des applications mobiles. La position
doctrinale ainsi établie permettra l’instruction des plaintes en cours et, le cas échéant, la conduite de
contrôles dans un second temps.

25