Combien de temps faut-il pour développer un logiciel sur mesure ?

Quelles sont les phases d'un projet logiciel et ce qui fixe leur durée ?

Un projet logiciel sur mesure enchaîne cinq phases, et chacune a son propre facteur limitant, qui n'est presque jamais la vitesse d'écriture du code.

Ces unités sont des ordres de grandeur prudents, pas des engagements. Un outil interne à un seul rôle peut se construire en quelques semaines ; une plateforme ouverte à des clients externes, avec paiement et intégrations, se compte plutôt en trimestres.

Quels repères de durée publient les sources officielles ?

Peu de sources publiques chiffrent la durée des projets logiciels ; les repères les plus solides viennent de l'État, de la méthode Scrum et des éditeurs des stores d'applications.

Les durées de la DINUM portent sur des services publics numériques qui continuent d'évoluer après la phase de construction : elles montrent surtout qu'un besoin se valide en semaines et qu'un service se construit en mois. Les deux publications ne donnent d'ailleurs pas la même durée de construction : 12 à 18 mois dans le livre blanc de mars 2025, six mois à un an sur la page du programme. Les étapes de publication mobile sont détaillées dans la page publier une application sur l'App Store et Google Play.

Qu'est-ce qui allonge un projet logiciel ?

Un projet logiciel s'allonge d'abord par les temps d'attente : une décision, un accès ou un fichier qui n'arrive pas bloque l'équipe plus sûrement qu'une difficulté technique.

• Les décisions en comité. Une question sur une règle de remise qui attend la réunion mensuelle de direction immobilise tout le lot concerné.
• Les intégrations avec des tiers. L'accès à l'API d'un éditeur peut exiger un contrat, un environnement de test, parfois une homologation. Pour le site de pièces Peugeot Motocycles, chaque service Chronopost a dû être validé par le transporteur sur des étiquettes de test avant l'ouverture des accès de production.
• Les données à reprendre. Un tableur où les dates sont saisies de quatre façons et où un même client existe sous trois noms impose un nettoyage avant toute bascule.
• Le périmètre qui glisse. Une fonction ajoutée en cours de route rallonge la construction et la recette ; sa place est dans le lot suivant.
• Une recette tardive. Découvrir en fin de projet qu'un écran ne colle pas au travail réel coûte des semaines de reprise.

Qu'est-ce qui accélère vraiment un développement ?

Ce qui accélère un développement, c'est de supprimer les attentes et de resserrer la première version, pas d'ajouter des développeurs en cours de projet.

1. Un décideur unique et disponible, capable de trancher une question métier en quelques jours.
2. Un premier lot resserré sur le flux qui fait gagner le plus de temps, le reste étant planifié dans les lots suivants.
3. Les accès demandés dès le cadrage : API des éditeurs, comptes développeur des stores, nom de domaine, exports des données existantes.
4. Des services du marché pour les briques standard : paiement, envoi d'e-mails, authentification, cartographie.
5. Des testeurs identifiés côté client, avec un créneau réservé à chaque fin de cycle.

Pourquoi une version testable tôt change-t-elle tout ?

Une version testable livrée tôt transforme les malentendus en corrections de quelques jours, au lieu de reprises de plusieurs semaines en fin de projet.

Le Scrum Guide, référence de la méthode Scrum, fixe des cycles d'un mois ou moins et précise que chaque incrément doit être utilisable pour apporter de la valeur. Le principe dépasse Scrum : un utilisateur qui manipule un vrai écran repère en dix minutes ce qu'aucune réunion n'avait révélé, comme un champ obligatoire dont il ne connaît jamais la valeur au moment de la saisie. Pour le robot de livraison de Sakura France Service, plus de 60 versions ont été itérées sur le terrain avec l'équipe soignante avant la mise en service. C'est la raison pour laquelle la méthode de YMHB Web prévoit une version testable accessible en permanence pendant la construction.

Comment bâtir un planning réaliste ?

Un planning réaliste part de la date qui compte pour l'entreprise et remonte le temps, en gardant de la marge pour la recette et les dépendances externes.

1. Nommer la contrainte de date : un événement, une saison, une échéance réglementaire. Pour Tapas Tour 2026, l'application, le back-office, l'API et la boutique devaient être livrés ensemble pour la date de l'événement.
2. Placer la mise en service hors des pics d'activité, avec la reprise des données et la formation.
3. Réserver la recette avant cette date, avec des testeurs déjà désignés.
4. Ajouter les délais externes : examen des stores, homologations, ouverture des accès chez les éditeurs tiers.
5. Découper la construction en lots et vérifier à chaque fin de cycle que le rythme réel tient le calendrier.

Si la date ne tient pas avec le périmètre souhaité, c'est le premier lot qu'il faut réduire, pas la recette. Le guide recette logicielle détaille comment l'organiser.