La réponse courte
Un MVP mobile bien périmétré prend 3 à 5 mois du début du développement au lancement dans les deux stores. Une application grand public complète avec fonctionnalités complexes prend 5 à 9 mois. Les projets natifs iOS + Android en équipes séparées durent 30 à 40 % plus longtemps que le multiplateforme pour le même objectif.
| Type d’application | Multiplateforme | Natif (iOS + Android) |
|---|---|---|
| MVP simple (3–5 écrans) | 3–4 mois | 4–6 mois |
| MVP complet (6–12 écrans, API, auth) | 4–6 mois | 6–9 mois |
| Application grand public (paiements, médias sociaux, hors ligne) | 5–9 mois | 8–14 mois |
| Application d’entreprise (workflows, rôles, intégrations ERP) | 6–12 mois | 10–18 mois |
Phase 1 : Découverte et planification (2–4 semaines)
La découverte est la phase de planification structurée avant que le code ne soit écrit. Elle comprend typiquement :
- Cartographie des user stories et des parcours utilisateurs
- Analyse de l’architecture technique et des risques d’intégration
- Wireframes et validation des maquettes UX
- Priorisation du MVP et définition du backlog initial
- Chiffrage et planification de la capacité
Une découverte pour un MVP typique prend 2 à 4 semaines avec une équipe composée d’un product manager, d’un architecte et d’un designer UX. Les équipes qui ignorent la découverte font généralement face à leur première refonte majeure lors du sprint 3 ou 4 — à ce stade, le coût de correction est 5 à 10 fois plus élevé. La phase de découverte n’est pas du temps perdu ; c’est de l’assurance.
Phase 2 : Conception UX/UI (3–6 semaines)
La conception mobile est plus rigoureuse que la conception web parce que les modèles d’interaction sont différents : les gestes, les surfaces réduites, l’ergonomie du pouce, l’utilisation hors ligne et les composants spécifiques à chaque plateforme (Human Interface Guidelines sur iOS, Material 3 sur Android) créent tous des contraintes sans équivalent sur le web. Un bon design mobile prend du temps.
Le calendrier de conception comprend :
- Wireframes basse fidélité pour la structure et les flux — 1–2 semaines
- Maquettes haute fidélité avec système de design, couleurs et typographie — 2–3 semaines
- Prototypes interactifs pour les flux critiques (onboarding, paiement, authentification) — 1 semaine
- Révisions et approbations avec les parties prenantes — variable (c’est ici que les délais explosent)
Le goulot d’étranglement le plus fréquent en phase de conception : les cycles d’approbation avec plusieurs parties prenantes qui font passer une révision d’un jour à deux semaines. Si vous avez plus de trois approbateurs, définissez à l’avance un processus de prise de décision.
Phase 3 : Développement (8–20 semaines)
Le développement est la phase la plus longue, et c’est celle que les estimations manquent le plus souvent parce que les gens estiment les fonctionnalités isolément sans modéliser les dépendances, les intégrations et la dette technique.
Semaines 1–3 : Infrastructure et fondations
Mise en place du repo, CI/CD, configuration de l’environnement, architecture backend, schémas de base de données, intégration des services d’authentification. C’est ici que les choix d’architecture structurent la rapidité ou la lenteur de tout ce qui suit. Oui, les premières semaines ressemblent à peu de fonctionnalités livrées — c’est normal.
Semaines 4–12 : Développement de fonctionnalités par sprint
Sprints de deux semaines livrant des fonctionnalités vérifiables. Pour un MVP standard, les premières semaines couvrent typiquement l’onboarding et l’authentification, puis le flux de fonctionnalités principal, puis les notifications push, puis l’état hors ligne (si applicable) et enfin les intégrations tierces.
Règle empirique : les intégrations tierces prennent toujours deux fois plus de temps que prévu. Les passerelles de paiement (Stripe, Adyen), les SDK KYC, les connecteurs de santé (HealthKit, Google Fit), les API d’analyse — chacun a sa propre documentation, ses cas limites, ses environnements sandbox et ses délais de certification. Construire les intégrations en dernier rend les retards visibles trop tard ; construisez-les tôt.
Semaines 12–16 (MVP) / 12–20 (produit complet) : Polissage et durcissement
Optimisation des performances, gestion des états d’erreur, peaufinage des animations, conformité à l’accessibilité, préparation aux revues des stores. Ne sacrifiez pas cette phase sous pression de délai — les revues des stores détectent les crashs évidents et le non-respect des directives, et un refus retarde le lancement de 1 à 2 semaines.
Phase 4 : Tests et assurance qualité (2–4 semaines)
Les tests mobiles sont plus complexes que les tests web parce que vous testez sur deux systèmes d’exploitation, des dizaines de tailles d’appareils et des versions d’OS variées. Un plan de test mobile robuste comprend :
- Tests fonctionnels sur les parcours utilisateurs critiques (enregistrement, fonctionnalité principale, paiements, notifications)
- Tests de régression pour s’assurer que les nouvelles fonctionnalités ne cassent pas les existantes
- Tests de performance : temps de démarrage, fréquence d’images sur les animations clés, comportement réseau dégradé
- Tests d’appareils réels sur les appareils les plus répandus dans votre audience cible — pas seulement le simulateur
- Tests de pénétration et d’accessibilité pour les applications réglementées (fintech, healthtech, RGPD)
Pour les applications avec des exigences réglementaires strictes (RGPD, données de santé, paiements), les tests incluent un audit de conformité structuré. Lisez notre article sur la sécurité des applications mobiles et la conformité RGPD pour comprendre ce que cela implique en pratique.
Phase 5 : Soumission aux stores et lancement (1–3 semaines)
Les développeurs et les fondateurs sous-estiment systématiquement cette phase. La soumission aux stores n’est pas « cliquer sur Envoyer ». Elle comprend :
- Préparation des assets des stores (captures d’écran pour chaque taille d’écran, vidéo de prévisualisation, icônes, textes traduits)
- Configuration de la conformité à la confidentialité (App Privacy Nutrition Labels sur iOS, data safety sur Android)
- Soumission de revue — Apple : 1–3 jours en moyenne ; Google : quelques heures à 3 jours
- Gestion des refus et des demandes de clarification (courants pour les applications avec des fonctionnalités sensibles)
- Plan de déploiement par phases pour les applications grand public
Intégrez toujours 2 semaines de tampon de soumission dans votre calendrier de lancement. Le non-respect de cette règle provoque la majorité des « glissements de dernière minute » que les équipes signalent lors des post-mortems.
Phase 6 : Après le lancement
Le lancement n’est pas la fin — c’est le début d’un cycle de maintenance continu. Les applications mobiles nécessitent des mises à jour régulières pour rester dans les stores (Apple et Google suppriment les applications non mises à jour qui ne respectent plus les exigences de l’OS), se conformer aux nouvelles directives de plateforme et adresser les retours utilisateurs. Notre article sur le coût de maintenance d’une application mobile détaille les budgets et la planification après le lancement.
Ce qui fait glisser les calendriers
Voici les cinq causes les plus fréquentes de dépassement de délai, basées sur les post-mortems de projets réels :
1. Périmètre flou ou expansion du périmètre
Le périmètre flou en début de projet se transforme en « on voulait dire quelque chose d’un peu différent » au milieu du développement, ce qui entraîne des refontes de fonctionnalités complètes. L’expansion du périmètre (« pendant qu’on y est, ajoutons X ») est le problème classique. La règle : toute fonctionnalité ajoutée après le début du développement devrait passer par un processus de priorisation formel, pas une décision orale dans un stand-up.
2. Goulots d’étranglement dans les décisions client
Les équipes de développement attendent souvent des validations : maquettes, résultats de tests, credentials API, accès aux environnements. Si les cycles d’approbation du côté client prennent 2 à 5 jours par itération et que vous avez 30 itérations, vous venez d’ajouter 2 à 3 mois. La solution : définir à l’avance les délais de réponse attendus et maintenir une liste de « bloqueurs en attente » visible des deux côtés.
3. Intégrations tierces non documentées
Chaque intégration tierce est une boîte noire jusqu’à ce que vous y plongiez. Les SDK peuvent avoir une documentation obsolète, des comportements sandbox différents des comportements production, des exigences de certification inattendues (paiements, KYC) ou simplement des bugs que votre cas d’usage déclenche et que personne n’a signalés avant. Modélisez chaque intégration dans votre estimation, pas comme une ligne unique « 2 jours ».
4. Décisions d’architecture tardives
Changer d’architecture à mi-chemin — passer de REST à GraphQL, repenser la gestion d’état, retravailler l’implémentation hors ligne — est coûteux. Ce sont des décisions qui auraient dû être prises en phase de découverte. Lorsqu’elles glissent dans les sprints de développement, elles entraînent du refactoring qui efface souvent deux à trois semaines de travail livré.
5. Préparation des stores insuffisante
Les équipes qui préparent les assets des stores, les textes de confidentialité et la configuration de conformité une semaine avant le lancement prévu se retrouvent systématiquement en retard. La préparation des stores devrait commencer 3 à 4 semaines avant le lancement visé, en parallèle de la phase de polissage finale.
FAQ
Combien de temps faut-il pour développer une application mobile simple ?
Un MVP — authentification, deux à trois fonctionnalités de base, un backend simple et soumission aux deux stores — prend généralement 3 à 4 mois avec une équipe à temps plein. Une application simple est une application dont le périmètre est bien défini, sans intégrations complexes, fonctionnalités hors ligne, flux de paiement ou contraintes réglementaires. Le calendrier suppose que votre phase de découverte soit terminée avant le démarrage du développement — si ce n’est pas le cas, ajoutez 2 à 4 semaines supplémentaires.
Quelle est la durée de développement typique pour les applications iOS et Android ?
Pour le multiplateforme (Flutter, React Native), comptez 3 à 5 mois pour un MVP et 5 à 9 mois pour une application grand public complète. Pour les développements natifs parallèles (iOS + Android en équipes séparées), les mêmes objectifs prennent 5 à 8 mois et 8 à 14 mois, car les deux plateformes doivent toutes deux franchir les étapes de conception, construction et test. Le multiplateforme réduit le calendrier de 30 à 40 % par rapport au natif. Consultez notre comparaison natif vs multiplateforme pour comprendre quel choix convient à votre projet.
Pourquoi les projets d’application mobile durent-ils plus longtemps que prévu ?
Les cinq causes les plus fréquentes : une conception démarrée sans phase de découverte terminée (entraînant des refontes majeures en cours de route) ; un périmètre mal défini qui s’élargit pendant le développement ; des cycles de revue et d’approbation en amont qui font passer les tâches de 3 jours à 3 semaines ; des intégrations tierces non documentées (passerelles de paiement, connecteurs KYC, SDK de santé) qui prennent deux fois plus de temps que prévu ; et une sous-estimation du délai de soumission aux stores — Apple prend 1 à 3 jours en moyenne, Google de quelques heures à 3 jours, avec possible refus qui allonge le calendrier de 1 à 2 semaines.
Que comprend la phase de découverte et en combien de temps se déroule-t-elle ?
La découverte est la phase de planification structurée avant que le code ne soit écrit. Elle comprend typiquement la cartographie des user stories et des parcours utilisateurs, l’analyse de l’architecture technique et des risques d’intégration, les wireframes et la validation des maquettes UX, la priorisation du MVP et la définition du backlog initial, et le chiffrage et la planification de la capacité. Une découverte pour un MVP typique prend 2 à 4 semaines avec une équipe composée d’un product manager, d’un architecte et d’un designer UX. Les équipes qui ignorent la découverte font généralement face à leur première refonte majeure lors du sprint 3 ou 4 — à ce stade, le coût de correction est 5 à 10 fois plus élevé.
Les demandes de révision App Store peuvent-elles retarder un lancement ?
Oui, et les équipes les sous-estiment régulièrement. Apple prend en moyenne 1 à 3 jours pour la revue initiale, avec des refus qui allongent le calendrier de 1 à 2 semaines par cycle de correction. Si votre application utilise des fonctionnalités sensibles — achats intégrés, authentification, collecte de données de santé, accès localisation — la probabilité de refus et de demandes de clarification augmente significativement. Google est généralement plus rapide (quelques heures à 3 jours) mais peut retenir les nouvelles applications pour un examen étendu. Intégrez toujours 2 semaines de tampon de soumission dans votre calendrier de lancement.
Dernière mise à jour le 12 juin 2026.
