Combien de temps pour développer un logiciel métier ?

La plupart des articles qui posent cette question n'y répondent pas. Ils énumèrent les phases d'un projet, expliquent que « ça dépend », et laissent le lecteur repartir sans le seul chiffre qu'il était venu chercher. Celui-ci commence par les fourchettes, explique ensuite ce qui les fait bouger, et finit par la question qui compte vraiment : à quelles conditions vous pouvez annoncer une date sans vous dédire.

⏱️ Les fourchettes, tout de suite

Un outil de gestion ou un tableau de bord sur mesure sort en 6 à 8 semaines. Un site en 1 à 2 semaines. Une application mobile disponible sur iPhone et Android en 8 à 12 semaines. Ce sont les délais qu’OTTOPILOTE annonce publiquement sur sa page forfaits, et sur lesquels le studio s’engage : en cas de retard, les jours supplémentaires sont absorbés.

Ces chiffres ne sont pas une moyenne de marché. Une statistique de « 4,5 mois en moyenne » circule sur le web francophone, mais la page qui la relaie ne nomme aucune source, et nous ne la reprenons pas. Les fourchettes ci-dessus sont des engagements, ce qui est une information plus utile qu’une moyenne.

🧩 Ce qui fait bouger ces fourchettes

Trois facteurs expliquent l’essentiel de l’écart entre le bas et le haut d’une fourchette. Ils se repèrent tous dès le cadrage, ce qui veut dire qu’un délai annoncé après un vrai cadrage vaut infiniment mieux qu’un délai annoncé au téléphone.

Si vous hésitez encore sur la famille d’outil à viser, ce choix précède le chiffrage du délai : CRM, ERP ou EOS, quelle solution choisir pose les critères.

📆 Calendaire ou charge : la confusion qui déçoit

Un projet « de huit semaines » ne représente pas huit semaines de travail continu, et cette confusion est la première source de déception sur un planning. Le délai calendaire inclut des temps d’attente structurels que personne ne peut compresser : vos validations, la disponibilité de vos équipes, les allers-retours avec un éditeur tiers, et pour une application mobile, la validation par les magasins d’applications.

Un projet de huit semaines, semaine par semaine

Prenons un cas concret : une PME de services qui suit ses interventions sur trois classeurs et veut un outil unique, avec des comptes pour ses techniciens et un tableau de bord pour la direction. Voici où passent réellement les huit semaines, et ce qui se joue de votre côté.

Additionnez la colonne de droite : sur huit semaines calendaires, votre charge réelle représente une semaine dense au début, puis quelques heures par semaine. Ce n’est pas beaucoup. Mais chacune de ces heures est bloquante : elle ne se rattrape pas, et son report décale tout ce qui suit. C’est exactement pour cette raison qu’un délai calendaire et une charge de travail ne se comparent pas.

Notez aussi les deux semaines marquées en bleu, la première et la septième. Ce sont celles où le projet dépend entièrement de vous. Un décalage d’une semaine sur la recette produit un décalage d’une semaine sur la mise en service, quelle que soit l’équipe en face.

🗂️ Les phases et ce qu’elles pèsent

Un projet de logiciel métier s’organise toujours de la même façon, et le poids relatif des phases varie moins qu’on ne le croit. Ce qui change d’un projet à l’autre, c’est le nombre d’itérations de développement, pas la structure.

🙋 La part du délai qui dépend de vous

Voici la partie que les guides de prestataires évitent, alors qu’elle contient le levier le plus puissant dont vous disposez. Sur les trois facteurs majeurs de réussite d’un projet identifiés par le CHAOS Report du Standish Group, deux sont entre vos mains : l’implication des utilisateurs et le soutien du management. Le troisième, l’énoncé clair des besoins, se construit à deux.

Ce n’est pas un reproche, c’est une bonne nouvelle. Le prestataire ne peut pas accélérer ce qui lui échappe, mais vous, si.

Il y a exactement trois moments où le projet vous attend.

La différence entre un projet qui tient son planning et un projet qui glisse tient rarement à la technique. Elle tient au délai de réponse : un client qui tranche en une demi-journée et un client qui tranche en trois jours ne vivent pas le même projet, même avec la même équipe en face.

Le remède est simple et se pose au cadrage : nommer une personne décisionnaire, unique, disponible, et bloquer à l’avance dans les agendas les créneaux de validation et de recette. Pas au moment où ils arrivent, dès la semaine 1.

🚀 Ce qui raccourcit réellement un projet

Réduire le périmètre, jamais la qualité

C’est le seul levier vraiment efficace, et il est adossé à un chiffre solide. Le CHAOS Report du Standish Group établit que les petits projets réussissent dans environ 90 % des cas, contre moins de 10 % pour les grands. Découper n’est donc pas seulement plus rapide : c’est ce qui fait la différence entre un projet qui aboutit et un projet qui s’enlise.

Concrètement, cela veut dire livrer d’abord le processus qui fait perdre le plus de temps aujourd’hui, pour un seul type d’utilisateur, sans intégration. Puis ajouter, en apprenant de l’usage réel. La deuxième version est toujours meilleure que la première, parce qu’elle est écrite avec un outil entre les mains plutôt qu’avec des hypothèses.

Pourquoi ajouter des développeurs ne marche pas

L’intuition dit que doubler l’équipe devrait diviser le délai par deux. C’est faux, et c’est documenté depuis cinquante ans. La loi de Brooks, énoncée par Fred Brooks dans The Mythical Man-Month en 1975, tient en une phrase : ajouter des personnes à un projet logiciel en retard le retarde davantage.

Deux mécanismes l’expliquent. Les arrivants doivent d’abord comprendre le projet, ce qui mobilise précisément ceux qui savent déjà et qui produisaient. Et le coût de coordination croît plus vite que l’effectif : à trois personnes il y a trois liens à entretenir, à six il y en a quinze.

Le cas de l’échéance imposée

Parfois la date n’est pas négociable : une obligation réglementaire, une saison haute, un bail qui se termine, un ancien logiciel dont le support s’arrête. Dans ce cas, la variable d’ajustement n’est ni le délai ni la qualité, c’est le périmètre.

La méthode est de partir de la date et de remonter : qu’est-ce qui doit absolument fonctionner ce jour-là, et qu’est-ce qui peut attendre la version suivante ? Cette question produit presque toujours une liste plus courte que prévu. Un projet qui vise une date sans avoir fait cet exercice arrive en retard, ou arrive à l’heure avec un outil que personne n’ose utiliser.

🤝 Peut-on s’engager sur une date ?

Oui, à trois conditions, et un prestataire qui s’engage sans les avoir vérifiées ne s’engage pas, il devine.

Ces trois conditions réunies, un délai ferme devient tenable. C’est sur cette base qu’OTTOPILOTE annonce publiquement ses fourchettes sur sa page forfaits, et absorbe les jours de retard le cas échéant. Le calcul de rentabilité qui justifie ce délai est détaillé dans le guide du développement sur mesure et dans notre méthode de calcul du ROI.

⚠️ Les 6 pièges qui font déraper un planning

🎯 En résumé

📚 Sources

• Standish Group, CHAOS Report 2020 : taux de réussite global et effet de la taille du projet (rapport édité et vendu par le Standish Group, pas librement consultable)
• Fred Brooks, The Mythical Man-Month (1975, édition anniversaire chez Addison-Wesley) : loi de Brooks sur le renfort d’équipe en cours de projet
• OTTOPILOTE, page forfaits : délais annoncés et engagement d’absorption des retards