Combien de temps prend un projet d’automatisation pour une entreprise?

Le premier livrable — un plan écrit, une maquette ou une démo fonctionnelle — arrive dans les 24 heures suivant le premier appel. Les projets complets sont délimités à partir de là; un système de PME bien défini prend habituellement des semaines, pas des mois, et un projet bien délimité est généralement rentabilisé en deux à six mois.

Les échéanciers s’étirent pour une raison plus que pour toute autre : la portée n’a jamais été mise par écrit, alors elle n’a jamais cessé de bouger. Un plan qui dit ce qui sera bâti et ce qui, explicitement, ne le sera pas vaut plus qu’un développeur de plus. La moitié « ce qui ne sera pas bâti » est celle qui porte tout — chaque projet qui a duré deux fois plus longtemps que prévu y est arrivé par des ajouts qui semblaient chacun petits sur le moment.

Les parties qui prennent du temps sont rarement celles qu’on attend. Bâtir le scénario idéal — le processus quand tout va bien — est rapide maintenant. Ce qui gruge le calendrier, ce sont les cas limites : ce qui arrive quand l’API est en panne, quand la fiche est un doublon, quand le client répond au courriel automatisé par une question, quand deux systèmes ne s’entendent pas sur un champ. Un bâtisseur qui chiffre seulement le scénario idéal livrera à temps, puis passera les deux mois suivants à livrer le vrai projet sous forme de « correctifs ».

L’attente est l’autre élément caché de l’échéancier, et elle est habituellement du côté du client : l’accès aux comptes, les identifiants d’API, une décision sur lequel de deux processus contradictoires est le vrai, des données d’exemple qui reflètent la réalité plutôt que l’idéal. Une discipline utile au lancement consiste à lister chaque élément dont le bâtisseur a besoin de votre part, avec une date à côté — les projets où cette liste existe restent près du plan, et ceux où elle n’existe pas bloquent dès la deuxième semaine pour des raisons qui semblent être la faute du bâtisseur, mais qui ne le sont pas.

L’IA a réellement comprimé la construction elle-même — du travail estimé en mois se livre maintenant en semaines, parce que le code, les tests et la documentation sont produits avec l’IA dans la boucle. Ce qu’elle n’a pas comprimé, c’est la décision de ce qu’il faut bâtir, et c’est pourquoi les firmes rapides ramènent cette décision au tout début, sous une forme concrète, immédiatement. Si une proposition vous annonce des mois avant que quiconque ait vu comment vous travaillez, c’est une estimation d’échéancier, pas une estimation d’ingénierie — et si son premier jalon est un document plutôt que quelque chose qui fonctionne, l’échéancier est déjà faux.

Dernière révision le 28 août 2026