DélaisMéthodeApplication métierPrototype
Combien de temps faut-il pour développer une application ?
7 min de lecture
Pour une application métier, comptez quelques semaines pour une première version utilisable et quelques mois pour un périmètre large. Le délai dépend moins du nombre d'écrans que des intégrations, de la reprise de données et de la vitesse à laquelle les décisions sont prises côté client. Un prototype visible avant le développement est ce qui raccourcit le plus un projet, parce qu'il tranche les questions avant qu'elles ne coûtent du temps.
Une durée annoncée sans phases ni hypothèses ne vaut pas grand-chose. Voici comment se découpe réellement un projet, ce qui l'allonge, ce qui le raccourcit, et ce que l'IA change, ou ne change pas.
Un repère de marché, à lire avec précaution
Peu de sources publient des durées de projet. Clutch, plateforme d'avis B2B, agrège les budgets et durées déclarés dans les avis vérifiés de clients. Sa page de tarifs du développement logiciel, mise à jour en septembre 2026, indique une durée moyenne d'environ 13 mois par projet.
Ce chiffre est mondial, mélange tous les budgets, et une moyenne est tirée vers le haut par les gros projets. Il décrit des programmes entiers, pas une première version. Il dit surtout une chose : un projet logiciel se compte rarement en jours, et la vraie question n'est pas « combien de temps au total », mais « quand aurai-je quelque chose d'utilisable ».
Les cinq phases d'un projet
| Phase | Ce qui s'y passe | Ce qui fait varier la durée |
|---|---|---|
| Cadrage | Comprendre le problème, les utilisateurs, les outils en place | La disponibilité des personnes qui connaissent le métier |
| Prototype | Écrans, parcours et données réalistes, présentés avant tout développement | Le nombre de parcours à montrer, la rapidité des retours |
| Développement par paliers | Construction, intégrations, reprise de données | Les règles métier, les connexions aux autres outils, la qualité des données |
| Recette | Les utilisateurs testent sur des cas réels | La disponibilité des testeurs, la rigueur des retours |
| Mise en production | Déploiement, formation, bascule | Le besoin de faire tourner l'ancien et le nouveau outil en parallèle |
Chez LPR Studio, le prototype visuel est présenté en visio sous 5 jours ouvrés après l'échange de cadrage. C'est volontairement court : son rôle est de rendre le périmètre visible tant que rien n'est encore construit. Le détail de la démarche est sur la page de notre approche.
Ce qui allonge un projet
Les décisions en attente. C'est la première cause de retard, et elle ne se voit dans aucun devis. Un écran à valider, une règle de calcul que deux services interprètent différemment, un accès technique demandé à un éditeur tiers : chaque question ouverte immobilise une partie du travail.
Les intégrations. Se connecter à un ERP, à un outil comptable ou à une base ancienne suppose de comprendre un format, d'obtenir des accès, de gérer les erreurs et les doublons. Quand l'autre système n'a pas d'interface documentée, la durée peut doubler sur ce poste. Notre article sur l'intégration à un ERP existant détaille ce cas.
La reprise de données. Des années de tableurs, de doublons et de versions contradictoires ne se migrent pas d'un clic. Il faut nettoyer, rapprocher, faire valider par quelqu'un du métier. Ce travail est invisible dans l'application finie et pèse pourtant lourd dans le planning.
Le périmètre qui bouge. Ajouter « juste un écran » en cours de route n'est jamais juste un écran : il faut le concevoir, le relier au reste, le tester. Un périmètre qui change sans arbitrage explicite décale toutes les dates suivantes.
Ce qui raccourcit un projet
Un prototype validé avant de coder. Il transforme des discussions abstraites en décisions concrètes : on voit l'écran, on dit oui ou non. Les désaccords qui auraient surgi en recette sont réglés en amont, quand ils ne coûtent presque rien. C'est le sujet de notre article voir son logiciel avant de le payer.
Un décideur disponible. Une personne côté client, qui connaît le métier et peut trancher dans la semaine, fait souvent gagner plus de temps qu'un développeur supplémentaire.
Une première version resserrée. Livrer d'abord le processus qui fait gagner le plus de temps, puis ajouter par paliers. C'est la logique du MVP : chaque palier est utilisable, et les retours du terrain orientent le suivant.
Des données préparées tôt. Lancer le nettoyage des fichiers existants pendant que l'application se construit, plutôt qu'à la fin.
Et l'IA, dans tout ça ?
Les outils d'IA accélèrent réellement certaines tâches : écrire du code répétitif, proposer des tests, documenter. Une équipe qui s'en sert bien livre plus vite. Mais l'IA ne décide pas d'une règle de remise, n'obtient pas un accès à votre ERP et ne valide pas un écran à votre place. Or c'est là que se perd l'essentiel du temps.
Elle introduit aussi un risque : du code produit vite et non relu. Le gain de vitesse ne tient que si chaque ligne est vérifiée par un développeur qui la comprend. Nous expliquons notre façon de faire dans développement assisté par IA : pourquoi la vérification humaine fait la différence.
Ordres de grandeur, selon le type de projet
Sans chiffre inventé, voici comment se situent les projets les uns par rapport aux autres :
| Type de projet | Première version utilisable | Remarque |
|---|---|---|
| Outil interne pour un service, peu d'intégrations | Quelques semaines | Le cas le plus rapide si les décisions suivent |
| Application qui remplace un tableur partagé | Quelques semaines | La reprise des données fixe souvent le rythme |
| Portail client avec facturation et outil comptable | Quelques semaines à quelques mois | Les intégrations pèsent lourd |
| Logiciel multi-sites, droits différenciés, plusieurs systèmes connectés | Quelques mois | Livrer par paliers est indispensable |
Dans tous les cas, l'important est la date de la première version utile, pas celle de la dernière fonctionnalité. Une application qui sert dès le deuxième mois et s'enrichit ensuite rapporte plus qu'une application parfaite livrée en un bloc au bout d'un an.
Comment obtenir un planning fiable
- Décrire le problème et les échéances réelles. Une date liée à une saison, un salon ou une obligation réglementaire se dit dès le premier échange : elle change la façon de découper le projet.
- Voir le périmètre avant de le chiffrer. Un planning n'est fiable que si le périmètre est fermé. Le prototype sert à ça.
- Fixer la date, laisser varier le périmètre. Ce qui doit marcher le jour J passe en premier ; le reste attend le palier suivant.
- Exiger des paliers utilisables. Un planning qui ne montre rien avant la fin ne permet ni de corriger ni d'arrêter à temps.
Pour situer ce délai par rapport au budget, notre article sur le prix d'une application mobile montre que les mêmes facteurs font varier les deux.
Par où commencer
Décrivez votre besoin et votre échéance en quelques lignes : nous revenons vers vous sous 24 h ouvrées, puis nous vous présentons en visio, sous 5 jours ouvrés, un prototype visuel gratuit. C'est à partir de lui que le planning est annoncé, avec le forfait, et que vous savez quand vous aurez une première version entre les mains.