« Ça va prendre combien de temps ? »
C'est la deuxième question que chaque client pose, juste après « combien ça va coûter ? ». Et la réponse honnête — « ça dépend » — est correcte mais inutile. Vous essayez de planifier un budget, de fixer des attentes avec vos parties prenantes, ou de coordonner un lancement. Vous avez besoin d'un chiffre, pas d'une philosophie.
Voici ce qu'on a appris en livrant des projets logiciels sur mesure : pas une moyenne générique de l'industrie, mais les vrais délais qu'on observe, ce qui les détermine, et où les projets perdent du temps que personne n'avait prévu.
La réponse courte
La plupart des projets logiciels sur mesure prennent entre 3 et 9 mois du lancement à la mise en production. Cette fourchette couvre la majorité de ce que les entreprises construisent réellement : outils internes, portails clients, CRM sur mesure, plateformes d'automatisation, et MVPs SaaS.
En dessous de 3 mois, on est sur du petit et bien défini — un outil à usage unique, une migration de données, ou un site avec de la logique custom. Au-dessus de 9 mois, on est dans le territoire entreprise — systèmes multi-modules, intégrations complexes avec du legacy, ou plateformes servant des milliers d'utilisateurs simultanés.
Mais cette fourchette ne veut rien dire sans comprendre ce qui détermine où votre projet se situe sur le spectre.
Ce qui détermine réellement le délai
Nombre d'écrans et rôles utilisateurs
C'est le proxy le plus simple pour la taille du projet. Une application de 10 écrans avec un rôle utilisateur est fondamentalement différente d'une application de 40 écrans avec cinq rôles, chacun voyant des données différentes avec des permissions différentes. Plus d'écrans signifie plus de design, plus de développement, plus de tests, et plus de cas limites.
Guide approximatif de notre expérience : 5-15 écrans signifie typiquement 2-4 mois de développement. 15-30 écrans, c'est 4-6 mois. Plus de 30 écrans, c'est 6-9 mois ou plus.
Intégrations avec d'autres systèmes
Chaque intégration avec un système externe — passerelle de paiement, outil comptable, base de données legacy, API tierce — ajoute du temps. Pas parce que l'intégration en soi est difficile (la plupart ne le sont pas), mais parce qu'on devient dépendant de la documentation, de la fiabilité et du temps de réponse d'un autre système.
Un projet sans intégration est simple. Un projet qui doit se synchroniser avec SAP, tirer des données de trois APIs, et envoyer des notifications via la passerelle d'un opérateur télécom ? C'est un calendrier complètement différent. On ajoute typiquement 2-4 semaines par intégration significative.
La vitesse de prise de décision
C'est le facteur dont personne ne parle, et c'est souvent le plus grand facteur de variation du délai.
On a eu des projets où le client revoyait les designs sous 48 heures, répondait aux questions le jour même, et prenait les décisions en une seule réunion. Ces projets ont fini en avance. On a eu des projets de taille équivalente où la validation du design a pris trois semaines parce qu'il fallait l'aval de cinq personnes, et les questions restaient dans la boîte mail de quelqu'un pendant des jours. Ces projets ont pris deux fois plus de temps.
La vitesse de l'équipe de développement n'est que la moitié de l'équation. La réactivité du client est l'autre moitié. Une agence rapide avec un client lent livre plus lentement qu'une agence normale avec un client engagé.
Clarté des besoins
Les projets où le client arrive avec un brief clair, des wireframes validés et des fonctionnalités priorisées démarrent plus vite et restent sur les rails. Les projets où les besoins sont encore en cours de découverte pendant le développement prennent plus de temps — pas parce que la découverte est mauvaise, mais parce que construire en découvrant signifie refaire.
On a écrit un guide sur comment rédiger un bon brief spécifiquement pour aider les clients à partir d'une meilleure position. Le temps que vous investissez en clarté avant le développement vous revient en double pendant le développement.
Où les projets perdent réellement du temps
Dans notre expérience, le travail de développement en soi cause rarement les retards. Le code s'écrit. Les fonctionnalités se construisent. Le temps perdu arrive autour du développement, pas dedans.
Le scope creep sans compromis. « Est-ce qu'on peut aussi ajouter... » c'est bien — tant que quelque chose d'autre est repoussé en Phase 2. Quand des nouvelles fonctionnalités s'ajoutent sans rien retirer ni reporter, le calendrier s'étire. C'est pour ça qu'on utilise un processus de livraison par phases avec des limites de périmètre explicites.
Les boucles de validation du design. Une revue de design qui devait prendre 3 jours prend 3 semaines parce que le décideur est en déplacement, ou parce que « l'équipe » doit donner son avis et l'équipe a 8 opinions. Intégrez un décideur unique dans votre processus.
Le feedback flou. « Je n'aime pas » sans précisions renvoie l'équipe deviner. « Le tableau de bord devrait montrer des tendances mensuelles, pas quotidiennes » est actionnable. La qualité du feedback affecte directement la vitesse d'itération.
Les surprises d'intégration. L'API tierce ne fonctionne pas comme documenté. Les données du système legacy sont plus désordonnées que prévu. Le prestataire de paiement met 3 semaines à valider un compte sandbox. C'est réel, et c'est difficile à prévoir. La meilleure parade est de commencer le travail d'intégration tôt, pas de le garder pour la fin.
Un calendrier réaliste détaillé
Voici comment un projet typique de 5 mois se décompose dans notre processus :
Semaines 1-2 : Cadrage et besoins. Transformer le brief du client en document de spécifications structuré avec user stories, priorités et limites explicites. Cette phase est courte mais critique — la sauter coûte des mois plus tard.
Semaines 3-4 : Design et validation. Wireframes, puis design UI. Le client voit et valide chaque écran avant qu'on écrive du code. C'est là que les malentendus se règlent à moindre coût.
Semaines 5-16 : Développement en sprints. Des cycles de deux semaines avec une démo à la fin de chacun. Le client voit du logiciel fonctionnel tous les 14 jours. C'est le gros du calendrier, et c'est là que le nombre d'écrans et la complexité des intégrations déterminent la durée réelle.
Semaines 17-20 : Tests, finitions et déploiement. QA sur le staging, tests d'acceptation client, corrections de bugs, optimisation des performances, et la mise en production. Cette phase est compressée sur trop de projets — ne le permettez pas. Se précipiter en production avec du logiciel non testé coûte plus cher que les deux semaines de QA supplémentaires.
Peut-on construire plus vite ?
Oui, avec des compromis.
Réduire le périmètre. La façon la plus rapide de livrer plus tôt est de construire moins. Lancez avec les 5 fonctionnalités qui comptent le plus et ajoutez le reste après la production. C'est l'approche MVP, et elle marche — mais seulement si le client accepte de lancer quelque chose qui ne fait pas tout.
Décider plus vite. Si vous pouvez vous engager sur des retours sous 48 heures pour les revues de design et les questions, vous gagnerez des semaines sans aucun changement de vitesse de développement.
Ne pas ajouter de monde. Ajouter des développeurs à un projet en retard le retarde encore plus. C'est une loi du génie logiciel, pas une suggestion. Une petite équipe focalisée qui communique bien surpassera toujours une grande équipe avec des frais de coordination.
Utiliser un framework avec un écosystème mature. C'est pour ça qu'on construit avec Laravel — l'écosystème gère l'authentification, les panels admin, le déploiement et le monitoring nativement, ce qui élimine des semaines de travail qui seraient autrement construites from scratch.
Que faire avec ces informations
Si vous planifiez un projet logiciel sur mesure, voici comment obtenir un calendrier réaliste :
Comptez vos écrans. Listez vos intégrations. Identifiez votre décideur. Rédigez un brief clair. Puis demandez à votre agence de découper le projet en phases avec des estimations de temps pour chaque phase — pas une seule réponse « ça prendra 6 mois ».
Une bonne agence vous donnera un calendrier phasé que vous pouvez suivre. Une mauvaise agence vous donnera une date unique et croisera les doigts.
On a écrit sur comment les modèles de tarification affectent les résultats et sur quand construire vs. acheter. Le délai n'est qu'une pièce d'un ensemble plus large de décisions qui déterminent le succès de votre projet.
Vous voulez un calendrier réaliste pour votre projet spécifique ? Cadrons-le ensemble →