Combien de temps faut-il pour développer une application mobile ?
Un calendrier compréhensible pour prévoir la sortie d'une application, distinguer travail et attente, organiser les tâches parallèles et réduire les retards.
Un prototype assisté par IA ou un pilote très limité peut généralement être préparé en deux semaines environ. Une application low-code avec des écrans standard, un profil principal et des intégrations simples demande souvent un à deux mois. Un MVP mobile sur mesure nécessite plutôt 12 à 20 semaines, un produit intermédiaire 20 à 32 semaines et une plateforme complexe 32 à 52 semaines ou davantage. Les délais courts servent à valider l'idée et ne rendent pas automatiquement le produit sûr, évolutif et prêt pour les stores.
Estimez votre app avec un bref questionnaire
CommencerDes fourchettes réalistes selon le produit
Ces durées servent à planifier. Elles supposent une petite équipe expérimentée, des validations assez rapides et des fournisseurs externes accessibles.
| Résultat visé | Durée courante | Ce que la livraison peut raisonnablement contenir |
|---|---|---|
| Prototype assisté par IA ou pilote limité | Environ 2 semaines | Parcours central, écrans générés et démonstration fonctionnelle avec peu de données et d'intégrations |
| Pilote low-code | 4-8 semaines | Un profil principal, connexion standard, formulaires ou catalogue, données simples, automatisation de base et test utilisateur |
| MVP sur mesure ciblé | 12-20 semaines | Un parcours central, serveur, administration simple, analytique, recette et soumission |
| Produit intermédiaire | 20-32 semaines | Plusieurs profils, paiement ou réservation, intégrations, notifications et tests élargis |
| Plateforme complexe | 32-52 semaines ou plus | Plusieurs applications, migration, données sensibles, synchronisation hors connexion ou intégrations difficiles |
Le nombre d'écrans donne une image trompeuse. Six écrans reliés à une vérification d'identité, à des paiements récurrents et à un ancien logiciel métier peuvent représenter plus de travail qu'un catalogue riche.
Comment le low-code et l'IA modifient le délai
Deux semaines constituent un repère réaliste pour un prototype interactif assisté par IA ou un pilote très restreint, pas pour n'importe quel produit en exploitation. Les outils actuels créent très vite une première base : FlutterFlow Designer génère un storyboard modifiable à partir d'une description et le guide Replit Agent présente une première version fonctionnelle produite en quelques minutes. Le reste du délai sert à corriger le résultat, connecter un petit volume de données réelles, tester le parcours principal et préparer une démonstration utile.
Une réalisation low-code demande généralement quatre à huit semaines lorsqu'elle repose sur des composants courants : un profil principal, une connexion standard, des formulaires ou un catalogue, une base simple, des notifications et une intégration déjà prise en charge. Ce délai d'un à deux mois doit aussi couvrir les décisions métier, les accès, les essais sur appareils et les retours d'un petit groupe d'utilisateurs. Le guide FlutterFlow ou développement sur mesure précise les cas adaptés.
Le raccourci cesse d'être crédible avec des paiements complexes, plusieurs niveaux d'autorisation, un fonctionnement hors connexion particulier, des données réglementées, un ancien système difficile à relier ou une forte charge dès le départ. L'IA accélère encore les écrans, le code courant et certains tests, mais l'architecture, la sécurité, les cas limites et les règles des stores nécessitent une vérification humaine. Ces risques sont détaillés dans l'article sur l'IA appliquée au développement d'applications.
Un plan progressif peut donc consacrer deux semaines au prototype IA, un à deux mois au pilote low-code et ne lancer une phase sur mesure plus longue qu'après validation de la demande. Si le pilote devient indispensable aux opérations, il faut prévoir son renforcement ou sa migration avec la check-list de reconstruction d'un MVP no-code avant d'accumuler trop de données et de dépendances.
Répartition du calendrier
Les lignes suivantes ne s'additionnent pas simplement. L'architecture démarre pendant la finalisation des maquettes. Le mobile et le serveur avancent ensemble. La recette commence avant que toutes les fonctions soient terminées.
| Chantier | Fourchette fréquente | Ce qui permet de le clôturer |
|---|---|---|
| Cadrage du produit | 1-3 semaines | Public, objectif, règles et limite de la V1 sont décidés |
| UX et interface | 2-5 semaines | Parcours, états, contenus et direction visuelle sont validés |
| Architecture et mise en place | 1-3 semaines | Intégrations, environnements, comptes et sécurité sont clarifiés |
| Mobile, serveur et administration | 8-18 semaines | Priorités stables, accès disponibles et validation régulière |
| Recette et stabilisation | 2-6 semaines | Périmètre stable et anomalies bloquantes corrigées |
| Stores et mise en ligne | 1-2 semaines de marge | Comptes, fiches, réponses de confidentialité et accès de test sont prêts |
Apple indique actuellement que 90 % des soumissions sont examinées en moins de 24 heures en moyenne. Google recommande de prévoir de quelques heures à sept jours, voire plus dans certains cas. Ce délai ne couvre pas une nouvelle soumission après un refus ou des informations manquantes.
Exemple d'un MVP de réservation sur 16 semaines
Prenons une application avec compte client, choix d'une prestation, disponibilités, acompte, rappels et petit outil d'administration.
| Semaines | Travail principal | Résultat visible |
|---|---|---|
| 1-2 | Règles, périmètre et risques techniques | Parcours principal, exclusions et intégrations définis |
| 2-4 | UX/UI et architecture en parallèle | Parcours testé, identité validée et plan des environnements |
| 4-7 | Comptes, prestations et disponibilités | Réservation complète dans l'environnement de test |
| 7-11 | Acompte, rappels et opérations internes | L'équipe traite une réservation et les incidents courants |
| 10-13 | Tests, analytique et cas limites | Version candidate stable avec événements clés mesurés |
| 14-15 | Recette et préparation des stores | Version validée et soumissions complètes |
| 16 | Marge de revue et lancement progressif | Mise en production surveillée avec support désigné |
Si les conditions d'annulation ou de remboursement restent ouvertes jusqu'à la dixième semaine, le retard touche plusieurs chantiers : logique serveur, états, écrans, messages et cas de test.
Le temps de production n'est pas le temps écoulé
Une intégration de paiement peut demander une journée de code et deux semaines d'attente pour la vérification du compte marchand. Une maquette peut être prête le matin et rester une semaine entre plusieurs décideurs.
Le planning doit donc montrer le travail de l'équipe, les décisions du client, les délais des fournisseurs, les fenêtres de recette et une réserve pour les inconnues.
Chaque dépendance a besoin d'un responsable et d'une date. « Le client fournira l'accès à l'API » n'est pas assez précis. Il faut savoir qui obtient le compte de test, avant quelle date et quelle tâche sera décalée si l'accès manque.
Ce qui peut réellement avancer en parallèle
Les développeurs mobile et serveur peuvent travailler ensemble si les formats de données sont définis. L'équipe de test prépare les scénarios et vérifie chaque parcours terminé. Le client crée ses comptes de stores, de paiement ou de cartographie pendant le développement.
En revanche, certains choix structurants ne supportent pas une décision tardive : profils utilisateurs, source de référence des données, modèle de paiement, titulaire des comptes et navigation principale.
Le Guide Scrum officiel définit le sprint comme une période fixe d'un mois ou moins. Un sprint sert à produire et examiner un incrément utile; il ne garantit pas qu'une application complète sera prête en deux itérations.
Vous avez une idée d'app et voulez clarifier la suite ?
Revoir mon idéeLes éléments qui font le plus varier le délai
Chaque profil ajoute des autorisations, des états et des parcours. Une marketplace distingue acheteur, vendeur et administration. Une activité de livraison peut demander une application pour le livreur et un outil pour la répartition.
Les intégrations sont incertaines lorsque la documentation, l'environnement de test ou le support du fournisseur sont faibles. Paiement, cartes, CRM, ERP, vérification d'identité et objets connectés méritent un essai technique précoce.
La reprise de données exige correspondances, nettoyage, traitement des doublons, répétition et possibilité de retour arrière. Un fichier tableur existant n'est pas toujours importable.
Enfin, accessibilité, tablettes, langues, fonctionnement hors connexion, anciens appareils Android ou données de santé élargissent la conception et les tests. Ces exigences doivent apparaître au calendrier.
Ce que le client peut préparer
Une personne capable de décider doit centraliser les avis internes. Un délai de réponse convenu évite que chaque démonstration bloque la suite.
Le client prépare les règles métier, tarifs, conditions, contenus réels, comptes d'entreprise et accès fournisseurs. Il nomme aussi les responsables de la confidentialité, de la sécurité ou des validations sectorielles.
Un document d'exigences produit pour application permet de fixer le résultat, le public et les priorités avant de figer les dates.
Aller plus vite sans sacrifier la sortie
Le moyen le plus sûr consiste à réduire la première version. Un parcours central, moins de profils et quelques opérations manuelles pendant le pilote font réellement gagner du temps. Supprimer la recette, la récupération de compte ou la surveillance ne fait que reporter le risque.
Une technologie multiplateforme peut réduire une partie du travail dupliqué entre iOS et Android. Elle ne supprime ni le serveur, ni l'UX, ni les intégrations, ni les tests sur appareils, ni les stores.
Un pilote via TestFlight ou les canaux de test Google Play donne des retours réels avant l'ouverture générale. Il doit être accompagné d'analytique, d'assistance et d'une règle de retour arrière.
Comment lire le délai d'un devis
Le devis devrait montrer le parcours exact qui sera mis en ligne, les chantiers parallèles, les dépendances du client, le rythme des démonstrations et l'étendue de la recette.
Méfiez-vous d'un calendrier limité à « design, développement, lancement », d'une date où toutes les fonctions se terminent ensemble ou d'une absence totale de marge pour les stores. Un diagramme détaillé reste théorique si personne n'est responsable de ses dépendances.
La planification chez Appfyl
Chez Appfyl, le premier délai est une fourchette accompagnée d'hypothèses : profils, parcours principal, opérations d'administration, intégrations, état du design et pays de lancement. Nous le transformons ensuite en résultats vérifiables.
Un parcours de réservation fonctionnel est plus instructif qu'un indicateur affirmant que le développement est terminé à 70 %. Les décisions ouvertes et les fournisseurs restent visibles dans le même plan.
Le brief interactif Appfyl aide à organiser les fonctions avant de discuter du délai. La recette mobile avant lancement et la check-list de mise en ligne évitent de repousser toute la qualité à la dernière semaine.
Voir comment Appfyl transforme un périmètre en produit lancé. Voir les cas Appfyl.
Transformer la recherche en plan
Appfyl transforme votre idée en plan d'app clair, liste de fonctions et premier plan de travail.
Discuter du plan de l'appPoints clés
- Un MVP ciblé demande généralement 12 à 20 semaines.
- Le calendrier comprend décisions, fournisseurs, recette et revue des stores.
- Le travail parallèle n'aide que si les dépendances sont claires.
- Réduire la V1 est plus sûr que réduire la qualité.
- Une date crédible est accompagnée d'hypothèses, de responsables et de jalons.
Liens utiles
Questions fréquentes
Un MVP sur mesure bien délimité demande souvent 12 à 20 semaines. Un produit intermédiaire prend généralement 20 à 32 semaines et une plateforme complexe 32 à 52 semaines ou davantage.
Oui. Un MVP ou un pilote low-code peut tenir en un à deux mois avec un profil principal, des composants standard, peu d'intégrations et des décisions rapides. Huit semaines sont beaucoup moins crédibles pour un produit sur mesure complet avec plusieurs profils, des paiements complexes et une exploitation étendue.
En deux semaines, l'IA peut aider à produire un prototype utile ou un pilote fonctionnel très limité. Ce délai comprend la vérification et la correction du résultat généré, la connexion de quelques données réelles et le test du parcours principal. Il ne constitue pas une date universelle de mise en production pour une application avec paiements, données sensibles ou intégrations complexes.
Les changements tardifs, validations lentes, accès fournisseurs manquants, règles métier ouvertes, migration de données et anomalies critiques découvertes en fin de projet.
Non. Une base mobile commune réduit une partie du travail dupliqué, mais ne divise pas le cadrage, le backend, le design, les intégrations, les tests et la préparation des stores.
Une à deux semaines de calendrier reste prudente, même si beaucoup d'examens sont plus rapides. Cette marge permet de préparer la soumission et d'effectuer une correction.