Combien de temps
pour développer une application ?
Les vrais délais, ceux que je tiens. Et surtout ce qui les allonge, parce que la moitié des retards ne vient pas du développeur.
Réponse courte
Une première version utile est en ligne en six à douze semaines pour la plupart des projets. Un site de présentation demande 3 à 4 jours, un outil métier interne 5 à 7 semaines, une application mobile 9 à 14 semaines, une plateforme web et mobile 13 à 22 semaines. Ces durées comptent les jours réellement travaillés, à raison de cinq par semaine. Vous voyez une version testable toutes les deux semaines dès le début : vous n'attendez jamais la fin pour savoir où en est le projet.
Les délais, par type de projet
Cadrage compris, mise en production comprise. Ce sont des jours de travail, pas des semaines d'attente.
| Type de projet | Jours | Délai | Premier lot |
|---|---|---|---|
| Site de présentation | 3 à 4 | 3 à 4 jours | Semaine 1 |
| Site avec espace client | 12 à 16 | 2 à 3 semaines | Semaine 2 |
| Reprise d'une application existante | 11 à 15 | 2 à 3 semaines | Semaine 2 |
| Outil métier interne | 25 à 37 | 5 à 7 semaines | Semaine 3 |
| Application mobile iOS et Android | 47 à 71 | 9 à 14 semaines | Semaine 3 |
| Plateforme web et mobile | 67 à 111 | 13 à 22 semaines | Semaine 3 |
Deux repères viennent de projets réellement livrés : trois jours pour un site de présentation, deux mois minimum pour une application mobile. Les valeurs intermédiaires sont des ordres de grandeur, confirmés au cadrage.
Ce qui allonge un délai
Dans l'ordre, et le premier facteur ne dépend pas de moi.
-
Le temps que vous mettez à répondre
C'est de loin le premier. Un projet où les retours arrivent en trois jours avance deux fois plus vite que le même projet où ils prennent trois semaines. Une version livrée qui attend un mois de validation, ce sont quatre semaines ajoutées au calendrier sans qu'une ligne de code soit en cause.
-
Les données à reprendre
Dix ans de tableurs mal structurés se nettoient avant d'être importés. Ce travail se chiffre en jours, parfois en semaines, et il se découvre rarement à l'avance quand personne n'a ouvert les fichiers.
-
Les décisions qui remontent une chaîne
Un arbitrage tranché dans la journée coûte une journée. Le même arbitrage soumis à un comité mensuel coûte un mois. C'est pour cela que je demande toujours qui décide, avant de commencer.
-
Les validations que personne ne maîtrise
Apple valide une application en 24 heures à quelques jours, et peut refuser. Un prestataire tiers met le temps qu'il met à ouvrir un accès. Ces délais s'anticipent, ils ne se raccourcissent pas.
-
Le périmètre qui grandit en cours de route
Chaque fonctionnalité ajoutée après le cadrage décale la mise en ligne. Ce n'est pas un problème si c'est un choix : on en parle, on chiffre, vous décidez. Ça en devient un quand personne ne le dit.
Ce que l'IA change, et ce qu'elle ne change pas
Plus rapide grâce à l'IA
- L'écriture du code répétitif
- Les écrans d'administration standards
- La documentation technique
- L'exploration d'une solution avant de trancher
Aussi long qu'avant
- Les tests, et la correction de ce qu'ils révèlent
- La mise en production et la sécurisation
- La reprise et le nettoyage de vos données
- Les allers-retours de validation avec vous
- La validation Apple et Google
C'est pour cela qu'une application ne se livre pas en une semaine, même en 2026. L'IA a raccourci la partie qui était déjà la plus rapide. Ce qui reste est précisément ce qui fait qu'une application tient en production.
Questions de calendrier
Peut-on livrer plus vite en payant plus ?
Rarement. Ajouter une personne sur un projet en cours coûte d'abord du temps à celui qui est déjà dessus. Ce qui accélère vraiment, c'est de réduire le périmètre de la première version : moins d'écrans livrés plus tôt, le reste ensuite.
Que se passe-t-il si le délai dérape ?
Vous le voyez à la fin du lot suivant, pas à la fin du projet. Le découpage en lots de deux semaines existe pour ça : un retard se constate au bout de quinze jours et se traite pendant qu'il est encore petit.
À partir de quand puis-je montrer l'application en interne ?
Dès le premier lot testable, entre la première et la troisième semaine selon le projet. C'est une version incomplète mais réelle, installée et utilisable, pas une maquette.
Le cadrage rallonge-t-il le projet ?
Il ajoute un à trois jours au début et en fait gagner bien davantage ensuite. C'est là que les fonctionnalités inutiles disparaissent et que les règles métier non écrites sortent, avant qu'elles ne se découvrent en plein développement.
Travaillez-vous sur plusieurs projets en même temps ?
Les durées annoncées ici tiennent compte de ma charge réelle. Quand un créneau n'est pas disponible, je le dis avant de démarrer plutôt que de l'absorber en allongeant discrètement le calendrier.
Votre calendrier, en trente minutes
Décrivez votre échéance et je vous dis si elle tient, ce qu'il faut retirer pour qu'elle tienne, ou pourquoi elle ne tiendra pas.