Combien de temps faut-il pour développer une application mobile ?

Combien de temps faut-il pour développer une application mobile

Une application mobile publiée sur les deux stores représente 60 à 90 jours-homme, tous profils confondus. C’est le chiffre de la grille publique Lonestone, et il ne dit rien du calendrier.

Le calendrier, lui, dépend d’abord de vous, pas de la vitesse de frappe de l’équipe technique. Un projet à 70 jours-homme se livre en six semaines ou en huit mois selon une seule variable : la vitesse à laquelle les décisions se prennent et les accès arrivent. Confondre les deux nombres est la première cause de déception sur un projet mobile.

Jours-homme et semaines de calendrier ne sont pas la même chose

Un jour-homme est une journée de travail d’une personne. Soixante-dix jours-homme ne font pas soixante-dix jours de calendrier.

Ils peuvent en faire moins, si plusieurs personnes travaillent en parallèle sur des parties indépendantes. Ils peuvent aussi en faire beaucoup plus, et c’est le cas le plus fréquent. Quatre choses transforment des jours-homme en mois de calendrier :

L’attente d’un accès à une base de données, d’un compte store, d’une validation de maquette. Pendant l’attente, le compteur de jours-homme est à l’arrêt, celui du calendrier tourne.
Le séquencement : certaines tâches ne peuvent pas commencer avant que d’autres soient finies. On ne branche pas un écran sur des données qui n’existent pas encore.
Le passage de relais. Chaque personne supplémentaire dans la boucle ajoute une explication, un compte-rendu, un délai de réponse.
La reprise. Une décision qui change après coup coûte le temps de défaire ce qui a été construit sans elle.

Deux équipes séparées, une iOS et une Android, doublent mécaniquement le premier nombre. Un code unique compilé pour les deux plateformes reste l’arbitrage par défaut sur une application métier, précisément pour cette raison.

Ce volume de jours se traduit ensuite en euros, poste par poste, dans combien coûte une application mobile en 2026.

Ce qui prend vraiment du temps

Écrire le code n’est pas ce qui consomme le calendrier. Voici ce qui le consomme, dans l’ordre.

Les décisions non prises

« On verra plus tard si on met un espace administrateur. » Cette phrase, dite en semaine 1, coûte deux semaines en semaine 5. Une application se construit en couches : la gestion des rôles n’est pas un écran qu’on ajoute, c’est une hypothèse qui traverse toute la base.

Le coût d’une décision repoussée n’est pas le temps de la prendre, c’est le temps de défaire ce qui a été construit sans elle.

Vos données et vos accès

Si l’application doit lire ou écrire dans un système existant, tout dépend de l’état de ce système. Une interface documentée et testable, c’est quelques jours. Un logiciel métier historique sans interface prévue pour ça, c’est un projet dans le projet, et il commence par obtenir les accès auprès d’un éditeur qui n’a aucune raison de se presser.

Ce point s’instruit en premier, avant même les maquettes. Un projet qui découvre en semaine 6 que l’ERP n’expose rien repart de zéro sur son planning.

Les comptes stores

Un compte Apple Developer d’entreprise exige un identifiant DUNS. L’obtenir prend de quelques jours à plusieurs semaines selon la réactivité de l’organisme et l’état de vos informations légales. Google Play demande une vérification d’identité de l’organisation.

Ce délai est purement administratif, il n’apporte rien, et il bloque la publication. Il se lance le premier jour du projet, pas le jour où le code est prêt.

La review Apple et Google

Comptez de quelques heures à quelques jours pour un passage nominal. Le risque se situe ailleurs, dans le refus : politique de confidentialité incomplète, fonctionnalité de suppression de compte absente, paiement qui contourne les règles de la plateforme, capture d’écran non conforme.

Chaque refus coûte un aller-retour. Deux refus enchaînés sur une fin de projet tendue, et la date de lancement commerciale saute.

La recette

C’est la phase que les plannings optimistes suppriment en premier, et celle qui décide de la note du store. Faire tester l’application par de vraies personnes sur de vrais appareils, corriger, refaire tester : ce temps se prévoit.

Un calendrier réaliste, semaine par semaine

Pour une application métier de périmètre resserré, avec un décideur unique et des données accessibles :

Période	Ce qui se passe	Ce qu’on attend de vous
Semaine 0	Cadrage, périmètre écrit, ouverture des comptes stores et de la demande DUNS	Vos informations légales, un décideur nommé
Semaines 1 à 2	Parcours, écrans clés, modèle de données, accès aux systèmes existants	Valider les parcours, ouvrir les accès
Semaines 2 à 5	Construction, avec un build installable livré chaque semaine	Installer et rendre un retour sous 48 h
Semaines 5 à 6	Recette sur appareils réels, corrections, préparation des fiches store	Faire tester par vos équipes
Semaine 6	Soumission, review, publication	Valider les textes et les captures

La colonne de droite est celle qui décide du résultat. Un retour rendu en 48 heures tient le planning. Le même retour rendu en dix jours le décale d’autant, et cinq fois de suite il l’a doublé.

Ce rythme suppose aussi un périmètre resserré et une décision centralisée. Un projet à valider par un comité qui se réunit tous les quinze jours ne tient pas ce calendrier, et c’est normal : c’est un rythme d’entreprise, pas un problème technique. Il se planifie.

Les quatre choses qui font déraper un planning

Le périmètre qui bouge en cours de route. Chaque ajout est légitime pris isolément, c’est leur accumulation qui tue la date. La parade tient en une ligne : tout ajout est accepté, et il déplace explicitement la date ou remplace autre chose.
Les comptes stores lancés trop tard. C’est le déraillement le plus bête et le plus évitable.
L’accès aux systèmes existants. Le prestataire attend l’accès, l’éditeur historique attend une demande formelle, et le dirigeant apprend le blocage trois semaines après.
La validation à plusieurs sans arbitre. Trois personnes qui donnent trois avis contradictoires sur une maquette produisent un cycle, pas une décision. Un projet mobile a besoin d’un décideur nommé, avec le droit de trancher seul.

Pourquoi certains livrent en semaines quand d’autres mettent des trimestres

La différence ne tient pas à la vitesse des personnes, mais au nombre de couches que le projet doit traverser.

Dans une organisation classique, une décision descend d’un responsable de compte vers un chef de projet, puis vers un lead technique, puis vers deux équipes de développement séparées, puis remonte en comité de pilotage. Chaque palier ajoute un compte-rendu, un délai de réponse et une reformulation. Le temps de travail réel ne change pas. Le temps de calendrier est multiplié.

Quand la personne qui vous parle est la personne qui construit, ces paliers disparaissent : plus de relais, plus de compte-rendu facturé, plus de traduction entre celui qui a entendu le besoin et celui qui écrit le code. Une base de code unique pour les deux plateformes supprime le palier suivant. La vitesse vient de là, et d’aucun outil.

Et l’intelligence artificielle, elle fait gagner combien ?

C’est la question qu’on nous pose systématiquement, et la réponse ne va pas dans le sens du marché : aucune étude sérieuse ne mesure aujourd’hui un gain de vitesse de bout en bout sur une application en production.

L’étude la plus rigoureuse disponible, menée par METR en 2025, a suivi 16 développeurs expérimentés sur 246 tickets, dans leurs propres dépôts de code. Résultat mesuré : ils ont été 19 % plus lents avec l’assistance IA. Ils avaient prédit un gain de 24 %, et après coup, ils croyaient encore avoir été accélérés. L’écart entre la perception et la mesure est d’environ 39 points. La reconduction de février 2026 ne trouve toujours pas de gain significatif.

Le fameux « +55 % » de GitHub, lui, porte sur un serveur HTTP écrit depuis une page blanche : pas de code existant, pas d’architecture à respecter, pas de revue, pas de tests, pas de passage en review de store. L’étude est financée par GitHub. Elle mesure sincèrement un exercice qui n’a rien à voir avec un projet client.

Ce qui est mesuré, en revanche, mérite d’être connu d’un dirigeant qui achète une application. Le relevé Faros sur des équipes réelles montre des demandes de fusion de code en hausse de 98 %, mais aussi des incidents par demande en hausse de 242,7 %, des bugs par développeur en hausse de 54 %, une charge de revue de code en hausse de 441 %, et des métriques de livraison finales plates.

Pour votre projet, ça veut dire ceci : l’IA augmente le volume de code produit et, mécaniquement, la charge de test. Elle raccourcit le chemin jusqu’à une application stable en production seulement si quelqu’un absorbe la charge de vérification supplémentaire.

C’est pour ça qu’on ne vend pas de multiplicateur. On utilise ces outils tous les jours, ils font partie du métier, et ils ne figurent sur aucune ligne de facture. La vitesse qu’on annonce vient de l’absence de couches à payer.

Quand l’application existe déjà et qu’il faut la reprendre, le planning commence par un audit et par la récupération des accès, ce qui change complètement la première phase : reprendre une application mobile ratée.

Ce que vous pouvez préparer pour gagner deux semaines

Avant même de choisir un prestataire, ces cinq points sont sous votre contrôle et ils valent une quinzaine de jours de calendrier.

Lancer la demande d’identifiant DUNS si votre entreprise n’en a pas. C’est gratuit et c’est le chemin critique le plus long.
Nommer un décideur unique, avec le droit de trancher sans réunion.
Identifier qui détient les accès à vos systèmes existants, et prévenir cette personne qu’on va la solliciter.
Écrire ce que l’application doit débloquer, en euros ou en heures. Pas la liste des fonctionnalités : le coût de la situation actuelle. C’est ce qui permettra d’arbitrer le périmètre quand il faudra couper.
Décider maintenant des trois choses structurantes : y a-t-il des rôles différents, faut-il un espace d’administration, l’application doit-elle fonctionner sans réseau.

Si vous voulez qu’on regarde votre cas, le questionnaire de cadrage prend cinq minutes et prépare un appel de 45 minutes. Ce qu’on livre et dans quel ordre est détaillé sur la page application mobile.

Questions fréquentes

Comptez 60 à 90 jours-homme pour une application publiée sur les deux stores. En calendrier, six semaines sont atteignables sur un périmètre resserré, avec un décideur unique et des retours rendus sous 48 heures. Le même projet prend six à huit mois quand les validations passent par un comité.

Qu’est-ce qui retarde le plus un projet d’application mobile ?

Les décisions structurantes repoussées, l’accès aux systèmes existants, et les comptes développeur ouverts trop tard. Le compte Apple d’entreprise exige un identifiant DUNS dont l’obtention peut prendre plusieurs semaines, et il bloque la publication.

Combien de temps prend la validation Apple et Google ?

De quelques heures à quelques jours pour un passage nominal. Le risque réel est le refus : politique de confidentialité incomplète, absence de suppression de compte, paiement qui contourne les règles de la plateforme. Chaque refus coûte un aller-retour.

L’intelligence artificielle accélère-t-elle le développement d’une application ?

Aucune étude sérieuse ne mesure de gain de bout en bout sur une application en production. METR a mesuré en 2025 des développeurs expérimentés 19 % plus lents avec l’assistance IA, sur leurs propres dépôts. Le relevé Faros montre un volume de code en hausse de 98 % mais des incidents par demande de fusion en hausse de 242,7 %.

Peut-on développer une application iOS et Android en même temps ?

Oui, avec une base de code unique compilée pour les deux plateformes. C’est l’arbitrage par défaut sur une application métier : deux équipes séparées doublent le travail, les tests et les régressions.

En résumé

Un MVP publié sur les deux stores, c’est 60 à 90 jours-homme. Le calendrier, lui, dépend de votre rythme de décision.
Ce qui prend du temps : les décisions repoussées, l’accès à vos données, les comptes stores, la review, la recette.
Six semaines sont atteignables sur un périmètre resserré, avec un décideur unique et des retours rendus sous 48 heures.
Les paliers d’organisation coûtent plus de calendrier que le code lui-même.
L’IA n’a pas de gain de vitesse mesuré sur une application en production. METR mesure 19 % plus lent, et Faros mesure surtout une charge de test en hausse. Méfiez-vous de tout prestataire qui vend un délai par ce levier.