Combien de temps faut-il pour créer une application web métier ?

C’est la première question qu’on me pose en atelier de cadrage, souvent avant même qu’on ait parlé du besoin. Je comprends pourquoi : il y a un budget à défendre, une date à annoncer en comité. Mais j’ai appris à ne jamais y répondre tout de suite — parce que la réponse dépend d’arbitrages qu’on n’a pas encore faits.

J’ai réécrit cet article : les fourchettes que j’y donnais ne tiennent plus. Elles décrivaient nos projets d’avant l’intégration de l’IA à notre chaîne de production. Nous mettons aujourd’hui une application en production en un à trois mois, contre trois à six auparavant.

Ce qui est intéressant n’est pas le chiffre, c’est ce qui a bougé — et surtout ce qui n’a pas bougé du tout.

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

Elle a divisé la construction. Génération de code, tests, documentation : la partie répétitive du développement se fait en une fraction du temps qu’elle demandait. Sur un périmètre donné, nous passons aujourd’hui un à trois sprints là où il en fallait trois à six.

Elle n’a rien changé au reste. Pas au cadrage, qui est une affaire d’arbitrage entre des personnes. Pas au délai de décision côté client. Pas à la reprise de données, qui est une enquête sur dix ans d’historique, pas une tâche technique. Pas à la recette, qui suppose des utilisateurs disponibles.

La conséquence est contre-intuitive, et c’est le vrai sujet de cet article : la construction n’est plus la phase la plus longue du projet. Avant, une décision qui traînait trois semaines se diluait dans une construction qui en durait douze — personne ne la voyait passer. Aujourd’hui elle est directement sur le chemin critique, et elle se lit sur la date de mise en production.

Le calendrier n’est donc plus dominé par ce que nous faisons, mais par ce que nous décidons ensemble. C’est une bonne nouvelle pour le délai, et une exigence nouvelle pour vous.

Le calendrier, phase par phase

Cadrage — 1 à 2 semaines

Ateliers avec les métiers, cartographie de l’existant, arbitrage de ce qui entre dans la première version. C’est la phase la plus rentable du projet, et celle qu’on cherche toujours à raccourcir. À tort : chaque jour passé ici en économise plusieurs plus tard.

Elle est passée de deux-quatre semaines à une-deux, et pas grâce à l’IA : parce que nous avons industrialisé nos ateliers et que nous refusons désormais de cadrer plus d’un périmètre à la fois. Le livrable n’a pas changé — un backlog priorisé et chiffré. Quand un prestataire chiffre avant d’avoir cadré, il ne chiffre pas : il devine, et vous découvrirez l’écart au pire moment.

Conception — 1 à 3 semaines

Parcours utilisateurs, maquettes, modèle de données, architecture, sécurité. L’écart entre 1 et 3 semaines tient à une seule variable : le nombre de décisions structurantes à prendre. Remplacer un tableur en demande peu. S’interfacer avec trois systèmes existants, dont un que personne ne sait plus documenter, en demande beaucoup.

Le prototypage est ce qui a le plus changé ici. Une maquette devient une interface manipulable en quelques heures, ce qui déplace la discussion : les métiers ne valident plus une image, ils essaient. Les malentendus qui se découvraient en recette se découvrent maintenant en atelier.

Construction — 2 à 6 semaines, par sprints de 2 semaines

Itérations courtes, avec une démonstration en fin de sprint sur un environnement réel — pas une capture d’écran, pas une maquette cliquable. C’est le seul moyen que j’aie trouvé pour qu’un malentendu se paie en deux semaines plutôt qu’à la recette.

C’est la seule phase où le gain s’est produit, et il est net : la génération de code, les tests et la documentation absorbent la partie répétitive du travail. La revue humaine, elle, reste systématique — du code généré et non relu est une dette contractée sans le savoir, et elle se rembourse pendant le RUN, au prix fort.

Le rythme de démonstration n’a pas changé pour autant. Nous tenons le sprint de deux semaines parce que c’est un rythme de décision, pas un rythme de production : ce qu’il cadence, c’est le moment où vous regardez le résultat et où vous dites si c’est bien ça.

Mise en production — 1 à 2 semaines

Recette avec les utilisateurs, reprise des données existantes, bascule, plan de retour arrière. C’est la phase la plus sous-estimée, systématiquement. La reprise de données, en particulier, fait toujours remonter des cas que personne n’avait décrits : le client sans adresse, le dossier ouvert en 2014 et jamais fermé, les doublons que tout le monde connaît et que personne n’a nettoyés.

Les trois choses qui font vraiment déraper un projet

Ce ne sont jamais celles qu’on craignait au départ, et l’ordre a changé depuis que la construction s’est raccourcie.

Des décisions qui attendent. C’est désormais le premier facteur, sans concurrence. Un développeur bloqué sur une règle de gestion non tranchée coûte exactement autant qu’un développeur qui code — mais un projet de deux mois supporte beaucoup moins bien une décision qui met trois semaines à tomber qu’un projet de cinq. La marge qui absorbait ces attentes a disparu avec la construction. C’est le prix du gain de délai, et il se paie de votre côté.

Un périmètre qu’on n’a pas su réduire. La première version doit résoudre un problème, pas tous. Chaque fonctionnalité ajoutée « tant qu’on y est » retarde la mise en production — donc le moment où l’on apprend enfin quelque chose des vrais utilisateurs. C’est mon métier de dire non, et c’est la partie la plus inconfortable du travail.

L’après-production qu’on n’a pas prévu. Une application livrée sans budget d’exploitation ni d’évolution se dégrade en quelques mois. Ce n’est pas un problème de planning projet, mais c’est ce qui détruit la valeur de tout ce qu’on vient de construire.

Photo : rawpixel — licence CC0.

Tous les projets ne se valent pas

Les fourchettes ci-dessus supposent un projet « standard ». Voici ce qui les déplace vraiment, par ordre d’impact décroissant.

Le nombre d’interfaces avec l’existant. C’est de loin le premier facteur. Une application autonome qui remplace un tableur tient dans le bas de la fourchette. La même application qui doit lire un ERP, écrire dans un outil comptable et s’authentifier sur l’annuaire de l’entreprise peut doubler. Chaque interface ajoute une dépendance à une équipe qui n’est pas la vôtre, avec son propre calendrier.

La reprise de données. Reprendre dix ans d’historique n’est pas une tâche technique, c’est une enquête. Il faut décider quoi faire des enregistrements incomplets, des doublons, des statuts qui n’existent plus. Ces décisions appartiennent au métier, et elles prennent du temps parce qu’elles engagent.

Le nombre de profils utilisateurs. Une application avec un seul type d’utilisateur va vite. Dès qu’il y a un back-office, des rôles, des délégations et des règles de visibilité, le travail de conception se démultiplie — parce qu’il faut penser chaque écran autant de fois qu’il y a de profils.

La contrainte réglementaire. Données de santé, données bancaires, marchés publics : ce n’est pas plus difficile techniquement, mais cela ajoute des étapes de validation qui ne se compressent pas.

Comment raccourcir sans casser

On peut légitimement vouloir aller plus vite. Il y a de bonnes et de mauvaises façons.

Ce qui marche : réduire le périmètre fonctionnel. Sortir une version qui traite le cas principal et laisse les cas particuliers en traitement manuel, quitte à les automatiser au trimestre suivant. C’est frustrant sur le moment, et c’est presque toujours la bonne décision.

Ce qui marche aussi, et qui est devenu le levier numéro un : désigner un décideur unique côté client, disponible, avec le mandat de trancher. Un projet où chaque question remonte à un comité mensuel perd aujourd’hui plus de temps en attente qu’en développement — au sens strict, pas comme figure de style : le comité mensuel coûte à lui seul un tiers du calendrier.

Ce qui ne marche pas : ajouter des développeurs. Sur une application métier, la connaissance du domaine est le facteur limitant, pas la capacité de frappe. Doubler l’équipe au milieu du projet le ralentit, le temps que les nouveaux comprennent les règles de gestion.

Ce qui ne marche pas davantage : compter sur l’IA pour rattraper un retard. Le gain qu’elle apporte est déjà dans les fourchettes ci-dessus ; il est acquis dès le premier jour, pas mobilisable en renfort au troisième mois. Un projet en retard l’est sur des décisions, et aucun modèle ne décidera à votre place ce que devient le dossier ouvert en 2014.

Ce qui ne marche pas non plus : supprimer la recette. C’est la tentation classique quand la date approche. On gagne deux semaines avant la mise en production, et on les repaie au triple dans les six semaines qui suivent, en corrections dans l’urgence et en confiance perdue chez les utilisateurs.

Photo : energepic.com — licence CC0.

Photo : Startup Stock Photos — licence CC0.

Ce que je réponds vraiment, en atelier

Quand on me pose la question au premier rendez-vous, je réponds désormais ceci : « Donnez-moi une semaine de cadrage et je vous donnerai une date que je tiendrai. »

Ce n’est pas une esquive. Un délai annoncé avant le cadrage est une estimation faite sans information — elle sera fausse, et tout le monde le sait, y compris celui qui l’annonce. Un délai annoncé après cadrage engage.

J’ajoute maintenant une seconde phrase, qui n’était pas nécessaire avant : « et dites-moi qui tranche. » Sur un projet de deux mois, la disponibilité du décideur pèse plus lourd sur la date que n’importe quel choix technique.

« Une application en trois semaines grâce à l’IA »

Vous verrez passer cette promesse, et elle sera parfois tenue — sur une application à un seul profil d’utilisateur, sans interface avec l’existant et sans reprise de données. C’est un vrai cas, il n’est simplement pas le vôtre si vous lisez cet article.

La question à poser n’est pas « combien de temps » mais « sur quelle phase le gain est-il réalisé ». Si la réponse est « la construction », elle est crédible : c’est là que le gain existe. Si la promesse de trois semaines couvre aussi le cadrage, la recette et la reprise de données, ce n’est pas de l’accélération — c’est du périmètre qu’on ne vous a pas encore dit qu’on allait retirer.

En résumé

Phase	Durée	Livrable
Cadrage	1 à 2 semaines	Backlog priorisé et chiffré
Conception	1 à 3 semaines	Maquettes, modèle de données, architecture
Construction	2 à 6 semaines, par sprints de 2 semaines	Incrément démontrable toutes les 2 semaines
Mise en production	1 à 2 semaines	Recette, reprise de données, plan de bascule
RUN	En continu	Supervision, correctif, évolutif

Un à trois mois pour une première version en production, c’est ce que nous constatons aujourd’hui sur un périmètre maîtrisé. En dessous, méfiez-vous du périmètre annoncé. Au-dessus, demandez ce qui justifie l’écart — il y a toujours une raison, et elle est désormais encore plus rarement technique.