Le programme est écrit, tu sais ce que ton app va faire. Mais deux questions restent ouvertes : comment les gens vont-ils l'utiliser, et sur quelles fondations va-t-elle reposer ? Aujourd'hui, deux spécialistes entrent sur le chantier. Le décorateur d'intérieur arrive avec ses plans de circulation — par où on entre, comment on passe d'une pièce à l'autre, ce qu'on voit en arrivant. Et l'architecte déroule ses grandes feuilles : fondations, murs porteurs, réseaux. Avant de poser la première brique, tout doit être dessiné.
Dans cette fiche, tu crées le parcours utilisateur avec le décorateur, puis les plans techniques avec l'architecte. À la fin, deux documents supplémentaires rejoignent ton dossier de projet.
Le PRD dit "l'utilisateur peut créer une entrée". L'UX Design dit "l'utilisateur clique sur le bouton + en haut à droite, un formulaire apparaît en modal, il remplit le titre, appuie sur Entrée, et la carte apparaît immédiatement dans sa liste."
C'est la différence entre un plan d'étage et une visite virtuelle.
Lance le workflow :
Donne-lui le contexte :
Le UX Designer va créer un document qui décrit :
Un écran n'a pas qu'une seule apparence. Il en a au moins quatre :
| État | Ce que l'utilisateur voit |
|---|---|
| Vide | Première visite, aucune donnée — "Aucun élément. Commence ici !" |
| Chargement | Les données arrivent — un indicateur de progression |
| Normal | Tout fonctionne, données présentes |
| Erreur | Quelque chose a cassé — un message clair avec quoi faire |
Si le décorateur ne mentionne pas ces états, demande-lui de les ajouter. Ce sont les quatre situations que tout utilisateur va vivre.
Quand le document te semble cohérent, valide. Le fichier ux-design.md apparaît dans ton projet.
L'architecte, lui, ne pense pas à l'expérience — il pense à la structure. Fondations, murs porteurs, réseaux. Il répond à la question : "Est-ce que ce qu'on veut construire peut tenir debout techniquement ?"
Lance le workflow :
Donne-lui le contexte :
Si tu ne le fais pas, l'architecte pourrait proposer d'autres technologies. La stack est décidée, il n'a pas à la remettre en question.
RLS signifie Row Level Security. En clair : chaque utilisateur ne voit que ses propres données. C'est comme des boîtes aux lettres individuelles dans un immeuble — tu ouvres la tienne, pas celle du voisin.
Demande-lui de l'ajouter. Sans ça, tous les utilisateurs voient toutes les données. C'est un problème de sécurité critique.
Et c'est voulu. L'architecte génère les plans techniques, l'inspecteur va les valider. Ton rôle est de vérifier que le modèle de données a du sens par rapport à ce que ton PRD demande — que chaque fonctionnalité a un support dans les tables décrites.
Quand le document te semble cohérent, valide. Le fichier architecture.md apparaît dans ton projet.
L'architecture est un document technique. Lance l'inspecteur pour vérifier la cohérence :
Il va vérifier que le schéma est cohérent, que le nombre de tables est raisonnable, et que l'ensemble tient la route dans la stack de la formation. S'il propose des ajustements, applique-les et valide le document.
Tu as deux nouveaux documents. Deux prompts pour les voir prendre vie.
Pour le parcours utilisateur, copie-colle dans Claude Code :
Pour l'architecture, copie-colle dans Claude Code :
Ouvre chaque fichier HTML généré dans ton navigateur.
Ces fichiers HTML ne sont pas des livrables du projet. Ils sont là pour toi, pour voir ton travail prendre forme. Tu peux les supprimer après.
| Symptôme | Cause probable | Solution |
|---|---|---|
| Le décorateur produit des maquettes ultra-détaillées | Il est allé trop loin pour un MVP | Dis "Simplifie. Je veux des wireframes textuels basiques, pas du design final." |
| Le parcours utilisateur a 15 étapes | Trop complexe pour une V1 | Dis "Le parcours principal doit tenir en 3-5 étapes maximum." |
| Les états des écrans ne sont pas mentionnés | Le décorateur a oublié | Demande "Ajoute les états de chaque écran : vide, chargement, normal, erreur." |
| L'architecte propose une autre stack | Tu n'as pas précisé que la stack est fixée | Dis "La stack est imposée : Next.js (App Router), Supabase, Shadcn/ui, Vercel. Ne la change pas." |
| L'architecture est très longue et hyper technique | Over-engineering pour un MVP | Dis "C'est un MVP de formation. Simplifie au maximum." |
| Le modèle de données ne correspond pas au PRD | Décalage entre les documents | Dis "Relis le PRD @prd.md et vérifie que chaque fonctionnalité a un support dans le modèle de données." |
| /brik:corriger archi signale des problèmes | Le schéma a des incohérences | Lis la réponse de l'inspecteur — il explique toujours quoi ajuster. Applique et relance. |
Tu as quatre documents. Un brief, un PRD, un UX Design, une architecture. Chacun a été validé séparément. Mais sont-ils cohérents entre eux ? L'inspecteur va faire une dernière revue globale avant de donner le feu vert définitif pour la construction.
-> Fiche suivante : Vérifier avec le correcteur