Quatre mois : c’est court pour construire un produit et long pour attendre une réponse. Voici comment ce calendrier se remplit, semaine par semaine, et à quels moments tombent les décisions.

Avant de signer un projet d’application métier, on nous demande rarement ce que nous allons construire. On nous demande ce qui va se passer pendant ces quatre mois, et ce que le client aura à faire. Voici la réponse, sans jargon de méthode.

Semaines 1 et 2 : écrire la question à trancher

Un projet qui démarre par une liste de fonctionnalités a déjà pris son premier virage au mauvais endroit. La liste répond à « que voulons-nous construire », alors que la seule question qui compte à ce stade est « qu’est-ce que nous ne savons pas encore ».

Ces deux premières semaines servent donc à écrire une phrase, toujours de la même forme : des gens comme X vont-ils faire Y assez souvent pour que Z devienne viable ? Tant que cette phrase n’a pas de vrais noms, un vrai comportement et un vrai seuil, elle n’est pas finie.

C’est la partie la plus inconfortable du projet. Elle oblige à admettre que certaines fonctionnalités auxquelles on tient ne servent pas la démonstration, donc qu’elles attendront. À la fin, deux listes existent : ce qui sera construit, et ce qui ne le sera pas. La seconde est celle qui protège le calendrier.

Semaines 3 à 6 : un objet manipulable, même laid

Cette phase sert à rendre l’idée critiquable. Tant qu’un produit n’existe que dans une conversation, tout le monde est d’accord, parce que chacun se représente une chose différente.

Nous sortons donc rapidement un parcours cliquable sur les écrans qui portent l’enjeu. Il ne fait pas tout, il n’est pas beau, et c’est volontaire. Ce qu’on cherche à provoquer, ce sont les phrases du type « ah, mais je pensais que ». Chacune vaut une semaine gagnée plus tard.

Pour cette étape de prototypage, nous détaillons les générateurs assistés par IA dans notre comparatif Bolt ou Lovable.

C’est aussi le moment où l’on tranche la plateforme, une fois que le périmètre est connu et pas avant. Le critère est l’usage réel : un outil manipulé assis devant un écran ne vit pas au même endroit qu’un outil sorti de la poche sur un chantier. Nous détaillons cet arbitrage sur la page développement d’applications.

Semaines 7 à 14 : construire, par cycles de quinze jours

C’est la phase la plus longue et la plus calme. Elle se déroule par cycles de deux semaines, avec quelque chose de manipulable à la fin de chacun.

Ce rythme protège le projet. Un projet qui ne montre rien pendant deux mois n’a aucun moyen de savoir qu’il dérive, et découvre l’écart au moment où il coûte le plus cher à corriger. Le corollaire est que vous verrez tôt des versions imparfaites : c’est le fonctionnement normal, pas un signal d’alarme.

Trois choses se jouent ici sans se voir à l’écran : le modèle de données, qu’on ne corrige plus sans tout reprendre une fois le produit en service ; les droits d’accès, vérifiés là où la donnée est lue ; et les noms donnés aux choses, que la personne qui reprendra le produit doit pouvoir comprendre.

Semaines 15 à 17 : entre de vraies mains

La mise en ligne ouvre la phase de mesure. Les dernières semaines servent à mettre le produit devant des utilisateurs qui ne vous doivent rien, et à les regarder faire sans les aider.

L’exercice est inconfortable pour tout le monde, et c’est celui qui apprend le plus : si la plupart des testeurs ne trouvent pas un bouton, plus personne ne discute de sa couleur.

En parallèle se fait le transfert : la prise en main par votre équipe, la documentation de ce que fait chaque partie, et la désignation de la personne qui portera le produit après nous.

Les trois décisions qui tombent toujours au même moment

  • Fin de semaine 2 : que coupe-t-on ? C’est la décision qui détermine si le délai tiendra. Elle se prend une fois, par écrit, et se rouvre seulement avec le délai.
  • Fin de semaine 6 : le parcours est-il le bon ? C’est le dernier moment où changer d’avis coûte des jours plutôt que des semaines.
  • Fin de semaine 14 : qui teste, concrètement ? Cette décision se prépare dès le départ, parce que mobiliser dix utilisateurs réels prend plus de temps qu’on ne le croit.

Ce qui fait glisser le calendrier

Trois causes reviennent, et aucune n’est technique.

Une décision reportée à une réunion que personne ne planifie. Un projet qui attend deux semaines a perdu deux semaines, quel que soit le rythme de construction.

Un périmètre qui s’élargit alors que le délai, lui, ne bouge pas. Chaque idée nouvelle est raisonnable prise isolément ; ensemble elles épuisent le budget avant la mise en ligne.

Des utilisateurs de test qu’on n’arrive jamais à mobiliser, si bien que le produit finit par se juger sur des avis internes. C’est la façon la plus discrète de rater une première version : il est livré à l’heure et il n’a rien démontré.

Ce qu’on ne met jamais dans une première version

La liste de ce qu’on coupe est plus instructive que celle de ce qu’on construit, parce que les mêmes éléments reviennent d’un projet à l’autre.

Les réglages. Un écran de paramètres suppose qu’on sait déjà ce que les utilisateurs voudront modifier. À ce stade, on ne le sait pas. Une valeur fixée en dur, que l’on change soi-même quand quelqu’un le demande, apprend davantage et coûte cent fois moins.

Les rôles multiples. Un produit qui distingue cinq profils d’utilisateurs multiplie les parcours à concevoir, à construire et à tester, avant même de savoir si l’un d’eux tient debout. On démarre avec un rôle, éventuellement deux quand la relation entre les deux est le sujet même du produit.

Les tableaux de bord. Ils sont demandés très tôt et servent très tard. Tant qu’il n’y a pas de volume, on lit les données à la main en trois minutes, et cette lecture manuelle apprend des choses qu’un graphique aurait masquées.

Le paiement, souvent. C’est le point qui surprend le plus. Accepter de payer et accepter de payer ce prix-là sont deux questions distinctes, et la seconde ne se teste pas sur dix utilisateurs issus de votre réseau. Encaisser à la main les premiers clients renseigne mieux qu’un tunnel de paiement construit à l’avance.

Aucun de ces éléments n’est écarté définitivement. Ils entrent dans le lot suivant, qui se décide avec les données du premier plutôt qu’avec les hypothèses du départ.

Avant les quatre mois : passer d’une idée à quelque chose de constructible

Le calendrier décrit plus haut commence le jour où le projet est décidé. La question qui précède est celle que l’on nous pose le plus souvent, et elle n’a rien de technique : comment savoir si l’idée tient avant d’engager quatre mois.

Trois vérifications, et elles se font en quelques jours, pas en quelques semaines.

Nommer la personne qui souffre. Pas un segment, une personne, avec son métier et sa journée. Une idée qui ne peut pas désigner qui perd du temps aujourd’hui, et combien, n’est pas prête. Il manque du cadrage, et cela se corrige en allant parler à trois personnes concernées.

Décrire ce qui se passe aujourd’hui sans l’outil. Toute tâche que vous voulez outiller est déjà faite, autrement : dans un tableur, par courriel, à la main. Si personne ne sait décrire ce contournement, c’est que le besoin n’est pas encore ressenti, et un outil ne crée pas un besoin.

Écrire la première version en une phrase. Si elle en demande trois, le périmètre est trop large pour une première version. Cette phrase devient le critère qui tranchera toutes les demandes d’ajout des quatre mois suivants, et c’est à ce titre qu’elle vaut le temps qu’on y passe.

Ces trois vérifications ne demandent aucun budget de développement. Elles évitent le cas le plus coûteux que nous voyons arriver : un outil bien construit, livré dans les temps, et que personne n’utilise parce qu’il résout un problème que personne n’avait.

Ce que vous obtenez au bout des quatre mois

Un produit en ligne, utilisé par de vraies personnes avec de vraies données. Une réponse à la question écrite en semaine 1, qui peut très bien être négative. Un modèle de données validé par l’usage, des parcours éprouvés et des règles métier écrites.

Ce dernier point est celui qu’on sous-estime. Le code vous revient avec le reste du projet ; mais si le produit décolle et qu’il faut un jour le faire évoluer en profondeur, c’est cette connaissance qui fait gagner le plus de temps. Une équipe technique qui démarre avec elle ne construit pas la même chose qu’une équipe qui démarre avec un cahier des charges. C’est là que la première version prend sa valeur économique réelle, en réduisant le risque plutôt qu’en remplaçant le développement.

Si l’idée doit d’abord être testée sur de vrais utilisateurs, voyez nos MVP et POC IA.