Combien de temps prend un projet logiciel sur mesure ?

C'est la deuxième question de presque toutes les entreprises qui nous approchent, juste après le prix : combien de temps avant d'avoir quelque chose qui fonctionne ?

La réponse courte : un premier jalon utilisable en quelques semaines, un ERP sur mesure complet en quatre à douze mois selon la portée, avec des mises en production progressives dès les premiers mois. Un logiciel n'arrive pas en un bloc à une date — il arrive par tranches.

Cette distinction est la seule chose qui compte vraiment dans un échéancier, et c'est celle qu'on oublie le plus souvent de vous expliquer.

La question qu'il faut poser à la place

« Combien de temps prend le projet ? » est une mauvaise question. Elle suppose qu'il existe un moment unique où le logiciel passe de zéro à fini.

La bonne question est double :

1. Dans combien de temps mon équipe pourra-t-elle s'en servir pour vrai ?
2. Dans combien de temps l'ensemble sera-t-il en place ?

L'écart entre les deux réponses est souvent de six à dix mois. Une entreprise qui ne pose que la deuxième question croit qu'elle devra attendre un an avant le moindre bénéfice — alors que la première tranche peut déjà régler son irritant le plus coûteux.

Les délais par type de projet

Ces intervalles viennent des projets que nous chiffrons et livrons sur le marché québécois. Ils correspondent aux fourchettes de prix des mêmes catégories.

• Petite envergure (un irritant précis, un connecteur, un outil interne) : de quelques semaines à deux ou trois mois.
• Moyenne envergure (application métier, portail, module opérationnel) : quelques mois, avec une première version utile bien avant la fin.
• ERP sur mesure ou plateforme complexe : de quatre à douze mois selon la portée, avec des mises en production progressives dès les premiers mois.

Le point commun des trois : la date de fin n'est jamais la date du premier bénéfice.

Pourquoi livrer par tranches change tout

L'erreur classique consiste à développer le système complet pendant douze mois, puis à le livrer d'un coup. Deux choses se produisent, systématiquement.

D'abord, personne ne l'adopte. Une équipe à qui on demande de changer toutes ses habitudes le même lundi matin retourne à ses anciens outils dans la semaine.

Ensuite — et c'est plus coûteux — les écarts avec la réalité du terrain n'apparaissent qu'à la toute fin. Un module de bons de travail conçu en salle de réunion révèle ses failles le jour où un contremaître l'utilise dans l'atelier. Il vaut mieux découvrir cet écart au troisième mois qu'au douzième, quand la correction coûte le plus cher.

Ce qui allonge réellement un échéancier

Ce n'est presque jamais la vitesse de développement. Quatre facteurs pèsent bien plus lourd.

Les décisions en attente

Un projet avance à la vitesse à laquelle son client tranche. Une question laissée sans réponse pendant trois semaines coûte trois semaines. C'est la cause d'allongement numéro un, et elle est entièrement sous votre contrôle.

Les règles métier que personne ne sait expliquer

Quand le calcul de prix de revient vit dans la tête d'une seule personne, ou dans un fichier Excel que son auteur a quitté l'entreprise, il faut le reconstituer avant de le programmer. Cette archéologie est du vrai travail, et elle n'est pas dans l'estimation initiale si personne ne l'a signalée.

L'accès aux données existantes

Récupérer l'historique d'un ancien système prend du temps quand la structure est inconnue ou que les exports sont partiels. Nous l'abordons en détail dans l'article sur la reprise d'un logiciel dont on n'a plus le code source.

La portée qui grandit en cours de route

Chaque ajout est légitime pris isolément. Additionnés, ils déplacent la date. Le remède n'est pas de tout refuser : c'est de décider explicitement, à chaque ajout, ce qui sort de la première tranche en échange.

Ce que l'IA a changé, et ce qu'elle n'a pas changé

La production de code s'est nettement accélérée. Sur certaines phases d'un projet, notre équipe avance de trois à cinq fois plus vite qu'avec une méthode traditionnelle.

En revanche, l'analyse, l'architecture, la sécurité et les décisions techniques n'ont pas accéléré. Comprendre vos opérations, choisir le bon modèle de données, décider ce qu'on ne construit pas : ces étapes restent le travail de développeurs chevronnés, et elles déterminent si le logiciel tiendra dix ans.

Concrètement, l'IA raccourcit surtout le délai entre deux tranches. Elle ne raccourcit pas le temps qu'il faut pour comprendre votre entreprise.

Un exemple concret

Une entreprise manufacturière entrait les mêmes cartes de temps dans son ERP, puis dans son logiciel comptable. Ce n'était pas un projet de douze mois : c'était un pont à construire entre deux systèmes.

Résultat : cinq heures libérées chaque semaine, soit 260 heures et environ 7 500 $ par année. Ce type de mandat se règle en semaines, pas en trimestres — et il n'exige pas d'attendre que l'ERP complet soit refait.

C'est exactement l'intérêt de découper : le gain arrive avant la fin du projet.

Comment lire une estimation de délai

Trois questions à poser à quiconque vous remet un échéancier :

1. Quelle est la première chose que mon équipe pourra utiliser, et quand ? Si la réponse est « à la fin », méfiez-vous.
2. Qu'est-ce qui est exclu de cette estimation ? La migration des données et la formation sont les oubliés les plus fréquents.
3. Qu'est-ce qui ferait déraper cette date ? Un partenaire qui n'a pas de réponse n'a probablement pas assez creusé.

En résumé

Un projet logiciel sur mesure ne se mesure pas en une date, mais en une suite de mises en production. Comptez quelques semaines pour le premier jalon utile, quelques mois pour une application métier, et de quatre à douze mois pour un ERP complet livré par tranches.

Si vous avez un échéancier à valider ou une urgence opérationnelle à régler, parlons-en — nous vous dirons franchement ce qui est réaliste.