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

La question qu’on nous pose avant de signer n’est presque jamais « qu’est-ce que vous allez construire ». C’est « qu’est-ce qui va se passer pendant ces quatre mois, et qu’est-ce que j’ai à faire ». Voici la réponse, sans le vocabulaire de méthode.

Semaines 1 à 3 : écrire la question, pas le cahier des charges

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 trois 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 4 à 7 : un objet manipulable, même laid

L’objectif de cette phase n’est pas de construire vite, c’est de 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.

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

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.

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 8 à 13 : 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 n’est pas une préférence de méthode, c’est une protection. 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, et aucune n’est visible à l’écran. Le modèle de données, parce que c’est le seul élément qu’on ne peut plus corriger sans tout reprendre. Les droits, gérés au niveau de la donnée et non de l’affichage, parce qu’un bouton caché n’est pas une protection. Et la nomenclature, pour que la personne qui reprendra le produit dans un an comprenne ce qu’elle regarde.

Semaines 14 à 16 : entre de vraies mains

La mise en ligne n’est pas la fin du projet, c’est le début de la mesure. Les dernières semaines servent à mettre le produit devant des utilisateurs qui ne vous doivent rien, et à les regarder faire sans les aider.

C’est l’exercice le plus révélateur et le plus désagréable du métier. Il montre en direct ce qu’on avait défendu en réunion. Quand trois personnes sur cinq ne trouvent pas le bouton, la discussion sur sa couleur devient sans objet.

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 3 : 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 7 : 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 13 : 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 qui attend une réunion qui n’est jamais planifiée. Un projet qui attend deux semaines a perdu deux semaines, quel que soit le rythme de construction.

Un périmètre rouvert sans que le délai soit rouvert avec lui. 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.

Ce que vous avez à la fin

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. Si le produit décolle et qu’il faut un jour le redévelopper, ce qui se transfère n’est pas le code : c’est cette connaissance. 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.