Combien de temps faut-il pour développer une application métier ?

La question du délai vient juste après celle du prix, et elle est tout aussi piégeuse. Un chiffre annoncé sans connaître votre organisation ne vaut rien : la durée d'un projet dépend autant de votre capacité à décider que de la vitesse du prestataire.

Les quatre jalons qui comptent

Le cadrage — quelques jours

Observer les process réels, identifier les irritants, les classer par coût. Cette phase est courte, et c'est la plus rentable du projet. La raccourcir revient à économiser une heure pour en perdre vingt.

Le prototype cliquable — une à deux semaines

Vos écrans, votre vocabulaire, des données d'exemple. Rien ne fonctionne vraiment, mais tout se manipule. C'est le jalon le plus important : c'est là que les malentendus se révèlent, quand ils ne coûtent encore rien à corriger.

Si l'on vous propose de sauter cette étape, refusez. Voir pourquoi le cahier des charges fait échouer les projets.

La mise en production — trois à seize semaines

C'est ici que les fourchettes s'écartent, selon le mode de réalisation :

• Adaptation d'une base existante : trois à six semaines.
• Développement intégral : deux à quatre mois pour un premier périmètre utilisable.

Dans les deux cas, méfiez-vous d'un projet annoncé « livré d'un coup » après plusieurs mois de silence. Une mise en production progressive, service par service, réduit massivement le risque.

L'appropriation — deux à six semaines après la livraison

Le projet n'est pas terminé à la livraison. Il l'est quand vos équipes utilisent l'outil sans y penser. Cette période demande de la présence, des ajustements rapides et de la patience.

Ce qui fait vraiment déraper un planning

D'expérience, le développement n'est presque jamais le coupable. Les vrais responsables sont :

• Les décisions en attente. Une question laissée sans réponse pendant dix jours décale le projet de dix jours. C'est le premier facteur, et il est de votre côté.
• L'état des données. Fichiers incohérents, doublons, champs libres : la reprise prend alors trois fois le temps prévu.
• Les intégrations tierces. Attendre un accès API, une documentation ou un interlocuteur chez un éditeur externe peut coûter des semaines sur lesquelles personne n'a de prise.
• L'élargissement discret du périmètre. « Pendant qu'on y est, on pourrait aussi… » — chaque ajout est légitime pris isolément, et ruine un planning cumulé.
• La validation dispersée. Quand cinq personnes doivent approuver sans qu'aucune ne décide, rien n'avance.

Comment aller plus vite, côté client

• Désignez une seule personne qui tranche, disponible une heure par semaine.
• Préparez vos données tôt, même imparfaites : les voir révèle les problèmes.
• Acceptez un périmètre réduit pour la première mise en production.
• Faites tester par ceux qui utiliseront l'outil, pas seulement par leurs responsables.
• Notez les demandes supplémentaires dans une liste « version 2 » plutôt que de les intégrer au fil de l'eau.

Le bon indicateur de santé d'un projet

Ce n'est pas le pourcentage d'avancement annoncé, toujours optimiste. C'est la réponse à cette question : quand ai-je manipulé le logiciel pour la dernière fois ?

Si la réponse dépasse deux semaines, le projet dérive — que le prestataire le sache encore ou non.