La fausse évidence
« Il faut être sur les deux, sinon je perds la moitié du marché. » C'est l'argument qu'on entend le plus souvent au premier appel, et il part d'une bonne intention : ne fermer aucune porte. Le problème, c'est qu'il ignore ce que coûte réellement cette porte ouverte, et à quel moment du projet elle mérite de l'être.
Ce que développer pour les deux plateformes coûte vraiment
Développer une application « iOS et Android en même temps » ne double pas seulement le nombre d'écrans à construire. Cela multiplie plusieurs postes à la fois.
Le temps de développement. Même avec un langage partagé comme React Native, chaque plateforme a ses spécificités : gestion des permissions, notifications, comportement des animations, taille et forme des écrans. Une fonctionnalité qui fonctionne du premier coup sur iOS demande souvent des ajustements sur Android, et inversement.
Les revues de publication. L'App Store et le Google Play Store ont chacun leurs règles, leurs délais et leurs motifs de refus. Préparer un dépôt qui passe des deux côtés, c'est préparer deux dossiers, pas un seul recopié.
La maintenance dans la durée. Chaque mise à jour d'iOS ou d'Android peut casser un comportement qui marchait la veille. Maintenir deux applications, c'est surveiller deux calendriers de versions système, deux écosystèmes d'appareils, deux jeux de retours utilisateurs.
L'attention de l'équipe. C'est le coût le moins visible et souvent le plus lourd : une équipe qui répartit son temps sur deux plateformes avance deux fois moins vite sur chacune, au moment précis où la vitesse compte le plus, c'est-à-dire au lancement.
Pourquoi nous conseillons presque toujours iOS d'abord
Notre position, assumée depuis le premier projet du studio : pour une première version, iOS seul, presque toujours. Trois raisons concrètes.
Un public qui paie plus volontiers. C'est une réalité connue de tout le secteur : l'écosystème iOS a une réputation de meilleure conversion vers le payant que l'écosystème Android. Pour une application qui vise un modèle payant (abonnement ou achat), cela concentre l'effort là où la conversion a le plus de chances d'être favorable.
Un lancement concentré s'apprend plus vite. Une seule plateforme, c'est un seul jeu de retours à analyser, un seul comportement à corriger, une seule fiche à optimiser. Les enseignements du premier mois arrivent plus vite et plus nets quand ils ne sont pas dilués entre deux écosystèmes.
Un environnement technique plus prévisible. iOS tourne sur un nombre limité d'appareils, tous mis à jour rapidement par leurs propriétaires. Android couvre des milliers de modèles, avec des versions du système qui cohabitent pendant des années. Tester une application sur l'ensemble du parc Android est, à budget de studio égal, une tâche d'une tout autre ampleur.
C'est cette logique que nous suivons nous-mêmes sur nos propres applications : Solys, TradaZen, Nolera et Piaf sont toutes nées et pensées pour iOS d'abord.
Les cas où il faut penser aux deux dès le départ
Cette règle n'est pas absolue. Trois situations changent la réponse :
Votre audience existante est majoritairement Android. Si vous lancez une application pour une communauté que vous connaissez déjà (un club, une clientèle locale, un public professionnel précis), et que cette audience utilise majoritairement Android, il faut évidemment partir de là où sont les gens, pas de la plateforme qui convertit le mieux en moyenne.
L'application dépend d'un effet de réseau immédiat. Une application de messagerie ou de mise en relation qui ne vaut rien sans masse critique d'utilisateurs peut avoir besoin des deux plateformes dès le lancement, pour ne pas exclure une partie du réseau visé.
Le marché visé est structurellement différent d'iOS. Sur certains marchés hors de France et d'Europe de l'Ouest, la part Android dépasse très largement iOS. Le choix de plateforme doit alors suivre le marché réel, pas une règle générale.
Une décision à prendre au cadrage, pas en cours de route
Le choix de la ou des plateformes n'est pas un détail technique qu'on tranche une fois le développement commencé : c'est une des questions qui doivent figurer noir sur blanc dans le cahier des charges de votre projet, au même titre que le modèle de revenu ou le public visé. La trancher tôt évite un débat qui revient sinon à chaque réunion, sans jamais vraiment se clore, et qui finit par retarder le lancement au lieu de l'accélérer.
Le bon moment pour ajouter Android
La bonne nouvelle : commencer par iOS ne ferme pas Android, ça le reporte à un moment où la décision se prend avec des faits plutôt qu'avec de l'espoir. Une fois la première version publiée, mesurée et ajustée, vous savez si le produit retient ses utilisateurs, quel prix ils acceptent de payer, et quelles demandes reviennent. Ajouter Android à ce moment-là se fait sur une base solide, avec un produit déjà validé, plutôt qu'en pariant sur les deux plateformes en même temps sans savoir si l'une ou l'autre fonctionne.
C'est la même logique que nous suivons pour cadrer toute première version : réduire au testable, publier, mesurer, décider la suite avec des chiffres. Notre méthode complète de cadrage part de ce principe.
Notre recommandation, en une phrase
Sauf si votre audience ou votre marché impose clairement Android, lancez sur iOS, apprenez vite, et décidez d'Android une fois que le produit a fait ses preuves plutôt qu'en même temps que vous découvrez s'il en a.
Une idée d'application et une hésitation sur la plateforme à choisir : parlons-en 30 minutes. Nous vous donnerons un avis honnête sur votre cas précis, et un prix ferme si le projet est prêt à démarrer.
