Mis à jour le 16/08/2026 · 9 min de lecture
Combien de temps pour développer une application mobile ?
C’est la deuxième question de chaque rendez-vous, juste après celle du budget. Voici les durées réelles par type de projet, ce qui les fait glisser, et les points de contrôle qui permettent de s’en rendre compte à temps plutôt qu’à trois semaines de l’échéance.
La réponse courte
Comptez 3 à 6 semaines pour une première version restreinte publiée sur un store, et 2 à 5 mois pour une application mobile aboutie sur iOS et Android. En dessous de trois semaines, on ne parle plus de développement sur mesure mais de prototype.
Les délais par type de projet
Ces durées vont du premier atelier de cadrage à l’application mobile disponible au téléchargement sur l’App Store et le Play Store, revue des stores comprise.
| Type de projet | Ce que ça comprend | Délai |
|---|---|---|
| Prototype cliquable | Maquettes navigables, aucun code | 1 à 2 semaines |
| MVP publié sur les stores | Un parcours principal, une plateforme | 3 à 6 semaines |
| Application métier | Comptes, back-office, une plateforme | 6 semaines à 3 mois |
| Application grand public | iOS et Android, paiement, notifications | 2 à 5 mois |
| Plateforme complexe | Temps réel, hors ligne, back-office avancé | 5 mois et plus |
Le rythme se joue à deux
Un projet d’application mobile avance à la vitesse du plus lent des deux côtés. Nous tenons nos livraisons toutes les deux semaines, mais une maquette validée trois semaines après son envoi décale mécaniquement tout le rétroplanning qui suit.
C’est pourquoi nous demandons dès le cadrage qui serala personne décisionnaire et sous quel délai elle peut se prononcer. Quand le circuit de validation est long, nous l’intégrons au planning au lieu de le découvrir en route : le rétroplanning annoncé est alors celui que nous tiendrons.
Où passe le temps
La répartition est stable d’un projet d’application mobile à l’autre. Elle vous sert surtout à situer où vous en êtes : à la fin du design, un cinquième du calendrier est consommé sans que vous ayez vu une seule ligne de code, et c’est normal. Chaque phase se termine par un jalon que vous validez, ce qui vous donne six points de contrôle plutôt qu’une livraison finale.
Cadrage et spécifications
10 %Ateliers, arborescence, arbitrage du périmètre. Se déroule avant toute ligne de code.
Design et maquettes
11 %Parcours et écrans, validés par vous avant le développement.
Développement mobile
45 %Écrans, navigation, logique métier, cas particuliers. Vous recevez une version installable toutes les deux semaines.
Back-end et API
14 %Base de données, comptes, back-office. Mené en parallèle du développement mobile.
Tests et recette
14 %Tests sur iPhone et Android réels, bêta-test via TestFlight, corrections, validation de votre côté.
Publication
6 %Fiches App Store Connect et Google Play Console, captures, conformité, revue Apple et Google.
Ce qui allonge un projet, par ordre d’impact
- Le périmètre qui bouge. De loin la première cause. Chaque ajout accepté en cours de route décale la livraison, et l’accumulation de petits ajouts fait plus de dégâts qu’une grosse fonctionnalité assumée dès le départ.
- Les connexions à vos outils existants. Se brancher sur un logiciel métier sans documentation, ou attendre les accès d’un éditeur tiers, peut ajouter des semaines sur lesquelles votre prestataire n’a aucune prise.
- Les contenus. Textes, photos, conditions générales, traductions. Ce sont souvent les derniers éléments fournis, et ils bloquent la publication alors que l’application est prête.
- Le mode hors ligne et le temps réel. Deux sujets techniquement difficiles, qui ajoutent facilement 20 à 30 % au calendrier. À réserver aux cas où l’usage l’impose vraiment.
Aller plus vite, sans dégrader le résultat
Il existe deux bons leviers, et beaucoup de mauvais. Le premier est de réduire le périmètre de la première version : c’est exactement la logique d’un MVP, où l’on ne développe que le parcours qui prouve la valeur du produit. Le second est de passer en multiplateforme, en couvrant iOS et Android avec une base de code unique en Flutter ou React Native, plutôt que de développer deux applications natives distinctes, l’une en Swift pour iOS et l’autre en Kotlin pour Android.
À l’inverse, ajouter des développeurs sur un projet déjà lancé le ralentit presque toujours, le temps qu’ils comprennent le code et se coordonnent. Et supprimer la phase de recette pour livrer plus tôt revient à déplacer les corrections après la mise en ligne, quand elles sont vues par vos utilisateurs.
Les délais qui ne dépendent de personne
Une fois l’application mobile terminée, il reste la revue des stores. Apple valide généralement en 24 à 48 heures, Google en quelques jours pour une première publication. Ces délais sont courts, mais ils s’ajoutent, et un refus pour un motif administratif fait repartir le compteur. Prévoyez une semaine de marge entre la fin des tests et la date que vous annoncez en interne.
Deux cas particuliers valent d’être connus. Un compte développeur d’entreprise nouvellement créé demande une vérification d’identité qui peut prendre plusieurs jours, à lancer dès le début du projet plutôt qu’à la fin. Et les périodes de forte affluence sur les stores, en particulier la première quinzaine de décembre, allongent sensiblement les revues.
Et pour votre projet ?
Le délai d’une application mobile ne se devine pas à partir d’une idée, il se déduit d’un périmètre : nombre d’écrans, parcours utilisateur, intégrations au système d’information. Poser ce périmètre par écrit prend une heure et donne une estimation nettement plus fiable : c’est l’objet de notre trame de cahier des charges, en six questions. Une fois le périmètre posé, le budget se calcule d’ailleurs avec la même mécanique, puisque les deux dépendent du nombre de jours.
Si vous avez une échéance à tenir, dites-la nous dès le premier échange. C’est la contrainte qui structure le mieux un projet, et il vaut mieux savoir tout de suite qu’elle est intenable que le découvrir à trois semaines de la date.