Pourquoi une fiche Google Play compte pour un SaaS
Un onglet de navigateur est en concurrence avec tous les autres onglets ouverts. Une app installée a sa propre icône sur l'écran d'accueil, sous les yeux de l'utilisateur chaque fois qu'il déverrouille son téléphone. Pour un SaaS que l'on ouvre tous les jours, la différence n'a rien de cosmétique : elle se voit dans la rétention.
Icône sur l'écran d'accueil
Un rappel quotidien de votre produit, là où un onglet finit oublié
Notifications push
Faire revenir les utilisateurs inactifs, prévenir avant la fin d'un essai, annoncer une nouveauté
Visibilité dans le store
La recherche Google Play amène des utilisateurs qui n'ont jamais vu votre site
Signal de confiance
« Disponible sur Google Play » rassure les acheteurs qui hésitent
Aucune réécriture
Votre stack web est l'app : vous mettez à jour le site, l'app suit
Ce que le Play Store vérifie vraiment
La revue automatisée de Google Play pour les packages de web apps vérifie quatre choses :
- Niveau d'API cible — doit être 36 (Android 16) pour toutes les nouvelles apps et mises à jour depuis le 31 août 2026.
- Fonctionnalité minimale — selon les règles de Google sur le spam et les fonctionnalités minimales, l'app doit faire quelque chose d'utile. Une page statique à un seul écran échoue ; un app multi-écrans, un dashboard SaaS, ou une plateforme de contenu passe.
- Formulaire de sécurité des données — vous devez déclarer quelles données votre app collecte (même si c'est juste de l'analytics). Requis pour toutes les apps.
- Signature valide — le .aab doit être signé avec un keystore. Le même keystore doit être utilisé pour chaque future mise à jour de ce nom de package.
TWA vs Capacitor : choisir le bon build pour votre web app
La méthode de build que vous choisissez affecte la taille de l'app, l'accès aux fonctionnalités PWA, et la compatibilité Play Store. Les deux produisent un .aab valide — la différence est ce qui se passe à l'exécution.
| Critère | TWA | Capacitor |
|---|---|---|
| Manifest PWA requis | Oui (icône ≥192px, HTTPS) ; service worker recommandé, pas obligatoire | Non — n'importe quelle URL HTTPS fonctionne |
| Taille de l'app | Très légère | Plus lourde : elle embarque une coque native |
| Rendu | Navigateur Chrome (partage cookies/cache) | WebView système (isolée) |
| Notifications push | Web Push de votre site (service worker) | Firebase natif (plus fiable) |
| Plugins natifs | Non | Caméra, biométrie, raccourcis |
| API level 36 | ✓ (via Bubblewrap) | ✓ (via Capacitor CLI) |
| Support offline | Nécessite service worker dans votre app | Peut injecter SW ou utiliser cache natif |
Étape par étape : de l'URL web app au Play Store
1. Lancer une vérification PWA
Collez votre URL dans un vérificateur PWA gratuit. Cela vous indique votre score manifest, si vous avez un service worker, et si TWA ou Capacitor est le bon chemin. Prend 10 secondes.
2. Configurer l'identité de votre app
Définir un nom de package au format domaine inversé (com.votresociete.nomapp). C'est permanent — cela identifie votre app dans le Play Store pour toujours. Définissez-le une fois ; ne le changez jamais.
3. Builder le .aab signé
Un build payant SaasToStore génère l'Android App Bundle signé. Votre keystore est créé au premier build payant, conservé chiffré et réutilisé à chaque mise à jour ; son mot de passe vous est envoyé une fois par e-mail. Le build cible l'API level 36 (Android 16) automatiquement et prend quelques minutes.
4. Créer un compte Play Console
S'inscrire sur play.google.com/console et payer les 25$ de frais développeur uniques. La vérification d'identité est requise. L'approbation prend généralement 1 à 2 jours.
5. Créer une nouvelle app et uploader
Dans la Play Console, créer une nouvelle app → Production track → uploader le .aab. Compléter les sections requises : contenu de l'app, audience cible, déclaration de sécurité des données, questionnaire de classification du contenu, URL de politique de confidentialité. Puis soumettre pour revue.
Préparer la fiche et éviter les rejets
Avant de soumettre, la fiche Google Play doit être complète. Voici ce qu'elle demande. SaasToStore peut générer l'icône, la bannière, les captures et un premier jet des descriptions à votre place.
Fichier de l'app
Un .aab signé
Icône
PNG 512×512 px
Bannière (feature graphic)
1024×500 px
Captures d'écran
Au moins 2, sur téléphone
Description courte
80 caractères au plus
Description complète
4 000 caractères au plus
Politique de confidentialité
Une URL publique
Les quatre erreurs qui bloquent le plus souvent une première publication :
Perdre le keystore
Sans la clé d'origine, impossible de publier une mise à jour sous le même nom de package. SaasToStore crée la clé de chaque app au premier build payant, la conserve chiffrée et la réutilise à chaque mise à jour ; son mot de passe vous est envoyé une fois par e-mail.
Soumettre sans politique de confidentialité
Mettez en ligne une politique de confidentialité et indiquez son URL avant de soumettre. SaasToStore peut en générer une.
Une icône à la mauvaise taille ou transparente
Préparez un PNG carré de 512×512 px, sur fond plein. Google Play arrondit lui-même les coins.
Un site sans HTTPS
Activez HTTPS chez votre hébergeur avant de lancer le build : sans lui, aucun wrapper ne fonctionne.
Ce que coûte la publication
Côté Google, l'inscription développeur de l'étape 4 coûte 25$ une seule fois, et vaut pour toutes les apps publiées depuis ce compte. L'autre coût, c'est la fabrication du bundle signé. À la main, les outils sont gratuits : la CLI Bubblewrap de Google pour une TWA, la CLI Capacitor pour une coque native. Vous payez en temps : installer et maintenir le SDK Android et Java, déboguer les builds qui échouent, garder une clé de signature qu'il ne faut jamais perdre. Un builder hébergé s'occupe de tout cela et conserve la clé pour chaque mise à jour.
Avec SaasToStore, le build de test gratuit est un APK au logo SaasToStore, pour voir l'app sur votre propre téléphone. Le .aab à uploader sur Google Play vient avec un build payant : voir les tarifs.
Conformité 2026 : ce qui a changé
Niveau d'API cible 36
RequisDepuis le 31 août 2026, toutes les nouvelles soumissions et mises à jour doivent cibler Android 16 (API 36). Les niveaux cibles plus anciens échouent la validation avant la revue.
Play Integrity API
Délai dépasséL'ancienne API SafetyNet Attestation est dépréciée. Si votre web app ou backend appelle SafetyNet, migrez vers Play Integrity API.
Section Sécurité des données
RequisVous devez déclarer avec précision toutes les données que votre app collecte (même via des SDK tiers comme l'analytics). Les incohérences entre votre déclaration et le comportement de l'app déclenchent une suppression.
Vérification d'identité
RequisTous les comptes développeur nécessitent désormais une vérification d'identité (personnelle ou organisation). Requis pour les nouveaux comptes.
Spécificités SaaS : connexion et notifications push
Connexion : en général, rien à changer
Votre authentification actuelle (Supabase, Auth0, Clerk, vos propres sessions) continue de fonctionner dans l'app. E-mail et mot de passe ou codes à usage unique se comportent comme sur votre site ; les magic links aussi, une fois que les deep links les renvoient vers l'app. Dans une TWA, l'app partage les cookies de Chrome : un utilisateur déjà connecté dans Chrome sur ce téléphone l'est souvent aussi dans l'app. Un build natif Capacitor garde sa propre session : l'utilisateur se connecte une fois dans l'app. L'exception, c'est Google : il refuse sa connexion dans une WebView intégrée, donc l'app native ouvre « Se connecter avec Google » dans le navigateur du système, puis y ramène l'utilisateur. Ce retour demande d'autoriser une adresse chez votre fournisseur d'authentification.
Les notifications push, levier de rétention
Le push est le principal levier de rétention qu'une app de store donne à un SaaS. Les messages qui marchent le mieux :
- — La fin d'un essai dans 3 jours, avec un lien pour passer à l'offre payante
- — Une nouvelle activité sur ce que l'utilisateur suit : un commentaire, une mention, une mise à jour
- — Un récapitulatif hebdomadaire, ou un palier d'usage atteint
- — Une nouvelle fonctionnalité, envoyée aux utilisateurs actifs
- — Une relance après 7 jours sans visite
Dans le build natif, les notifications partent de l'app elle-même : les notifications navigateur de votre site ne passent pas dans l'app.
Au-delà de Google Play
La même session de build qui produit votre Google Play AAB peut également générer un Windows .msi, macOS .dmg, et Linux .AppImage — publiés sur le Microsoft Store, le Snap Store, Flathub, et GitHub Releases. Si vous allez empaqueter votre web app une fois, il n'y a aucun coût marginal à atteindre les 7 stores dans le même build.
Sur Android, la même app part aussi sur l'Amazon Appstore et le Samsung Galaxy Store, et la même URL donne une app iPhone pour l'App Store. Votre site est fait avec un outil no-code ? Voir les guides Lovable, Bubble et Webflow.
Vérifiez si votre web app est prête pour les stores
Vérification PWA gratuite — score manifest, statut service worker, recommandation de chemin de build. 10 secondes.
Vérifier mon app →