Checklist securite Android avant publication sur Google Play

1. Donnees sensibles et roles

Commencez par une liste simple. Quelles donnees l'app collecte-t-elle?

• email, telephone, nom et adresse;
• statut de paiement, historique de commandes ou position de livraison;
• photos, fichiers ou messages;
• donnees de sante, bien-etre ou identite;
• notes support, actions admin ou revenus de prestataires.

Ensuite, precisez qui peut voir ou modifier chaque information: utilisateur, prestataire, support, admin, livreur, medecin, professeur, vendeur ou finance. Une erreur frequente consiste a masquer un bouton dans l'app alors que l'API renvoie encore les donnees. Les controles serveur comptent plus que les ecrans caches.

2. Retirer les secrets de l'app

Tout ce qui est livre dans une app Android peut etre inspecte. Ne placez pas de cles API privees, tokens admin, secrets de paiement, acces base de donnees ou cles de signature dans l'app.

Approches saines:

• paiements et actions privilegiees passent par le backend;
• tokens courts quand c'est possible;
• cles SDK publiques traitees comme publiques;
• rotation rapide des cles exposees;
• verification des endpoints de test et flags debug dans la build finale.

Ce controle evite une erreur courante et couteuse.

3. Minimiser les permissions

Les utilisateurs remarquent les permissions, et Google Play surveille les permissions sensibles. Demandez uniquement ce qui est necessaire, au bon moment, avec une explication simple.

Verifiez:

• localisation precise ou approximative, premier plan ou arriere-plan;
• camera et medias;
• contacts et calendrier;
• notifications;
• micro et Bluetooth;
• permissions speciales avec justification forte.

Si une fonction MVP peut fonctionner sans permission sensible, evitez-la. Les permissions excessives reduisent la confiance et peuvent compliquer la review.

4. Proteger le stockage local

Ne stockez pas de donnees sensibles localement sans besoin. Si c'est necessaire, utilisez un stockage securise, evitez les tokens en clair et definissez ce qui est supprime a la deconnexion.

Controlez:

• tokens hors fichiers simples;
• cache prive limite;
• captures et logs sans ecrans prives;
• deconnexion qui nettoie l'etat sensible;
• sauvegardes qui n'incluent pas de donnees interdites.

Pour sante, chat prive et paiement, ces regles doivent etre decidees avant le developpement.

5. Reseau et acces backend

Le backend doit verifier les droits a chaque requete. L'app Android ne doit pas etre le seul endroit ou vivent les regles metier.

Verifiez:

• trafic API en HTTPS;
• chaque utilisateur accede uniquement a ses donnees;
• roles prestataire/admin verifies cote serveur;
• limites pour actions risquees;
• fichiers uploades verifies;
• statut de paiement confirme cote serveur;
• erreurs sans details prives.

Pour marketplaces et livraison, regardez de pres la propriete de commande, la visibilite des adresses et les actions prestataire.

6. Authentification et recuperation

L'authentification comprend inscription, connexion, login social, reset mot de passe, suppression de compte, expiration de session et recuperation via support.

Un MVP simple peut utiliser un fournisseur reconnu. Les apps plus sensibles peuvent demander des regles plus strictes, controle de changement d'appareil, second facteur ou confirmation supplementaire.

Si l'app contient chat prive, notes medicales, paiements ou acces admin, la recuperation de compte doit etre planifiee tot.

7. SDK, logs et analytics

Les SDK tiers peuvent collecter des donnees, ajouter des permissions, affecter la performance et changer les declarations store. Gardez seulement ce qui est utile.

Avant publication:

• supprimez les SDK inutilises;
• verifiez les exigences de confidentialite;
• evitez donnees personnelles, tokens ou texte prive dans les evenements;
• inspectez les crash logs;
• coupez les logs debug verbeux en release.

Les analytics doivent aider sans capturer de donnees privees inutiles.

8. Play Integrity si le risque le justifie

La documentation Android mentionne Play Integrity API et Credential Manager. Tous les MVP n'en ont pas besoin, mais les apps avec paiement, risque d'abus, contenu payant ou marketplace devraient en discuter.

Ces signaux ne remplacent pas les controles backend. Ils ajoutent une couche d'information.

9. Tester la vraie build release

Les builds debug peuvent masquer des problemes. Testez la build signee qui sera envoyee a Google Play.

Parcourez:

• premiere installation et premiere connexion;
• reset mot de passe ou login social;
• permissions;
• achat, reservation ou commande;
• deconnexion et suppression de compte;
• reseau lent ou hors ligne;
• crash reporting et analytics;
• actions admin si elles touchent l'utilisateur Android.

Google ajoute davantage d'alertes pour les developpeurs, mais mieux vaut corriger avant soumission.

Cout et perimetre

L'effort securite depend des donnees et des parcours. Un MVP contenu n'a pas le meme risque qu'une app de livraison, sante, chat prive ou marketplace avec paiements.

Chez Appfyl, un MVP cible commence souvent autour de 15.000-20.000 EUR. Un produit moyen se situe plutot entre 20.000-50.000 EUR. Une app plus large avec paiements, roles, panneau d'administration, donnees sensibles, monitoring et tests pousses peut atteindre 50.000-100.000 EUR.

La securite est une raison d'estimer par parcours et risques, pas seulement par nombre d'ecrans. Vous pouvez les decrire dans le brief d'estimation Appfyl.

Comment Appfyl l'aborde

Nous gardons la premiere version pratique. L'objectif n'est pas d'acheter tous les outils, mais d'eviter les erreurs couteuses apres lancement.

Nous verifions:

• donnees sensibles et roles;
• droits cote backend;
• permissions et stockage local;
• statuts paiement, reservation ou commande;
• analytics et logs;
• comportement de la build finale.

Pour sante, paiement ou communication privee, nous recommandons une verification plus approfondie avant lancement.

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

Questions fréquentes