Combien de temps prend le développement d'un logiciel sur mesure

Les repères, par type de projet

Un projet complet, de la première rencontre au jour où l'outil est réellement utilisé, se termine en général en un mois. Rendez-vous, allers-retours et validations compris. Les durées ci-dessous correspondent à la construction elle-même, à l'intérieur de ce mois.

• Un outil interne remplaçant un tableur ou un processus manuel : une à deux semaines de construction.
• Un configurateur produit : une à deux semaines, le catalogue et les visuels mis à part.
• Une chaîne de traitement automatisée, images ou documents : une à deux semaines.
• Un portail client raccordé à un système existant : une à deux semaines.
• Une plateforme métier complète, multi-rôles : livrée par étapes successives, chacune au même rythme.

Ces durées valent sous quatre conditions qu'il faut vérifier avant de s'en servir : un périmètre tenu, des données exploitables, des systèmes existants accessibles, et un nombre d'utilisateurs qui n'impose pas de contraintes particulières de sécurité ou de validation. Changez l'une des quatre et le calendrier change avec.

Où passe réellement le temps

La répartition surprend. Sur un projet d'un mois, le développement proprement dit occupe rarement plus de la moitié du calendrier.

Le reste se partage entre trois postes, et aucun ne figure dans un planning de développement : comprendre le métier et écrire les règles, obtenir les accès aux systèmes existants, et préparer les données qui vont servir.

Le poste des accès est celui que personne n'anticipe, et c'est le plus pénalisant. Obtenir un droit de lecture sur un système de production implique souvent un prestataire historique, un responsable de la sécurité et parfois un éditeur extérieur. Trois semaines d'attente ne sont pas rares, et elles arrivent toujours au moment où l'équipe est prête à développer.

C'est pourquoi la toute première action d'un projet n'est pas une réunion de cadrage, c'est une demande d'accès. Elle ne coûte rien, elle ne bloque personne, et elle supprime le risque le plus courant.

La préparation des données est le second. Un référentiel propre accélère tout ; un référentiel approximatif transforme chaque fonction en négociation, parce qu'il faut décider, cas par cas, ce qui est vrai.

Les trois causes de dérapage

Trois causes expliquent l'essentiel des projets qui s'étirent, et aucune n'est technique.

• L'absence d'arbitre. Un projet avec une personne qui décide avance. Un projet avec quatre avis également légitimes passe son calendrier en réunions.
• Le périmètre qui s'étend en route. Chaque ajout semble modeste pris isolément ; accumulés, ils doublent la durée sans que personne n'ait vu le moment où cela s'est produit.
• La validation reportée. Un outil qui attend trois semaines une relecture perd ces trois semaines, et il les perd deux fois, parce que les retours arrivent alors groupés et contradictoires.

À l'inverse, ce qui n'allonge presque jamais les délais : la complexité technique annoncée au départ. Elle est estimée, planifiée, et elle se déroule comme prévu dans la grande majorité des cas.

Fixer la date avant le périmètre

La méthode la plus efficace paraît contre-intuitive : fixer une date de mise en production avant de fixer le périmètre, puis ajuster le périmètre pour tenir la date.

C'est pourtant ce qui produit les meilleurs résultats. Une équipe qui sait qu'elle livre dans un mois arbitre naturellement ce qui peut attendre, et ces arbitrages sont presque toujours les bons : la moitié des fonctions demandées au départ ne sont jamais réclamées une fois l'outil en service.

Deux pratiques complètent utilement cette approche. Mettre en service une version partielle en conditions réelles, sur un périmètre restreint, plutôt que d'attendre la version complète. Et prévoir, dès le planning initial, une semaine après la mise en service pour les corrections : elle existera de toute façon, autant l'assumer.

Enfin, une réunion hebdomadaire de trente minutes avec le décideur vaut mieux qu'une réunion mensuelle de deux heures. Les questions se posent au moment où elles se posent, et se tranchent en quelques jours au lieu de quelques semaines.

Ce qu'un calendrier court dit d'un projet

Un délai annoncé court n'est pas un signe de légèreté, c'est souvent l'inverse. Il indique un périmètre tenu et des décisions prises.

Nous avons mis en ligne le configurateur d'un chantier naval en douze jours. Ce chiffre ne dit pas que le travail était simple : il dit que le directeur commercial avait le catalogue et les règles en tête et qu'il a accepté d'y consacrer une à deux journées dès le départ.

À l'inverse, un prestataire qui annonce six mois pour un outil interne décrit en une page mérite une question : qu'est-ce qui, exactement, prend six mois ? La réponse est instructive.

Le bon signe dans une proposition est la présence d'une mise en production intermédiaire. Un projet qui ne produit rien d'utilisable avant son dernier jour est un projet dont personne ne connaît l'avancement réel.

Le même sujet du côté du budget : Combien coûte un logiciel sur mesure

La mise en production est le milieu du projet

Les deux semaines qui suivent la mise en service produisent plus d'informations que toute la phase de conception, parce qu'elles confrontent l'outil à l'usage réel plutôt qu'à l'usage imaginé.

Prévoyez explicitement ce temps : quelques jours de corrections immédiates, puis un point à dix jours pour traiter ce que l'usage a révélé. C'est court, et c'est ce qui transforme une livraison en outil adopté.

La suite relève du rythme de croisière, quelques heures par mois pour accompagner les évolutions du métier. Un outil qui ne bouge plus du tout est généralement un outil qui ne sert plus.

Et si vous avez une échéance à tenir, dites-la au premier rendez-vous plutôt qu'au troisième. Un calendrier contraint est une information utile : il change la façon dont le périmètre est construit, et il produit souvent un meilleur outil.