iOS et Android : faut-il vraiment lancer les deux ?

En France, Android représente 63,26 % du trafic mobile et iOS 36,72 % (StatCounter, juillet 2026). Ces chiffres ne suffisent pourtant pas à décider. La seconde plateforme ne double pas le budget de développement, mais elle double presque tout le reste : les règles, les cycles de mise à jour et les motifs de refus.

Ce que les parts de marché disent, et ce qu'elles ne disent pas

Le rapport est d'environ deux tiers contre un tiers en faveur d'Android en France (StatCounter, juillet 2026). C'est une information utile, mais limitée : cette mesure porte sur des pages vues dans un navigateur, pas sur l'usage d'applications, et encore moins sur ce que les gens dépensent. Deux publics de taille différente ne se comportent pas forcément de la même façon une fois dans une application.

Je n'ai pas de chiffre public défendable sur la répartition des dépenses entre iOS et Android en France, et je préfère le dire plutôt qu'en citer un approximatif. Ce que je constate en revanche, c'est que la question « quelle plateforme est la plus grosse » est presque toujours la mauvaise. La bonne est : où sont les gens que vous visez précisément.

Une application destinée aux techniciens d'une entreprise se décide en regardant le parc de téléphones de cette entreprise, pas une moyenne nationale. Une application grand public destinée à une clientèle urbaine et jeune ne se répartit pas comme la moyenne non plus.

Ce que la seconde plateforme coûte vraiment

Le coût de la seconde plateforme n'est pas là où on l'attend. Avec un code partagé, le développement ne double pas. Ce qui double, c'est tout ce qui entoure le code : deux comptes à maintenir, deux processus de validation avec des règles différentes, deux calendriers de mise à jour imposés, et deux jeux de visuels de fiche qui obéissent à des consignes contradictoires.

Sur les frais : 99 USD par an chez Apple, contre 25 USD une seule fois chez Google (Apple, 2026 ; Google Play Console Help, 2026). C'est la partie négligeable. Sur les délais : Apple examine 90 % des soumissions en moins de 24 heures (Apple App Review, 2026), tandis que Google impose un niveau d'API cible qui monte chaque année — les applications existantes doivent atteindre Android 15 (API 35) au 31 août 2026 (Google Play Console Help, 2026).

La différence essentielle est ailleurs : les deux stores ne demandent pas la même chose. Google plafonne le texte marketing à "not more than 20% of the image" sur les captures et déconseille les mockups d'appareils ; Apple autorise explicitement les surimpressions et impose ses propres mockups, utilisés sans modification. Un seul jeu de captures pour les deux stores en enfreint généralement un.

Quand sortir sur une seule plateforme est le bon choix

Une plateforme unique est souvent la bonne décision, et c'est rarement présenté comme tel. Elle divise la surface à tester, réduit le nombre de règles à respecter, et permet de corriger vite pendant les semaines où l'on découvre ce que les gens font réellement de l'application. Le budget économisé finance généralement mieux la deuxième version que la deuxième plateforme.

Trois situations où c'est clairement le bon choix : une application interne dont vous connaissez le parc de téléphones, une application de terrain destinée à des équipes équipées par l'entreprise, et une première version dont l'objectif est d'apprendre plutôt que de couvrir. Dans ces trois cas, la seconde plateforme n'apporte pas d'utilisateurs, elle apporte du travail.

En pratique, sortir sur une seule plateforme est aussi le meilleur moyen de découvrir tôt que la moitié des fonctionnalités prévues n'intéressent personne — le sujet du piège du cahier des charges.

Quand il faut les deux dès le départ

Il existe des cas où la question ne se pose pas. Dès que le public est grand public et non identifié à l'avance, se priver d'un tiers ou de deux tiers du marché n'est pas une économie, c'est un plafond. C'est également vrai lorsque l'application fait partie d'une offre déjà vendue, où un client à qui l'on répond « nous ne sommes pas sur votre téléphone » est un client perdu immédiatement.

Le cas le plus net reste le produit dont la valeur dépend du nombre d'utilisateurs entre eux : prise de rendez-vous entre deux parties, marketplace, tout ce qui met en relation. Une plateforme unique y coupe non pas la moitié des utilisateurs, mais une part bien plus grande des rencontres possibles.

Un dernier cas mérite d'être cité parce qu'il est souvent découvert trop tard : l'application vendue à une entreprise qui laisse ses salariés utiliser leur téléphone personnel. Le parc n'est alors pas homogène, il suit la répartition du pays. Répondre « nous couvrons deux tiers de vos équipes » à un directeur des opérations revient à lui demander de gérer lui-même le tiers restant, ce qu'aucun ne fait.

Ce qui décide réellement

En résumé : les parts de marché renseignent sur le pays, pas sur votre public. La question n'est pas de savoir quelle plateforme est la plus répandue, mais si le public que vous visez se trouve réellement des deux côtés, et si vous avez le budget de maintenir deux fiches, deux calendriers et deux jeux de règles pendant des années.

Le point le plus important est que cette décision se reprend. Sortir sur une plateforme puis ajouter la seconde six mois plus tard est une trajectoire courante et souvent plus saine. L'inverse — retirer une plateforme qu'on ne parvient plus à entretenir — se voit beaucoup moins souvent, parce qu'il est bien plus difficile à assumer vis-à-vis des utilisateurs.

Je remarque souvent que la question arrive dans le mauvais sens : on demande combien coûte la seconde plateforme, alors que la vraie question est combien elle rapporte. Sur une application interne, la réponse est parfois zéro, et personne ne l'avait calculée. Sur une application grand public, la réponse est presque toujours « plus que son coût », et l'hésitation vient d'ailleurs — généralement d'un budget de départ fixé avant de savoir ce qu'on allait construire.

Questions fréquentes

Par quelle plateforme commencer si je ne dois en choisir qu'une ?

Par celle où se trouve votre public, pas par la plus grande. En France, Android domine le trafic mobile avec 63,26 % contre 36,72 % pour iOS (StatCounter, juillet 2026), mais une moyenne nationale ne décrit ni une clientèle professionnelle, ni un parc d'entreprise, ni une audience urbaine jeune. Si vous connaissez vos utilisateurs, regardez leurs téléphones plutôt que la statistique.

Un code partagé permet-il de sortir sur les deux sans surcoût ?

Il réduit fortement le coût de développement, mais pas le reste. Il faut toujours deux comptes développeur, deux fiches store avec des règles de visuels contradictoires, deux processus de validation et deux calendriers de mise à jour à suivre. Le surcoût de la seconde plateforme est surtout un coût de maintenance et de conformité, pas un coût de code.

Peut-on ajouter la seconde plateforme plus tard sans tout refaire ?

Oui, à condition que ce soit décidé au début. Une application conçue dès le départ pour accueillir une seconde plateforme s'y étend sans réécriture. Une application conçue pour une seule, avec des choix techniques qui en dépendent, se paie en reprise. C'est une décision d'architecture, prise avant la première ligne de code, pas une option à activer plus tard.

Le nombre de plateformes est une décision de budget avant d'être une décision technique, et elle se prend avec le même raisonnement que le reste des coûts qui arrivent après le lancement : ce qui compte n'est pas ce que cela coûte à construire, mais ce que cela engage à entretenir chaque année.