En janvier 2024, la CNIL a infligé une amende de 10 millions d’euros à une société éditrice d’une application mobile de e-commerce pour collecte excessive de données de géolocalisation sans consentement valide. Ce chiffre résume à lui seul pourquoi rédiger une clause de protection des données pour application mobile n’est pas une formalité administrative, mais une obligation concrète avec de vraies conséquences. Je vais décortiquer ce sujet comme je le fais avec n’importe quel système : en cherchant les failles, les angles morts, et les bonnes pratiques qui font la différence.
Ce que le RGPD impose concrètement aux éditeurs d’applications mobiles
Le RGPD (Règlement UE 2016/679 du 27 avril 2016) s’applique à toute organisation qui traite des données de personnes situées sur le territoire européen, quelle que soit sa taille. Un éditeur d’application mobile est donc concerné dès la première collecte : identifiant, adresse IP, position GPS, préférences d’utilisation. Tout cela constitue une donnée à caractère personnel au sens du règlement.
L’article 13 du RGPD impose une information claire et complète dès la collecte. Concrètement, votre politique de confidentialité ou votre clause dédiée doit mentionner :
- L’identité et les coordonnées du responsable du traitement (et du DPO si désigné)
- Les finalités du traitement et leur base légale respective
- Les destinataires des données, y compris les sous-traitants
- La durée de conservation pour chaque catégorie de données
- Les droits des utilisateurs et la possibilité de saisir la CNIL
- L’existence éventuelle de transferts hors Union européenne
Les durées de conservation varient selon les finalités. La gestion clients et la prospection commerciale imposent une conservation de 3 ans à compter du dernier contact. La facturation et la comptabilité montent à 10 ans. Les données de cartes bancaires sont supprimées en base active après la transaction, puis conservées 13 mois en base intermédiaire. La lutte contre la fraude justifie une conservation de 6 mois. Ce tableau illustre les principales durées légales :
| Finalité | Durée de conservation |
|---|---|
| Gestion clients / prospects / communication commerciale | 3 ans |
| Facturation et comptabilité | 10 ans |
| Cartes bancaires (base intermédiaire) et mesure d’audience | 13 mois |
| Lutte contre la fraude | 6 mois |
La loi Informatique et Libertés exhaustive ce cadre en droit français. Les sanctions maximales atteignent 4 % du chiffre d’affaires mondial annuel pour les manquements les plus graves. En 2024, la CNIL a également sanctionné une société développant une extension navigateur (240 000 euros pour défaut de base légale) et un éditeur de portefeuille de cryptomonnaie (750 000 euros pour défaut de sécurité et durée de conservation). Ces chiffres ne sont pas abstraits : ils traduisent des décisions réelles appliquées à des produits numériques courants.
Exemple de clause de protection des données : les éléments indispensables
Une clause de confidentialité pour application mobile bien rédigée suit une logique précise. Voici un modèle commenté, adaptable à la majorité des applications qui ne traitent pas de données sensibles.
Bloc 1 – Identité du responsable du traitement : “La société [Nom], [forme juridique], immatriculée sous le numéro [SIRET], dont le siège est situé [adresse], est responsable du traitement des données collectées via l’application [Nom de l’app].” Ce bloc est non négociable. Sans identification claire, toute la clause tombe juridiquement.
Bloc 2 – Données collectées et finalités : “Nous collectons les données suivantes : [liste précise]. Ces données sont traitées aux fins de [finalité 1] sur la base de [base légale], et de [finalité 2] sur la base de [base légale].” La base légale doit être précisée pour chaque finalité, pas en bloc. Le consentement, le contrat, l’obligation légale et l’intérêt légitime sont les quatre bases légales les plus fréquentes pour une application mobile.
Bloc 3 – Droits des utilisateurs : Mentionnez explicitement le droit d’accès, de rectification, d’effacement, d’opposition, de portabilité et de limitation. L’application doit proposer un mécanisme concret pour exercer ces droits. Un centre de gestion intégré à l’app est la meilleure pratique, complété par un espace web en cas de perte du terminal.
Sur le consentement in-app, les règles sont strictes : pas de case pré-cochée, un consentement distinct par finalité (notifications, géolocalisation, accès aux photos constituent trois autorisations séparées), et la preuve du consentement doit être conservée avec horodatage et version des conditions. protéger ses comptes en ligne passe aussi par une gestion rigoureuse des autorisations accordées aux applications. Si le retrait du consentement n’est pas aussi simple que son octroi, la clause est non conforme.
Concernant les SDK tiers intégrés dans l’application : chacun collecte potentiellement des données. Il faut dresser la liste exhaustive de ces outils dans la politique de confidentialité et recueillir le consentement avant d’activer les trackers non essentiels. Firebase, par exemple, transfère des données vers les États-Unis et nécessite des clauses contractuelles types conformément à l’article 44 du RGPD. Les assistants vocaux et la vie privée posent des questions similaires sur la collecte silencieuse de données, un réflexe d’analyse que j’applique systématiquement à chaque couche d’un système.
Privacy by design, violations de données et bonnes pratiques opérationnelles
Le privacy by design recommandé par la CNIL consiste à cartographier toutes les données personnelles dès la phase de conception, avant d’écrire la moindre ligne de code. Cette approche m’a toujours semblé plus honnête intellectuellement : on pense la sécurité comme une contrainte d’architecture, pas comme un vernis appliqué après coup.
En pratique, cela signifie identifier chaque opération de lecture/écriture qui touche une donnée personnelle, définir la base légale correspondante, fixer la durée de conservation, et documenter le tout dans un registre des traitements (obligatoire selon l’article 30 du RGPD dès qu’un traitement existe). La CNIL met à disposition un modèle de registre gratuit. Ce document doit rester à jour à chaque évolution fonctionnelle de l’application.
En cas de violation de données, le délai est court : 72 heures pour notifier la CNIL après découverte de l’incident, avec description de la nature de la violation, des données concernées et des mesures correctives prises. L’absence de notification constitue elle-même un manquement sanctionnable. sécuriser efficacement ses mots de passe et chiffrer les données stockées localement sont deux réflexes techniques qui réduisent significativement l’exposition au risque.
Le privacy by default complète cette logique : les paramètres de confidentialité les plus protecteurs doivent être activés par défaut à l’installation. L’utilisateur élargit ensuite ses autorisations s’il le souhaite, jamais l’inverse. Apple et Google appliquent leurs propres politiques de permissions via iOS et Android, mais celles-ci ne remplacent pas les obligations RGPD. Ce sont deux niveaux distincts et cumulatifs.
La maintenance de l’application est souvent oubliée dans la réflexion juridique. Une application qui n’est plus maintenue doit être décommissionnée, ou faire l’objet de mesures techniques minimisant les risques. Les librairies et SDK obsolètes sont des vecteurs d’attaque courants, et la CNIL l’a bien identifié. les mythes sur la sécurité des systèmes s’appliquent aussi aux applications mobiles : aucun écosystème n’est immunisé. Documenter, auditer, mettre à jour : voilà la réalité du traitement conforme sur la durée.
