C'est l'objection qui empêche le plus de gens de commencer, et elle repose sur une hypothèse fausse : que la description partirait directement en code, sans retour possible. Ce n'est pas le déroulé. Votre description produit d'abord un PLAN — la liste des données, des écrans et de leur type — qui vous est montré et que vous corrigez AVANT qu'une seule ligne de code existe : renommer une entité, changer le nom d'un champ, ajouter ou retirer une valeur de statut, et même changer le type d'un écran. À ce stade, se tromper ne coûte rien. Après la génération, une modification reste possible en décrivant le changement en français, mais elle reconstruit l'application et la revalide : c'est un geste plus lourd, pas un ajustement.
L'erreur qu'on redoute n'est pas celle qui arrive
La crainte est de rendre une description imprécise et de recevoir un outil à côté du sujet, sans recours. Dans les projets classiques, cette peur est fondée : le cahier des charges part chez un prestataire, le premier écran arrive des semaines plus tard, et l'écart se paie en jours de développement. C'est ce délai — pas la difficulté d'écrire — qui rend l'exercice angoissant.
La littérature sur l'expression de besoin dit d'ailleurs la même chose sous un autre angle : la difficulté n'est pas de rédiger, c'est de savoir ce qu'on veut avant d'avoir vu quelque chose. On ne devine pas ses propres usages ; on les reconnaît quand on les voit posés.
Le plan est montré avant le code, et il se corrige
Entre votre description et l'application, il y a une étape intermédiaire : un plan. Il liste les données que l'outil va gérer, leurs champs, et les écrans avec le TYPE de chacun — un tableau, un agenda, un tableau de bord, une carte. Ce plan s'affiche et s'édite.
Concrètement, à ce moment-là vous pouvez renommer une donnée et son libellé, corriger les champs qu'elle porte, ajouter ou retirer une valeur dans une liste de statuts (« En attente », « Validé », « Annulé »), renommer un écran, changer son icône — et changer sa nature : une liste qui aurait dû être un agenda se corrige ici, en une fois.
C'est le moment qui rend l'objection caduque. Une description approximative n'engage rien : elle produit une proposition que vous relisez, et corriger un mot dans le plan revient exactement au même que l'avoir écrit juste du premier coup.
Après la génération : possible, mais ce n'est plus le même geste
Une fois l'application produite, un changement se demande toujours en français — « ajoute un champ pour la date de relance », « sépare les devis des factures ». La différence est ailleurs : cette demande régénère le plan, reconstruit l'application et la repasse par la validation automatique avant de la remettre en service. C'est fiable, ce n'est pas instantané.
D'où le seul conseil pratique de cette page : la relecture du plan mérite cinq minutes d'attention réelle. Ce sont les cinq minutes les moins chères du projet.
Ce qu'il vaut mieux savoir avant de modifier une application déjà en service
Deux points ne se devinent pas, et il vaut mieux les poser avant de lancer une modification sur un outil qui contient déjà vos données réelles.
Le premier : ce que deviennent les données déjà saisies quand la structure change (un champ retiré, une donnée scindée en deux). Je ne l'affirme pas ici — c'est une question à poser explicitement avant de modifier une application en production, ici comme chez n'importe quel éditeur.
Le second : il n'existe pas de bouton « revenir à la version d'avant ». Le retour arrière se prépare, il ne s'improvise pas — d'où l'intérêt d'exporter vos données avant un changement de structure, ce que l'écran Paramètres permet en CSV et en JSON.