Ta première interface dans le navigateur
Rejoins-le pour progresser et valider tes étapes.
Se connecter pour rejoindreBRIEFING MISSION
En Semaine 1, tu as appris la boucle sur des rails en construisant Captage. Maintenant ton app à toi existe sur le papier : son intention, ce qu'elle capte, ce qu'elle prouve. Le piège classique, c'est de vouloir tout câbler avant de voir le moindre pixel. On fait l'inverse.
Le walking skeleton, c'est le squelette qui marche : le plus petit système complet qui tient debout tout seul. Une page s'affiche, ET une donnée fait l'aller-retour. Tu tapes quelque chose, ça part en base, ça revient à l'écran. C'est minuscule, c'est moche, et c'est exactement ce qu'il faut. C'est le même geste que dans Captage, quand ta page est née vide sur :3333 et que tu as vu « 0 item » : ton premier vrai « ça marche ».
Ce que ça débloque : à partir du moment où le front naît et qu'une donnée circule, tu n'ajoutes plus que des branches sur un tronc vivant. Chaque feature suivante devient un petit changement vérifiable au lieu d'un saut dans le vide. Tu auras aussi posé dès le départ la séparation données / affichage, qui t'évitera la moitié des galères de la Semaine 2.
Niveau de la mission : à peine chatouillant. Ce qui est dur ici, ce n'est pas le code, c'est la discipline de ne PAS en faire trop.
OBJECTIFS MISSION
Consigne et checklist
La mission sera considérée comme réussie si…
- Une page s'affiche dans ton navigateur, avec un champ pour saisir une donnée et une liste des données existantes.
- Une donnée que tu saisis toi-même part en base, y est gravée, et réapparaît dans la liste à l'écran sans que tu touches à la base à la main.
- La même donnée se retrouve dans la base : la requête SQL (
SELECT * FROM ...) la montre noir sur blanc. - Les requêtes SQL vivent dans un module dédié ; la page ne contient AUCUNE requête SQL en direct.
Pour aller plus loin
- Vérifie l'aller-retour deux fois de suite (deux saisies) pour t'assurer que la liste se rafraîchit à chaque ajout, pas juste au premier.
- Ajoute un
created_ataffiché à l'écran pour voir l'ordre dans lequel tes données arrivent. - Ajoute un
UNIQUEsur le champ qui doit l'être (comme leurl TEXT UNIQUEde Captage) : la déduplication dans le design, pas en rattrapage.
ETAPES
La mission est découpée en étapes progressives :
- 1Étape 1 — Reste en terrain connu. Réutilise la même stack que Captage pour ne pas te disperser : FastAPI + Postgres dans Docker, lancés avec
uv, page sur le port 3333 (jamais 8000 ni 3000, c'est la convention que tu as gravée dans leCLAUDE.mdde Captage). Si tu préfères un autre couple simple (Flask + SQLite, Node + Postgres), libre à toi, le principe reste identique. Mais ne change de stack que si tu sais déjà pourquoi. - 2Étape 2 — Avant de toucher quoi que ce soit, inventaire. On ne demande jamais à Claude Code d'agir sans qu'il sache ce qui existe déjà. C'est le premier réflexe de la discipline vibecoding.
ls -la
cat README.md 2>/dev/null
cat CLAUDE.md 2>/dev/null
docker ps- 1Étape 3 — Le contrat avant le code. Écris ton intention à Claude Code en une phrase. Une seule entité, un seul champ qui compte. Si ton app capte des idées, l'entité c'est
ideeet le champ c'esttexte. Reste pauvre exprès. Et exige le plan avant l'écriture : tu valides, PUIS il code.
Mon app capte des [idées]. Pour le walking skeleton, je veux UNE seule
entité avec UN champ texte. Je veux : une page qui liste les entités
existantes et un champ pour en ajouter une. Quand je soumets, la donnée
va en base et la liste se réaffiche avec elle. Ne fais RIEN d'autre.
Pas d'auth, pas de style, pas de validation. On veut juste prouver
l'aller-retour. La page tourne sur le port 3333. Avant d'écrire,
propose-moi le plan en 4 étapes max et attends mon feu vert.Tu lis le plan. Tu valides ou tu corriges. Puis seulement, tu fais avancer un changement à la fois.
- 1Étape 4 — La base d'abord (pas de base, pas de preuve). Fais lever Postgres dans Docker et fais créer la table. Une donnée qui n'a nulle part où se graver n'est pas une donnée.
docker compose up -dCrée la migration pour une table `idees` : un id, un champ texte
non vide, un created_at. Applique-la. Puis montre-moi la table avec
un \d idees dans psql pour qu'on vérifie qu'elle existe vraiment.- 1Étape 5 — La séparation données / affichage dès le départ. Exige deux couches distinctes : un module qui parle à la base (lire / écrire), une page qui parle à l'utilisateur (afficher / soumettre). La page ne touche jamais Postgres en direct. C'est exactement la règle de Captage : l'UI affiche ce que l'APIAPI : ouvre la porte aux fonctionnalités logicielles. renvoie, rien d'autre.
Sépare strictement : un module qui lit/écrit en base (les requêtes SQL
vivent là et nulle part ailleurs), et la page qui appelle ces fonctions.
La page ne contient AUCUNE requête SQL. Montre-moi les deux fichiers.- 1Étape 6 — L'aller-retour, et tu le regardes. Lance le serveur, ouvre la page, tape une donnée, valide. Elle doit réapparaître dans la liste.
uv run uvicorn app:app --host 127.0.0.1 --port 3333Ouvre http://localhost:3333, saisis une première donnée, soumets. Si elle revient à l'écran, ton squelette marche. Vérifie ensuite qu'elle est bien gravée en base (la même donnée des deux côtés, c'est ça la preuve) :
docker compose exec db psql -U postgres -d captage -c "SELECT * FROM idees;"- 1Étape 7 — Tout ce qui a raté en chemin (une commande qui ne passe pas, un prompt qui dérape, un port déjà pris) part au JOURNAL, au format que tu connais déjà depuis Captage. C'est la discipline vibecoding : le raté est une donnée, pas une honte. Et un choix qui engage la suite (changement de stack, de port) va dans les Décisions historiques de ton CLAUDE.md, pas dans le JOURNAL.
La suite est réservée aux membres du parcours
Rejoins 3 semaines pour créer une App en partant de 0 pour débloquer la suite, les templates et suivre ta progression.