L’utilisation d’applications mobiles implique très souvent un traitement de données personnelles : ces données sont soit fournies par les utilisateurs, soit collectées directement par l’application lorsqu’elle accède aux ressources présentes sur son smartphone ou sa tablette. Dans ce dernier cas, l’application demande l’accord de l’utilisateur via un système mis à disposition par les systèmes d’exploitation : les autorisations.
Qu’est-ce que l’autorisation ?
Les autorisations d’accès (ou « autorisations ») mises en œuvre dans le système d’exploitation du terminal mobile sont des dispositifs permettant à l’utilisateur de choisir quelles fonctionnalités et données sont accessibles à chacune de leurs applications mobiles.
Grâce à ces dispositifs, l’utilisateur choisit d’autoriser ou non l’accès aux applications aux capteurs (accéléromètre, localisation, luminosité, objectif photo, microphone, etc.) ou en mémoire (stockage de fichiers, photos, vidéos, sons, carnet de contacts, historiques divers, etc.) Ce sont des terminaux mobiles.
La grande majorité des autorisations visent uniquement à donner ou bloquer l’accès technique à certaines ressources protégées, sans tenir compte des objectifs (ou finalités) pour lesquels les applications le demandent. Il s’agit donc d’autorisations « techniques » qui ne réglementent pas l’usage pour lequel les informations peuvent ou non être traitées. Recommandations de la CNIL concernent ce type d’autorisations.
► Voir la recommandation sur les applications mobiles, partie 8.3.1.
Les autorisations doivent être distinguées de l’obtention du consentement
Les autorisations techniques sont très utiles pour respecter la vie privée. Ils permettent aux utilisateurs de bloquer techniquement l’accès à certaines données, garantissant ainsi confidentialité des informations. Ce mécanisme offre un moyen simple et direct de préserver leur vie privée (voir recommandation, partie 8.3.1, p. 78).
Concrètement, en acceptant ou en refusant des autorisations, l’utilisateur comprend quelles données il partage avec l’application. Cela lui permet de repérer les demandes excessivescomme une lampe de poche qui demande l’accès aux contacts.
Cependant, ces autorisations « techniques » ne sont pas conçues pour recueillir le consentement les utilisateurs, au sens du RGPD et de la Loi Informatique et Libertés :
- En fait, ils visent uniquement à donner ou bloquer l’accès aux ressources et informations protégées du terminal mobile indépendamment des finalités poursuivies par l’éditeur de l’application. Le fournisseur du système d’exploitation suggère uniquement d’expliquer dans la demande pourquoi l’accès est demandé. Ces Des autorisations peuvent donc être requises dans des situations où le consentement de l’utilisateur n’est pas requis par la réglementation. Par exemple, l’accès à la localisation est dispensé de consentement pour le fonctionnement même d’une application de navigation puisque ces données sont nécessaires au service. Cependant, le fournisseur du système d’exploitation exige que l’éditeur demande l’autorisation d’accéder à ces données.
- Même lorsque le consentement est requis, un simple la demande d’autorisation ne permet pas toujours d’obtenir un consentement libre, spécifique, éclairé et sans équivoque, conformément au RGPD ou à la loi Informatique et Libertés (article 82). Elle n’est suffisante que dans des cas limités, par exemple si l’autorisation concerne un seul traitement, une seule finalité et un seul destinataire des données (voir la recommandation, partie 8.3.2). Dans la plupart des cas, il est nécessaire d’utiliser une plateforme de gestion du consentement en plus de la demande d’autorisation.
Que retenir des recommandations de la CNIL en matière d’autorisations ?
Meilleures pratiques pour les fournisseurs de systèmes d’exploitation
La recommandation fournit un certain nombre de bonnes pratiques à destination des fournisseurs d’OS dans le cadre de la mise en place des autorisations, concernant opérations qui devraient être couvertesle portée des autorisations ou le niveau d’information qu’ils devraient permettre.
Les fournisseurs d’OS sont notamment encouragés à concevoir leur système d’autorisations de manière à permettre à l’éditeur de choisir le plus finement possible l’étendue des autorisations. Ainsi, un système de permissions idéal permet à l’éditeur de choisir :
- le degré de précision les données fournies en fonction de la finalité poursuivie (ex : localisation plus ou moins précise) ;
- le portée matérielle autorisation (ex : accès aux photos sélectionnées plutôt qu’à la galerie média globale) ;
- le durée pendant la durée de l’autorisation (ex : activation ponctuelle de l’autorisation ou pour une durée prédéterminée).
Le but des autorisations est de permettre aux gens de contrôler leurs données ; ils ne doivent en aucun cas conduire à privilégier les applications conçues par le fournisseur de l’OS.
► Voir recommandation, partie 8.3
L’éditeur doit choisir les autorisations à mettre en œuvre et identifier les situations dans lesquelles le consentement doit être recueilli
L’éditeur doit choisir les autorisations qu’il souhaite mettre en œuvre pour le fonctionnement de son application. En ce sens, la recommandation oriente dans un premier temps les choix de l’éditeur d’application concernant l’utilisation des autorisations.
Il doit notamment identifier :
- au cas par cas, parmi les autorisations mises à disposition par l’OScelui qui permet de remplir les objectifs poursuivis, tout en respectant le principe de minimisation : lorsque l’OS le permet, la CNIL recommande à l’éditeur de choisir, pour chaque autorisation, la version la moins intrusive qui répond à ses besoins.
- en tant que responsable du traitement, les situations dans lesquelles le règlement requiert le consentement en plus de l’autorisation imposée par le fournisseur du système d’exploitation. Pour ce faire, il faudra déterminer si le le traitement lié aux autorisations implique des opérations de lecture/écriture qui nécessitent le consentement de l’utilisateur (article 82 de la loi Informatique et Libertés). Dans ce cas, mettre en œuvre une plateforme de gestion du consentement (« Plateforme de gestion du consentement » ou CMP) peut être nécessaire en complément de la demande d’autorisation « technique ». La recommandation guide les développeurs sur le moyen d’obtenir le consentement dans ce cadre. À cet égard, la CNIL considère comme une bonne pratique de recueillir les consentements de manière contextuelle à partir des actions entreprises plutôt qu’une seule sélection initiale.
► Voir la recommandation sur les applications mobiles, partie 5.5 et partie 6.2.3, pp. 52-53
Comment articuler autorisation et recueil du consentement ?
Lorsqu’un CMP et une demande d’autorisation sont présentés à l’utilisateur, leur articulation ne doit pas générer de confusion pour ces derniers.
Le consentement peut être obtenu avant ou après avoir demandé l’autorisation. Toutefois, la CNIL recommande au développeur, en lien avec l’éditeur responsable du traitement, de s’assurer que cette articulation se fait de manière pour favoriser la compréhension des utilisateurs.
L’infographie ci-dessous précise comment cette articulation peut se faire afin d’éviter toute confusion pour l’utilisateur :
Consultez l’infographie au format PDF
Ce schéma concerne l’articulation entre la fenêtre de requête (CMP) et les autorisations techniques, et non les autorisations visant à autoriser ou refuser l’exécution de certaines actions en vue d’une finalité précise (autorisations « for Purpose »).
Comme le montre le schéma précédent, le responsable du traitement est libre de choisir l’ordre dans lequel l’autorisation et la CMP sont présentées (A ou B).
Le responsable de traitement, pour mettre en œuvre son traitement de données doit, d’une part, pouvoir accéder techniquement aux données (autorisation) et, d’autre part, démontrer qu’il a obtenu le consentement conformément aux exigences fixées par le RGPD (CMP ). Si l’une ou l’autre de ces autorisations n’est pas accordée, la CNIL conseille de ne pas afficher la seconde demande pour éviter de solliciter inutilement les utilisateurs.
► Voir recommandation, partie 6.2.3
