← Retour
Jour 2 · 29 avril 2026 · Guide pratique

LANCER LE PROJET.

De l'idée à un repo qui tourne, sans se planter dès le premier prompt.

Le planning détaillé reste sur le brief. Cette page est le mode d'emploi.

Avant de toucher au clavier

J2, c'est la journée où une idée devient une vraie app. Un seul piège, mais énorme : aller trop vite. Demander à Claude de "construire l'appli" d'un coup. Accepter le premier mockup. Pousser sur main parce que c'est plus simple. Vous le payerez cher.

La règle d'or de la journée

Avant de coder, l'IA doit comprendre. Avant qu'elle comprenne, vous la laissez poser des questions. Avant qu'elle touche un fichier, elle vous montre son plan.

01 — Git, en 5 minutes

Vraiment, cette fois

Si J1 vous a perdus sur Git, c'est normal. Voici la version qui vous suffit pour J2.

La métaphore qui marche

Git, c'est un Google Docs avec un historique infini, sauf que c'est vous qui choisissez quand sauvegarder. Et au lieu d'écrire à plusieurs sur le même document en même temps (catastrophe), chacun travaille sur sa propre copie en parallèle. Quand c'est prêt, on assemble proprement.

MAINla vraie appli, en ligneFEATURE/FORMULAIRELéa code en parallèle, sans toucher mainFEATURE/PAGE-PROFILMateo bosse de son côté pendant ce tempsdépartMERGE PR #1MERGE PR #2suite…
Main = la vraie appli. Branches = des brouillons isolés. PR = "tu valides ?". Merge = "OK c'est intégré".

Le vocabulaire en 6 mots

  • repo — le dossier du projet sur GitHub. Un seul par groupe.
  • branche — une copie parallèle où vous bossez sans toucher la version qui marche. Une branche par feature.
  • commit — une sauvegarde, avec un petit message qui dit ce qui change.
  • push — envoyer ses sauvegardes sur GitHub.
  • pull request (PR) — demander à intégrer sa branche dans la version principale.
  • merge — la PR est validée, votre travail rejointmain. Bravo.
Rassurez-vous

Vous ne tapez aucune commande. Vous parlez à Claude en français, il s'occupe de tout. Comprendre le vocabulaire ci-dessus suffit pour ne pas paniquer quand un message rouge tombe.

Le rituel à apprendre par cœur

Vous allez répéter ce mini-protocole 10 fois dans la journée. C'est tout ce qu'il y a à savoir.

Avant de commencer une feature
  1. Dire à Claude : « récupère le travail des autres et crée-moi une branche pour la feature X ».
  2. Décrire la feature, lui demander un plan, valider, coder.
Quand la feature est finie
  1. Relire ce que Claude a écrit. Vraiment.
  2. Lui dire : « sauvegarde, envoie sur GitHub et ouvre la pull request ». Il fait tout.
  3. Un binôme du groupe va sur GitHub, relit la PR, valide, merge.
La règle absolue

Personne ne touche à main directement. Toujours via une branche + une PR. C'est la règle qui évite 80% des problèmes en groupe.

02 — Attention à votre crédit

Le piège du compte partagé

Vous avez tous Claude Pro à 20€. Largement suffisant, mais avec une limite par tranche de 5h. Et Claude Design consomme beaucoup plus de crédit qu'une conversation texte (il génère et lit des images).

Cas concret

Un groupe partage un seul compte Pro. Quelqu'un grille la limite à 11h en lançant 8 brouillons Claude Design. Plus personne ne peut bosser jusqu'à 16h. C'est le scénario à éviter.

Si vous partagez un compte

  • Un seul actif à la fois. Jamais en parallèle.
  • Tour de rôle : un binôme bosse 1h, l'autre relit et prépare le prompt suivant sur papier. Puis on échange.
  • À la fin de votre tour : taper /clear dans Claude Code, et déconnexion. Pas de session zombie.

Les 5 réflexes anti-gaspillage

  1. Mode plan systématique dès qu'on touche à plus d'un fichier. Shift+Tab dans Claude Code pour l'activer.
  2. /clear entre deux features. Une session = une tâche.
  3. /compact quand la conversation devient longue mais que vous voulez garder le fil. Claude résume au lieu de tout garder.
  4. Pas de "regarde tout le projet". Demandez des fichiers précis.
  5. Sur Claude Design : pas de 10 brouillons. Brief précis dès le départ, 2-3 itérations max.

03 — Étape 1 : mocker l'UI

Avec Claude Design

Avant de coder, on dessine. Contre-intuitif quand l'IA code en 30 secondes, mais c'est ce qui sauve le plus de temps dans la journée. Mocker, c'est forcer le groupe à se mettre d'accord avant que Claude génère 200 lignes de code à jeter.

Allez sur claude.ai/design (inclus dans votre Pro). Décrivez votre UI en français, Claude génère un mockup interactif, exportable directement vers Claude Code.

Prompt — Brief design (exemple Relay)
On va concevoir l'écran principal de Relay, une appli d'entraide entre étudiants Ynov. Quelqu'un a un besoin urgent (matériel, avis sur un projet, test utilisateur), il publie une demande, et un autre étudiant à proximité y répond en moins de 5 minutes. Avant de proposer un mockup, pose-moi 5 questions max pour clarifier : la cible, les actions clés sur l'écran, ce qui doit sauter aux yeux, le style visuel souhaité. Ne génère rien tant que tu n'as pas mes réponses.

Pourquoi forcer les questions : sans ça, Claude génère un mockup générique qui ressemble à toutes les apps étudiantes. Avec ça, le mockup colle vraiment à votre projet.

Itérer 2-3 fois max

Une fois le mockup généré, vous itérez sur des points précis. Pas sur "tout refaire".

Prompt — Itération ciblée (exemple Fix My Slide)
Le mockup est presque bon. Trois changements précis : 1. Le bouton "Importer mes slides" doit être beaucoup plus visible, c'est l'action principale. 2. Les commentaires anonymes apparaissent sous chaque slide, pas dans une colonne séparée. 3. Plus de gris, moins de bleu. On veut un truc qui rassure, pas qui ressemble à LinkedIn. Garde tout le reste identique.
Économie de crédit

Une génération Claude Design ≈ 5 messages texte en coût. Réfléchissez à votre prompt avant de cliquer. 30 secondes à reformuler valent mieux qu'une génération qui rate.

Le handoff vers Claude Code

Quand le mockup vous va : bouton Send to Claude Code en haut à droite. Ça transmet tout (composants, couleurs, layout) directement dans votre projet. Pas besoin de copier quoi que ce soit à la main.

04 — Étape 2 : créer le repo

Sur GitHub, en 10 minutes

Un repo par groupe. Naming convenu : campus-helper-gX (votre numéro de groupe). Une seule personne le crée, puis invite les autres.

  1. Aller sur github.com/new.
  2. Nom : campus-helper-g1 (votre numéro). Public. Ne cocher aucune case (Claude créera tout).
  3. Une fois créé : Settings → Collaborators, ajouter les 3 autres membres avec leur pseudo GitHub.
  4. Settings → Branches → Add branch protection rule pour main. Cocher "Require a pull request before merging". Filet de sécurité gratuit.

Pour cloner le repo en local : « Claude, clone le repo [URL GitHub] dans mon dossier projets ». Il s'occupe de tout.

05 — Étape 3 : Claude Code + CLAUDE.md

Le fichier qui change tout

Une fois dans votre dossier projet, lancez Claude Code (claude dans le terminal) puis tapez /init. Ça analyse le projet et génère un CLAUDE.md de base. Vous allez ensuite le compléter.

Le CLAUDE.md de votre groupe

Ce fichier est lu par Claude à chaque session, par n'importe qui dans votre groupe. C'est la "constitution" de votre projet. Court et précis > encyclopédique.

Demandez à Claude : « remplace le CLAUDE.md actuel par le template ci-dessous, en gardant les zones [À REMPLIR] vides », en collant ce template :

# Campus Helper — [NOM DU PROJET]

## Le projet
[À REMPLIR : 1 phrase claire de ce que fait l'app]

## Cible utilisateur
[À REMPLIR : qui exactement, en 1-2 lignes]

## Le problème résolu
[À REMPLIR : 2-3 phrases sur le problème concret]

## Stack imposée par le cours
- Next.js 16 + TypeScript + Tailwind CSS
- shadcn/ui pour les composants
- SQLite en dev, Vercel Postgres en prod si besoin
- Déploiement Vercel via push sur main

## DA (direction artistique)
[À REMPLIR : palette de couleurs, ambiance — sortir
du mockup Claude Design une fois validé]

## Git — règles absolues
- Branches : feature/<scope> ou fix/<scope>
- Jamais de push direct sur main, toujours via PR
- 1 PR = 1 binôme la review avant merge

## Comportement attendu de l'IA
- Pose des questions si la demande est ambiguë (max 5)
- Propose un plan avant de toucher au code dès que
  ça touche plus d'un fichier
- Ne modifie pas plus de 3 fichiers sans validation
- N'invente pas de librairies, vérifie les imports
- Quand un test rate, fixe la cause, ne supprime pas
  le test

Une fois le fichier en place, remplissez les [À REMPLIR] à 4. C'est le moment où vous figez votre projet par écrit. C'est précieux.

Le piège classique

Un CLAUDE.md de 200 lignes, "au cas où". Claude ignore les règles du milieu. Mieux vaut 30 lignes lues à chaque fois que 200 survolées. Le fichier grossira au besoin.

06 — Étape 4 : le premier prompt

Mode plan + laisser l'IA poser des questions

Repo créé. CLAUDE.md en place. Mockup validé. C'est le moment de vérité. Tentation : taper "construis l'app". Réflexe à ancrer : faire l'inverse.

Activer le mode plan

Dans Claude Code, Shift+Tab active le mode plan. Claude lit, réfléchit, propose, mais ne touche aucun fichier. Vous validez son plan, ensuite seulement il code.

Prompt — Kick-off projet (exemple Relay)
On va construire Relay, une appli d'entraide entre étudiants Ynov pour publier une demande d'aide rapide (matériel, avis, test utilisateur) et y répondre en moins de 5 minutes. Voici le mockup de l'écran principal : [coller le bundle Claude Design ou décrire les écrans en quelques lignes]. Avant d'écrire la moindre ligne de code, interroge-moi sur : - les fonctionnalités essentielles vs nice-to-have - les écrans à créer pour une V1 démontrable - les cas limites auxquels je n'ai pas pensé - comment on identifie un utilisateur (auth ou pas pour la V1 ?) Pose tes questions une par une. Quand tu te sens confiant à 90%, écris une spec courte dans SPEC.md. Ne touche aucun fichier de code tant que je n'ai pas validé la spec.

Claude pose 4-6 questions. Vous répondez précisément. Il écrit SPEC.md. Vous lisez, corrigez, validez. À ce stade seulement, on passe au code.

Du plan au code, étape par étape

Une fois la spec validée, ne demandez jamais "implémente tout". Demandez l'étape 1, vous relisez, vous validez. Puis l'étape 2. C'est le seul moyen de garder le contrôle.

Prompt — Passer à l'implémentation
OK pour la spec. Implémente seulement l'étape 1 du plan : la page d'accueil avec le formulaire de publication d'une demande. Ne touche aucun autre fichier. Quand c'est fait, arrête-toi pour que je relise et qu'on sauvegarde avant de passer à l'étape 2.

Variations selon votre projet

  • Study Vibes — insister sur la dimension sociale : « L'app sert à provoquer des rencontres entre étudiants qui ne se connaissent pas. La friction d'inscription doit être minimale. »
  • JobyMatch — préciser les deux profils : « Deux types d'utilisateurs avec des besoins opposés (étudiant qui cherche, recruteur qui propose). Demande-moi comment on gère cette dualité dans la V1. »
  • Campus Pitch / Fix My Slide — insister sur le cœur : « L'utilisateur upload une présentation, il reçoit du feedback. Tout le reste est secondaire. Demande-moi comment on gère l'upload. »

07 — Étape 5 : le cycle quotidien

Tout en parlant à Claude, en français

Une journée type, en 5 phrases :

  1. « Récupère le travail des autres et crée-moi une branche pour [la feature] ».
  2. Vous décrivez la feature en français. Claude pose des questions, propose un plan (mode plan). Vous validez.
  3. Claude code. Vous relisez. Vous testez (ouvrez le navigateur, cliquez partout).
  4. « Sauvegarde, envoie sur GitHub et ouvre la pull request ». Claude écrit un commit propre, pousse, ouvre la PR. Vous n'avez rien tapé d'autre.
  5. Un binôme va sur GitHub, lit le diff, teste si possible, valide, merge.

Les conventions du cours

  • Branches feature : feature/<scope>-<descriptif-court>. Exemples : feature/relay-formulaire-publication, feature/jobymatch-page-recruteur, feature/study-vibes-feed-activites.
  • Branches fix : fix/<scope>-<ce-qui-est-cassé>. Exemple : fix/fix-my-slide-upload-pdf-cassé.
  • Claude utilise les commits "conventional" automatiquement (feat:, fix:, chore:). Vous n'avez pas à y penser.

La review entre binômes

Une PR n'est jamais mergée par celui qui l'a écrite. Un autre membre ouvre la PR sur GitHub, lit le diff, teste si possible, commente si quelque chose cloche, approuve, merge en squash. 5 minutes qui peuvent sauver 2 heures de débogage.

Si Claude se plante en cours de feature

Pas de panique : votre branche est isolée. Tant que la PR n'est pas mergée, main reste intacte. Dites simplement à Claude : « annule les modifs non sauvegardées » ou « reviens à la dernière sauvegarde qui marchait ». Il gère.

08 — Étape 6 : mettre l'app en ligne

Avec Vercel, en 3 minutes

Une app qui tourne sur votre ordi, c'est bien. Une app accessible par un lien que vous envoyez à n'importe qui, c'est mieux. Vercel fait exactement ça : à chaque fois que vous mergez sur main, votre app est mise à jour automatiquement sur une URL publique.

La connexion la plus simple

Une seule personne du groupe le fait, c'est suffisant. Les autres seront ajoutés au projet ensuite.

  1. Aller sur vercel.com et cliquer Sign Up. Choisir Continue with GitHub. C'est tout pour le compte.
  2. Sur le dashboard Vercel, cliquer Add New… → Project.
  3. Vercel affiche la liste de vos repos GitHub. Cliquer Import à côté de campus-helper-gX.
  4. Vercel détecte tout seul que c'est un projet Next.js et pré-remplit les options. Ne touchez à rien. Cliquer Deploy.
  5. 30 secondes plus tard, votre app est en ligne. Vercel donne une URL du genre campus-helper-g1.vercel.app. C'est l'URL que vous mettrez sur la page groupes.

Ajouter les autres membres du groupe

Sur le projet Vercel : Settings → Members → Invite, ajouter les pseudos ou emails GitHub des binômes. Ils auront accès aux logs et aux déploiements.

Et après ?

Plus rien à faire. Vercel surveille votre repo GitHub. À chaque PR mergée sur main, il rebuild et redéploie tout seul. Vous codez, vous mergez, l'URL publique se met à jour. C'est l'effet magique du jour.

Bonus : les preview URLs

Vercel déploie aussi automatiquement chaque pull request sur une URL temporaire dédiée. Ça permet de tester une feature avant le merge sans toucher la prod. Vous verrez le lien dans les commentaires GitHub de la PR.

Si le déploiement échoue

Vercel envoie un email avec le log d'erreur. Le réflexe : copier-coller le message dans Claude Code et lui dire : « le déploiement Vercel échoue avec cette erreur, corrige et ouvre une PR ». Dans 9 cas sur 10, c'est une variable d'environnement manquante, un import cassé, ou une dépendance oubliée. Claude diagnostique vite.

Prompt — Demander à Claude de préparer le déploiement
On va déployer sur Vercel pour la première fois. Avant que je connecte le repo, vérifie que tout est prêt : - le projet build sans erreur en local - pas de variable d'environnement utilisée sans valeur par défaut ou sans avertissement - pas de chemin en dur qui ne marcherait qu'en local - le README mentionne comment lancer le projet Si tu vois quelque chose à corriger, propose-moi un plan avant de toucher au code.

09 — Les 7 pièges à éviter

À garder en tête toute la journée

Piège 01
L'IA invente des librairies

Mettez les liens des docs officielles dans le CLAUDE.md ou dans le prompt. Demandez-lui de vérifier que les imports existent avant d'écrire.

Piège 02
La session devient confuse

Une session = une tâche. /clear entre deux features. Sinon le contexte précédent pollue la suivante et ça coûte du crédit pour rien.

Piège 03
On corrige en boucle, ça ne marche pas

Après 2 corrections ratées : /clear et reformulez le prompt initial en intégrant ce qui a raté. Continuer à corriger empire toujours la situation.

Piège 04
On accepte sans relire

Avant chaque sauvegarde, lisez ce que Claude a changé. Cherchez les cas limites non gérés. 30 secondes de relecture économisent 30 minutes de debug.

Piège 05
Tout demander d'un coup

"Crée toute l'appli avec login, dashboard, profil, API et BDD". Non. Une feature, une sauvegarde, on avance petit. Le mode plan vous force à découper.

Piège 06
Bosser sans sauvegarder

Dites à Claude de sauvegarder avant chaque grosse session. Si tout part en sucette, vous revenez à la dernière sauvegarde en 2 secondes.

Piège 07
Compte partagé mal géré

Un seul actif à la fois. Tour de rôle. /clear et déconnexion à la fin de votre tour. Sinon le quota saute pour tout le groupe.

Pour ensuite

À la fin de J2, vous devriez avoir :

  • un repo GitHub avec main protégée
  • un CLAUDE.md personnalisé, rempli
  • une spec claire de la V1
  • au moins une feature mergée
  • un premier déploiement Vercel sur une URL publique

Si vous avez tout ça, vous êtes très bien partis.

J3 (mardi 6 mai) sera consacré aux tests utilisateurs et à l'itération. C'est là que le vrai apprentissage commence. Voir le brief J3 pour la suite.

Pendant que vous bossez, remplissez les infos de votre groupe sur la page groupes (URL de l'app, repo, checklist, outils IA). Ça me permet de suivre votre avancement entre les séances.

← Brief projetRessources →