Politique de confidentialité d'une app : les vérifications avant publication

Ce que regardent Apple et Google

Apple demande une URL publique dans App Store Connect ainsi qu'un accès facile à la politique depuis l'application. L'éditeur doit aussi remplir les informations App Privacy visibles sur la fiche. Elles couvrent ses propres traitements et ceux des partenaires dont le code est intégré, par exemple l'analyse, la publicité, les cartes ou le suivi des erreurs.

Google Play exige lui aussi un lien dans la fiche et un accès dans l'application. Tous les éditeurs doivent compléter la section Sécurité des données. La règle Google Play sur les données utilisateur impose d'expliquer l'accès, la collecte, l'utilisation et le partage, y compris lorsqu'ils proviennent d'une bibliothèque tierce.

Une bonne politique n'est donc pas seulement complète. Elle doit être cohérente avec la version distribuée, les réponses données aux deux stores, les demandes de permission, les choix de consentement et les outils internes.

Faire l'inventaire depuis les parcours

Réunissez le propriétaire du produit et les personnes qui connaissent l'application mobile, le serveur et les prestataires. Parcourez l'inscription, l'action principale, le paiement, les messages, le support et la fermeture du compte. Chaque passage de données doit devenir une ligne vérifiable.

Pour chaque ligne, notez la catégorie de données, l'origine, la finalité, la base légale envisagée, les destinataires, la région d'hébergement, les rôles autorisés, la durée et le mécanisme de suppression. Une formule comme « améliorer le service » ne suffit pas à concevoir ni à expliquer le traitement.

Cet inventaire conduit souvent à supprimer des collectes. Une app de réservation n'a pas besoin d'une date de naissance par défaut. Un service de livraison peut avoir besoin de la position pendant la course, sans conserver tous les trajets pendant des années.

Les informations que le lecteur doit vraiment trouver

Commencez par identifier l'entité qui décide des finalités et des moyens. Sa dénomination, son adresse et son contact doivent correspondre à l'éditeur présenté dans le store. Ajoutez le délégué à la protection des données ou le représentant lorsqu'ils sont requis.

Présentez ensuite les données par catégories compréhensibles. Ne réunissez pas dans un même terme le nom, la position, un enregistrement audio et des informations médicales. Indiquez si la personne les fournit, si le terminal les rend accessibles, si le service les crée ou si un partenaire les transmet.

Associez chaque finalité à une explication concrète et à sa base légale. « Personnaliser l'expérience » reste vague. « Mémoriser un panier pendant sept jours » ou « transmettre la position du coursier au client pendant la livraison » permet de comprendre le service et sa limite.

Le texte couvre aussi les prestataires et destinataires, les transferts hors de l'Espace économique européen, les durées ou critères de conservation, les droits et leur exercice, le retrait du consentement lorsqu'il s'applique, la réclamation auprès de l'autorité, la sécurité sans promesse absolue, la date d'effet et les changements.

Les articles 13 et 14 du RGPD fournissent le socle européen. Les règles sectorielles et nationales peuvent ajouter d'autres obligations.

Évitez d'annoncer une suppression immédiate de « toutes les données » si certaines factures doivent rester ou si les sauvegardes suivent un cycle d'expiration. Décrivez honnêtement le motif, le périmètre et la durée.

Permission technique et consentement ne se remplacent pas

La politique donne une information d'ensemble. Les fiches Apple et Google la résument avant l'installation. Une permission iOS ou Android ouvre techniquement l'accès à la caméra, au micro, aux photos ou à la position. Le consentement est un choix pour une finalité précise lorsqu'il constitue la bonne base légale.

Autoriser la caméra pour joindre une photo n'autorise pas une analyse publicitaire du visage. Refuser une mesure d'audience facultative ne devrait pas bloquer une réservation indépendante de cette mesure. Une explication courte, présentée au moment où la fonction en a besoin, rend la demande plus honnête.

La CNIL rappelle dans ses recommandations sur les permissions mobiles qu'une permission technique ne recueille pas, à elle seule, le consentement au sens du RGPD. Cette distinction doit se retrouver dans l'interface.

Il peut donc falloir un centre de préférences, un historique des choix, un export et une suppression de compte. La préparation de l'authentification et des comptes aide à inscrire ces états dans le produit.

Les SDK, angle mort le plus fréquent

Un kit de développement logiciel, ou SDK, ajoute une fonction déjà construite : analyse, carte, paiement, chat, publicité, attribution ou rapport d'erreur. Il peut lire un identifiant et envoyer des événements directement vers son fournisseur, sans passer par la base principale.

Apple rend l'éditeur responsable du code tiers et impose des manifestes de confidentialité à de nombreux SDK répandus. Google demande également d'inclure la collecte et le partage réalisés par les bibliothèques dans la déclaration Sécurité des données.

Conservez un registre avec nom, version, fonction, permissions, données, destinations, configuration, possibilité de refus et responsable interne. Vérifiez une version de production et son trafic réseau. Un environnement de test peut envoyer moins, ou parfois davantage, d'informations.

La check-list de sécurité Android complète ce contrôle pour les permissions, journaux, secrets et dépendances. Le guide de mesure mobile aide à définir des événements sans informations personnelles inutiles.

Supprimer le compte jusque dans les systèmes associés

Une application iOS qui crée des comptes doit permettre d'en lancer la suppression depuis l'app. Google Play demande aussi un parcours interne et une ressource web externe depuis laquelle la personne peut demander la suppression du compte et des données associées.

Une désactivation ou un profil rendu invisible ne suffit pas. Le produit doit décider du sort des abonnements, commandes ouvertes, contenus, messages, factures, preuves de fraude, demandes d'assistance et sauvegardes. Une conservation nécessaire doit être limitée, sécurisée et expliquée.

Le parcours peut demander une nouvelle authentification proportionnée, confirmer les conséquences, arrêter la facturation future, envoyer un reçu et créer un état que l'assistance peut suivre. Testez ensuite la propagation de la demande vers les prestataires.

Les exigences Google sur la suppression de compte peuvent devenir des critères de recette. Ajoutez-les à la check-list de lancement avant la soumission.

Une politique différente pour chaque réalité produit

Une application de salon traite souvent un nom, un numéro, des rendez-vous et un acompte. Elle doit expliquer les rappels, l'accès des employés et la conservation des annulations. Des paragraphes sur la biométrie n'apportent rien si elle n'en utilise pas.

Un service de livraison combine adresse client, position du coursier, photo de preuve et accès du dispatch. Chaque donnée répond à un moment distinct. La géolocalisation d'une course active ne doit pas être noyée dans une phrase laissant entendre un suivi permanent.

Une app de santé ou d'éducation peut concerner des données sensibles ou des mineurs. Les rôles, contrats, exports, incidents et accès professionnels doivent alors être définis bien avant le texte final. La check-list de sécurité d'une application mobile couvre les décisions techniques qui soutiennent ces engagements.

Organiser la validation avant envoi

1. Figer l'inventaire du candidat. Relever les fonctions, permissions, points de connexion, versions de SDK, outils internes et prestataires de la vraie version.
2. Compléter les chemins de données. Inclure ce qui se passe avant la connexion, les notifications, journaux, exports, support et sauvegardes.
3. Rédiger pour les marchés proposés. Utiliser une langue claire et faire examiner les risques juridiques particuliers.
4. Remplir les stores depuis la même source. Comparer ligne par ligne App Privacy et Sécurité des données avec la politique.
5. Tester le contrôle utilisateur. Refuser une permission, retirer un choix facultatif, demander l'accès et supprimer un compte de test.
6. Archiver la preuve. Conserver la version, la date, le responsable et les événements qui imposeront une nouvelle revue.

Le guide de remise de documentation précise les éléments qui doivent rester chez le propriétaire de l'application en cas de changement d'équipe.

Éviter que le texte vieillisse après la sortie

Installer un outil de relecture de sessions, changer de cartographie ou ajouter une pièce jointe au support peut rendre la politique fausse sans modifier sa page.

Chaque changement devrait répondre à quelques questions : quelle donnée entre, quel fournisseur la reçoit, pour quelle raison, quel choix reste à l'utilisateur et comment une suppression atteint-elle ce système ? La fonctionnalité n'est terminée qu'après avoir décidé si les écrans, la politique et les stores doivent être mis à jour.

Gardez les anciennes versions et leurs dates. Informez clairement des changements importants, sans imposer un nouveau consentement pour une simple correction de forme.

La méthode Appfyl pendant le cadrage

Chez Appfyl, nous partons des rôles et des actions. Nous précisons les données nécessaires au service, celles visibles dans l'interface d'administration, les prestataires concernés et le résultat attendu après une suppression.

Ce travail révèle les postes souvent oubliés dans une estimation : réglages, logique d'effacement côté serveur, accès de l'assistance, journal des demandes et tests. Il donne aussi au juriste une description factuelle plutôt qu'une liste de fonctions marketing.

Le brief interactif Appfyl permet d'indiquer comptes, permissions, intégrations et exigences de suppression. Pour parler du projet complet, consultez Appfyl.

Voir comment Appfyl transforme un périmètre en produit lancé. Voir les cas Appfyl.

Questions fréquentes