Prompts Vibe Coding pour application CRUD : kit full‑stack à copier-coller

Ce que cet ensemble de prompts construit (en clair)

Cet ensemble de prompts est conçu pour générer une application CRUD complète et fonctionnelle : les écrans que les gens utilisent, l'API qui traite les requêtes, et la base de données PostgreSQL qui stocke les données. Il inclut aussi l'authentification et l'accès basé sur les rôles, pour que différents utilisateurs voient et fassent des choses différentes.

CRUD, ce sont quatre actions quotidiennes dont votre application a besoin :

• Create : ajouter un nouvel enregistrement (par exemple un client ou une tâche)
• Read : afficher une liste et ouvrir un élément
• Update : modifier un élément existant
• Delete : supprimer un élément (souvent avec confirmation)

Sur le front end, vous devriez obtenir un ensemble d'écrans prévisibles : une page de liste, une page de détail, un formulaire de création, un formulaire d'édition, plus une page de connexion et une navigation de base. Sur le back end, vous aurez des endpoints qui correspondent à ces écrans (list, get by id, create, update, delete), soutenus par une table Postgres et des validations simples.

La qualité du prompt compte plus que le choix du modèle. Le modèle ne peut suivre que ce que vous spécifiez. Si votre prompt est vague, vous obtiendrez des noms de champs décalés, des routes manquantes, une auth incomplète, ou une UI qui ne correspond pas à l'API. Un prompt précis agit comme un contrat : UI, API et BDD utilisent les mêmes noms et règles.

Avant de commencer, décidez de quelques points pour que la construction reste cohérente :

• Votre entité principale et 6 à 12 champs (noms, types, requis vs optionnel)
• Les rôles (par exemple : admin, manager, viewer) et ce que chaque rôle peut faire
• Règles basiques (qui peut modifier, suppression douce vs suppression définitive, champs requis)
• Les écrans « happy path » dont vous avez besoin le jour 1
• Contraintes éventuelles (champs uniques, plages de dates, valeurs de statut)

Si vous utilisez Koder.ai, cette séquence peut être une seule conversation qui produit une UI React, une API Go et un schéma PostgreSQL qui s'imbriquent sans collage manuel.

Fiche de préparation : les quelques détails nécessaires avant de prompt

Une bonne construction CRUD commence par un petit ensemble de décisions. Notez-les d'abord et vos prompts resteront clairs, vos écrans cohérents et votre API correspondante à la base.

Commencez par une entité centrale. C'est la « chose » que votre app gère quotidiennement (Item, Customer, Appointment). Ajoutez une seconde entité seulement si elle est vraiment nécessaire dès le départ (par exemple, Item a besoin de Category). Si vous commencez avec trois ou quatre, vous passerez la plupart du temps à démêler des relations au lieu d'obtenir une app fonctionnelle.

Écrivez les champs de votre entité avec un type et un exemple. L'exemple compte car il guide les libellés, le formatage et la validation.

• Field: type - example (notes)
• name: text - "Paper towels" (requis, 2-80 chars)
• quantity: number - 24 (min 0)
• reorder_date: date - 2026-02-01 (optionnel)
• status: enum - "in_stock" | "low" | "out" (default in_stock)

Ensuite, listez les rôles et permissions en langage clair. Restez spécifique. Pour beaucoup d'apps, 2 à 3 rôles suffisent :

• Admin : gérer les utilisateurs, CRUD complet sur tous les enregistrements
• Manager : CRUD sur les enregistrements, ne peut pas gérer les utilisateurs
• Viewer : lecture seule

Enfin, créez 5 à 10 enregistrements d'exemple. Ils produisent des libellés UI réalistes, des options de dropdown et des valeurs par défaut sensées. Exemple (inventaire) : “Hand soap, qty 6, reorder_date 2026-01-20, status low”.

Si vous construisez sur Koder.ai, collez cette fiche dans votre premier prompt pour que la plateforme garde l'app cohérente entre écrans, auth et l'API PostgreSQL.

Prompt de base : définir les règles pour toute la construction

Commencez par un seul prompt « règles de conduite ». Il maintient la cohérence entre écrans, API et base de données, et réduit les allers-retours lorsque vous ajoutez des fonctionnalités plus tard.

Demandez un plan court avant tout code. Vous voulez que le modèle nomme les écrans et routes, les tables et les endpoints API. Exigez aussi qu'il indique les hypothèses dès le départ (par ex. quels rôles existent) et qu'il ne change pas ces hypothèses sans votre accord.

Voici un prompt de base à copier-coller :

You are building a complete full-stack CRUD app.

Tech targets (do not change):
- Frontend: React web app
- Backend: Go REST API
- Database: PostgreSQL

Before writing any code, produce a short plan (max 25 lines) that includes:
1) Screens + key UI components
2) Routes/navigation
3) Roles and permissions
4) PostgreSQL tables (with columns and relationships)
5) API endpoints (method + path) for auth and CRUD

Assumptions:
- If any detail is missing, make a reasonable default and list it under “Assumptions”.
- Keep assumptions consistent across UI, API, and DB. If you must change an assumption, stop and ask.

Rules:
- Use simple, boring CRUD first. No “nice to have” features unless asked.
- Include input validation, basic error messages, and loading states.
- Use clear names that match across layers (same field names in UI, API, and DB).

Non-goals (do NOT implement):
- Payments, subscriptions, invoices
- Complex workflows/approvals
- Multi-tenant org hierarchy
- Real-time chat/notifications

Now ask me 5 clarifying questions max. If I answer “default”, proceed with your assumptions.

Un exemple concret : si le plan choisit role: admin|member, il ne devrait pas ensuite inventer manager pour résoudre un cas d'UI. Ce prompt l'oblige à s'arrêter et demander votre approbation au lieu de dériver.

Prompts prêts-à-coller : écrans et navigation

De bons écrans viennent d'abord d'une carte de pages claire. Utilisez les prompts ci-dessous avant de demander le code de la base de données ou de l'API. Cela stabilise les routes et noms d'UI, là où beaucoup de constructions déraillent.

Prompt 1 : liste de pages et flux utilisateurs

You are building a full-stack CRUD app UI. Start by proposing a complete page list and user flows.

App concept (1 sentence): <PASTE YOUR APP CONCEPT>
Entities (list): <ENTITY_1>, <ENTITY_2>
Roles: <ROLE_1>, <ROLE_2> (include an Admin role)

Deliverables:
1) A table of pages with: Route, Page name, Who can access, Primary actions, Empty state behavior.
2) Key user flows (bullets): sign up, sign in, create record, edit, delete, search/filter, admin manages users.
3) Route naming rules: kebab-case paths, consistent singular/plural, no duplicates.
4) Component naming rules: PascalCase, one top-level page component per route.
Ask me 5 questions max only if needed.

Après qu'il ait répondu, verrouillez les noms. Si vous changez les noms de route plus tard, l'API et les tests vont diverger.

Prompt 2 : navigation et formulaires bien conçus

Using the approved page list and route names, generate:

A) Navigation
- A simple top nav for desktop and a compact mobile menu.
- Show which items appear for each role.
- Add a clear "You do not have access" page and redirect rules.

B) Page skeletons
For each page, create a minimal UI with:
- A visible page title and short helper text.
- Loading state, empty state, error state.
- A primary button for the main action.

C) Accessible forms
For all create/edit forms:
- Labels tied to inputs, required markers, inline validation errors.
- Disable submit while saving, show a spinner, prevent double submits.
- Toast or inline success message after save.

D) Consistent action names
Use these verbs exactly: list, view, create, update, delete.
Use these UI actions: onCreate, onUpdate, onDelete, onSearch.

Si l'UI est trop complexe, demandez-lui de garder un seul layout, un seul style de table et un seul pattern de formulaire pour toutes les pages.

Prompts prêts-à-coller : authentification et rôles

Pour obtenir des résultats prévisibles, soyez explicite sur la façon dont les utilisateurs se connectent, la durée des sessions et ce que chaque rôle peut faire. Ces prompts supposent une connexion simple par email + mot de passe et une approche basée sur la session (facile à tester entre écrans et API).

Collez ceci d'abord pour générer login, logout et gestion de session :

Implement authentication for this app.

Requirements:
- Add UI screens: Login, Logout action, and a simple “My account” page that shows the logged-in user email and role.
- Use email + password login.
- Session handling: keep the user logged in across refresh; include a clear “Log out” button.
- API endpoints: POST /auth/login, POST /auth/logout, GET /auth/me.
- Show friendly error messages for wrong password, unknown email, and locked/disabled accounts.

Security (keep it simple):
- Password rules: minimum 12 characters; must include at least 1 letter and 1 number.
- Store passwords securely (hash + salt). Never store plain text.
- Basic protections: rate-limit login attempts per email/IP and return generic error text that doesn’t reveal which part was wrong.

Deliverables:
- Working UI flows + backend endpoints.
- Seed one default admin user for local testing and tell me the credentials.
- Add clear comments explaining where to change password rules and session duration.

Ajoutez ensuite rôles et règles de protection. Gardez les permissions petites et faciles à tester :

Add role-based access control (RBAC) with these roles: admin, manager, viewer.

Rules:
- admin: can create, edit, delete, and manage users/roles.
- manager: can create and edit records, cannot delete, cannot manage users.
- viewer: read-only.

Enforcement:
- Protect both routes (screens) and API endpoints. Do not rely on the UI alone.
- If a user lacks permission, show a “Not allowed” page in the UI and return HTTP 403 from the API.

Deliverables:
- A simple “Users” admin screen to list users and change roles.
- A clear table (in text) mapping each route + API endpoint to required role.
- Add automated checks or middleware so every protected endpoint enforces the rules.

Vérifications manuelles rapides qui attrapent la plupart des erreurs :

• Connectez-vous en tant que chaque rôle et confirmez ce que vous pouvez ou ne pouvez pas voir.
• Essayez une action restreinte (comme delete) et confirmez que vous obtenez 403.
• Confirmez que logout supprime la session et que l'app revient à l'écran Login.

Si vous utilisez Koder.ai, gardez auth et RBAC dans un seul snapshot pour pouvoir revenir en arrière proprement si les permissions se mélangent.

Prompts prêts-à-coller : schéma PostgreSQL et modèle de données

Un bon prompt de schéma fait deux choses : il force des relations de table claires (pour que l'UI et l'API restent compatibles), et il empêche une base “presque correcte” (index manquants, timestamps, mapping des rôles absent).

Avant de coller, décidez de ces deux bascules (une ligne chacune) :

• Primary keys: uuid or bigserial
• Soft delete: yes (use deleted_at) or no (hard delete)

Collez ce prompt d'abord pour verrouiller le modèle de données :

You are building the PostgreSQL data model for a full-stack CRUD app.

Domain: <DESCRIBE YOUR APP IN 1 SENTENCE>
Core entities: <LIST 3-6 ENTITIES>

Rules:
- Use PostgreSQL.
- Choose primary key type: <uuid|bigserial>.
- Timestamps: every table must have created_at and updated_at.
- Soft delete: <yes|no>. If yes, add deleted_at and default queries should ignore deleted rows.
- Define users, roles, and permissions storage:
  - users table (email unique, password_hash, status)
  - roles table (name unique)
  - user_roles join table (user_id, role_id) with unique(user_id, role_id)
- For each core entity: define columns, types, required vs optional, and relationships.
- Call out any many-to-many relationships and introduce join tables.
- Propose indexes for common lookups (foreign keys, email, name/search fields).

Output:
1) A short ERD description in plain English.
2) The final table list with columns and constraints.
3) The index list with rationale.

Puis collez ce prompt pour générer les migrations ou étapes d'initialisation qui correspondent au projet :

Now generate the actual database setup for this project.

Requirements:
- Provide SQL migrations (up and down) for all tables, constraints, and indexes.
- Ensure foreign keys and on-delete behavior are explicit.
- Include extensions you rely on (for example uuid generation), but only if needed.
- Add a seed migration for: one admin user, one admin role, and the user_roles link.

Output:
- migrations/ file names in order
- contents of each up/down migration
- brief notes on how to apply migrations in the project

Si quelque chose est ambigu, ajoutez une ligne : “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”

Prompts prêts-à-coller : API CRUD en Go (backed par Postgres)

Si vos sorties backend reviennent incomplètes, ce prompt force les bases : routes claires, validation, pagination et vérification des rôles dans chaque handler.

Collez ceci tel quel, puis remplacez les placeholders (RESOURCE, FIELDS, ROLES) par vos détails d'app.

You are building the backend API in Go for a Postgres-backed CRUD resource.

Resource
- RESOURCE name (singular/plural): <Item/items>
- Table: <items>
- Primary key: <id UUID>
- Fields (name, type, required?, rules):
  - <name TEXT required, 2..80 chars>
  - <qty INT required, min 0>
  - <status TEXT optional, one of: active, archived>
- Ownership: <tenant_id UUID required> and <created_by UUID required>

Auth and roles
- Roles: <admin, manager, viewer>
- Authorization rules:
  - Every endpoint must check role and tenant_id.
  - admin: full access
  - manager: create, read, update, list; cannot delete
  - viewer: read and list only

API requirements
1) Implement REST endpoints:
- POST /api/items
- GET /api/items/{id}
- PUT /api/items/{id}
- DELETE /api/items/{id}
- GET /api/items

2) Define request/response JSON shapes for each endpoint, including examples.

3) Validation
- Return 400 with field-level errors (clear messages) when invalid.
- Return 401 if no auth, 403 if role not allowed, 404 if not found in tenant.

4) List endpoint
- Support filtering by: <status>
- Support sorting by: <created_at,name> with order asc/desc
- Support pagination: page, page_size; return total, page, page_size, items.

5) Data access
- Use database/sql (or pgx) with parameterized queries only.
- Include migrations SQL for the table and indexes (tenant_id + created_at).

Deliverables
- Go code: routes, handlers, DTOs, validation helpers, repository layer
- SQL: migration(s)
- Notes: any assumptions

Après génération, faites une passe rapide pour vérifier la cohérence : codes de statut et corps d'erreur correspondent, l'endpoint de liste renvoie un ordre stable, et chaque handler vérifie rôle et appartenance au tenant avant toute modification de la DB.

Si vous utilisez Koder.ai, signalez que le backend doit rester en Go et la base en PostgreSQL pour que le code exporté corresponde à la stack attendue.

Étapes pas à pas : générer, exécuter et vérifier

Générez tout (UI, API, base), puis passez en mode vérification stricte. L'objectif n'est pas d'admirer les écrans mais de prouver que la boucle complète fonctionne : UI - auth - rôles - Postgres - API - UI.

Une vérification simple

1. Lancez l'app et chargez l'écran d'accueil. Confirmez que la navigation fonctionne et que vous ne voyez pas de données factices. Si la page est blanche, notez le premier message d'erreur visible (toast UI, console ou log serveur).

2. Créez un compte de test par rôle (Admin, Manager, Viewer). Connectez-vous et déconnectez-vous avec chaque utilisateur. Confirmez que l'app affiche le rôle quelque part (menu profil, paramètres, ou un petit badge).

3. Choisissez un écran CRUD et faites un cycle complet : créez un enregistrement, rafraîchissez la page, puis éditez et supprimez-le. La vérification clé est la persistance : après rafraîchissement, l'enregistrement doit refléter ce qui est en Postgres, pas seulement en mémoire.

4. Essayez des actions interdites volontairement. Connectez-vous avec le rôle le plus bas et tentez d'accéder à un écran admin, appelez une action restreinte (comme delete), ou éditez un enregistrement auquel vous ne devriez pas accéder. Vous voulez des résultats clairs : soit une UI bloquée avec un message, soit une erreur 403 sans modification de données.

5. Testez des cas limites : listes vides, noms très longs, champs requis manquants, formats invalides (email, dates). Confirmez que l'app affiche des validations utiles et ne plante pas.

Si vous utilisez Koder.ai, prenez un snapshot juste après le premier test CRUD de bout en bout réussi. Cela vous donne un point de retour sûr avant d'ajouter des extras.

Échecs courants de prompt et comment les corriger

La plupart des builds “cassés” ne sont pas vraiment cassés. Il manque juste une contrainte qui maintient UI, API et BDD alignés.

1) Vous avez demandé trop à la fois

Quand vous demandez écrans, auth, rôles, schéma et tous les cas limites en une seule fois, l'app devient souvent incohérente (routes qui ne correspondent pas, modèles qui dérivent, pages à moitié finies).

Correction : scindez par couche et forcez l'outil à redire ce qu'il va générer avant d'écrire du code. Sur Koder.ai, cela aide aussi à maintenir plusieurs agents alignés.

2) Les rôles sont vagues, donc les vérifications manquent

Si vous dites seulement “admin et user”, vous pouvez obtenir un label de rôle dans l'UI mais pas d'autorisation réelle côté serveur.

Correction : définissez les permissions comme des actions (create, read, update, delete) par ressource, et exigez l'application côté serveur sur chaque endpoint.

3) Types de champs manquants provoquent une dérive UI/BDD

Si vous décrivez des champs en langage libre (“price”, “date”, “status”), les formulaires peuvent rendre des inputs texte alors que Postgres attend des nombres, des dates ou des enums.

Correction : spécifiez types, nullabilité, valeurs par défaut et contraintes, et exigez des règles de validation partagées.

4) Pas d'états de chargement ou d'erreur, l'UI semble cassée

Sans états de chargement et d'erreur, une requête échouée ressemble à une page figée.

Correction : exigez des spinners de chargement, des états vides et des messages d'erreur visibles pour chaque écran.

5) Les noms changent en cours de route

Renommer “Projects” en “Workspaces” à mi-chemin casse souvent routes, handlers et noms de table.

Correction : verrouillez un glossary tôt. Quand vous renommez, demandez un plan de renommage (search/replace, migrate) plutôt que de laisser le modèle improviser.

Utilisez ce prompt de réparation quand quelque chose déraille :

Audit the current app and list mismatches between: (1) routes, (2) API endpoints, (3) database tables/columns, (4) UI form fields.
Then propose a minimal patch plan.
Rules: do not invent new names, do not add new features, keep existing behavior, and update tests if present.
Output: a checklist of changes, then apply them.

Si les incohérences persistent, il vous manque probablement une « source unique de vérité ». Ajoutez une phrase : “The Postgres schema is the source of truth; UI and API must match it exactly.”

Checklist rapide avant de considérer le travail terminé

Avant de polir, vérifiez rapidement que l'app se comporte comme un produit réel. C'est là que la plupart des apps CRUD échouent : de petites incohérences entre écrans, règles et données.

• Les écrans correspondent au spec de l'entité : chaque écran (list, details, create, edit) utilise exactement les noms et la liste de champs que vous avez définis.
• Les rôles sont univoques : écrivez un tableau allow/deny par rôle et confirmez que UI et API appliquent les mêmes règles.
• Les réponses API sont cohérentes : choisissez un pattern (codes de statut, forme d'erreur, pagination) et vérifiez que tous les endpoints le suivent.
• Les contraintes DB correspondent à la validation des formulaires : si la BD exige un email unique ou un nom non-null, validez avant submit et affichez un message clair quand l'API rejette.
• Create/edit/delete survivent au rafraîchissement : créez un enregistrement, rafraîchissez, confirmez qu'il est toujours là ; éditez, rafraîchissez, confirmez ; supprimez, rafraîchissez, confirmez.

Un test concret : connectez-vous avec le rôle le plus bas et tentez une action que vous pensez bloquée (par ex. supprimer). Si elle réussit, corrigez la politique à un endroit (l'API) d'abord, puis ajustez l'UI pour qu'elle corresponde.

Exemple réaliste : un petit suivi d'inventaire

Imaginez une petite équipe IT qui prête des laptops, écrans et adaptateurs au personnel. Elle a besoin d'un endroit pour voir ce qui est disponible, qui a quoi, et quand cela doit être rendu. C'est un bon cas de test car il force les rôles, quelques écrans et une vraie base.

Fiche de préparation remplie

Utilisez ceci comme entrée exacte pour votre étape de préparation (copiez tel quel, puis ajustez les noms) :

App name: IT Equipment Loans
Goal: Track inventory and loans. Staff can request items. Admin approves and records check-out and return.
Roles:
- admin: manage inventory, approve/deny requests, edit any loan, see all
- staff: browse inventory, create a request, see own requests/loans
- viewer: read-only access to inventory and aggregate loan status
Core screens:
- Login
- Inventory list + item detail
- Request item (staff)
- Admin requests queue
- Loans list (filter: active/overdue)
Data rules:
- An item can have 0 or 1 active loan at a time
- Due date required for approved loans
- Overdue if due_date < today and not returned
Sample data:
- Items: MacBook Pro 14 (MBP-014), Dell 27 Monitor (MON-227), USB-C Dock (DOC-031)
- Users: alice(admin), ben(staff), carla(viewer)

Ordre de collage

Collez vos prompts dans cet ordre pour que l'app reste cohérente :

1. Prompt de base (règles globales, stack, nommage, gestion des erreurs)
2. Écrans et navigation (Inventory, Requests, Loans, Admin queue)
3. Authentification et rôles (admin, staff, viewer permissions)
4. Schéma PostgreSQL et données d'amorçage (items, loans, requests, users)
5. API CRUD en Go (endpoints et validation qui correspondent aux règles)

Un bon résultat ressemble à ceci : le staff peut demander “MBP-014”, l'admin l'approuve avec une date d'échéance, et la liste d'inventaire l'affiche comme indisponible avec le nom de l'emprunteur.

Si la construction est proche mais pas correcte, ajustez une chose à la fois : resserrez les permissions de rôle (un viewer ne doit jamais voir un bouton d'édition), réaffirmez la règle “une seule loan active par item”, ou demandez de renommer des champs pour que les libellés UI et les colonnes DB correspondent exactement.

Étendre en toute sécurité et réutiliser les prompts

Une fois les bases en place, traitez les prochains changements comme de petites releases. Choisissez une fonctionnalité, définissez ce que signifie “done”, puis prompt pour elle.

Un ordre sensé pour beaucoup d'apps :

• Audit log : enregistrer qui a modifié quoi et quand (create, update, delete), et l'afficher sur un écran admin only.
• Uploads de fichiers : attacher un document ou une image à un enregistrement, stocker les métadonnées en Postgres, et garder l'accès derrière l'auth.
• Notifications simples : afficher des alertes in-app (par ex. “stock faible” ou “nouveau commentaire”), avec une action “mark as read”.

Quand un changement casse la construction, ne tentez pas de tout réparer d'un coup. Revenez en arrière, puis ré-appliquez le changement dans un prompt plus petit et ciblé. Si vous utilisez Koder.ai, les snapshots et rollback sont un filet de sécurité pratique, surtout avant des changements qui touchent le schéma DB, les règles d'auth ou les composants partagés.

Le Planning Mode aide aussi quand une fonctionnalité traverse plusieurs couches. Demandez au modèle de redécrire le plan d'abord (écrans, endpoints API, changements DB, rôles), puis approuvez ce plan avant de générer du code. Cela évite le décalage courant où l'UI attend des champs que l'API ne retourne pas, ou l'API écrit dans des colonnes qui n'existent pas.

Si vous souhaitez continuer en dehors de la plateforme, exportez le code source et modifiez-le dans votre workflow habituel. Conservez l'ensemble de prompts à côté du repo comme “instructions de build” pour pouvoir recréer l'app plus tard ou faciliter l'onboarding.

Si vous construisez sur Koder.ai (koder.ai), cet ensemble de prompts s'aligne bien sur les defaults React + Go + PostgreSQL de la plateforme, et il est facile d'itérer en toute sécurité en utilisant des snapshots pendant que vous affinez les exigences.

Enfin, enregistrez un prompt modèle réutilisable pour votre prochain projet. Gardez les parties stables (stack, règles CRUD, conventions d'auth et rôles, patterns Postgres) et ne remplacez que les noms de domaine. Avec le temps, vos prompts deviennent une recette répétable plutôt qu'une expérience ponctuelle.