← Retour
Projet · Campus Helper

LE BRIEF.

Tout ce qu'il faut savoir sur le projet, la méthode, le planning et la notation. À lire en intégralité avant la fin de J1.

Le pitch

En 21 heures de cours réparties sur 4 journées, chaque groupe livre une webapp déployée en ligne qui résout un micro-problème réel de la vie étudiante à Ynov. Elle doit être utilisable par n'importe quel étudiant de l'école, sans installation, depuis une URL publique.

Le projet s'appelle Campus Helper. C'est un thème, pas un produit précis : chaque groupe choisit son angle. Le seul critère : que le problème existe vraiment, et que les utilisateurs testeurs soient à portée de main dans l'école.

Exemples de micro-problèmes

Ces idées sont là pour débloquer, pas pour limiter. Un bon projet part d'une frustration concrète que quelqu'un dans le groupe a déjà vécue.

  • Trouver un binôme de sport. App qui permet de poster un créneau et un sport, et qui match les étudiants dispos au même moment.
  • Échange de notes de cours. Plateforme pour partager ses notes par matière, avec un système de "merci" ou d'upvote.
  • Covoiturage campus. App qui liste les trajets quotidiens proposés par les étudiants vers et depuis Ynov.
  • Entraide devoirs. "Je bloque sur cet exo, qui peut m'aider en 5 min ?" — plateforme de mise en relation rapide entre étudiants.
  • Micro-services entre étudiants. Quelqu'un a besoin d'une relecture, d'un coup de main Photoshop, d'un test utilisateur : il poste, les autres répondent.
  • Carte interactive du campus. Salles, machines libres, microondes dispo, fontaines, avec mises à jour crowdsourcées.
  • Sondage éclair des pauses déj. "Où on va manger ?" — app qui liste les options autour de l'école et fait voter les gens en 30 secondes.
  • Perdu/Trouvé du campus. Déclarer un objet perdu ou retrouvé, voir s'il y a un match.

Vous pouvez aussi proposer le vôtre. Mais il doit rentrer dans ces contraintes : problème simple, utilisateurs dans l'école, scope atteignable en 21 heures avec l'aide d'une IA.

Contraintes

Contraintes produit

  • Un seul problème, bien résolu. Pas dix fonctionnalités moyennes. Trois écrans maximum pour la v1.
  • Webapp responsive. Ça doit marcher sur un téléphone dans un couloir. Pas d'app native.
  • Utilisable par quelqu'un qui n'a rien lu. Si l'app nécessite une notice, ce n'est pas une bonne app.
  • Testée par de vrais étudiants avant la fin de J3, avec retours écrits.
  • Déployée publiquement sur une URL (Vercel gratuit) avant la fin de J4.

Contraintes techniques

  • Stack imposée : Next.js + TypeScript + Tailwind + shadcn/ui. Déploiement Vercel. Base de données optionnelle (SQLite ou Vercel Postgres selon le besoin).
  • Au moins un compte Claude Code par groupe (plan A) ou une combinaison d'outils gratuits selon le plan B.
  • Au moins un dépôt GitHub public par groupe, avec tous les membres en collaborateurs.
  • Au moins deux branches distinctes utilisées pendant le cycle (pas tout sur main).
  • Au moins une pull request mergée par chaque membre du groupe pendant les 4 jours.

Contraintes humaines

  • Groupes de 4 maximum (3 accepté si besoin).
  • Tous les profils sont utiles : tech, marketing, PM. Celui qui connaît le mieux le problème n'est souvent pas celui qui "code" le plus.
  • Chaque membre doit avoir utilisé Claude Code personnellement au moins une fois pendant les 4 jours.

Planning des 4 journées

Les horaires sont indicatifs. L'important, ce sont les livrables de fin de journée. Si vous êtes en retard sur un bloc, rattrapez entre les journées.

J1THÉORIE & CADRAGE
15 avril 2026 · 7h
09h00 — 12h30
Cours théorique
Les 7 chapitres du cours : IA, LLM, Claude Code, anatomie d'une app, Git, vibe coding. Questions/réponses. Pause 15 min incluse.
12h30 — 13h30
Déjeuner
13h30 — 14h30
Brief projet + constitution des groupes
Lecture collective du brief, formation des groupes de 4, échange sur les idées de micro-problèmes.
14h30 — 16h30
Brainstorm produit
Choix du problème, identification des utilisateurs cibles, description de la v1 en 5 phrases max, croquis papier des 2-3 écrans principaux.
16h30 — 17h30
Setup & check-list J2
Création d'un GitHub par groupe, compte Vercel, plan d'achat des abonnements Claude Code (plan A/B), check-list d'installation pour J2.
Livrables fin de journée
  • Un Notion ou Google Doc par groupe avec : nom du projet, problème résolu en 3 phrases, 3 écrans en croquis, rôles dans le groupe.
  • Un dépôt GitHub vide créé avec tous les membres en collaborateurs.
  • La check-list d'installation lue et comprise (à exécuter avant J2).
J2BUILD
29 avril 2026 · 7h
09h00 — 10h30
Vérif setup + initialisation du projet
Tour de table : qui a Claude Code installé, qui bloque. Création du projet Next.js via Claude Code, premier commit, premier push sur GitHub.
10h30 — 12h30
Design system & wireframes
Mise en place de shadcn/ui, définition de la palette, construction des composants de base et des écrans en structure (sans vraies données).
12h30 — 13h30
Déjeuner
13h30 — 16h30
Développement des fonctionnalités
Travail en pair programming distribué : chacun prend une feature, travaille dans sa branche, ouvre une PR, merge. Tests continus dans le navigateur.
16h30 — 17h30
Premier déploiement sur Vercel
Connexion du repo GitHub à Vercel, premier déploiement, URL publique partagée. Debug des erreurs de build si nécessaire.
Livrables fin de journée
  • URL publique Vercel qui affiche au moins la page d'accueil et un écran fonctionnel.
  • Au moins 5 commits sur GitHub, 2 branches distinctes utilisées, au moins 1 PR mergée par membre.
  • Une preuve vidéo (capture d'écran) de Claude Code en train de travailler, par groupe.
J3TESTS UTILISATEURS & ITÉRATION
6 mai 2026 · 3h (après-midi)
14h00 — 14h45
Méthodologie de test
Comment on observe un utilisateur sans l'influencer. Grille d'observation. Quelles questions poser, lesquelles éviter.
14h45 — 16h15
Session de test
Chaque groupe fait tester son app à au moins 5 étudiants qui ne sont pas dans le cours. Observation silencieuse, prise de notes. 10 min par testeur.
16h15 — 17h00
Débrief & priorisation
Retour en classe, synthèse des retours. Tri : ce qui est critique, ce qui est nice-to-have, ce qu'on ignore. Création d'une liste de 3 actions max pour J4.
Livrables fin de journée
  • Grille de retours utilisateurs remplie (au moins 5 testeurs).
  • Liste des 3 actions prioritaires à faire pour J4, avec justification.
  • Un commit ou une issue GitHub par action prioritaire.
J4FINALISATION & DÉMOS
20 mai 2026 · 4h
09h00 — 11h30
Dernières corrections & polish
Implémentation des 3 actions prioritaires définies en J3. Fignolage visuel. Vérification que tout marche en ligne sur l'URL publique. Dernier push.
11h30 — 12h00
Préparation des démos
Chaque groupe prépare 10 min de présentation : problème, démarche, démo live, retours utilisateurs, démo, apprentissages, prochaine étape.
12h00 — 13h00
Démos en classe
10 min par groupe : 7 min de présentation + 3 min de questions. Notation en direct selon le barème.
Livrables fin de journée
  • URL publique finale de l'app déployée (capture dans le Notion du groupe).
  • Présentation de 10 min en classe.
  • Le repo GitHub propre avec README qui explique le projet et l'URL de démo.

Barème de notation

Note sur 20. Six critères, pondérés selon leur importance. Le projet est noté en groupe. Une note individuelle peut moduler la note collective à la marge (± 2 points) en cas de contribution notablement déséquilibrée, au jugement de l'enseignant.

CritèreCe qu'on regarde/20
FonctionnalitéL'app fait ce qu'elle annonce. Parcours principal sans bug. Un vrai étudiant peut l'utiliser du début à la fin./6
Qualité UX/UIL'interface est claire, cohérente, agréable. Design system respecté. Pas de texte placeholder en prod. Responsive mobile./3
Intégration des retours utilisateursTraces d'une vraie session de test en J3. Les retours ont été analysés et au moins deux d'entre eux ont été implémentés avant J4./3
Usage de Claude Code & GitPair programming effectif, branches utilisées, PR mergées, historique de commits propre avec messages qui racontent quelque chose./3
Démo oraleClarté de la présentation, capacité à expliquer pourquoi tel choix plutôt qu'un autre, gestion du temps, réponses aux questions./3
BonusOriginalité du problème, ambition raisonnable, déploiement propre, README soigné, petit "wow" qui montre du soin./2
Notation philosophie

Ce barème récompense un projet fini, honnête, testé. Un MVP fonctionnel de 3 écrans qui tourne vraiment en ligne et qui a reçu du feedback utilisateur vaudra toujours plus qu'un projet ambitieux mais cassé. La règle : livrer petit et propre plutôt que gros et bancal.

Check-list à faire avant J2

Entre J1 et J2, vous avez 14 jours. Voici ce que chaque groupe doit avoir fait avant de revenir le 29 avril. La liste d'installation complète est sur la page ressources.

  1. Choisir définitivement le micro-problème (pas d'hésitation le jour J).
  2. Décider du plan d'abonnement : plan A (payant) ou plan B (gratuit). Au moins 1 compte Claude Code actif par groupe si plan A.
  3. Installer Claude Code sur l'ordinateur de la personne qui aura l'abonnement principal.
  4. Créer le compte GitHub pour les membres qui n'en ont pas, et créer le dépôt du projet avec tous les membres en collaborateurs.
  5. Créer un compte Vercel gratuit (par la personne qui déploiera), connecté au compte GitHub.
  6. Avoir fait un premier croquis papier ou Figma des 2-3 écrans principaux de l'app.
← Cours théoriqueRessources →