J'ai vu trois personnes différentes mal gérer le même écran de trente secondes — la carte de plan qui apparaît entre votre requête et la construction — et chacune l'a payé d'une monnaie différente. L'une l'a payé par une reconstruction. Une autre par du temps de frappe gaspillé. Une troisième par un produit incapable de faire ce dont elle avait réellement besoin. La carte de plan est le moment le moins cher de tout le processus pour changer d'avis, et c'est précisément ce qui la rend si facile à survoler.
Erreur numéro un : valider sans regarder
C'est l'erreur classique. Le squelette semble correct, on clique sur valider, on passe à autre chose — j'ai fait ça pendant des semaines avant que ça ne me retombe dessus. Le build qui a finalement fait cesser cette habitude est revenu avec un paiement Stripe câblé sur un site statique qui n'avait nulle part où stocker l'état de compte dont Stripe avait besoin. Le plan indiquait pourtant type de produit : site statique en clair, juste là sur la carte, et j'étais passé outre parce que la liste des pages semblait correcte et que j'étais pressé.
Les dégâts de cette erreur ont toujours la même forme : tout ce qui découle du plan est correct compte tenu du plan, donc l'échec ne se manifeste pas comme une erreur, il se manifeste comme un build qui fonctionne mais qui est structurellement faux. Personne ne le signale car rien n'est cassé — un site statique avec un bouton de paiement fait simplement la mauvaise chose silencieusement, ou échoue au moment précis où un vrai utilisateur clique sur « payer ». On s'en rend compte en revue, c'est-à-dire l'endroit le plus coûteux pour le découvrir.
Erreur numéro deux : sur-spécifier pour éviter un deuxième aller-retour
L'erreur inverse paraît plus responsable, mais ne l'est pas. Certains, échaudés par la première erreur, réagissent en écrivant un paragraphe d'exigences précises dès l'étape du plan — texte exact, préférences d'espacement, quelles fonctionnalités doivent absolument exister ou non, formulé comme un cahier des charges. J'ai fait ça aussi, par une vague anxiété à l'idée que sauter des détails maintenant signifierait « gaspiller » un cycle de build plus tard.
C'est contre-productif, et voici pourquoi : le plan va de toute façon être révisé une fois que vous verrez les vraies pages, quel que soit le soin apporté la première fois. Et quand il est révisé, vous n'obtenez pas un différentiel de ce qui a changé — vous obtenez une carte toute neuve qui intègre déjà votre modification, un point c'est tout, sans notes de version. Donc la précision que vous avez tapée au premier tour ne survit pas intacte au deuxième de toute façon ; vous relisez tout dans les deux cas. Deux ou trois tours de « non, plutôt comme ça » vous mènent à un meilleur résultat, plus vite en temps réel, qu'un brief exhaustif — même si rédiger le brief donne l'impression d'être plus efficace sur le moment.
Les modifications en langage courant qui fonctionnent vraiment sont courtes :
- « Retire le blog, ajoute une page tarifs » — remplace proprement la liste des pages.
- « Fais-en un jeu à deux joueurs plutôt qu'un seul » — plus important que ça n'en a l'air. Cela peut affecter le modèle de données, qui suit désormais deux participants au lieu d'un, et le plan révisé montrera cette répercussion plutôt que de la masquer.
- « Il faut des comptes utilisateurs » — si le plan actuel est un site statique, c'est la phrase qui force carrément la question du type de produit.
Erreur numéro trois : traiter le type de produit comme un champ secondaire
C'est l'erreur coûteuse, et elle est coûteuse parce que tout le reste sur la carte est réellement récupérable. Les pages, les fonctionnalités déduites, la plupart des embranchements de questions — tout cela est réparable via une itération de version une fois le build livré. Le type de produit ne l'est pas. Il existe quatre catégories :
| Type de produit | Ce que cela signifie |
|---|---|
| Site statique | Simple, sans logique serveur. |
| Application installable | De type PWA — fonctionne hors ligne, peut être ajoutée à l'écran d'accueil, toujours sans logique serveur. |
| Build framework | De type React/Next, interactivité côté client plus poussée, toujours sans backend persistant. |
| Application avec backend | La seule des quatre catégories avec une véritable base de données et un système de comptes derrière. |
Valider un plan de site statique, puis décider trois versions plus tard que vous voulez une connexion utilisateur, ce n'est pas une simple mise à jour de version — c'est une reconstruction depuis un type de produit différent, et vous perdez la continuité que l'historique des versions vous offrait pour tout le reste.
Les gens se trompent de deux façons. D'abord, ils ne vérifient pas leur propre requête par rapport au champ — si votre requête contient « comptes », « connexion », « sauvegarder », « tableau de bord qui se met à jour », « paiements », ou « plusieurs utilisateurs modifiant la même chose », et que la carte n'indique pas « avec serveur », c'est la seule modification qui vaille la peine d'être faite avant de valider, sans exception. Ensuite, ils confondent application installable et build framework, car les deux ressemblent à « une application » dans une conversation informelle. Ce ne sont pas des équivalents : une application installable convient à un outil dont tout l'état réside sur l'appareil de l'utilisateur — un calculateur de pourboire, un minuteur d'entraînement. Un build framework signifie plus d'interactivité et une structure en composants, mais toujours rien qui persiste côté serveur d'une session ou d'un appareil à l'autre. Aucun des deux n'est « une application » au sens d'avoir des comptes et des données qui vous suivent d'un appareil à l'autre — seul le type avec serveur l'est. Et surdimensionner « au cas où » vers le type avec serveur pour un site portfolio ou une page de documentation n'est pas non plus le choix prudent ; revenir en arrière plus tard représente autant une reconstruction qu'une montée en gamme.
Ce qui reste une fois qu'on arrête ces trois erreurs
Une fois que vous ne survolez plus la ligne du type de produit, que vous n'écrivez plus un cahier des charges à l'étape du plan, et que vous ne traitez plus le vocabulaire lié aux comptes, aux données ou aux paiements dans votre propre requête comme négociable, il reste une vérification rapide et ciblée :
- Lisez le type de produit.
- Vérifiez-le par rapport à votre requête.
- Parcourez la liste des fonctionnalités déduites pour repérer tout ce que vous rejetteriez au premier coup d'œil.
Cette liste existe précisément parce qu'une requête comme « outil de planification pour salons de coiffure » entraîne des éléments que vous n'avez pas tapés — vue calendrier, rappels SMS, liste de clients, dont certains sont voulus et d'autres relèvent d'une dérive fonctionnelle ajoutée par le modèle parce que ces fonctionnalités vont statistiquement de pair. Élaguez ce qui n'a pas sa place, ici, dans une phrase, plutôt qu'après la construction.
Tout le reste — le texte, l'espacement, la nuance de couleur d'accent, si le bouton dit « Commencer » ou « Essayer gratuitement » — n'apparaît pas du tout sur la carte, volontairement. Ces éléments sont peu coûteux à voir et à corriger sur un build fonctionnel, donc la carte ne gaspille pas votre attention dessus, et vous ne devriez pas non plus. Cela représente environ quinze secondes de jugement réel sur les trente secondes que prend la lecture de la carte.
