Objectif
Concevoir et réaliser une page web interactive de A à Z (HTML + CSS + JS) sur un sujet de ton choix, puis la présenter en expliquant tes choix techniques.
Le projet doit mobiliser au minimum les notions suivantes :
- Au moins une saisie utilisateur (champ
<input> ou prompt).
- Au moins une condition (
if / else).
- Au moins une boucle (
for ou while).
- Au moins une fonction déclarée par toi (en plus de celles appelées par les events).
- Au moins une manipulation du DOM (changer du texte, une couleur, ajouter un élément).
- Au moins un événement (
click, input, submit…).
- Une structure de données : tableau ou objet (idéalement un tableau d'objets).
Suggestions de projets
Quelques idées si tu manques d'inspiration. Tu n'es pas obligé d'en choisir une — un projet personnel motivant vaut mieux qu'un projet imposé.
Niveau accessible
- Quiz à choix multiple — questions chargées depuis un tableau d'objets, score affiché à la fin.
- Calculatrice — boutons, opérateur, deux opérandes, affichage du résultat.
- Convertisseur d'unités — euros↔dollars, km↔miles, °C↔°F.
- Liste de tâches (to-do) — ajouter, cocher, supprimer des tâches.
- Devine le nombre — l'ordinateur tire un nombre, l'utilisateur essaie de le trouver avec indices.
Niveau ambitieux
- Pierre/feuille/ciseaux contre l'ordinateur, avec score sur plusieurs manches.
- Memory (jeu d'appariement de cartes) avec timer.
- Mini-galerie photo avec filtrage par catégorie.
- Carnet de notes persistant dans
localStorage.
- Mini-Pokédex : liste de créatures, recherche, fiche détaillée.
Étapes recommandées
1. Cahier des charges (1 page maximum)
Avant d'écrire une ligne de code :
- Quoi ? Une phrase qui décrit ce que fait l'application.
- Pour qui ? Une cible imaginaire (joueur, élève, prof, client…).
- Fonctions essentielles (3 à 5 max, sans détails techniques).
- Maquette papier — un schéma rapide de l'écran. Pas besoin d'être beau, juste lisible.
2. Squelette HTML + CSS statique
Une page qui ressemble au produit fini, sans aucune logique JS. Tu mets juste les éléments en place : titres, champs, boutons, zones d'affichage. Tu vérifies dans le navigateur que ça se présente correctement.
3. JavaScript par petits incréments
Une fonctionnalité à la fois. Toujours dans cet ordre :
- Écris la fonction.
- Teste-la dans la console avec un cas simple.
- Branche-la sur l'événement (clic, soumission…).
- Vérifie dans le navigateur que ça marche.
- Passe à la suivante.
Ne code pas 3 fonctionnalités d'affilée sans tester.
C'est le piège classique : tu écris 100 lignes, rien ne marche, et tu ne sais plus quelle ligne casse. Un truc à la fois, on teste, on continue. Si tu bloques 15 minutes : console.log partout.
4. Polissage
Une fois que tout marche :
- Vérifie les cas limites : champ vide, valeur négative, click avant saisie…
- Renomme tes variables et fonctions si certaines sont devenues vagues.
- Retire les
console.log inutiles.
- Ajoute un peu de CSS pour que ce soit présentable.
5. Préparation de la présentation
- 5 minutes maximum de démonstration.
- Prévois un scénario d'utilisation : ce que tu vas montrer, dans quel ordre.
- Anticipe les questions techniques : "pourquoi un objet et pas un tableau ici ?", "que se passe-t-il si on clique sans rien taper ?".
- Sois prêt à lire un morceau de ton code et l'expliquer.
Grille d'évaluation
| Critère |
Pondération |
| Le projet fonctionne sans erreur visible |
/20 |
| Toutes les notions requises sont présentes (saisie, condition, boucle, fonction, DOM, event, structure de données) |
/20 |
| Le code est lisible : noms clairs, indentation, pas de copié-collé évident |
/20 |
| Les cas limites sont gérés (saisie vide, valeur invalide…) |
/10 |
| Présentation orale claire, capacité à expliquer ses choix techniques |
/20 |
| Originalité / soin / ambition raisonnable |
/10 |
Le critère le plus important est la lisibilité.
Un projet petit et propre vaut mieux qu'un projet ambitieux et illisible. Si tu dois copier-coller le même code à trois endroits, c'est qu'il manque une fonction. Si une variable s'appelle x, c'est qu'il manque un nom. Code pour le toi de la semaine prochaine.
Quelques règles d'autonomie
Tu vas inévitablement rencontrer un problème que le cours ne couvre pas. Bonne nouvelle : c'est exactement ce que fait tout développeur, tous les jours.
- Documentation MDN (
developer.mozilla.org) — la référence officielle. En français pour la plupart des pages. Toujours commencer par là.
- StackOverflow — une question = souvent déjà posée. Lis les questions autant que les réponses.
- Console du navigateur — quand un truc ne marche pas, l'erreur rouge te dit où.
- Le débogueur (onglet Sources) — pour mettre des points d'arrêt et exécuter pas à pas.
Une bonne recherche c'est : javascript [problème exact] + souvent l'année (2024) pour éviter les vieux articles avec var et ==.
À retenir
- Un projet, c'est : un cahier des charges → HTML/CSS statique → JS incrémental → polissage → présentation.
- Une fonctionnalité à la fois, testée avant de passer à la suivante.
- Lisibilité > ambition. Mieux vaut un quiz qui marche qu'un MMO qui plante.
- Quand tu bloques :
console.log partout, MDN, et reformuler le problème par écrit.
- À la présentation, sois prêt à expliquer pourquoi tu as fait tel choix, pas juste ce que ton code fait.
Bonne chance — et amuse-toi.
