Comment un éditeur peut-il garantir la conformité de son application mobile ?

La CNIL s’intéresse de près aux applications mobiles. Celles-ci font partie des thèmes prioritaires de contrôle pour l’année 2023 et la CNIL a publié cet été un projet de recommandation relative aux applications mobiles. Certaines exigences qui pèsent sur l’éditeur d’une application méritent une attention particulière afin d’être en conformité avec la protection des données : information et consentement de l’utilisateur, maitrise de l’appel des tiers. Décryptage.

Les applications mobiles font partie des thèmes prioritaires de contrôle de la CNIL pour l’année 2023 et s’inscrit dans son plan d’action relatif aux applications mobiles. Après la publication cet été du projet de recommandation relative aux applications mobiles[1], la dernière étape concernera le contrôle des acteurs sur la base des thèmes prioritaires de contrôle.

L’écosystème des applications mobiles comprend une pluralité d’acteurs : la plateforme (par exemple, Apple avec iOS et Google avec Android), l’éditeur de l’application (par exemple, Meta), les tiers impliqués tels que le développeur et le fournisseur de SDK. Cet article présente les problématiques propres aux éditeurs d’applications mobiles, maitrisant l’application et interlocuteur principal de l’utilisateur.

Rappelons tout d’abord que la réglementation sur la protection des données ne s’applique pas dans tous les cas. C’est par exemple le cas lorsque les applications fonctionnent en totale autonomie (c’est-à-dire un traitement de données sur seule décision de l’utilisateur, en local et sans intervention de l’éditeur, par exemple une calculatrice ou une authentification biométrique proposée par le système d’exploitation).

En revanche, dès lors que l’éditeur intervient sur les données de l’utilisateur, dès lors que l’application fourni un service associé impliquant un accès et/ou manipulation des données dans un environnement externe (par exemple une galerie photo avec sauvegarde cloud), le règles de protection des données s’appliquent. L’éditeur de l’application a alors une responsabilité dans les traitements réalisés par l’application, pour son compte ou celui d’un tiers[2], car l’éditeur a la maitrise de ce que l’application réalise et intègre.

Les obligations qui pèsent sur l’éditeur relèvent de la directive ePrivacy (et sa transposition à l’article 82 de la Loi « Informatique et Libertés ») et du RGPD. L’application de ces réglementations ne concerne pas spécifiquement les applications mobiles puisqu’elles s’appliquent indépendamment du type de technologie utilisée. Cependant, certaines exigences méritent une attention particulière de la part des éditeurs en ce qui concerne leur mise en œuvre dans le cadre d’applications mobiles.

1. Obtenir les permissions et consentements de l’utilisateur

Figure 1 : Exemple de permission technique du système d’exploitation (iOS)

Il convient de distinguer ce qui relève d’une simple permission (technique) de ce qui relève d’un consentement (juridique) de l’utilisateur.

Le système d’exploitation interroge l’utilisateur avec une permission technique pour accéder à certaines ressources et informations (capteurs tel que géolocalisation, répertoire de contact, identifiant matériel tel que l’adresse MAC, etc.) – voir image d’exemple ci-contre.

Les permissions (techniques) respectent des conditions qui sont propres aux systèmes d’exploitation[3] (par exemple, le système d’exploitation demande une permission de l’utilisateur pour que l’application accède au capteur de géolocalisation – voir image d’exemple ci-contre –alors que cela ne sera pas nécessairement le cas pour l’accès à un identifiant matériel).

En résumé, l’éditeur ne peut se contenter du processus technique de permission pour tenir lieu de consentement conforme à la réglementation.

a) Quand demander un consentement ?

L’éditeur doit porter une attention à la pluralité de ressources et d’informations mises à disposition d’une application par le terminal de l’utilisateur (identifiants matériels ou générés par les systèmes d’exploitation tel que IDFA ou IDFV pour Apple et Android ID pour Google, galerie photo, répertoire de contact, capteurs tel que géolocalisation) dont l’accès à distance est régi par la directive ePrivacy et peut requérir un consentement. Les lignes directrices de la CNIL relatives au dépôt de cookies et autres traceurs s’appliqueront donc.

Un consentement est requis par la directive ePrivacy dès lors que la lecture/écriture (distante) de l’information n’est pas nécessaire au fonctionnement de l’application. Cela exclut notamment les fonctionnalités demandées par l’utilisateur. Dans son projet de recommandation la CNIL présente le tableau suivant pour déterminer si un consentement de l’utilisateur est requis :

Figure 2 : Tableau de détermination d’une nécessité de consentement, issu du Projet de recommandation de la CNIL relative aux applications mobile

L’éditeur doit également porter attention au design de l’application pour que la fonctionnalité puisse être expressément demandée par l’utilisateur, afin de bénéficier de l’exemption de consentement.

De plus, si l’accès à la ressource ou à l’information (par exemple, un identifiant généré par le système d’exploitation) est nécessaire au fonctionnement de l’application et poursuit dans le même temps une autre finalité non exemptée de consentement (par exemple, un accès à l’IDFA pour la double finalité de sécuriser l’application et réaliser une mesure d’audience, à l’instar dans l’environnement web du cookie reCAPTCHA), un consentement sera nécessaire pour cette seconde finalité[4].

Enfin, si un consentement n’est pas requis en vertu de la directive ePrivacy, il peut être nécessaire au regard du RGPD (en tant que base légale d’un traitement).

b) Permettre le retrait et l’absence de consentement

Lorsque le consentement de l’utilisateur est demandé, celui-ci doit avoir la possibilité de refuser de le donner et de le retirer à tout moment (le consentement étant libre et ne pouvant pas conditionner l’accès à un service). L’éditeur doit donc prévoir :

• La possibilité pour l’utilisateur de retirer aisément son consentement (ex. bouton flottant ou lien dans le footer du site internet suivant les recommandations de la CNIL) ;
• Une alternative technique pour un fonctionnement de l’application « sans consentement », notamment dans le cadre d’utilisation de SDK.

 

2. Informer dans l’environnement applicatif

Dans la continuité des lignes directrices du G29 sur la transparence, la CNIL précise dans son projet de recommandation qu’une information en un seul niveau – dans l’espace limité d’une application – ne répond « souvent » pas à l’objectif de simplicité et de concision.

Figure 3 : Illustrations de fenêtres de consentement, issues des Recommandations de la CNIL relatives aux cookies et autres traceurs

L’éditeur doit donc par défaut prévoir deux niveaux d’information, comme : une information partielle (par exemple, une page résumant les traitements réalisés) et renvoyant à un espace d’information complète (par exemple, une Politique de confidentialité intégrée à l’application ou accessible sur un site internet) – comme recommandé par le CNIL[5] (cf. images ci-contre).

Concernant les permissions (techniques) demandées à l’utilisateur par le système d’exploitation (pop-ups pour accéder à la géolocalisation, déclencher le micro, etc. vu plus haut), la CNIL indique qu’il est nécessaire de compléter l’information fournie par le système. En effet, il est impossible pour le système d’exploitation de connaitre la finalité d’accès à une ressource. De plus, rappelons que l’éditeur devra souvent ajouter à l’information fournie à l’utilisateur le caractère obligatoire ou facultatif de chaque traitement et les conséquences du refus.

En résumé, lors de la construction du storyboard d’une application il est recommandé à l’éditeur de prévoir a minima :

• Pour l’onboarding de l’utilisateur :
  • Une page d’information « niveau 1 » des traitements de données (une page d’information résumée), renvoyant à une page d’information « niveau 2 » des traitements de données (une politique de confidentialité) ;
  • Une page dédiée au(x) consentement(s) pour l’accès aux ressources et informations du terminal ne nécessitant pas une permission technique par le système d’exploitation (par exemple, selon le système d’exploitation, les identifiants matériels ou générés).
• Pour l’accès aux ressources et informations soumises à une permission du système d’exploitation (par exemple, le capteur de géolocalisation) : de tirer parti des possibilités de personnalisation des fenêtres de permissions du système pour éviter la création d’une page complémentaire de consentement.

3. Maitriser l’appel aux tiers

a) Encadrer l’appel aux SDK et API tiers

Le développement d’applications implique l’utilisation répandue de SDK et API, qui permettent d’intégrer un outil existant à l’application, afin de ne pas avoir à le créer soi-même (par exemple, faire appel à l’API de Google Maps pour s’épargner la création d’une carte du monde). Les SDK et API étant susceptibles d’impliquer des traitements de données, l’éditeur doit impérativement encadrer leur intégration pour en garantir la conformité.

Le premier réflexe à avoir est de comprendre le fonctionnement du SDK pour savoir si son utilisation requiert un consentement ou implique un traitement de données personnelles. Le second réflexe est de savoir pour qui le SDK traite les données. 3 situations sont possibles :

• Le SDK traite des données pour le compte de l’éditeur: la sous-traitance du fournisseur de SDK pour le compte de l’éditeur doit être encadrée (conformément à l’article 28 du RGPD) ;
• Le SDK traite des données pour le compte de l’éditeur et les réutilise pour son propre compte(un parallèle peut à nouveau être fait avec le cookie reCAPTCHA qui procède à de la mesure d’audience pour le compte de Google) : une autorisation doit être délivré par l’éditeur au fournisseur de SDK. La CNIL rappelle et souligne dans son projet de recommandation que ces traitements ultérieurs par le fournisseur de SDK doivent se conformer aux conditions de la réutilisation de données confiées par un responsable de traitement ;
• Le SDK traite des données uniquement pour son propre compte (tel que certains cookies tiers dans l’environnement web) : un accord de responsabilité conjointe sur la collecte doit être prévu entre le fournisseur de SDK et l’éditeur (le fournisseur de SDK étant par la suite responsable distinct des traitements de statistiques, publicité, etc. qu’il effectue).

L’éditeur doit donc porter une attention particulière aux conditions contractuelles (par exemple, Conditions Générales) qui peuvent accompagner l’utilisation du SDK et, le cas échéant, les renégocier pour tenir compte de la situation et des qualifications en matière de protection des données. Ce contrat d’utilisation du SDK est primordial en ce qu’il permet :

• De connaitre les traitements réalisés par le SDK et les éventuelles obligations de ce dernier en matière d’information des personnes et de collecte du consentement. La nécessité d’une bonne gestion et répartition des obligations entre chaque partie dans ce type de situation a d’ailleurs récemment été rappelée par la sanction CRITEO;
• De protéger l’éditeur si le fournisseur de SDK réalise des traitements en dehors ce qui est instruit ou autorisé par l’éditeur (conformément à la répartition de responsabilité prévue à l’article 82 du RGPD).

S’il ne lui est pas possible d’encadrer la relation contractuelle avec le fournisseur d’un SDK procédant à la lecture/écriture (distante) et/ou au traitement de données personnelles des utilisateurs de l’application, l’éditeur doit recourir un autre SDK.

b) Maitriser l’utilisation du SDK de la plateforme

Certaines fonctionnalités d’une application (par exemple, les notifications push) doivent obligatoirement passer par le cadre du SDK de l’éditeur de la plateforme (par exemple, le SDK iOS pour Apple et Android pour Google).

Cela peut poser des questions de conformité à la protection des données, relatives à la mise en place de mesures de sécurité adaptées à la sensibilité des données et la bonne information des destinataires au sein des mentions d’information, comme l’explique le développeur David Libeau dans son article Push notifications are a privacy nightmare.

c) Encadrer le recours à un développeur externe

En cas de recours à un développeur externe, l’éditeur devra s’attacher à :

• Préciser au cahier des charges les traitements souhaités dans l’application: cela permettra de limiter le développeur à l’intégration de SDK ne dépassant pas les instructions données. Dans tous les cas, le devoir de conseil développeur entrera en jeu sur les tenants et aboutissants de l’intégration des SDK.
• Intégrer le privacy by design (c’est-à-dire la prise en compte des principes de la protection des données personnelles dès la conception du traitement) dans les exigences contractuelles relatives au développement de l’application.

Pour conclure, l’éditeur ne doit pas négliger les points d’attention usuels en matière de conformité pour la protection des données personnelles (minimisation, durées de conservation, sécurité des traitements, etc.) et doit les documenter. S’agissant des applications mobiles, la CNIL recommande la mise en place de mesures permettant de respecter le principe de minimisation pour les permissions (techniques) : mise en place des « runtime permissions » (c’est-à-dire une demande d’accès au moment où la ressource devient nécessaire) plutôt que des « intall-time permissions » (c’est-à-dire une demande d’accès à l’installation de l’application), afin d’empêcher la collecte de données si la fonctionnalité visée n’est jamais utilisée. Cela permet aussi à l’utilisateur de profiter d’une information mieux contextualisée à l’attention de l’utilisateur.

A la fin de son projet de recommandation, la CNIL propose une liste de vérifications pour chaque acteur de l’écosystème des applications mobiles (éditeur, développeur, fournisseur de SDK, etc.) qui peut servir de base de travail.

Le projet de recommandation de la CNIL relative aux applications mobiles étant soumis à consultation publique jusqu’au 8 octobre, la version définitive devrait être publiée l’année prochaine.

[1] Le projet de recommandation s’applique à tous les environnements qui permettent la distribution d’applications (ordinateurs, montres, IoT, voitures, etc.).

[2] La CNIL rappelle dans son projet de recommandations que l’éditeur reste responsable conjointement de la collecte des données et fait références dans l’environnement web à la décision « Éditions Croque Futur » (Conseil d’Etat, n° 412589) et sa délibération n° SAN-2021-013 du 27 juillet 2021.

[3] Ces garde-fous techniques sont à la discrétion des fournisseurs de système d’exploitation et peuvent faire débat, à l’image du blocage de suivi inter-app mis en place par Apple, critiqué par l’industrie publicitaire et soutenue par les associations de défense de la vie privée.

[4] Par exemple, sanction VOODOO relative au consentement pour le suivi publicitaire, rappelée par la CNIL dans son projet de recommandation.

[5] Délibération n° 2020-092 du 17 septembre 2020 portant adoption d’une recommandation proposant des modalités pratiques de mise en conformité en cas de recours aux « cookies et autres traceurs »