Applications mobiles : ce que la CNIL réserve aux développeurs

Natives, hybrides ou web progressives ? La CNIL englobe toutes ces options dans son projet de recommandation relative aux applications mobiles.

Le texte est soumis à consultation jusqu’au 8 octobre 2023. Son principal objectif : permettre aux parties prenantes de cet écosystème de déterminer leurs qualifications juridiques au sens du RGPD. Et les obligations qui en découlent.

La CNIL a défini cinq types d’acteurs : éditeurs, développeurs, fournisseurs de SDK, fournisseurs d’OS et fournisseurs de magasins d’applications.

Elle définit l’éditeur comme suit :

l’entité personne morale (ou l’entreprise individuelle d’une personne physique) qui met l’application à disposition des utilisateurs

Quant au développeur :

l’entité morale ou l’entreprise individuelle qui procède aux opérations techniques de développement de l’application, pour le compte et sur instruction de l’éditeur

Les deux profils peuvent se confondre en une entité unique.

Les éditeurs sont responsables de traitement quand…

Un éditeur peut être responsable des traitements réalisés lors du recours aux services proposés à travers l’application. On parle là de traiter des données issues de la gestion du compte et/ou des données nécessaires à l’utilisation desdits services.

L’éditeur peut aussi être responsables des traitements découlant d’opérations de lecture et/ou d’écriture qu’il réalise lui-même pour son compte. Exemple avec la lecture des identifiants mobiles :

– L’Identifiant publicitaire unique pour le suivi par des tiers
– L’identifiant du compte de l’utilisateur, lu par un fournisseur de magasin d’applications pour y personnaliser les suggestions (il agit alors en tant qu’éditeur)
– Ce même identifiant, lu par le fournisseur de l’OS pour améliorer des fonctionnalités (il agit alors en tant qu’éditeur d’apps système)

L’accès aux capteurs du terminal entre dans cette même catégorie, pour peu que les données soient transmises à travers un réseau. Idem pour l’accès aux données dans le cadre de fonctionnalités telles que la sauvegarde de fichiers, le chargement d’une photo de profil ou la découverte de contacts.

L’éditeur peut également être responsable – éventuellement de manière conjointe – de la lecture d’identifiants par un SDK tiers. Entre autres, si c’est à des fins de profilage des utilisateurs pour son compte ou d’amélioration de son service. Même chose dans le cas où le fournisseur du SRK réaliserait les opérations pour le compte de l’éditeur.

Les développeurs sont responsables (ou sous-traitants) quand…

Un développeur n’a pas de responsabilité au titre du RGPD s’il ne fait que fournir à l’éditeur le code de l’application. Et qu’il n’a ensuite plus aucun rôle dans son fonctionnement.

Il peut être sous-traitant s’il agit pour le compte d’un éditeur responsable de traitement. Par exemple en mettant en œuvre l’infrastructure de traitement et de stockage des données. Ou en réalisant des opérations sur des données côté serveur à des fins de maintenance ou d’infogérance.

Le développeur peut être responsable s’il traite des données pour son propre compte, pour des finalités qu’il définit. On nous mentionne :

– Amélioration de la sécurité des autres apps du développeur
– Réalisation de statistiques à des fins d’améliorations de ses propres services
– Croisement de données issues de différentes apps pour proposer de nouveaux services

Une « exception domestique »

La CNIL rappelle l’existence d’une forme d’exemption inscrite à l’article 2.2.c et au considérant 18 du RGPD. Dans les grandes lignes, le règlement ne s’applique pas aux traitements qu’une personne physique effectue au cours d’activités strictement « personnelles » ou « domestiques » (cadre familial ou amical).

Dans ce cas de figure, les éditeurs, en tant que tiers fournissant les moyens de traitement, ne sont pas responsables s’ils respectent deux critères cumulatifs :

Traitement effectué à l’initiative, à la discrétion et pour le seul compte de la personne

Traitement effectué sous le contrôle de la personne, sans intervention possible de tiers sur les données

La CNIL a établi que l’authentification biométrique avec stockage local et chiffré remplit ces critères. Et a dit de même des applis de santé qui enregistrent et conservent les données en local. Le même raisonnement pourrait s’appliquer, affirme-t-elle, au partage des données en P2P. Ou aux applications fonctionnant comme un simple logiciel mis à disposition de l’utilisateur. Ce serait le cas d’un clavier avec « apprentissage » local, sans fédération.

De manière générale, une application qui fonctionne sans intervention de son fournisseur ni transmission de données vers celui-ci a de fortes probabilités de relever de cette exemption, résume la commission.

Les recommandations aux éditeurs

Pour chaque traitement, on privilégiera une configuration répondant aux critères de cette exemption domestique, conseille la CNIL aux éditeurs. On aura ainsi recours à des calculs locaux plutôt qu’à des API. Ou à des outils de partage locaux des données entre applications sous le contrôle de l’utilisateur.

Comme pour la qualification juridique, de nombreuses recommandations ne sont pas spécifiques au cas des applications mobiles. Elles touchent à la conservation des données, à la tenue d’un registre des traitements, à la gestion des consentements, etc. Le principe de minimisation est aussi abordé, avec un exemple : ne pas stocker une date de naissance complète si l’application n’a besoin que de l’année.

« Cartographier ses partenaires » est un autre enjeu. Parmi eux, il y a le développeur. En premier lieu, on identifiera les traitements qu’il mettra en œuvre – y comprsi pour son propre compte – et on formalisera contractuellement les obligations qui en découlent.
On formalisera aussi les mesures techniques qu’on attend de sa part en matière de sécurité des données (les permissions en sont). Tout en s’assurant que le contrat prévoie la mise à jour de l’app en cas de vulnérabilité.

Les recommandations aux développeurs

La CNIL rappelle, par un renvoi aux lignes directrices du CEPD, que le fait pour un développeur de procéder à des choix techniques ne le rend pas nécessairement responsable du traitement. Elle fournit un certain nombre de recommandations « croisées » avec celles adressées aux éditeurs, par exemple sur la tenue de registres et la validation du recours à des sous-traitants ultérieures.

La relation avec l’éditeur induira aussi la mise en place de processus de maîtrise d’œuvre. On s’y engagera par exemple à impliquer l’éditeur en cas de décision (choix technique, design d’interface) impactant la vie privée des utilisateurs. On ne négligera pas, en outre, les effets des évolutions externes comme une nouvelle version de SDK ou la modification des permissions proposées par l’OS.

Dans ce dernier cas, la CNIL suggère au développeur de proposer à l’éditeur une mise à jour, au titre du « devoir de conseil du sous-traitant ». Cette notion doit porter des initiatives telles que :

– Aider au bon respect des droits des utilisateurs (mise à disposition de la politique de confidentialité au sein de l’app, voire d’un écran d’info RGPD simplifié au premier lancement ; fournir une page dédiée pour l’exercice des droits des utilisateurs…)

– Participer à la conformité en matière d’usage de traceurs et de recueil du consentement (la CNIL pointe ici vers ses recommandations « Cookies et autres traceurs »)

– Proposer des développements respectant les principes de protection des données personnelles (limiter les données affichées dans les notifications, chiffrer le contenu des sauvegardes et donner à l’utilisateur la maîtrise des clés…)

Des « mesures minimales » au « modèle de sécurité »

TLS, stockage des secrets cryptographiques par empaquetage, désactivation des sauvegardes indésirables niveau OS et authentification adéquate sont autant de « mesure de sécurité minimales » que la CNIL liste à l’attention des développeurs.

Elle leur recommande aussi d’adopter un modèle de sécurité adéquat. « Les mesures d’épinglage de certificat ou d’obfuscation de code ne constituent pas des mesures de sécurité pertinentes », leur clame-t-elle, tout en appelant à ne pas faire reposer le modèle sur l’intégrité du terminal.

Le développeur a aussi des responsabilités pour ce qui est de sélectionner les SDK. Entre autres, s’assurer qu’ils permettent de bloquer un traitement, un accès ou la mise en œuvre d’une permissions jusqu’au recueil d’un consentement valable. Mais aussi l’auditer, en retenant que l’éditeur du SDK, en tant que sous-traitant ou sous-traitant ultérieur, a l’obligation de faciliter la démarche.

Photo d’illustration générée par IA