Combien de temps pour développer une application mobile ?

« Combien de temps pour développer une application ? » C’est souvent la deuxième question, juste après le budget. La réponse courte : 4 à 8 semaines pour un MVP sur une plateforme, 3 à 4 mois pour une application complète iOS + Android, 5 à 8 mois pour une plateforme métier ou une marketplace.

La réponse utile est ailleurs. Sur les projets qui dérapent, le code est rarement en cause. Ce sont les stores, les intégrations, les contenus, les décisions et la conformité qui font glisser les dates. Voici nos repères, ce qui allonge un planning, comment le raccourcir sans sacrifier la qualité, et comment lire celui qu’on vous présente dans un devis.

Les délais réalistes par type de projet

Ces durées sont celles que nous constatons sur nos projets, du cadrage à la mise en ligne.

Si votre application embarque une fonction d’intelligence artificielle, ajoutez sa propre trajectoire : 1 à 2 semaines d’atelier de cadrage, 3 à 5 semaines de preuve de concept, puis 3 à 4 mois pour un assistant industrialisé. Ces phases peuvent avancer en parallèle de l’application, à condition de les prévoir dès le départ.

Charge et délai ne sont pas la même chose

Un devis parle souvent en jours-homme. Un MVP représente typiquement 30 à 60 jours-homme, une application complète 120 à 200, une plateforme 250 à 450. Ce chiffre mesure le travail, pas le calendrier.

Une application complète de 150 jours-homme ne prend pas 150 jours : plusieurs personnes travaillent en parallèle (design, mobile, back-end, tests) et le projet tient en 3 à 4 mois. L’inverse est vrai aussi. Doubler l’équipe ne divise pas le délai par deux. Chaque personne ajoutée doit être intégrée, coordonnée, relue. Au-delà d’une certaine taille, on perd du temps en synchronisation au lieu d’en gagner.

Retenez donc deux chiffres distincts : la charge détermine le budget, l’organisation de l’équipe détermine la date.

Ce qui allonge vraiment un planning

La publication sur les stores

C’est l’étape la plus souvent oubliée dans les plannings optimistes. Une application terminée n’est pas une application publiée.

Côté Apple, l’examen est rapide en temps normal : Apple indique traiter au moins 50 % des soumissions en moins de 24 heures et 90 % en moins de 48 heures. Le risque n’est pas l’attente, c’est le refus. Chaque rejet impose une correction, une nouvelle soumission et un nouvel examen. Nous avons détaillé les motifs de refus les plus fréquents : la plupart s’anticipent dès la conception.

Côté Google Play, deux points peuvent coûter des semaines :

• Les comptes développeur personnels créés après le 13 novembre 2023 doivent mener un test fermé avec au moins 12 testeurs inscrits sans interruption pendant 14 jours, puis demander l’accès à la production. Google indique que cet examen prend généralement sept jours ou moins, parfois davantage.
• Pour certains comptes, Google prévient que l’examen d’une application peut atteindre sept jours, voire plus dans des cas exceptionnels.

La parade est administrative. Publiez sous un compte d’organisation au nom de votre société, et créez-le dès la signature. Apple exige pour les organisations une entité juridique et un numéro D-U-N-S : si votre entreprise n’en a pas, la demande doit partir le plus tôt possible.

Les intégrations avec des systèmes tiers

Paiement, ERP, CRM, logiciel de caisse, API d’un partenaire : chaque intégration dépend de quelqu’un d’autre. Il faut obtenir les accès, un environnement de test, une documentation à jour et un interlocuteur qui répond.

Le développement de l’intégration elle-même est rarement long. C’est l’attente qui coûte : une clé d’API qui arrive après trois relances, un environnement de test qui ne reflète pas la production, un éditeur qui découvre en cours de projet que son API ne fait pas ce qui était prévu. Demandez les accès avant le début du développement et testez-les dès la première semaine.

Les contenus

Textes des écrans, photos, fiches produits, traductions, conditions générales, politique de confidentialité, visuels et descriptions pour les stores. Tout cela doit exister avant la mise en ligne, et c’est presque toujours au client de le fournir.

Un contenu livré en fin de projet oblige à reprendre des écrans déjà validés : un titre trop long casse une mise en page, une photo au mauvais format déforme une liste. Fixez une date de livraison des contenus dans le planning, comme n’importe quel autre jalon.

Les décisions côté client

Une maquette qui attend dix jours sa validation, ce sont dix jours de retard sur la suite. Le phénomène s’aggrave quand plusieurs personnes doivent donner leur accord et ne sont pas d’accord entre elles.

Deux règles simples changent la dynamique : un seul décideur côté client, qui tranche après avoir consulté, et un délai de validation convenu à l’avance pour chaque livrable. Si le délai n’est pas tenu, le planning glisse d’autant, et tout le monde le sait dès le départ.

La conformité

Données personnelles, données de santé, paiement, accessibilité : chaque exigence réglementaire ajoute des écrans (consentement, suppression de compte, export des données), des choix d’hébergement et parfois des validations externes. Le RGPD appliqué à une application mobile se traite très bien dès la conception. Découvert à la veille de la mise en ligne, il impose de reprendre l’architecture.

La règle est la même pour tous ces sujets : une contrainte connue au cadrage coûte quelques lignes dans le planning, une contrainte découverte en recette coûte des semaines.

Raccourcir le délai sans couper la qualité

Réduire le périmètre, pas les finitions

Le levier le plus puissant reste le périmètre. Une application qui fait moins de choses, mais les fait parfaitement, sort plus tôt et apprend plus vite. Nous avons consacré un article entier à la méthode pour définir le périmètre d’un MVP : le parcours unique, ce qu’on ne coupe jamais, et les coupes qui font gagner le plus de temps.

Ce qu’il ne faut pas faire, c’est garder tout le périmètre et compresser la fin. Les tests, la recette et la gestion des erreurs sont les premières victimes d’un planning trop serré, et ce sont elles qui décident si l’application tient après le lancement.

Choisir le cross-platform quand l’usage le permet

Pour une application iOS + Android, React Native ou Flutter permettent d’économiser 30 à 40 % sur le projet. Une seule base de code, une seule équipe, une seule série de tests fonctionnels : c’est autant de charge en moins à faire tenir dans le calendrier.

Le natif (Swift, Kotlin) reste pertinent pour les usages très matériels : Bluetooth intensif, capteurs, traitement vidéo, fonctions système avancées. Notre comparatif React Native, Flutter ou natif détaille les critères pour trancher.

Décider vite, et par écrit

Un cahier des charges clair évite des semaines d’allers-retours. Il ne s’agit pas d’un document de cent pages, mais d’une liste précise des parcours, des règles de gestion et des cas limites. Notre modèle de cahier des charges tient en quelques pages et suffit à lancer un projet sans ambiguïté.

Pendant le projet, une démonstration régulière de l’avancement permet de corriger tôt. Un écart repéré au bout de deux semaines se corrige en une journée. Le même écart repéré à la livraison finale se corrige en plusieurs semaines.

Paralléliser ce qui ne dépend pas du code

Pendant que l’équipe développe, vous pouvez rédiger les contenus, préparer les fiches des stores, recruter vos testeurs, obtenir les accès des partenaires et préparer le lancement commercial. Les projets qui sortent à l’heure sont ceux où le client avance sur sa propre liste en même temps que l’équipe technique.

Comment lire le planning d’un devis

Un planning dit beaucoup de choses sur la façon dont le prestataire travaille. Voici ce qu’on doit y trouver.

Deux questions à poser systématiquement. D’abord : que se passe-t-il si une validation arrive en retard ? Une réponse claire (le planning glisse d’autant, sans surcoût ou avec) vaut mieux qu’une promesse floue. Ensuite : comment le délai est-il engagé dans le contrat ? Un forfait, une régie et un budget plafonné ne répartissent pas le risque de retard de la même façon. Nous comparons ces formules dans notre article sur les modèles de facturation.

Méfiez-vous enfin du délai le plus court du comparatif. S’il est nettement inférieur aux autres pour le même périmètre, soit le périmètre n’a pas été compris de la même façon, soit la recette a disparu. Dans les deux cas, la date affichée n’est pas celle à laquelle votre application sera réellement en ligne.

Un planning réaliste n’est pas le plus court : c’est celui qui dit à l’avance ce qui peut le faire glisser, et qui doit agir pour l’éviter.

Ce qu’il faut retenir

Pour un premier projet mobile, raisonnez en trois temps. Choisissez le bon type de projet et son ordre de grandeur de délai. Lancez dès la première semaine tout ce qui ne dépend pas du code. Puis vérifiez que le planning proposé rend visibles les jalons, la recette, les stores et vos propres engagements.

Si vous voulez un délai chiffré pour votre projet, nous établissons un devis gratuit sous 24 heures, avec un planning détaillé par phase.

Pour aller plus loin : notre page création d’application mobile détaille notre façon de mener un projet, du cadrage à la publication sur les stores.

Sources

• Apple Developer, « App Review » : délais d’examen et demandes d’examen accéléré.
• Apple Developer, « Enrollment » : conditions d’inscription des organisations et numéro D-U-N-S.
• Aide Play Console, « Exigences de test pour les nouveaux comptes de développeur personnels » : test fermé de 14 jours avec 12 testeurs.
• Aide Play Console, délais d’examen des applications : examen pouvant atteindre sept jours ou plus.