Combien de temps pour développer une application ou une plateforme web ?

30 septembre 2026

Les projets perdent rarement des mois à cause du code. Ils perdent des mois à cause des décisions que personne n'a prises. Voici le calendrier honnête, phase par phase.

Agenda et calendrier ouverts sur un bureau

La deuxième question de tout acheteur, juste après le prix, c'est la date. Et comme pour le prix, la réponse honnête est une structure, pas un chiffre : les délais logiciels se jouent sur des phases et des décisions, pas sur la vitesse de frappe. Voici le calendrier que nous défendons en 2026, et les quatre choses qui l'allongent vraiment - dont aucune n'est de l'ingénierie.

Le calendrier honnête, phase par phase

Le cadrage : une à trois semaines. Spécification, modèle de données, prototype cliquable. Le sauter ne fait pas gagner ce temps - cela déplace la découverte dans la partie chère du projet.
Première version qui fonctionne : en semaine trois de la construction. Pas un diaporama - du logiciel cliquable, sur une vraie URL. C'est une règle fixe chez nous, parce qu'un projet qu'on peut toucher ne dérive pas en silence.
MVP utilisable : huit à quatorze semaines depuis le lancement pour un produit typique avec comptes et backend, en décidant ce qu'on coupe du MVP au départ plutôt qu'en panique à la fin.
Durcissement pour la production : deux à six semaines de plus - passes de sécurité, supervision, sauvegardes, charge, soumission aux stores. Invisible en démo, obligatoire avant de vrais utilisateurs.

Ce qui allonge vraiment un projet

La latence de décision côté client - la cause numéro un, devant toute cause technique. Chaque question sans réponse vieillit en blocage ; une équipe qui attend quatre jours par réponse livre avec des mois de retard sans que personne comprenne pourquoi.
Le périmètre ajouté en cours de route. Chaque « petit ajout » coûte son temps de construction plus un re-test de tout ce qu'il touche. Le planning est mort le jour où personne n'a dit non.
Les systèmes tiers. Accès aux environnements de test, clés d'API, la revue de conformité d'une banque - des calendriers externes que vous ne contrôlez pas, à lancer en semaine un, pas en semaine dix.
La revue des stores. Apple répond désormais sous 48 heures en général, mais un rejet coûte une semaine le temps de corriger et de resoumettre. Planifiez la date de lancement avec.

Lire le planning d'une agence

Un vrai plan nomme ce qui est livré chaque semaine, dit quelles décisions sont attendues pour quand, et place les risques d'intégration au début, pas à la fin. Un plan fait d'une seule barre qui se termine sur la date limite n'est pas un plan - c'est un espoir avec une date dessus. L'économie suit le calendrier : la structure qui fixe le délai fixe aussi le coût de l'application, et c'est pourquoi nous cadrons les deux dans le même cadrage pour chaque projet d'application web.

3 semaines avant une première version qui tourne - notre règle fixe
8-14 semaines du lancement au MVP utilisable pour un produit typique
×2 ce que les décisions non prises font discrètement à un planning

Les projets perdent rarement des mois à cause du code. Ils perdent des mois à cause des décisions que personne n'a prises.

Questions fréquentes

Plus de développeurs, c'est plus rapide ?

Seulement jusqu'à un petit nombre, et seulement sur du travail qui se découpe proprement. Au-delà, la coordination mange le gain - la plus vieille loi du génie logiciel. Passé un certain point, ajouter des gens à un projet en retard le retarde. Ce qui comprime un délai de façon fiable, c'est un périmètre plus petit et des décisions plus rapides, pas une équipe plus grosse.

Pourquoi les estimations doublent-elles si souvent ?

Parce que l'estimation couvrait la liste visible des fonctionnalités, et que la majorité invisible - états d'erreur, permissions, migrations, surprises d'intégration - a été découverte pendant la construction. C'est exactement à cela que sert un cadrage payant : déplacer la découverte dans les semaines bon marché, où elle modifie un document au lieu de réécrire du logiciel.

Une date de lancement ferme, c'est réaliste ?

Oui, à une condition : la date est fixe et le périmètre ne l'est pas. Les équipes tiennent les dates immuables - un salon, une saison, une réglementation - en coupant des fonctionnalités, jamais en comprimant les tests. Si la date et la liste complète des fonctionnalités sont déclarées non négociables toutes les deux, ce qui cède en silence, c'est la qualité, et cette facture arrive après le lancement, avec intérêts.