Utilisez un modèle de spécification d'une page pour transformer une idée floue en prompts clairs pour Planning Mode : utilisateurs, jobs-to-be-done, entités et cas limites.
Une idée floue va pour rêver. Elle est problématique pour construire.
Quand vous demandez à un constructeur IA « une application pour suivre des habitudes » sans plus de détails, il doit deviner ce que vous entendez. Ces suppositions changent d'un prompt à l'autre, donc l'app change aussi. Vous vous retrouvez avec des écrans incohérents, des données qui se voient renommer en cours de route, et des fonctionnalités qui apparaissent, disparaissent, puis réapparaissent sous une forme différente.
Cette incohérence se manifeste généralement à quelques endroits :
Le « Planning Mode » est une simple pause avant de construire. Vous notez les décisions que l'IA inventerait autrement. Le but est la cohérence : un ensemble de choix que l'UI, le backend et la base de données suivent.
L'objectif n'est pas la perfection. C'est une construction que vous pouvez itérer sans colmater sans cesse un tas d'hypothèses. Si vous changez d'avis plus tard, vous mettez à jour une petite spec et vous reconstruisez avec la même logique.
C'est pourquoi un modèle de spécification d'une page est important. Ce n'est pas un long PRD et ce n'est pas des semaines de diagrammes. C'est une page qui répond à quatre choses : qui sont les utilisateurs, ce qu'ils cherchent à accomplir, quelles données existent (en langage courant), et quels cas limites ou non‑objectifs empêchent la première version d'exploser.
Exemple : « Une appli de réservation » devient beaucoup plus claire quand vous décidez si elle s'adresse à un propriétaire unique de salon ou à une place de marché, et si les clients peuvent reprogrammer, annuler ou ne pas se présenter.
Un modèle de spécification d'une page est une note courte qui transforme une idée floue en instructions claires. Vous ne « concevez pas tout le produit ». Vous donnez à votre constructeur IA suffisamment de structure pour faire les mêmes choix à chaque fois.
La page comporte quatre blocs. Si vous ne pouvez pas tout tenir sur une page, vous avez probablement trop de fonctionnalités pour un premier build.
Une page impose des contraintes utiles. Elle vous pousse à choisir un utilisateur principal, définir le flux minimal qui marche, et éviter des promesses vagues comme « tout supporter ». Ces contraintes empêchent l'app construite par l'IA de changer d'avis entre les écrans.
Le niveau de détail « suffisant » ressemble à des énoncés simples et testables. Si quelqu'un peut lire et demander « Comment sait‑on que ça marche ? », vous êtes au bon niveau.
Un repère rapide :
Gardez le langage simple. Écrivez des lignes que vous pouvez coller directement dans des prompts, comme « Un manager peut approuver ou rejeter une demande, et le demandeur reçoit une mise à jour de statut. »
Mettez un minuteur à 20 minutes et visez « suffisamment clair pour construire », pas « parfait ». Le but est de supprimer les conjectures pour que votre constructeur IA fasse les mêmes choix à chaque fois.
Commencez par une phrase unique qui répond : pour qui, et quel résultat obtiennent-ils ?
Exemple : « Une appli mobile pour propriétaires de chiens pour suivre promenades et visites chez le vétérinaire en un seul endroit. »
Si vous ne pouvez pas le dire en une phrase, l'idée est probablement deux applications.
Ensuite, nommez 1 à 3 types d'utilisateurs comme des personnes réelles, pas des rôles abstraits. « Owner, Vet, Family member » vaut mieux que « User A ». Pour chacun, ajoutez une ligne courte sur ce qui l'intéresse le plus.
Puis écrivez 3 à 7 jobs-to-be-done au format : « Quand [situation], je veux [action], pour [résultat]. » Restez testable. « Quand je finis une promenade, je veux enregistrer la distance et des notes, pour repérer des tendances » est plus clair que « suivre la santé ».
Maintenant définissez vos entités et champs clés sans parler base de données. Pensez « choses que l'app se rappelle ». Pour l'appli chien : Dog (nom, âge), Walk (date, durée, notes), Visit (date, clinique, coût). Si un champ n'est pas utilisé dans un écran ou un job, laissez‑le de côté.
Terminez par deux blocs courts : cas limites et non‑objectifs. Les cas limites sont ennuyeux mais courants (« pas d'internet », « deux chiens avec le même nom »). Les non‑objectifs sont ce que vous ne ferez pas encore (« pas de paiements », « pas de fil social »).
Enfin, convertissez chaque bloc en prompts que votre constructeur peut suivre. Garder la structure (but, utilisateurs, jobs, entités, cas limites) aide le système à générer écrans, données et flux cohérents.
Si votre spec dit « pour tout le monde », un constructeur IA doit deviner quoi faire en premier. Dans une spec d'une page, définissez les utilisateurs par intention (ce qu'ils viennent faire), pas par démographie. L'intention conduit à des choix clairs sur les écrans, les données et les permissions.
Nommez 2–4 types d'utilisateurs, chacun avec un objectif principal unique. Bons exemples : « Client passant une commande », « Membre d'équipe traitant des commandes », « Manager regardant la performance ». Exemples vagues : « 18–35 », « professionnels occupés », ou « admins » (sauf si vous dites quoi ils administrent).
Utilisez la même structure de phrase à chaque fois : « Quand..., je veux..., pour... ». Cela garde l'app centrée sur les résultats et donne à l'IA des exigences stables et testables.
Voici des exemples réalistes avec un « fini » clairement défini :
Les critères de réussite comptent parce qu'ils retirent l'ambiguïté « ça a l'air bien ». Ils disent au constructeur ce que l'UI doit permettre et ce que le backend doit stocker.
N'écrivez pas un plan de sécurité complet. Indiquez juste qui peut faire quoi, en langage simple.
Exemple : « Les membres peuvent créer et éditer leurs objets. Les managers peuvent éditer n'importe quel objet et changer le statut. Les owners peuvent gérer les utilisateurs et la facturation. »
Si vous utilisez un pas de planification dans un outil comme Koder.ai, ces types d'utilisateurs, lignes JTBD et permissions deviennent des entrées fiables. Ils empêchent aussi l'IA d'inventer des rôles supplémentaires ou de mélanger les responsabilités entre écrans.
Les entités sont les « choses » que votre app garde en mémoire. Si vous les nommez clairement, votre constructeur IA peut créer des écrans, des formulaires et une base cohérente. C'est ce qui évite des champs dépareillés et des fonctionnalités aléatoires.
Commencez par lister vos noms principaux. Si l'app gère « des projets », vos noms pourraient être Project, Task, Comment. Si c'est « réserver des coupes de cheveux », vous aurez Booking, Service, Customer, Staff.
Pour chaque entité, écrivez les champs en mots courants, pas en termes de base de données. Imaginez ce qu'une personne taperait dans un formulaire.
Si vous ne pouvez pas expliquer un champ en une phrase, il est probablement trop détaillé pour la première version.
Décrivez comment les entités se connectent avec des phrases simples :
« Un utilisateur peut avoir plusieurs projets. » « Chaque tâche appartient à un projet. » « Un commentaire appartient à une tâche et a un auteur. »
Cela donne au constructeur assez de structure pour générer des listes cohérentes, des pages de détail et des filtres.
Ajoutez quelques règles de données pour éviter des comportements désordonnés :
Enfin, réduisez le périmètre en nommant ce que vous n'allez pas stocker encore. Exemple : « Pas de pièces jointes en v1 », ou « Ne pas suivre les plannings du staff, seulement les réservations. » Ces exclusions empêchent l'app de gonfler dans la mauvaise direction.
Un modèle d'une page marche mieux quand la première version a un petit nombre stable d'écrans. Si vous tentez de concevoir tous les écrans possibles, votre constructeur IA va deviner sans cesse, et l'UI dérivera d'une build à l'autre.
Commencez par nommer le minimum d'écrans qui permettent de finir le job principal. Pour la plupart des MVPs, 3 à 6 écrans suffisent :
Ensuite écrivez le chemin heureux comme une courte histoire du début à la fin.
Exemple : « L'utilisateur se connecte, arrive sur la liste, cherche, ouvre un élément, modifie un champ, sauvegarde, et revient à la liste. »
Pour chaque écran, notez les actions clés en langage courant. Évitez les écrans « tout faire ». Choisissez 2 à 4 actions qui comptent le plus, comme créer, éditer, chercher, exporter ou archiver.
Décidez aussi ce qui doit être rapide et ce qui peut être « suffisamment bien ». « Rapide » signifie souvent que la liste s'ouvre vite, la recherche répond vite, et la sauvegarde paraît instantanée. « Suffisamment bien » peut être une exportation de quelques secondes, des analytics basiques, ou des paramètres épurés.
Enfin, capturez les rôles et l'accès en une ligne par rôle :
Ceci rend les écrans prévisibles, évite les surprises de permissions et réduit les réécritures.
La plupart des réécritures arrivent pour une raison : l'app marche sur le chemin heureux, puis casse quand la vraie vie arrive.
Une bonne spec d'une page fait de la place pour les cas limites et les non‑objectifs, et ce petit espace économise des heures.
Commencez avec chaque job-to-be-done et demandez : qu'est‑ce qui peut mal tourner ? Restez simple, pas technique. Vous retirez l'ambiguïté pour que le constructeur prenne la même décision à chaque fois.
Cas limites courants à noter :
Puis décidez de la réponse. Soyez spécifique : « Bloquer l'action et afficher un message clair », « Autoriser en tant que brouillon », ou « Réessayer une fois, puis afficher un bouton pour retenter. » Ces règles se traduisent directement en prompts cohérents.
Ajoutez des attentes de confidentialité et de sécurité en une ou deux lignes. Par exemple : « Collecter le minimum de données nécessaires », « Les utilisateurs peuvent supprimer leur compte et toutes leurs données personnelles », « Cacher les éléments privés par défaut ». Si votre app implique du contenu généré par les utilisateurs, notez quoi faire avec les signalements et le spam, même si c'est simple en v1.
Enfin, écrivez des non‑objectifs pour stopper l'extension du périmètre.
Exemples clairs de non‑objectifs :
Un exemple rapide : si le job est « Créer un événement », définissez ce qui se passe quand la date est passée, quand le titre est vide, ou quand le même événement est créé deux fois. Cette clarté empêche la prochaine réécriture.
La façon la plus rapide d'obtenir des résultats cohérents est de transformer chaque bloc de votre spec en un prompt concis et direct. Pensez‑y comme donner au constructeur un jeu de cartes qu'il suit dans l'ordre, au lieu d'une grosse demande floue.
Convertissez chaque bloc (Users, Jobs, Entities, Screens, Edge cases, Non‑goals) en une instruction avec des noms et verbes clairs. Évitez les opinions comme « faire propre » à moins d'expliquer ce que « propre » signifie.
Utilisez un cycle en deux étapes : construire d'abord, puis valider contre la spec.
Ajoutez une courte définition de fini pour que le constructeur sache quand s'arrêter. Gardez‑la mesurable :
N'ajoutez des contraintes que si elles importent vraiment : appareils requis (mobile‑first), auth requise (actions admin uniquement), ou stack requise (React frontend, Go backend, PostgreSQL) si votre plate‑forme l'attend.
Quand vous voulez des modifications, référez‑vous au bloc de la spec, pas au code.
Exemple : « Mettez à jour le bloc Entities : ajoutez ‘Subscription’ avec les champs X et Y. Puis régénérez seulement les APIs et écrans affectés, et relancez la validation. »
Cette approche maintient le plan stable tout en permettant d'itérer en sécurité.
Imaginez que vous voulez un simple suivi de rappels de rendez‑vous pour un petit salon. Le but n'est pas un système complet de réservation. C'est un endroit léger pour stocker des rendez‑vous et envoyer des rappels.
Voici à quoi ressemble une spec d'une page remplie.
APP: Appointment Reminder Tracker
GOAL: Track appointments and send reminders. No payments, no online booking.
USERS
1) Owner/Staff: creates and manages appointments, wants fewer no-shows.
2) Client: receives reminders, wants an easy way to confirm.
JOBS TO BE DONE (JTBD)
1) As staff, I add an appointment in under 30 seconds.
2) As staff, I see today's schedule in time order.
3) As staff, I mark a client as confirmed or no-show.
4) As staff, I resend a reminder when asked.
5) As a client, I confirm from a message without creating an account.
ENTITIES (DATA)
- Client: id, name, phone, email (optional), notes
- Appointment: id, client_id, service, start_time, duration_min, status (scheduled/confirmed/canceled/no_show)
- Reminder: id, appointment_id, channel (sms/email), send_at, sent_at, result (ok/failed)
- StaffUser: id, name, role (owner/staff)
Relationships: Client 1-to-many Appointment. Appointment 1-to-many Reminder.
EDGE CASES (WHAT BREAKS NAIVE BUILDS)
1) Duplicate client (same phone, different name)
2) Overlapping appointments for the same staff
3) Time zone changes (travel, daylight saving)
4) Client has no email, SMS only
5) Reminder send fails, needs retry and visible status
6) Appointment edited after reminder scheduled
7) Client cancels after confirmation
8) Same-day appointment created 10 minutes before start
9) Phone number format varies (+1, spaces, dashes)
10) Deleting a client with future appointments
Ne le traduisez pas dans les prompts ci‑dessous : gardez-le tel quel si vous le collez dans un outil qui attend ce format.
Maintenant transformez‑le en un bundle de prompts que vous pouvez coller dans Planning Mode.
PLANNING MODE PROMPT BUNDLE
1) Build an MVP web app with these entities and relationships exactly as written.
2) Required screens: Login (StaffUser), Today Schedule, Client List, Client Detail, Appointment Create/Edit.
3) Required flows: create client, create appointment for a client, confirm/cancel/no-show, schedule reminders, resend reminder.
4) Constraints: no payments, no public booking page, no client accounts.
5) Edge-case handling: implement validation and UI feedback for all 10 edge cases listed.
6) Output: database schema, API endpoints, and UI behavior notes per screen.
Les sorties désordonnées commencent souvent par une spec floue et une liste de souhaits. Un constructeur IA fait ce que vous demandez, mais il ne lit pas dans vos pensées. De petites lacunes deviennent de grandes différences entre écrans et flux.
Ces pièges cassent la cohérence le plus souvent, et la spec d'une page les corrige :
Si vous utilisez Planning Mode dans Koder.ai, ces bases comptent encore plus car le plan devient la source des prompts répétés. Des jobs clairs, un petit modèle de données, des permissions explicites et des règles de succès testables maintiennent chaque nouvel écran aligné sur le reste.
Avant de lancer la génération, faites une passe rapide sur votre spec d'une page. Le but est de boucher les trous qui forcent l'IA à deviner. Ces devinettes se transforment en réécritures.
Voici un contrôle de complétude :
Si vous voulez une idée de scoring simple, notez chaque domaine de 0 à 2 :
Visez au moins 7/10 avant de générer quoi que ce soit. Si Entities ou Edge cases sont en dessous de 2, corrigez‑les d'abord. Ce sont eux qui causent le plus de retours.
Après le premier build, testez l'app contre chaque job-to-be-done et marquez les divergences. Prenez un snapshot avant chaque changement. Si une nouvelle itération empire les choses, revenez en arrière et essayez une modification plus limitée.
Si vous utilisez Koder.ai (koder.ai), Planning Mode est un endroit pratique pour garder cette spec d'une page comme « source de vérité » et ne régénérer que ce qui a changé au lieu de tout réécrire à la main.
Tenez la spec à jour au fur et à mesure. Quand vous acceptez un changement dans l'app, mettez à jour la spec le jour même. Quand vous rejetez un changement, notez pourquoi, pour que le prochain prompt reste cohérent.
Planning Mode est une courte pause où vous notez les décisions clés avant de générer les écrans et le code. L'objectif est la cohérence : mêmes utilisateurs, mêmes flux et mêmes noms de données dans l'UI, le backend et la base, pour éviter de reconstruire à chaque nouvelle hypothèse.
Commencez par une phrase-objectif, puis remplissez quatre blocs :
Si tout ne tient pas sur une page, réduisez les fonctionnalités pour la v1.
Restez pragmatique et basé sur l'intention. Nommez quelques types d'utilisateurs et ce qu'ils cherchent à accomplir.
Exemple : « Owner/Staff qui crée des rendez‑vous » est plus clair que « Admin ». Si vous ne pouvez pas expliquer ce que fait un rôle en une ligne, il est probablement trop vague.
Utilisez un patron strict pour que chaque job soit testable :
Ajoutez ensuite une définition de « fini » (ce qui doit être sauvegardé/mis à jour/visible). Cela empêche le générateur d'inventer des étapes ou des écrans supplémentaires.
Listez les « choses que l'app se souvient » en langage courant, puis donnez à chacune 3–7 champs utiles à l'écran.
Exemple : Appointment : heure de début, durée, statut, service, client. Si un champ n'est pas utilisé par un job ou un écran, laissez-le de côté pour la v1.
Exprimez les relations en phrases simples :
Ajoutez quelques règles de données de base (champs requis, champs uniques, valeurs par défaut). C'est généralement suffisant pour garder listes, formulaires et filtres cohérents.
Par défaut, 3 à 6 écrans suffisent pour compléter le travail principal :
Écrivez aussi un « chemin heureux » (start → action → sauvegarde → confirmation) pour éviter la dérive des flux.
Les edge cases cassent souvent les builds naïves. Notez les 5–10 cas les plus probables :
Pour chacun, indiquez le comportement attendu (bloquer + message, sauvegarde en brouillon, retry, etc.).
Transformez chaque bloc en une instruction courte que le générateur peut exécuter et vérifier.
Séquence simple :
Évitez un énorme prompt flou ; préférez des instructions précises et réutilisables.
Mettez d'abord la spec à jour, puis régénérez seulement ce qui a changé.
Exemple : « Ajouter une entité Subscription avec les champs X/Y ; régénérer les APIs et écrans concernés ; relancer la validation. »
Garder la spec comme source de vérité évite des modifications dispersées et incohérentes.