Combien de temps pour développer une application mobile ?
« En combien de temps ? » La question arrive au deuxième rendez-vous, juste après le budget, et presque tous les prestataires y répondent la même chose : trois à six mois, selon la complexité. La réponse est exacte et elle ne vous sert à rien. Ce que vous voulez savoir, c'est à quelle date votre application sera téléchargeable, et cette date dépend d'étapes qui ne produisent pas une ligne de code.
Deux durées que l'on confond
Un devis mobile porte une charge de travail, comptée en jours. Un planning porte un délai, compté en semaines de calendrier. L'un ne se déduit pas de l'autre. Sur un projet chiffré à soixante jours de travail, avec deux développeurs qui ne sont pas dessus à plein temps, trois semaines d'attente de contenus et une revue de boutique en fin de parcours, vous êtes à cinq mois de calendrier pour deux mois et demi de travail effectif.
Nous écrivons donc les deux séparément dans nos propositions. Le premier chiffre n'engage que nous. Le second engage les deux parties, et c'est pour cette raison qu'il est plus difficile à tenir.
Combien de temps pour un premier MVP mobile ?
Quatre à huit semaines pour un périmètre de cinq à huit écrans avec un seul rôle utilisateur. Deux à quatre mois pour une application grand public. Trois à cinq mois pour une application métier avec back-end et back-office. Ces durées couvrent la conception, le développement et la recette, mise en ligne exclue.
Ce sont les fourchettes que nous écrivons dans nos devis, celles qui accompagnent notre grille de budget d'une application mobile. Elles supposent trois conditions que l'on énonce rarement : un périmètre écrit et gelé avant le premier écran, une base de code unique en cross-platform plutôt que deux applications natives, et un interlocuteur qui répond dans la semaine.
Le poste qui déborde le plus souvent est la recette, pas le développement des écrans. Compter deux semaines de tests sur un projet de trois mois est une erreur que nous avons faite. Nous en comptons trois aujourd'hui dès qu'il y a deux plateformes, parce qu'un correctif validé sur iOS se revérifie sur Android, et qu'un aller-retour de correction traverse toujours un week-end.
Ce qui consomme du calendrier sans consommer de développement
C'est la partie que les comparatifs de délais passent sous silence, et c'est celle qui déplace les dates.
Google Play d'abord. Un compte développeur personnel neuf doit, avant de pouvoir demander l'accès à la production, « run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days » (exigences des nouveaux comptes développeur personnels, aide Google Play). Quatorze jours consécutifs, douze personnes réellement inscrites, et Google précise qu'un testeur qui se désinscrit puis se réinscrit repart de zéro. Sur un projet de dix semaines, cela fait deux semaines à réserver et douze volontaires à trouver, ce qui est plus long qu'il n'y paraît quand l'application n'est pas encore connue.
Apple ensuite. L'inscription au programme développeur en tant qu'organisation exige un numéro D-U-N-S : « Your organization must have a D-U-N-S Number so that we can verify your organization's identity and legal entity status » (inscription au programme, Apple Developer Support). Sa page d'inscription n'annonce aucun délai d'obtention ni de vérification. C'est précisément pour cela que la demande se lance le premier jour du projet et pas la veille de la soumission.
Les échéances d'outillage, enfin. Depuis le 28 avril 2026, les binaires téléversés sur App Store Connect doivent être construits « with Xcode 26 or later using an SDK for iOS 26 » ou l'équivalent sur les autres systèmes d'Apple (Upcoming requirements, Apple Developer). Côté Google, à partir du 31 août 2026, les nouvelles applications et les mises à jour doivent cibler Android 16 (niveau d'API 36) pour être soumises, avec une extension possible jusqu'au 1er novembre 2026 (niveau d'API cible requis, Android Developers). Un projet qui traverse une de ces dates porte une montée de version dans son planning, qu'il l'ait prévue ou non.
D'où notre règle : les comptes développeur s'ouvrent pendant la semaine de cadrage. Ce sont les seules tâches du projet dont le délai ne dépend ni de vous ni de nous.
Ce que trois projets livrés disent du calendrier réel
AquaPro est le cas le plus rapide de notre portfolio : une PWA en Vue.js et TypeScript pour des techniciens piscine en tournée, prototype fonctionnel en 24 heures, plus de 90 % de couverture de tests et une mise en production anticipée par la chaîne d'intégration continue. Le calendrier y était court pour une raison qui tient en un mot : aucune boutique n'intervenait. Donc aucun compte à faire vérifier, aucune revue à attendre, aucune échéance de SDK à honorer.
Daiky montre l'inverse, et c'est le projet où nous avons le plus mal estimé. L'application analyse la composition d'un cosmétique en une trentaine de secondes, en Flutter, avec Firebase et une lecture de codes-barres, et elle est bilingue français et anglais depuis la première version. Nous avions budgété le temps de la reconnaissance et de l'analyse. Ce qui a débordé, c'est la décision de ce qu'il fallait afficher en premier : un verdict trop tranché devient contestable, un verdict trop nuancé ne sert à rien devant un rayon. Cet arbitrage a demandé plus d'itérations que le scan lui-même. Nous provisionnons désormais des cycles de restitution sur tout produit grand public, parce que cette part-là ne se rattrape pas en écrivant du code plus vite.
AquaPro Manager, enfin, illustre le cas le plus fréquent en B2B : une architecture double, application Flutter pour les techniciens de terrain et web app Next.js pour le back-office des gérants, le tout sur Firestore avec des abonnements Stripe. Deux interfaces veulent dire deux recettes, et chaque changement du modèle de données se répercute des deux côtés. Un projet de ce type ne dure pas deux fois plus longtemps qu'une application seule, mais nous y provisionnons environ un tiers de calendrier en plus pour la seule synchronisation des deux chantiers.
Pourquoi un projet mobile prend-il du retard ?
Rarement à cause du code. Les décalages que nous constatons viennent de trois endroits : des contenus qui n'arrivent pas, des validations qui attendent la prochaine réunion d'un comité, et des accès ouverts trop tard, qu'il s'agisse des comptes de boutique, d'une API interne ou d'un jeu de données de recette. Le développement avance pendant ce temps, mais plus rien ne sort.
Un exemple ordinaire, qui revient sur presque tous les projets. Les deux boutiques réclament, au moment de créer la fiche produit, une politique de confidentialité et des déclarations sur les données collectées. Ces textes passent souvent par un conseil juridique, parfois par un délégué à la protection des données, et ils supposent que le traitement des données soit stabilisé. Ce sont deux à trois semaines qui n'apparaissent dans aucun planning de développement et qui arrivent toujours au pire moment, c'est-à-dire à la fin. Nous les déclenchons désormais en même temps que les maquettes, pour les sortir du chemin critique.
Ce que nous recommandons tient en une phrase : un décideur unique côté client, disponible une heure par semaine, avec le pouvoir de trancher seul sur le périmètre. Ce que nous déconseillons, c'est le comité de validation à cinq personnes. Il ne ralentit pas le projet d'un pourcentage, il le ralentit du délai de la prochaine réunion commune, et cela se produit à chaque question.
Le calendrier que nous mettons dans un devis
Voici la trame que nous proposons sur une application métier à deux plateformes. Les durées se recouvrent volontairement : le calendrier administratif court pendant que le développement avance.
| Jalon | Durée typique | Ce qui le bloque |
|---|---|---|
| Cadrage et périmètre écrit | 1 à 2 semaines | Disponibilité du décideur |
| Ouverture des comptes développeur | Lancée en semaine 1 | D-U-N-S, vérification d'identité |
| Maquettes et parcours validés | 2 à 3 semaines | Allers-retours de validation |
| Développement par lots livrés | 6 à 14 semaines | Changements de périmètre |
| Test fermé Google Play | 14 jours minimum, en parallèle | Recrutement de 12 testeurs |
| Recette sur les deux plateformes | 2 à 3 semaines | Contenus et données réelles |
| Soumission et revues | Non datée | Motifs de refus |
La dernière ligne est celle qui surprend, et nous la défendons. Nous n'inscrivons aucune durée de revue dans un planning et nous ne datons pas une mise en ligne dans un contrat, parce que c'est la seule étape où la décision ne nous appartient plus. Ce que nous pouvons faire, en revanche, c'est réduire la probabilité d'un refus : les motifs les plus fréquents et la façon de les anticiper sont détaillés dans notre article sur la publication sur l'App Store et Google Play.
Questions fréquentes
Combien de temps entre le premier rendez-vous et la mise en ligne ?
Peut-on aller plus vite en mettant plus de développeurs sur le projet ?
Combien de temps prend la validation par l'App Store et Google Play ?
Quand faut-il ouvrir les comptes développeur Apple et Google ?
Avant de demander un planning à qui que ce soit, écrivez deux choses. La liste des écrans de votre première version, celle que vous accepteriez de mettre en ligne sans les autres. Et le nom de la personne qui, chez vous, tranchera quand deux avis s'opposeront. Ces deux pages valent plus qu'un cahier des charges de quarante, parce qu'elles rendent le calendrier calculable.
Un prestataire qui vous annonce une date de mise en ligne au premier rendez-vous, sans avoir vu cette liste ni demandé qui décide chez vous, vous vend un chiffre. Nous préférons vous donner une charge, un jalon par lot et les dates que nous ne maîtrisons pas. C'est ce que nous cadrons dans notre service de développement d'application mobile, sur des projets menés depuis Antibes pour des entreprises de la Côte d'Azur.
