Délai d'un logiciel métier : le vrai calendrier

Quand un dirigeant demande un délai de développement d'un logiciel métier, la réponse qu'il reçoit le plus souvent est « ça dépend ». C'est vrai. C'est aussi inutile. Ce qu'il faut savoir, ce n'est pas la durée moyenne d'un projet qui n'est pas le vôtre, c'est de quoi dépend le calendrier, étape par étape, et lesquels de ces leviers sont entre vos mains.

Cet article déroule les sept étapes d'un projet chez le constructeur, ce qui les raccourcit, ce qui les allonge, et pourquoi le devis le plus rapide n'est pas toujours le meilleur signal.

Pourquoi « ça dépend » n'est pas une réponse

Deux projets facturés le même prix peuvent prendre trois semaines ou quatre mois. L'écart ne vient presque jamais du nombre d'écrans. Il vient de trois choses :

La netteté du processus métier. Une entreprise qui sait décrire son circuit de commande en dix minutes fait gagner deux semaines. Une entreprise dont trois personnes en donnent trois versions différentes va d'abord devoir trancher.
L'état des données existantes. Reprendre un fichier propre est rapide. Reprendre quatre classeurs avec des doublons, des colonnes libres et des conventions de nommage variables prend un temps qu'on sous-estime systématiquement.
La vitesse de décision côté entreprise. C'est le facteur numéro un, et on y revient plus bas parce qu'il mérite d'être dit franchement.

Un planning de projet sur mesure n'est donc pas une durée à deviner. C'est une suite d'étapes dont chacune a ses propres accélérateurs et ses propres pièges.

Les 7 étapes qui composent le délai de développement d'un logiciel métier

1. Le cadrage : comprendre le processus et décider ce qu'on ne fait pas

Le cadrage sert à trois choses : comprendre comment le travail se fait réellement, identifier le goulot (l'endroit où votre équipe perd du temps chaque semaine), et arbitrer le périmètre de la première version.

Ce dernier point est le plus important pour le calendrier. Un cadrage réussi produit autant de « non » que de « oui ». Chaque fonction retirée de la version 1 n'est pas une fonction perdue : c'est une fonction repoussée après la mise en service, quand vous saurez si elle est vraiment nécessaire.

Ce qui raccourcit : un interlocuteur unique, décideur, disponible. Une réunion de deux heures avec la personne qui connaît le terrain vaut cinq échanges par courriel.

Ce qui allonge : un cadrage mené avec quatre services qui n'ont pas les mêmes priorités, sans arbitre. Ou un périmètre qui grossit à chaque réunion.

2. La conception : les écrans, les règles, et ce qui se passe quand ça se passe mal

On dessine les écrans, on écrit les règles métier, et surtout on traite les cas d'exception. C'est là que se cachent les dépassements de planning.

Exemple concret : un devis se transforme en commande. Très bien. Mais que se passe-t-il si le client valide la moitié du devis ? Si le prix a changé entre-temps ? Si le commercial est parti ? Chacune de ces questions est une règle à écrire. Découverte en conception, elle coûte une heure. Découverte en recette, elle coûte trois jours et un décalage de planning.

Ce qui raccourcit : accepter de passer du temps sur les exceptions maintenant, même quand ça paraît tatillon.

Ce qui allonge : « on verra à l'usage ». On ne verra pas à l'usage, on verra au pire moment.

3. Les données : le modèle, et la reprise de l'existant

C'est la surprise récurrente des plannings. Le modèle de données (comment on range les clients, les chantiers, les pièces, les interventions) se construit assez vite quand le processus est clair. La reprise de l'historique, elle, est imprévisible.

Si vos informations vivent dans des tableaux tenus à la main depuis huit ans, il faut les nettoyer avant de les reprendre. Doublons, orthographes variables, colonnes ajoutées par une personne qui n'est plus là, notes libres qui contiennent en réalité une information structurante. Ce travail est faisable, mais il se chiffre en jours, parfois en semaines, et il dépend surtout de votre disponibilité à trancher les cas ambigus.

Ce qui raccourcit : un export propre, et une personne côté entreprise capable de dire « cette ligne, on la garde » ou « on la jette ».

Ce qui allonge : vouloir tout reprendre. Souvent, reprendre les trois dernières années et archiver le reste suffit et fait gagner un mois.

Si votre point de départ n'est pas un tableur mais une application existante qui ne suit plus, le sujet est différent et mérite son propre diagnostic. Nous l'avons traité dans reprendre une application métier qui ne suit plus.

4. Le développement

C'est l'étape que tout le monde imagine comme étant la plus longue. Elle ne l'est plus vraiment. Avec les méthodes de construction actuelles, la fabrication des écrans et des règles avance beaucoup plus vite qu'il y a quelques années, à condition que les trois étapes précédentes soient faites.

Un développement qui dérape n'est presque jamais un problème de fabrication. C'est un cadrage incomplet qui remonte à la surface.

Ce qui raccourcit : des livraisons par lots, montrées toutes les semaines ou tous les quinze jours. Vous voyez, vous corrigez tôt.

Ce qui allonge : un effet tunnel de deux mois suivi d'une grande révélation. Là, les écarts se découvrent tous en même temps.

5. Les tests et la recette avec les vrais utilisateurs

La recette n'est pas une formalité de fin de projet. C'est le moment où les personnes qui utiliseront l'outil tous les jours essaient de le casser avec leurs cas réels.

Cette étape est presque toujours sous-dotée dans les plannings. Pas par le constructeur : par l'entreprise, qui n'a pas réservé de temps à ses équipes pour tester. Résultat, la recette s'étale sur trois semaines au lieu de cinq jours, non pas parce qu'il y a beaucoup de corrections, mais parce que personne n'a eu le temps de regarder.

Ce qui raccourcit : deux ou trois utilisateurs désignés, avec des créneaux bloqués dans leur agenda, et des cas réels préparés à l'avance.

Ce qui allonge : une recette confiée « à tout le monde », donc à personne.

6. La formation

Elle est courte quand le logiciel suit le vocabulaire de l'entreprise et le sens du travail réel. Elle s'allonge quand l'outil impose une logique étrangère à l'équipe. C'est un bon révélateur : une formation qui dure, c'est souvent une conception qui a raté quelque chose.

Comptez peu de temps de formation en salle, et plus d'accompagnement les premiers jours d'usage. C'est à ce moment-là que les vraies questions arrivent.

7. La mise en production et les premières semaines

Le jour de bascule n'est pas la fin du projet. Les deux à quatre semaines qui suivent sont une étape à part entière : ajustements d'ergonomie, cas oubliés, réglages de droits, petites automatisations que personne n'avait vues venir.

Un planning honnête réserve ce temps. Un planning qui s'arrête à la date de mise en service reporte simplement les ajustements sur une facture ultérieure, ou sur le dos des équipes.

Le poids de chaque étape dans le planning

Les proportions ci-dessous sont des ordres de grandeur issus de la pratique de projets internes en PME, pas une mesure chiffrée. Elles servent à répartir un calendrier, pas à le garantir.

Étape	Part du planning	Ce qui la raccourcit	Ce qui l'allonge
Cadrage	Faible mais déterminante	Un décideur disponible	Périmètre qui grossit
Conception	Significative	Traiter les exceptions tout de suite	« On verra à l'usage »
Données et reprise	Très variable	Export propre, périmètre d'historique limité	Nettoyage tardif
Développement	Le gros du volume	Livraisons par lots	Effet tunnel
Tests et recette	Souvent sous-estimée	Utilisateurs désignés, créneaux bloqués	Recette sans pilote
Formation	Courte	Vocabulaire métier respecté	Logique imposée
Mise en service et ajustements	2 à 4 semaines	Temps réservé au planning	Projet déclaré fini trop tôt

Ce que ça donne en vrai chez Magram

Les Ateliers d'Art (enseignement artistique) : 8 semaines de développement pour une plateforme complète, du site public au back-office en passant par l'espace familles, avec un budget de 18 500 €. Le jour de la rentrée, l'outil a absorbé 390 inscriptions, soit 75 % du volume d'un mois en une journée.

Sur nos trois derniers projets, la construction a demandé 5 à 6 semaines de développement, livrées par lots. Chaque lot a été montré et validé avant de passer au suivant.

Le premier facteur de retard est chez vous, et c'est une bonne nouvelle

Il faut le dire simplement : dans la majorité des projets qui glissent, la cause n'est pas technique. C'est la disponibilité et la vitesse de décision côté entreprise.

Une validation d'écrans qui attend dix jours, c'est dix jours de projet. Une réunion de cadrage reportée deux fois, c'est trois semaines. Un choix de règle de facturation que personne n'ose trancher, c'est un développement en attente.

C'est une bonne nouvelle parce que ce levier vous appartient. Trois décisions suffisent à sécuriser un planning :

Nommer un référent unique côté entreprise, avec le pouvoir de trancher sans remonter à chaque fois.
Bloquer d'avance les créneaux de validation et de recette dans les agendas.
Accepter qu'une version 1 volontairement réduite sorte vite, plutôt qu'une version complète qui sort peut-être.

Pourquoi le délai le plus court n'est pas toujours bon signe

Quand vous comparez deux propositions et que l'une annonce trois semaines là où l'autre annonce deux mois, la première n'est pas forcément la meilleure. Posez trois questions.

Le cadrage est-il inclus, ou facturé après ? Un planning très court commence souvent après le cadrage, qui est alors invisible dans le chiffre annoncé.
La reprise des données est-elle comptée ? C'est l'exclusion la plus fréquente. Et la plus coûteuse en temps.
La recette et les ajustements post-mise en service sont-ils dans le délai ? Si la date annoncée est celle de la livraison technique et non celle de l'usage réel, vous ne comparez pas la même chose.

Le même raisonnement vaut pour les montants : deux devis qui n'incluent pas le même périmètre ne se comparent pas. Nous détaillons cette mécanique dans notre analyse du prix d'un développement logiciel sur mesure.

Ce que les méthodes actuelles changent vraiment au calendrier

La fabrication s'est accélérée. Écrans, règles, enchaînements : ce qui prenait des semaines se construit aujourd'hui en jours sur beaucoup de sujets. Nous l'avons détaillé dans notre article sur le développement assisté par l'intelligence artificielle.

Mais l'accélération ne porte que sur une partie du planning. Comprendre un processus métier, arbitrer un périmètre, nettoyer un historique, faire tester par des utilisateurs occupés, former une équipe : rien de tout cela n'a été divisé par deux. C'est pour cette raison qu'un projet sérieux ne descend pas indéfiniment en durée. Le temps humain reste le temps humain.

Autrement dit : la part « fabrication » du calendrier a fondu, la part « décision » est devenue proportionnellement plus lourde. Ce qui renforce encore le point précédent.

Comment obtenir une date fiable pour votre projet

Une estimation crédible suppose quatre informations :

Le processus à outiller, décrit du début à la fin, avec ses exceptions connues.
L'état des données existantes, et le périmètre d'historique que vous voulez vraiment reprendre.
Le nombre d'utilisateurs et leurs rôles, parce que les droits d'accès font partie du travail.
Les échéances externes non négociables (clôture, saison haute, audit, déménagement d'un site).

Avec ces quatre éléments, un planning se pose en étapes datées, avec les points de validation dont vous êtes responsable. Sans eux, toute date annoncée est une illusion polie.

Par quoi commencer

Si vous cherchez une durée avant de lancer un projet, commencez par le diagnostic et non par le devis. Une heure de conversation sur votre processus suffit généralement à dire si le sujet se traite en quelques semaines ou s'il demande un cadrage plus large, et à identifier tout de suite les deux ou trois points qui feront basculer le calendrier.

C'est exactement l'objet d'un premier échange avec le constructeur : regarder le goulot, poser le périmètre minimal utile, et sortir avec des étapes datées plutôt qu'avec un « ça dépend ».