Projet évaluatif
Vue.js + Vuetify + API

  • Projet 30 pts
  • Examen oral 50 pts
  • 6 semaines
  • Revue hebdomadaire

Ta mission

  • Construire une application Vue.js 3 avec Vuetify
  • Connecter une API externe avec Axios
  • Gérer l'état global avec Pinia
  • Déployer sur GitHub Pages ou Vercel
  • Examen oral de 20 min sur la théorie vue en cours et le code de ton projet
Voir les exigences Évaluation

Objectifs

Architecture composants

Découper une interface en composants Vue.js réutilisables et maintenables

Gestion d'état

Centraliser les données avec Pinia : state, actions, getters

Connexion API

Récupérer et afficher des données externes avec Axios

Navigation multi-pages

Configurer Vue Router avec routes dynamiques et paramètres

Design responsive

Créer des interfaces adaptatives avec Vuetify et Material Design

Compréhension profonde

100% du code doit être compris et expliqué à l'oral

À rendre

Application en ligne

  • Hébergée sur GitHub Pages ou Vercel
  • Application fonctionnelle sans erreurs console
  • Design responsive mobile → desktop
  • Connexion à une API externe
  • Dépôt GitHub propre et structuré

Arborescence type

mon-projet/
├── src/
│   ├── components/
│   ├── views/
│   ├── stores/
│   ├── plugins/
│   │   └── axios.js
│   ├── router/
│   │   └── index.js
│   └── App.vue
├── public/
├── .env.example
├── package.json
└── README.md

Documentation (README.md)

  • Description : Concept et objectif de l'application
  • Fonctionnalités : Liste des features implémentées
  • Installation : Instructions pour lancer le projet
  • API utilisée : Source et endpoints
  • Technologies : Vue.js, Vuetify, Pinia, Axios, etc.
  • Captures d'écran : Visuels de l'application
  • Transparence IA : Usage déclaré (voir section Support)

Fichiers obligatoires

  • .env.example - Template des variables d'environnement
  • mock.json - Backup des données API

Exigences techniques

Vue.js 3

Votre application doit utiliser Vue.js 3 avec la Composition API :

  • Composition API : <script setup> obligatoire
  • Réactivité : ref, reactive, computed
  • Composants : Au moins 3-4 composants réutilisables
  • Props & Emit : Communication parent-enfant
  • Lifecycle : onMounted pour les appels API

Pinia & API

Gestion de l'état et connexion aux données :

  • Store Pinia : State, actions, getters
  • Axios : Configuration dans plugins/axios.js
  • Variables .env : URL API préfixée VITE_
  • Mock JSON : Fallback si API indisponible
  • localStorage : Persistance des favoris

Vuetify & UX

Interface utilisateur avec Material Design :

  • Composants Vuetify : v-card, v-btn, v-text-field, etc.
  • Grille responsive : v-container, v-row, v-col
  • Navigation : v-app-bar, v-navigation-drawer
  • Feedback : v-snackbar, v-dialog, v-progress
  • Mobile-first : Testé sur mobile et desktop

Fonctionnalités requises

  • Page d'accueil : Liste ou grille des données (cards, tuiles, etc.)
  • Page de détail : Route dynamique /item/:id
  • Navigation : Menu fonctionnel (header ou drawer)
  • Favoris : Ajout/suppression avec persistance
  • Recherche : Filtrage par texte
  • Filtre : Par catégorie, type ou autre critère
  • Tri : Alphabétique, date, ou autre ordre

Qualité du code

  • Structure : Dossiers components/, views/, stores/
  • Commits : Réguliers avec messages clairs
  • README : Documentation complète
  • .env.example : Template sans secrets
  • .gitignore : .env et node_modules ignorés
  • Pas d'erreurs : Console propre (pas de warnings critiques)

Planification

  1. Semaine 1

    Lancement & Conception

    Choisir son sujet et poser les fondations.

    • Choix du sujet et de l'API
    • Validation de l'API par l'enseignant
    • Création du sitemap préliminaire
    • Création du dépôt GitHub
    • Début de l'exercice Pokédex Vuetify (étapes 1-12)
  2. Semaine 2

    Mise en place technique

    Configurer l'environnement et connecter l'API.

    • Configuration .env et axios.js
    • Création du store Pinia
    • Premier appel API fonctionnel
    • Affichage basique des données
    • Suite Pokédex Vuetify (étapes 13-17)
  3. Semaines 3-4

    Développement

    Développer les fonctionnalités principales.

    • Page d'accueil avec liste/grille
    • Page de détail avec route dynamique
    • Système de favoris
    • Recherche et filtres
    • Revue hebdomadaire avec l'enseignant
  4. Semaine 5

    Finalisation & Rendu

    Peaufiner, documenter et livrer.

    • Mock JSON créé et testé
    • localStorage pour la persistance
    • Design responsive finalisé
    • README.md complet
    • Déploiement sur GitHub Pages / Vercel
    • Rendu du projet (fin de semaine)
  5. Semaine 6

    Préparation de l'oral

    Réviser et s'entraîner pour l'examen.

    • Préparation de la démo (2-3 min)
    • Révision du code (comprendre chaque fonction)
    • Révision de la théorie Vue.js, Pinia, API
    • Lister les améliorations possibles
  6. 3 juin (après-midi)

    Examen oral

    Présenter et défendre son projet.

    • Démo de l'application (2-3 min)
    • Présentation des améliorations possibles
    • Questions théoriques : 3 questions × 6 pts = 18 pts
    • Questions pratiques : 3 questions × 9 pts = 27 pts
    • Durée totale : ~20 minutes par candidat

Ressources

⭐ APIs sans clé (recommandées)

🎮 PokéAPI Pokémons 👽 Rick & Morty Série 🌍 REST Countries Pays 🎌 Jikan Anime 🍹 TheCocktailDB Cocktails ⚠️ 🍽️ TheMealDB Recettes ⚠️ 🐕 Dog CEO Chiens 🎨 Art Chicago Art 🏛️ MET Museum Art ⚡ HP-API Harry Potter 🦸 SuperHero Héros 🔮 Digimon Créatures 🎯 Valorant Jeux 📺 Simpsons Série

🔑 APIs avec clé gratuite

🎬 TMDB Films 🕹️ RAWG Jeux vidéo 🦸‍♂️ Marvel Comics ⚽ TheSportsDB Sports 📷 Unsplash Photos 🖼️ Pexels Photos 🌄 Pixabay Images

✅ Critères d'une bonne API

  • Gratuite ou clé gratuite
  • Images disponibles
  • Endpoint liste : /items
  • Endpoint détail : /items/:id
  • Contenu riche exploitable

⚠️ À éviter : OpenLibrary (pas de liste), SWAPI (pas d'images), Deezer/Spotify (restrictions), OpenWeatherMap/NASA (pas de liste)

⚠️ Attention : TheCocktailDB et TheMealDB n'ont pas de liste complète gratuite → utiliser les filtres par catégorie, ingrédient ou zone

Évaluation du projet (30 pts)

Grille d'évaluation - Partie projet

Le projet est noté sur 30 points, convertis ensuite en note sur 6.

Fonctionnalités

17 pts

Focus : Ce que fait l'application

Attendus : Page d'accueil, page détail, routage dynamique, navigation, favoris, recherche, filtre, tri, feedback utilisateur.

Architecture technique

11 pts

Focus : Comment c'est construit

Attendus : Store Pinia bien structuré, composants réutilisables, séparation du code, responsive, mock JSON, connexion API, localStorage.

Qualité du code

7 pts

Focus : Propreté et documentation

Attendus : Organisation des fichiers, code commenté, README complet, .env.example, commits réguliers avec messages clairs.

UX / Design

5 pts

Focus : Expérience utilisateur

Attendus : Design cohérent, gestion des erreurs, navigation intuitive, icône/titre personnalisés, footer personnalisé.

Bonus

+3 pts

Focus : Au-delà des attentes

Attendus : Images avec alt/fallback, animations CSS pertinentes, design particulièrement soigné.

Examen oral (50 pts)

Déroulement (~20 minutes)

  • Présentation/démo : 2-3 minutes - Montrer l'application et ses fonctionnalités
  • Améliorations possibles : Ce que vous amélioreriez avec plus de temps
  • Questions théoriques : Pool de questions (Vue.js, Pinia, API, Vuetify)
  • Questions pratiques : Questions sur votre code

Répartition des points (50 pts)

  • Présentation : 5 pts (démo + améliorations possibles)
  • Questions théoriques : 3 questions × 6 pts = 18 pts
  • Questions pratiques : 3 questions × 9 pts = 27 pts

Chaque question est notée de 0 à 3, puis multipliée par son coefficient (×2 théorique, ×3 pratique).

Barème des réponses

  • 3 - Maîtrise complète : Réponse précise, complète et bien argumentée
  • 2 - Maîtrise partielle : Réponse correcte mais avec quelques imprécisions ou hésitations
  • 1 - Début de maîtrise : Réponse partielle, nécessite des relances pour aboutir
  • 0 - Aucune évidence : Pas de réponse ou réponse totalement incorrecte

Présenter les améliorations possibles

Durant votre présentation, vous devez aussi évoquer ce que vous amélioreriez si vous aviez plus de temps :

  • Démontre du recul sur votre projet
  • Identifie ce qui fonctionne moins bien
  • Propose des évolutions futures
  • Valorise l'autocritique et la vision d'ensemble

Exemples : "J'aurais aimé ajouter un tri par date", "Le design de la page détail pourrait être amélioré", "Je voudrais implémenter la pagination"...

Exemples de questions

Questions théoriques

  • Quelle est la différence entre ref et reactive ?
  • À quoi sert une propriété computed ?
  • Expliquez le rôle de Pinia dans une application Vue.js.
  • Pourquoi utilise-t-on un fichier .env ?

Questions pratiques (sur votre code)

  • "Explique-moi cette fonction, que fait-elle ?"
  • "Pourquoi as-tu utilisé computed ici ?"
  • "Comment fonctionne ton store ?"
  • "Que se passe-t-il si je clique sur ce bouton ?"

Important : Connaître son code

L'oral vise à vérifier que vous comprenez le code que vous avez écrit. Si vous ne pouvez pas expliquer une partie de votre code, cela sera pénalisé.

Conseil : Relisez votre code avant l'oral et assurez-vous de pouvoir expliquer chaque fonction, chaque choix technique.

Attitude professionnelle

L'oral est aussi l'occasion de démontrer votre professionnalisme :

  • Saluer le jury en entrant dans la salle
  • Adopter une posture correcte (pas affalé sur la chaise)
  • Maintenir un contact visuel avec les évaluateurs (pas uniquement l'écran)
  • Communiquer de manière claire et respectueuse

Support & IA

Support et aide

  • Revue hebdomadaire : 5-10 min par élève en classe
  • Canal : Teams du cours pour les questions
  • Délai : Réponse sous 48h en période de cours
  • Format attendu : Lien GitHub, description du problème, captures si besoin

Utilisation de l'IA

L'utilisation d'outils d'IA (ChatGPT, GitHub Copilot, Claude, etc.) est autorisée sous conditions strictes :

  • Compréhension obligatoire : Vous devez comprendre 100% du code
  • Oral décisif : Vous devrez expliquer votre code lors de l'examen
  • Transparence : Déclarez l'usage d'IA dans votre README
  • Personnalisation : Adaptez le code à votre projet

Attention : Un code non compris = mauvaise note à l'oral (50 pts sur 80)

Checklist d'auto-évaluation

0% complété

Fonctionnalités

Architecture technique

Qualité du code

Préparation oral