erberkk/privacy-and-declarations

Confidentialité et déclarations

Objectif

Des réponses de confidentialité véridiques et cohérentes dans les deux magasins, étayées par des preuves provenant du code. La plupart des rejets pour confidentialité sont dus à des incohérences : la politique dit une chose, l'application en fait une autre, le formulaire en dit une troisième.

Prérequis

• Accès au code source (application et backend) et aux fichiers de verrouillage (pubspec.lock, Podfile.lock, dépendances Gradle, package.json).
• La politique de confidentialité et les conditions d'utilisation actuelles.
• Connaissance de chaque point de terminaison backend et service tiers qui reçoit des données utilisateur.

1. Construire l'inventaire des données (à partir du code, pas de la mémoire)

Exécutez scripts/scan-sdks.mjs à la racine du dépôt. Il liste les SDK connus à partir des fichiers de verrouillage avec les catégories de données qu'ils touchent généralement, et recherche l'utilisation d'API à motif requis, les chaînes d'autorisation, l'ID publicitaire et les API de suivi. Complétez ensuite l'inventaire en lisant la couche réseau et le backend :

Données	Source (écran / SDK)	Envoyé hors de l'appareil ? À qui	Lié à l'utilisateur ?	Objectif	Conservation	Facultatif ?

Règles :

• "Traité uniquement sur l'appareil" signifie jamais envoyé, y compris à votre propre serveur. S'il est synchronisé avec votre backend, il est collecté.
• Vos sous-traitants (hébergement, fournisseur d'IA agissant sur vos instructions, SDK de paiement) sont toujours "collectés" ; selon le magasin, ils comptent ou non comme "partagés" (ci-dessous).
• Les rapports d'erreur anonymes et les compteurs d'utilisation sont toujours collectés (Diagnostics / Données d'utilisation), généralement "non liés".

Enregistrez l'inventaire sous docs/privacy-inventory.md. Chaque réponse ci-dessous se réfère à une ligne.

2. Confidentialité de l'application Apple (App Store Connect › App Privacy)

• Mappez chaque ligne de l'inventaire aux catégories d'Apple (Informations de contact, Santé et forme physique, Contenu utilisateur, Identifiants, Achats, Données d'utilisation, Diagnostics…), aux objectifs, lié vs non lié, et suivi.
• Suivi = lier vos données à des données tierces à des fins de publicité ciblée ou de mesure publicitaire, ou les partager avec des courtiers en données. Pas de SDK publicitaire et pas de courtier en données signifie généralement "Pas de suivi" et pas d'invite ATT.
• La divulgation facultative s'applique uniquement lorsque toutes les conditions d'Apple sont remplies (peu fréquent, facultatif, initié par l'utilisateur à chaque fois, pas de suivi/publicité). S'applique rarement aux fonctionnalités de l'application.
• Documentation : App privacy details.

3. Données de sécurité Google Play (Politique › Contenu de l'application › Données de sécurité)

• Même inventaire, taxonomie de Play (Informations personnelles, Santé et forme physique, Photos et vidéos, Messages, Activité de l'application, Informations et performances de l'application, Identifiants de l'appareil ou autres, Informations financières…).
• Partage exclut les transferts à des prestataires de services traitant pour votre compte ; un SDK qui crée des profils publicitaires inter-clients est un partage.
• Éphémère : traité uniquement en mémoire, non stocké, uniquement pour la requête en temps réel (par exemple, une photo analysée puis supprimée).
• Utilisez Exporter en CSV / Importer depuis CSV : conservez le CSV dans le dépôt (store/data-safety.csv) afin que les modifications soient examinées comme du code. L'importation remplace toutes les réponses.
• Documentation : Data safety.

4. Autres déclarations Play

• Déclaration des applications santé : chaque application doit la remplir, même sans fonctionnalités de santé. Documentation.
• Health Connect : une justification par autorisation ; ne demandez que les autorisations utilisées par une fonctionnalité visible ; une activité de justification (ACTION_SHOW_PERMISSIONS_RATIONALE) liant à la politique. Play peut demander un enregistrement d'écran du flux.
• Identifiant publicitaire : déclarez si vous l'utilisez. Pas de SDK publicitaire/d'attribution, déclarez "Non" et assurez-vous qu'aucune dépendance n'ajoute com.google.android.gms.permission.AD_ID (vérifiez le manifeste fusionné ; supprimez avec tools:node="remove" si ajouté).
• Public cible, classification du contenu (IARC), publicités, accès à l'application, actualités, fonctionnalités financières, gouvernement : répondez à partir de l'inventaire. Si une partie est derrière une connexion, fournissez des identifiants de test dans Accès à l'application.
• Suppression de compte : voir section 8.

5. Manifeste de confidentialité (iOS)

• Ajoutez PrivacyInfo.xcprivacy à la cible de l'application (modèle : templates/PrivacyInfo.xcprivacy).
• Déclarez NSPrivacyTracking, NSPrivacyTrackingDomains, NSPrivacyCollectedDataTypes (cohérent avec la confidentialité de l'application) et NSPrivacyAccessedAPITypes pour chaque catégorie d'API à motif requis que le code de l'application utilise lui-même : horodatage du fichier, heure de démarrage du système, espace disque, claviers actifs, UserDefaults. Choisissez les codes de motif approuvés dans la liste d'Apple. Les applications Flutter utilisent UserDefaults via des plugins comme shared_preferences — vérifiez que chaque plugin inclut son propre manifeste ; ajoutez ce que votre code et les plugins sans manifeste utilisent.
• Après la construction, inspectez les avertissements de construction / l'e-mail de l'App Store Connect pour les motifs de manifeste manquants.
• Documentation : Privacy manifest files, Required reason API.

6. Conformité aux exportations (iOS)

• ITSAppUsesNonExemptEncryption dans Info.plist : false est approprié lorsque l'application n'utilise aucun chiffrement ou uniquement un chiffrement exempté (par exemple HTTPS via le système d'exploitation, algorithmes standard utilisés uniquement pour protéger les propres données de l'utilisateur dans une application dont la fonction principale n'est pas la sécurité). Cela évite les questions par construction.
• Si vous implémentez ou intégrez une cryptographie propriétaire, ou si le chiffrement est une fonctionnalité principale, répondez plutôt aux questions et vérifiez si une documentation ou un rapport d'auto-classification annuel s'applique.
• Il s'agit d'une classification juridique ; en cas de doute, consultez un conseiller en conformité commerciale. Documentation : Complying with encryption export regulations.

7. Classification par âge

• Répondez honnêtement au questionnaire Apple actuel et au questionnaire IARC Play, y compris les questions sur les sujets de santé/bien-être, le chat IA ou le contenu généré, le contenu généré par l'utilisateur et l'accès web non restreint.
• Maintenez la classification cohérente avec l'âge minimum de vos Conditions d'utilisation et toute barrière d'âge dans l'application. Si le résultat du questionnaire est inférieur à l'âge minimum de vos Conditions, utilisez l'option du magasin pour définir une classification plus élevée plutôt que de laisser une incohérence.

8. Suppression de compte

• Dans l'application : si les utilisateurs peuvent créer un compte, ils peuvent lancer la suppression dans l'application (paramètres du compte). La désactivation seule ne suffit pas. Comptes invités/créés automatiquement aussi. La réauthentification ou la confirmation est autorisée mais ne doit pas être inutilement difficile. Apple : Offering account deletion.
• URL web (Play) : une page, accessible sans l'application ni connexion, nommant l'application telle que sur la fiche, expliquant comment demander la suppression, ce qui est supprimé et ce qui est conservé (et pourquoi), et toutes les étapes préalables (annuler l'abonnement). Documentation : Play account deletion.
• Abonnements : la suppression du compte n'annule pas un abonnement au magasin. Avertissez dans la feuille de suppression et liez à la gestion des abonnements du magasin.
• Connexion avec Apple : révoquez les jetons de l'utilisateur via l'API REST Connexion avec Apple lors de la suppression.
• Tiers : supprimez également l'utilisateur chez les sous-traitants (par exemple, le client RevenueCat, les identifiants d'analyse/erreur, les listes de diffusion).
• Déploiement de la réauthentification : si vous ajoutez une exigence de réauthentification au point de terminaison de suppression, publiez l'application qui gère la nouvelle réponse en même temps que la modification du backend, ou conservez l'ancien comportement pour les anciennes versions de l'application.
• Utilisez une seule formulation pour le chemin partout (application, politique, formulaires du magasin, page web), par exemple "Profil › Supprimer le compte".

9. Fonctionnalités IA

• Apple 5.1.2(i) : divulguez où les données personnelles sont partagées avec des tiers, y compris l'IA tierce, et obtenez d'abord une autorisation explicite.
• Avant la première utilisation d'une fonctionnalité IA : une courte fiche de consentement nommant le fournisseur et son rôle ("traité par pour générer la réponse"), ce qui est envoyé, que cela n'est pas utilisé pour entraîner des modèles (uniquement si les conditions du fournisseur le disent pour votre plan), et la conservation (du fournisseur et la vôtre). Un interrupteur dans les paramètres pour retirer le consentement.
• Formulation de la politique : le fournisseur d'IA agit en tant que sous-traitant/prestataire de services sur vos instructions ; listez-le avec l'emplacement et la conservation.
• Formulaires du magasin : les entrées IA (messages, photos, texte) sont des données collectées (Contenu utilisateur) ; généralement "non partagées" sur Play lorsque le fournisseur est un sous-traitant.
• Considérez : une mention "pas un avis professionnel" sur les réponses IA concernant la santé ou les finances, et une réponse de sécurité définie pour les sujets de crise.

10. Données de santé

• N'envoyez jamais de données HealthKit / Health Connect à des fournisseurs d'IA ou à d'autres tiers. Apple (5.1.3) restreint l'utilisation et la divulgation des données de santé ; la politique de Health Connect restreint également les transferts. La conception conforme la plus simple : les données lues depuis Apple Health / Health Connect restent sur l'appareil (ou dans le propre stockage du compte de l'utilisateur uniquement, divulgué), et les fonctionnalités qui appellent une IA utilisent uniquement les données que l'utilisateur a saisies dans votre application.
• N'utilisez pas les données de santé à des fins de publicité ou de marketing ; ne les stockez pas dans iCloud.
• Les chaînes d'utilisation d'Info.plist (NSHealthShareUsageDescription, NSHealthUpdateUsageDescription) doivent indiquer l'utilisation réelle. Si la chaîne dit "jamais partagé avec des tiers", le code doit le garantir.
• Appliquez-le dans le code : le constructeur de requête pour les appels IA prend une liste explicite de champs autorisés ; ajoutez un test qui échoue si un champ provenant de la santé apparaît dans une charge utile IA.

Points de décision nécessitant une approbation humaine

Les réponses finales sur chaque formulaire (le titulaire du compte est légalement responsable), la classification de conformité aux exportations, la classification par âge, le fournisseur d'IA et ses conditions relatives aux données, toute modification concernant les données de santé quittant l'appareil.

Vérification

• Chaque réponse du formulaire cite une ligne de l'inventaire ; l'inventaire cite le code.
• Vérification des écarts : politique de confidentialité ↔ Confidentialité de l'application ↔ CSV des données de sécurité ↔ texte de consentement dans l'application ↔ chaînes Info.plist. Aucune contradiction.
• Test : supprimez un compte de test ; confirmez que les lignes backend, les enregistrements du sous-traitant et l'utilisateur auth sont supprimés ; la page de suppression web est accessible sans connexion.
• La construction n'affiche aucun avertissement de manifeste de confidentialité.

Pièges courants

• "Les données ne quittent jamais l'appareil" dans la politique tandis qu'une synchronisation ou une fonctionnalité IA les envoie.
• Oublier votre propre rapport d'erreur/d'utilisation anonyme dans les formulaires.
• Une dépendance ajoutant silencieusement l'autorisation AD_ID.
• Les données de santé circulant dans une invite IA via un constructeur de "contexte" qui inclut "tout ce que nous savons".
• Le chemin de suppression nommé différemment dans l'application, la politique et les formulaires du magasin.
• Classification par âge 4+ alors que les Conditions d'utilisation indiquent 16+.