LaunchLint Academy
La réponse courte
- Data Safety décrit les données collectées ou partagées, leurs finalités, la sécurité et la suppression. Même sans collecte, l’app remplit le formulaire et lie une politique de confidentialité.
- package.json, configuration et permissions sont des signaux, pas une déclaration. SDK tiers, backend, consentement et transmissions réelles doivent être vérifiés.
- Créez une fiche par SDK et endpoint, classez collected et shared selon Google, puis réévaluez Play Console à chaque changement.
1. Version et données couvertes
Google exige le formulaire pour les apps publiées en closed, open et production ; internal testing exclusif est exempté. La déclaration s’applique au package et doit représenter les artefacts actifs. Une ancienne version distribuée peut encore contenir un autre SDK.
La collecte implique généralement un transfert hors de l’appareil. Un traitement uniquement local peut être exclu. Une permission ne prouve pas la collecte et l’absence de permission sensible ne prouve pas l’absence de télémétrie, IP ou identifiants.
3. Inventorier SDK Expo et dépendances natives
Expo abstrait le projet natif sans supprimer la responsabilité. Analytics, crash, push, auth, cartes, pubs, paiements et social login peuvent transmettre. Vérifiez dépendances directes et transitives, production, modules optionnels et initialisation avant consentement.
Google rend le développeur responsable du code tiers. Documentation et Play SDK Index aident, mais votre configuration décide.
{
"sdk": "example-analytics",
"enabledInProduction": true,
"dataTypes": ["Device identifiers", "App interactions"],
"transmittedOffDevice": true,
"purpose": ["Analytics"],
"requiredOrOptional": "optional after consent",
"encryptedInTransit": true,
"deletionPath": "privacy@example.com"
}- package.json et lockfile
- Plugins app config
- Manifest et permissions
- Initialisation et consent
- Endpoints et uploads
- Suppression et opt-out
- Variables de release
4. Finalité, choix, chiffrement et suppression
Sélectionnez seulement les finalités utilisées. Optional suppose un vrai moyen d’éviter la collecte ; un réglage après initialisation n’efface pas le transfert précédent.
Déclarez le chiffrement uniquement s’il couvre toutes les données transmises. Vérifiez anciens endpoints, uploads, WebViews et SDK. Distinguez compte, profil, backups, conservation légale et copies tierces.
- Finalité par type et destinataire
- Required ou optional testé
- TLS partout
- Conservation dans la politique de confidentialité
- Suppression in-app et web
- Abonnements et rétention expliqués
5. La suppression de compte est une preuve
Si l’app crée des comptes, Google exige un chemin in-app et une ressource web pour demander suppression du compte et des données. Le lien peut être public et doit mener au processus, pas à l’accueil.
Testez identification, confirmation, délai, statut et demandes incomplètes sans session développeur. Nommez les données légitimement conservées. Désactiver ou désinstaller n’est pas supprimer.
6. Valider contre build et runtime
L’analyse statique priorise les questions sans remplacer l’observation. Installez le build production sur un appareil neuf et testez premier lancement, consentement, login, fonction, upload, achat, push et suppression. Notez services et destinations réseau.
Rapprochez fichiers du projet, transmission, backend, documentation SDK, politique de confidentialité et formulaire. Ne devinez pas un cas ambigu : demandez et conservez la décision.
- Inventaire production figé
- Consent avant SDK optionnel
- Types et finalités alignés
- Exceptions documentées
- Chiffrement et suppression testés
- politique de confidentialité à jour
- Draft relu
- Responsable et date
7. Maintenir Data Safety à chaque release
Nouvel analytics, auth, publicité, upload ou finalité backend peut changer les réponses. Intégrez le contrôle à la Definition of Done et à la checklist de release. Le diff de package.json est un déclencheur utile, mais les changements serveur sans diff mobile comptent aussi.
LaunchLint trouve SDK, plugins, permissions, endpoints et signaux de suppression avec preuve de fichier, mais n’exécute pas le code et n’observe pas les transferts. La déclaration finale combine fichiers du projet, runtime, backend et console. Conservez formulaire, build, date et responsable pour comparer la prochaine release.
Ajoutez un journal de décision pour les réponses sensibles : source consultée, propriétaire du service, finalité confirmée et preuve de suppression. Lorsqu’un fournisseur change ses pratiques, le journal montre quelles réponses doivent être rouvertes. Faites relire le draft par une personne qui connaît le backend et une autre qui connaît le parcours utilisateur ; une seule perspective laisse facilement passer un transfert indirect ou une option conditionnelle.
Contrôle des changements :
- SDK ajouté, retiré ou mis à jour
- Nouvelle finalité
- Nouveau endpoint ou fournisseur
- Consentement déplacé
- Conservation ou suppression modifiée
- Nouvelle audience ou région
- Nouveau flux d’upload
- Relecture du draft
Questions fréquentes
Une app sans collecte remplit-elle Data Safety ?
Oui sur les tracks concernés. Elle lie aussi une politique de confidentialité et vérifie ses SDK.
package.json peut-il générer le formulaire ?
Non. Il ne connaît pas entièrement runtime, backend, finalités, consentement, conservation et suppression.
Un prestataire est-il toujours du sharing ?
Pas nécessairement ; Google prévoit des exceptions selon la relation et l’usage réel. Documentez la décision.
Quand mettre à jour ?
Quand types, finalités, destinataires, SDK, consentement, sécurité ou suppression changent.