Six mois est devenu le délai que beaucoup d'entreprises considèrent comme normal entre l'idée d'un outil interne et sa mise en ligne. Ce chiffre n'a rien d'une fatalité technique : dans la plupart des projets que nous voyons, l'écriture du code représente une minorité du temps écoulé. Comprendre où passe le reste est le meilleur moyen d'agir dessus.
Un délai de développement se raconte mal en une seule durée, parce qu'il recouvre des projets qui n'ont rien à voir entre eux. Un prototype destiné à valider une idée et un outil qui va porter la facturation d'une entreprise ne se mesurent pas sur la même échelle.
Trois échelles à ne pas confondre
Le prototype : quelques jours
Un prototype sert à répondre à une question, pas à être utilisé. On le construit pour montrer un parcours, tester une hypothèse auprès de vrais utilisateurs, ou convaincre un comité. Il n'a pas besoin de gérer les droits, la reprise de données ou les cas limites. C'est ce qui le rend rapide, et c'est aussi pourquoi il ne faut jamais le mettre en production tel quel.
La première version utile : quelques semaines
C'est le périmètre qui compte vraiment : la plus petite application qui remplace réellement une partie de votre quotidien. Un seul processus, ses règles, ses utilisateurs, ses droits. Elle est en production, elle est fiable, et elle est volontairement incomplète.
L'outil métier complet : quelques mois
Plusieurs processus, plusieurs profils d'utilisateurs, des intégrations avec l'existant, une reprise de l'historique. C'est là que les projets s'étirent, et presque toujours pour des raisons qui n'ont rien à voir avec la difficulté technique.
Les cinq phases d'un projet, et ce qu'elles pèsent
Un projet d'application métier se décompose invariablement en recueil du besoin, spécification, design, développement, recette. Ce qui varie d'un prestataire à l'autre n'est pas la liste, c'est la répartition du temps entre ces phases.
Dans un projet mené de façon classique, la spécification et le design occupent souvent plus de temps que le développement lui-même. Ce n'est pas une anomalie : décider ce qu'on construit est plus difficile que le construire. C'est en revanche l'endroit où un calendrier se joue.
Le développement est rarement le goulot d'étranglement. C'est la décision qui l'est.
Les quatre choses qui font déraper un calendrier
1. Le besoin n'est pas décidé
C'est de loin la première cause. Un projet démarre alors que deux personnes chez le client n'ont pas la même idée de ce qu'il faut construire. Le désaccord ne se voit pas au démarrage : il apparaît à la recette, quand il coûte dix fois plus cher à traiter. Aucune méthode ni aucun outil ne compense une décision qui n'a pas été prise.
2. Les circuits de validation
Une maquette envoyée le vendredi, validée trois semaines plus tard après passage en comité : le calendrier a pris trois semaines sans qu'une seule difficulté technique soit apparue. Sur un projet de quelques semaines, ce sont les délais de validation qui dominent le planning, pas la production. Nommer une personne qui décide seule est souvent le levier le plus efficace d'un projet.
3. La reprise des données existantes
Systématiquement sous-estimée. Reprendre l'historique d'un tableur ou d'un ancien logiciel suppose de traiter les doublons, les champs vides, les formats incohérents, les cas que personne n'avait prévus. Cette phase révèle en général que les données réelles ne ressemblent pas à ce que tout le monde croyait.
4. Les intégrations avec l'existant
Se brancher à un logiciel de comptabilité, un ERP ou un service tiers introduit une dépendance que vous ne maîtrisez pas : documentation incomplète, accès à obtenir, environnement de test à demander. Le temps d'attente d'un accès dépasse fréquemment le temps de développement de l'intégration elle-même.
Ce qu'on peut comprimer, ce qu'on ne peut pas
Une partie du travail se comprime réellement. La rédaction des spécifications, la production des maquettes, l'écriture du code de structure, la couverture de tests : ce sont des tâches où l'outillage change l'ordre de grandeur. C'est le terrain sur lequel nos agents IA travaillent, et où nous avons vu la production passer d'une vingtaine de semaines à quelques-unes sur des périmètres comparables.
Une autre partie ne se comprime pas, et il faut s'en méfier quand quelqu'un vous promet le contraire :
- Le temps qu'il vous faut pour décider ce que vous voulez.
- Le temps que vos utilisateurs mettent à essayer l'outil et à vous dire ce qui cloche.
- Le temps d'obtenir un accès chez un tiers.
- Le temps de vérifier, sur des données réelles, que les règles produisent le bon résultat.
Ces quatre lignes sont du temps calendaire, pas du temps de travail. Aucune technologie ne les raccourcit. En revanche, les anticiper au démarrage change complètement la tenue d'un planning.
Comment obtenir une estimation qui vaut quelque chose
Une estimation donnée sans avoir vu vos données et sans avoir parlé à vos utilisateurs n'est pas une estimation, c'est un argument commercial. Pour qu'un délai annoncé ait un sens, il faut au minimum que le prestataire ait pu répondre à ces questions.
- Quel processus précis est remplacé, et lequel ne l'est pas ?
- Combien d'utilisateurs, avec combien de profils de droits différents ?
- Quelles données existantes doivent être reprises, et dans quel état sont-elles ?
- Quels systèmes tiers faut-il interroger, et les accès existent-ils déjà ?
- Qui valide, et en combien de temps ?
Si ces cinq points ne sont pas éclaircis, tout chiffre annoncé est une supposition. Mieux vaut un délai annoncé après une semaine de cadrage qu'un délai annoncé au premier appel.
Notre façon de faire
Nous commençons par un appel de cadrage, puis une proposition qui engage un forfait, un périmètre et un délai. Sur un prototype, cela se compte en jours ; sur un outil métier complet, en semaines. Le chiffre n'est pas donné avant d'avoir compris le périmètre, précisément parce qu'un délai donné trop tôt ne tient jamais.
Nos agents IA prennent en charge la part comprimable du travail, nos ingénieurs gardent les décisions structurantes et la relecture. C'est ce partage qui explique nos délais, pas un raccourci sur la qualité.