Comment je publie des applis Android en solo en 2026

Le plus difficile quand on publie une appli Android en solo en 2026, ce n’est pas le code. Compose est mature, l’outillage de Play est bon, et il y a plus de bibliothèques que personne n’a le temps d’en lire. Le plus difficile, c’est de finir. Le périmètre s’étend, le peaufinage vide le calendrier, et un jour on réalise que l’appli commencée il y a trois mois est techniquement plus impressionnante et toujours pas sur le store.

J’ai publié deux applis de cette manière, une troisième est en préparation, et j’ai enfin arrêté un guide qui me mène de l’idée à la fiche en ligne en environ quatre à six semaines. Rien de tout cela n’est malin. Tout tient au fait de dire non aux choses.

1. Cadrez sans pitié — un écran, un verbe

Avant d’écrire le moindre Kotlin, je fais un seul exercice : décrire l’appli en une phrase avec un seul verbe. Granyn — enregistrer une dépense en deux touches. Hydrame — recevoir un rappel apaisant avant d’oublier de boire de l’eau. Subly — photographier une facture et faire extraire l’abonnement sur l’appareil. Si la phrase contient un « et », l’appli, ce sont deux applis.

Cette seule phrase devient la règle de chaque décision de fonctionnalité. Des graphiques ? Seulement s’ils servent le verbe. La synchro cloud ? Seulement si son absence casse le verbe. Les réglages ? Le moins possible. L’astuce la plus sous-estimée du développement en solo, c’est de ne pas construire de choses.

Si votre pitch en une phrase contient un « et », vous construisez deux applis.

Une vraie façon d’imposer cela : écrivez la fiche Play Store — titre, description courte, le sous-titre de 80 caractères — avant d’écrire la moindre ligne de code. Si vous ne pouvez pas vendre l’appli en 80 caractères, vous ne pouvez pas la construire en huit semaines non plus.

2. Choisissez une pile minuscule et ennuyeuse

Pour Android en 2026, toute ma pile est volontairement minuscule :

• Kotlin + Jetpack Compose (pas de layouts XML, pas de fragments)
• Une seule activity avec androidx.navigation.compose
• Room avec Flow et fonctions suspend pour tout ce qui est local
• DataStore (variante preferences) pour les réglages
• WorkManager pour l’arrière-plan, AlarmManager seulement là où l’exactitude est requise
• Material 3 pour les composants, avec un schéma de couleurs personnalisé
• Hilt pour l’injection de dépendances — mais seulement si l’appli est assez grosse pour en avoir besoin (Granyn oui, un petit utilitaire non)

Voilà toute la liste. Pas de générateurs lourds en KSP, pas de couche réseau à moins que l’appli parle vraiment à un serveur, pas de kits d’UI tiers. La règle : une nouvelle dépendance doit mériter sa ligne dans build.gradle.kts avec une justification en une phrase que je suis prêt à écrire.

3. Développez d’abord les écrans ennuyeux

Contre-intuitif mais vrai : je développe les écrans les moins excitants avant la fonctionnalité vedette. États vides, réglages, onboarding, marqueurs « pas encore de données ». Ils révèlent le modèle de données et le graphe de navigation plus vite que n’importe quoi, et ce sont les écrans que vous redouterez plus tard si vous les gardez pour la fin.

La fonctionnalité vedette arrive en troisième ou quatrième. Le temps que j’y arrive, la couche de données est déjà conçue par les écrans ennuyeux qui avaient besoin d’y lire.

Un échafaudage minimal que je réutilise sur chaque projet :

@Composable
fun App() {
    val navController = rememberNavController()
    Scaffold(
        bottomBar = { AppBottomBar(navController) },
    ) { inner ->
        NavHost(
            navController = navController,
            startDestination = Routes.Home,
            modifier = Modifier.padding(inner),
        ) {
            composable(Routes.Home) { HomeScreen() }
            composable(Routes.Stats) { StatsScreen() }
            composable(Routes.Settings) { SettingsScreen() }
        }
    }
}

C’est toute « l’architecture » de la moitié de mes applis.

4. Verrouillez le modèle de données tôt, migrez à jamais

Les migrations de schéma sont le tueur silencieux des applis indépendantes. La solution, c’est de penser la base de données comme une API publique — une fois en production, chaque changement est une migration avec un test. Room rend cela gérable :

@Database(
    entities = [Expense::class, Category::class],
    version = 4,
    autoMigrations = [
        AutoMigration(from = 1, to = 2),
        AutoMigration(from = 2, to = 3, spec = MigrateNotesField::class),
        AutoMigration(from = 3, to = 4),
    ],
    exportSchema = true,
)
abstract class AppDatabase : RoomDatabase() { ... }

La chose la plus utile que je fais : exportSchema = true et committer ces fichiers JSON dans git. Ensuite, un test géré par Room attrape les régressions de schéma avant qu’elles n’atteignent l’appareil d’un utilisateur. Je ne compte plus les mauvais après-midis que cela m’a épargnés.

5. Tests manuels sur de vrais téléphones, automatisés seulement là où ça compte

Pyramide de tests du dev solo : une poignée de tests unitaires purs pour les parties faciles à tester et impossibles à déboguer autrement (calculs de devise, calculs de dates, l’extraction de champs par OCR dans Subly). Zéro test d’UI. De gros tests de fumée manuels sur trois vrais téléphones : un Pixel, un Samsung de milieu de gamme, et un Xiaomi vraiment pas cher. Le téléphone pas cher n’est pas négociable — c’est celui que vos utilisateurs ont réellement.

Le Samsung et le Xiaomi feront tous deux ressortir de vrais problèmes qui n’apparaissent pas dans l’émulateur. Notifications tuées par une optimisation de batterie agressive, alarmes exactes discrètement reprogrammées, motifs de vibration qui se déclenchent 200 ms trop tard. Si votre appli a besoin de notifications fiables (Hydrame en a besoin), testez sur un Samsung sinon vous le découvrirez après le lancement.

6. La fiche Play Store, c’est la moitié de votre appli

Passez un week-end sur la fiche du store. Le titre et la description courte, c’est le SEO. Les captures d’écran, c’est la conversion. Le visuel de fonctionnalité (feature graphic), c’est les 1,6 premières secondes que quelqu’un passe avec votre marque.

Une checklist réaliste :

• Titre avec le mot-clé principal (ne soyez pas mignon — « Granyn — Budget & Expense Tracker » bat « Granyn »)
• Description courte (80 caractères) avec le verbe et l’unique différenciateur
• Description longue avec trois à cinq courts paragraphes, des sous-titres et des emojis utilisés avec parcimonie
• Captures d’écran en 1080×2400 ou plus, la première capture étant votre visuel vedette. La plupart des utilisateurs ne font jamais défiler.
• Visuel de fonctionnalité (1024×500). Gardez le texte minimal — c’est une bannière, pas un panneau publicitaire.
• URL de la politique de confidentialité — obligatoire. Hébergez-la vous-même (GitHub Pages fonctionne) pour pouvoir la modifier sans publier une version.
• Classification de contenu — remplissez le questionnaire honnêtement. C’est plus rapide que vous ne le pensez.
• Catégorisation de l’appli — formulaire de Sécurité des données (Data Safety). Prenez-le au sérieux ; c’est la version publique de votre politique de confidentialité.

Le formulaire de Sécurité des données est celui que la plupart des gens bâclent. Remplissez-le comme si vous l’expliquiez à un avocat. Si vous ne pouvez pas cocher « aucune donnée collectée », expliquez exactement quel tiers (Firebase, AdMob, Play Billing) traite quel champ. Google vérifie chaque année plus strictement par rapport au comportement d’exécution.

7. Lancez discrètement, surveillez le tunnel

Faites un lancement en douceur dans votre pays d’abord. Ne l’annoncez pas. Les 50 premières installations sont votre bêta — soyez attentif aux rapports de plantage, aux ANR et au ratio installation/désinstallation. Si la rétention au jour 1 est sous les 30 %, corrigez l’onboarding avant de faire le moindre marketing.

La première chose que je vérifie chaque matin dans la Play Console durant les deux premières semaines :

• % d’utilisateurs sans plantage
• Taux d’ANR
• Vitals (réveils excessifs, images figées)
• Avis 1 étoile — lisez chaque mot. Ce sont de l’or.

Ensuite je déploie plus large — au reste de l’Europe, puis à l’échelle mondiale. Le déploiement progressif (10% → 25% → 50% → 100%) est gratuit ; utilisez-le.

8. Le travail ennuyeux d’après-lancement

Deux semaines après le lancement, le vrai travail commence : répondre aux avis, corriger les petits bugs que les 500 premiers utilisateurs ont trouvés, et résister à l’envie de commencer l’appli suivante. Mettre à jour une fois par semaine avec de petits changelogs honnêtes bâtit une confiance qu’aucun marketing malin ne peut égaler.

C’est aussi là que l’ASO fait effet de levier. Des mots-clés dans le titre et la description, un flux régulier de petites mises à jour, et un lent filet d’avis organiques — rien de tout cela n’est glamour, tout cela fonctionne.

Ce que je ferais différemment la prochaine fois

Une courte liste, car le recul est le meilleur professeur :

1. Écrivez la fiche Play Store en premier. Traitez-la comme le cahier des charges. Je ne plaisante pas.
2. De plus grands états vides dès le premier jour. Un écran blanc tue les premières impressions ; un état vide réfléchi vous achète une deuxième ouverture.
3. L’onboarding a droit à un écran. Deux peut-être. S’il vous en faut trois, vous avez un problème d’UX à régler dans l’appli, pas un onboarding plus long.
4. Installez Crashlytics dès le premier jour. Oui, même pour un petit utilitaire.
5. Politique de confidentialité hébergée sur son propre domaine ou sur GitHub Pages. Vous la mettrez à jour plus souvent que vous ne le pensez et vous ne voulez pas une nouvelle revue de la Play Console pour chaque retouche.

Tout le guide est délibérément peu romantique. Le romantisme du développement indépendant, c’est la liberté de publier ; le guide, c’est ce qui protège cette liberté de votre propre dérive de périmètre.

Si vous êtes quelque part au milieu d’une appli Android à moitié construite en ce moment, la chose la plus utile que vous puissiez faire cette semaine, c’est de supprimer une fonctionnalité. Puis allez écrire la description Play Store. Le lancement est plus proche que vous ne le pensez — l’essentiel de ce qui vous bloque est de votre côté de l’écran.