Combien de temps pour développer une application mobile ?

Les délais mobiles sont souvent estimés comme des délais web avec une autre interface. Ils ne le sont pas, et la différence ne tient pas au code. Elle tient à ceci : vous ne pouvez pas corriger une application mobile au moment où vous constatez le problème.

Sur le web, une mauvaise mise en production se réverte en dix minutes. Sur mobile, elle reste sur les appareils de vos utilisateurs jusqu'à ce qu'ils décident de mettre à jour — et chaque correction doit d'abord passer une validation de store. Ce seul fait reconfigure tout le calendrier.

Fourchettes réalistes

Cross-platform, prêt pour la production, backend inclus, avec une équipe expérimentée :

Si votre application est en réalité un produit doté d'un client mobile, le backend en représente souvent la plus grande part — voir ce que coûte une application mobile.

Où passe le temps mobile qui n'existe pas sur le web

La validation des stores. Chaque version attend dans une file avant d'atteindre les utilisateurs. Les délais se sont réduits, mais ce n'est ni instantané ni garanti — les premières soumissions sont régulièrement refusées, souvent pour des métadonnées, des déclarations de confidentialité ou l'obligation de suppression de compte plutôt que pour un défaut de l'application. Prévoyez au moins un refus et une resoumission pour votre première version. Les équipes qui tablent sur un premier passage sans accroc sont celles qui ratent leur date.

La diversité des appareils. Une application web vise des navigateurs. Une application mobile vise un éventail de tailles d'écran, de versions d'OS et de variantes constructeurs. On ne teste pas tout, mais on teste plus de combinaisons que sur le web, et cela prend du temps réel.

Les cycles de bêta. TestFlight et les pistes de test Play apportent une vraie valeur et ajoutent du calendrier. Chaque tour, c'est compiler, distribuer, recueillir, corriger — des jours, pas des heures.

Une recette plus poussée, par nécessité. C'est le point structurel. Puisqu'un bug ne peut pas être corrigé à chaud, le coût d'en livrer un est bien plus élevé, donc le volume rationnel de tests avant sortie l'est aussi. Sur un projet web, la recette représente peut-être 10 % du calendrier ; sur mobile, plutôt 20 à 25 %. Ce n'est pas du rembourrage, c'est la réponse correcte à un mode de défaillance coûteux.

Le train des versions

Les produits web sortent en continu. Les produits mobiles sortent en versions, ce qui change la planification :

• Le travail se regroupe en versions au lieu de s'écouler au fil de son achèvement.
• Ce qui rate le départ attend le train suivant.
• Vos utilisateurs sont répartis sur plusieurs versions à la fois — votre backend doit continuer à servir des clients anciens pendant des mois, car tout le monde ne met pas à jour.

Ce dernier point surprend. Livrer un changement d'API incompatible est banal sur le web et devient un véritable incident sur mobile.

Un projet type de 16 semaines

• Cadrage — 1 à 2 semaines. Décider ce qui n'est pas dans la v1.
• Design — 3 à 4 semaines. Les conventions de deux plateformes, plus tous les états : vide, chargement, hors ligne, erreur.
• Backend — 4 à 6 semaines, en parallèle du travail applicatif plutôt qu'avant.
• Développement de l'app — 6 à 8 semaines.
• Recette et tests sur appareils — 3 à 4 semaines.
• Soumission et marge — 1 à 2 semaines.

Les tracks parallèles expliquent pourquoi le total ne s'additionne pas simplement. La marge de soumission finale est la partie la plus souvent supprimée, et la plus souvent regrettée.

Ce qui comprime réellement le calendrier

• Une seule plateforme d'abord. Lancez là où sont vos utilisateurs, ajoutez la seconde ensuite, financée par le chiffre d'affaires. C'est le levier le plus puissant.
• Le cross-platform. Une base de code au lieu de deux, ce qui est généralement le bon choix de toute façon.
• Acheter les briques résolues — authentification, paiements, notifications, analytics.
• Couper des fonctionnalités, pas les tests. Sur mobile, cet arbitrage est pire qu'il n'y paraît.
• Préparer tôt les éléments de store. Captures, descriptions, déclarations de confidentialité, et le parcours de suppression de compte si vous avez des comptes. C'est ingrat, c'est obligatoire, et cela surgit au pire moment quand on le laisse pour la fin.

Ce qui l'allonge systématiquement

La même chose que partout ailleurs : les décisions lentes. Comme nous l'avancions pour les délais SaaS, les projets prennent du retard parce que des questions restent sans réponse, pas parce que les ingénieurs tapent lentement. Le mobile ajoute sa variante : chaque question en suspens risque de faire manquer un train de version, et un jour de retard peut coûter une semaine.

Puis les causes proprement mobiles : surprises de matériel et de permissions, SDK tiers qui se comportent différemment selon la plateforme, et un design qui a ignoré les conventions d'une plateforme jusqu'à la fin.

Planifier en conséquence

Choisissez une date de lancement, remontez le calendrier, et gardez une vraie marge entre « code terminé » et « en ligne sur le store ». Deux semaines n'ont rien d'excessif pour une première version.

Et décidez tôt de ce qui se passe si la v1 glisse : quelles fonctionnalités sautent, plutôt que quelles dates bougent. Le périmètre est la variable sûre ; sur mobile, la qualité ne l'est absolument pas.

Si vous voulez un planning écrit avec des dates de jalons plutôt qu'une fourchette, c'est ainsi que notre agence cadre chaque mission. Découvrez notre approche du développement mobile et SaaS, ou contactez-nous.