Combien de temps faut-il pour développer une application ?

Les fondateurs posent généralement cette question juste après avoir demandé combien coûte une application, et les deux réponses sont liées. Le temps est le premier facteur de prix. Si vous savez à peu près combien de temps prendra votre projet, vous pouvez vérifier la cohérence de n'importe quel devis et caler votre lancement sur quelque chose de concret.

Je détaille ci-dessous les délais types par type d'application, ce qui se passe à chaque phase, ce qui ralentit vraiment les projets, et un planning réaliste semaine par semaine pour un MVP. Les chiffres viennent de la façon dont nous cadrons les projets chez Loha.dev, un studio basé aux États-Unis. Ce sont des fourchettes indicatives, pas des promesses.

Délais de développement types selon le type d'application

Le tableau suppose une petite équipe expérimentée qui construit une seule base de code pour iOS, Android et le web (React Native avec Expo, plus un backend partagé). Développer deux applications natives séparées ajoute en général du temps à ces fourchettes.

Remarquez que les lignes se chevauchent. Une app de réservation « simple » avec trois prestataires de paiement et une intégration à un vieux système d'agenda peut prendre plus longtemps qu'une app sociale au périmètre serré. Comptez les fonctionnalités et les intégrations, pas les catégories.

Le détail, phase par phase

Toute application passe par les cinq mêmes phases, même quand elles se chevauchent. Voici où part le temps. Pour une description plus complète de chaque étape, lisez le processus de développement d'une application expliqué.

Cadrage (1 à 3 semaines)

C'est ici que vous décidez de ce que vous n'allez pas construire. Un bon cadrage se termine par une liste de fonctionnalités priorisée, les principaux parcours utilisateurs et un plan technique qui précise la stack, l'hébergement et les services tiers. Le sauter ne fait pas gagner de temps : les débats sont simplement déplacés dans la phase de développement, où ils coûtent plus cher.

Design (2 à 6 semaines)

Le design peut démarrer dès que les parcours principaux sont validés. S'appuyer sur une bibliothèque de composants éprouvée et sur les conventions de chaque plateforme raccourcit cette phase. Une identité visuelle entièrement sur mesure, avec beaucoup d'animations, se situe en haut de la fourchette.

Développement (6 à 16 semaines et plus)

Le développement est la phase la plus longue, et il avance généralement en parallèle de la fin du design. Le backend, l'authentification, le modèle de données et les intégrations prennent souvent plus de temps que les écrans visibles. Le temps réel, le mode hors ligne et les paiements ajoutent chacun plusieurs semaines bien réelles.

Recette (2 à 4 semaines, en parallèle)

Les tests doivent avoir lieu tout au long du projet, mais prévoyez une période de stabilisation dédiée avant le lancement : vrais appareils, téléphones plus anciens, mauvaise connexion réseau, et un groupe de bêta-testeurs qui utilise l'app pour de vraies tâches.

Validation sur les stores et lancement (1 à 3 semaines)

L'examen lui-même est souvent rapide, mais préparer les fiches, les déclarations de confidentialité, les captures d'écran et les exigences de test prend plus de temps que prévu. J'y reviens plus bas.

Ce qui ralentit un projet d'application

D'après mon expérience, une application prend rarement du retard parce que le code est difficile. Elle prend du retard pour ces raisons :

• La dérive du périmètre. « On pourrait aussi ajouter… » est la phrase la plus chère du logiciel. Chaque ajout paraît minime ; ensemble, ils doublent le planning.
• Les décisions lentes. Si un retour sur une maquette ou une version met une semaine à arriver, le projet perd une semaine. Un seul décideur côté client change énormément de choses.
• Des besoins flous. Bien construire la mauvaise chose, puis la reconstruire : c'est le grand classique de la perte de temps.
• Les dépendances externes. Attendre un accès API, les identifiants sandbox d'un partenaire, la vérification d'un prestataire de paiement ou la documentation d'un système existant.
• Les contenus qui arrivent tard. Textes, mentions légales, données produits, fichiers de marque.
• Deux applications natives développées séparément. Deux bases de code, c'est deux implémentations de chaque fonctionnalité et de chaque correctif.
• Une conformité découverte en cours de route. Des exigences RGPD, de paiement, d'accessibilité ou de localisation des données identifiées en plein développement obligent à refaire du travail.
• La création des comptes développeur. Les comptes Apple et Google, surtout pour une entreprise, peuvent exiger une vérification qui prend plusieurs jours.

Comment sortir votre application plus vite

On ne fait pas apparaître un bon logiciel du jour au lendemain, mais on peut éliminer l'essentiel du gaspillage. Voici les leviers qui pèsent le plus sur le planning.

Réduire le périmètre à un vrai MVP

Choisissez le parcours qui prouve votre idée et lancez celui-là. Tout le reste va sur la liste de la version 2. Un MVP resserré peut sortir en 6 à 12 semaines là où la « vision complète » demanderait 6 mois. Notre offre de développement de MVP repose sur ce principe : décider quoi couper, lancer, puis apprendre de vrais utilisateurs.

Développer en cross-platform avec une seule base de code

Avec React Native et Expo, une seule équipe livre iOS, Android et souvent le web à partir d'un code partagé. Pour la plupart des applications métier, c'est nettement plus rapide que de développer séparément en Swift et en Kotlin, sans différence de qualité visible pour l'utilisateur. C'est notre choix par défaut pour nos projets de développement d'applications mobiles. Les mises à jour OTA (over-the-air) pour les changements JavaScript permettent en plus de corriger un bug sans attendre une nouvelle validation complète sur les stores.

Utiliser des services managés plutôt que construire l'infrastructure

Authentification, paiements, e-mails, stockage de fichiers et synchronisation en temps réel sont des problèmes résolus. Un backend managé (nous utilisons souvent Convex pour les données en temps réel et Cloudflare pour l'hébergement) fait gagner des semaines par rapport à la mise en place et à la maintenance de serveurs maison.

Exiger une démo chaque semaine

Une démo hebdomadaire de l'application qui tourne, sur votre téléphone, révèle les malentendus tant qu'ils coûtent peu à corriger. Elle force aussi des décisions rapides, car chaque démo se termine par « voici ce dont nous avons besoin de votre part cette semaine ». Si une équipe ne peut pas vous montrer quelque chose qui fonctionne toutes les une à deux semaines, demandez pourquoi.

Décider vite, avec un seul responsable

Désignez une personne capable de valider les maquettes et de refuser les nouvelles fonctionnalités. Un retour sous 24 heures de sa part vaut plus que n'importe quelle amélioration de process côté développement.

Délais de validation sur l'App Store et Google Play

La validation par les stores est la partie du planning que vous ne maîtrisez pas. Voici à quoi vous attendre, sachant que les deux stores font évoluer leurs processus et que les délais varient selon l'application et la période de l'année.

Prévoyez au moins un rejet lors d'une première soumission. C'est fréquent, généralement facile à corriger, et beaucoup moins stressant quand c'est déjà dans le planning. Pour la checklist complète, lisez comment publier une application sur l'App Store et Google Play.

Un planning de MVP réaliste, semaine par semaine

Voici à quoi ressemble typiquement un MVP en 10 semaines pour une application cross-platform avec comptes utilisateurs, un parcours principal, des notifications et un back-office simple. Prenez-le comme un exemple de planning, pas comme une garantie : c'est votre périmètre qui fixe les vrais chiffres.

Avec un nouveau compte Google Play personnel, l'obligation de test fermé peut décaler le lancement Android de deux semaines par rapport à iOS, sauf si les tests démarrent au plus tard en semaine 7. La version web peut généralement être mise en ligne en semaine 9 ou 10, sans aucune validation.

L'impact du délai sur le coût

La plupart des développements sont facturés au temps passé : un planning plus court donne donc presque toujours un projet moins cher. Réduire le périmètre d'un tiers fait plus pour votre budget que négocier le taux horaire. Pour les fourchettes de prix par type d'application, consultez combien coûte le développement d'une application.

L'inverse est vrai aussi : un devis très bas associé à un délai très court pour une application complexe doit vous alerter. Soit des fonctionnalités manquent dans l'estimation, soit elles réapparaîtront plus tard sous forme d'avenants.

Quand une solution plus rapide est plus pertinente

Parfois, l'application la plus rapide est celle que vous ne développez pas de zéro. Si un outil du marché couvre 90 % de vos besoins, commencez par là. Le développement sur mesure justifie son temps quand votre processus est le produit, quand vous devez maîtriser les données et l'expérience utilisateur, ou quand les outils existants vous imposent des contournements bancals. C'est là que le développement d'applications sur mesure rentabilise les semaines supplémentaires.

Si vous ne savez pas de quel côté se situe votre idée, obtenez un plan d'application gratuit. Vous recevrez une liste de fonctionnalités cadrée et une estimation de délai à comparer avec n'importe quel autre devis.