Chapitres, TP et corrigés consultables ; les TP sont principalement à réaliser hors de la page. Trois questions d’entraînement interactif facultatif sont proposées dans ce module, sans note ni validation automatique. Le manuel de formation est également consultable depuis le lien en haut de page. Les durées sont des repères pour organiser le parcours ; les lectures, activités, travaux pratiques et évaluations ne doivent pas être additionnés deux fois. La grille de soutenance est un outil d’autoévaluation, sans note attribuée automatiquement par le site.
Dans ce module — Accès rapide
MODULE 12 — PROJET INTÉGRATEUR ET SOUTENANCE
8 heures • Bloc C — Réalisation autonome • Prérequis : modules 1 à 11
Édition pédagogique V2.2 — Bilan du parcours
1. Finalité et résultat attendu
Réaliser une version complète et maintenable de « Mon espace de découverte » : site HTML/CSS/JavaScript accessible, responsive, doté d’une interaction créative, suivi dans GitHub et publié via Netlify. L’apprenant doit pouvoir présenter les décisions, les limites, les vérifications et les apports réels de l’IA.
Livrables : dépôt GitHub identifié si l’accès est disponible ; sinon, dossier local versionné ou dossier de simulation explicitement identifié, sans prétendre disposer d’un dépôt distant ; URL publique HTTPS si la publication est possible, ou dossier de simulation clairement identifié en cas d’absence d’accès ; fichiers index.html, style.css, script.js et README.md ; fiche de conception ; journal de tests ; journal d’assistance IA ; courte soutenance. Aucune donnée personnelle réelle n’est nécessaire.
Voir un exemple, essayer et vérifier
Je vois — exemple concret : Pour chaque étape A à F, associez une preuve : intention, structure, réalisation, interaction, vérification et livraison. Une capture n’est utile que si elle montre le résultat annoncé.
J’essaie — petit geste : Créez un tableau à six lignes A–F ; ajoutez pour chacune un fichier ou une observation vérifiable et un point restant à contrôler.
Je vérifie — si cela ne fonctionne pas : Séparez README (comment utiliser le projet) et recette (ce qui a réellement été testé). N’inventez pas de résultat.
2. Répartition des huit heures
Séquence A — Cadrage final et critères d’acceptation (1 h).
Séquence B — Intégration et corrections ciblées (2 h).
Séquence C — Tests UX, accessibilité, sécurité, SEO et performance (1 h 30).
Séquence D — Versionnement, publication et vérification Netlify (1 h).
Séquence E — Documentation et préparation de la soutenance (1 h).
Séquence F — Démonstration, évaluation et bilan (1 h 30).
3. Cahier des charges minimal
Le site comporte un titre principal, une navigation interne, trois cartes de contenu, une section « Explorer » à choix libres, un pied de page, des styles adaptés aux écrans étroits et une interaction JavaScript compréhensible. Les liens doivent fonctionner. Les textes restent lisibles sans animation et, autant que possible, sans script.
Le site n’a pas besoin de compte visiteur, de collecte de données, d’API externe, de formulaire opérationnel ni de service payant. Toute fonctionnalité supplémentaire doit être justifiée et testée ; la simplicité est une qualité, non un manque.
Critères d’acceptation : pour une publication réelle, ouverture de la page publique, HTTPS actif et vérification du commit déployé ; dans tous les cas, absence de ressource manquante dans le projet testé, fonctionnement au clavier, lisibilité mobile et absence d’erreur JavaScript bloquante. Pour une simulation, documenter les paramètres de déploiement et expliquer comment revenir à une version antérieure, sans présenter la simulation comme une publication effective.
Comprendre et essayer — exemple guidé
Je vois : Une exigence vérifiable précise ce qui doit être observable dans la version livrée.
J’essaie : Rédigez trois exigences vérifiables pour la version à livrer.
Je vérifie : Chaque exigence est testable et associe un comportement attendu à une observation.
Autre façon de faire : Rédigez trois exigences et, pour chacune, une méthode de contrôle observable.
Pour reprendre plus tard : Conservez uniquement l’exemple anonymisé, la correction retenue et l’affirmation ou la donnée qu’il faudra contrôler.
4. Préparer le projet et les preuves
Arborescence recommandée :
mon-premier-projet/
index.html
style.css
script.js
README.md
images/ (facultatif)
docs/
conception.md
recette.md
journal-ia.md
Dans conception.md : public, objectif, fonctionnalités, exclusions, accessibilité et confidentialité. Dans recette.md : date, appareil ou largeur, action, résultat attendu, résultat observé, correction et nouveau test. Dans journal-ia.md : demande formulée, réponse utile ou rejetée, modifications réellement retenues, vérification effectuée.
Ne jamais placer de mot de passe, jeton d’accès ou clé API dans ces fichiers.
Comprendre et essayer — exemple guidé
Je vois : Une livraison traçable relie sources, numéro de version et preuve de résultat.
J’essaie : Rassemblez le fichier source, la version et une preuve du résultat attendu.
Je vérifie : La version et les fichiers source sont identifiables ; la preuve correspond à cette version.
Autre façon de faire : Rassemblez les sources et leur version dans un dossier local ; conservez une preuve correspondant à cette version.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
5. Intégration sans régression
Partir du dernier commit fonctionnel. Faire une modification cohérente à la fois, inspecter le diff et vérifier qu’aucune section antérieure n’a disparu. Si une correction concerne l’exploration, ne pas réécrire inutilement la navigation ou le stockage du module 5.
Méthode : constater → isoler → proposer → modifier → tester → comparer → enregistrer. Lorsqu’une suggestion IA est utilisée, demander une modification ciblée et une explication des conséquences. Refuser toute correction non comprise ou non testée.
Exemple d’incident : un bouton « Effacer la préférence d’exploration » supprime toutes les données localStorage. Correction attendue : removeItem avec la clé exacte, plutôt que clear. Vérifier les autres fonctions mémorisées.
Comprendre et essayer — exemple guidé
Je vois : Un contrôle de non-régression vérifie qu'une fonction ancienne survit à un changement.
J’essaie : Comparez deux versions et vérifiez qu’une fonctionnalité ancienne fonctionne encore.
Je vérifie : Le comportement ancien est retesté après modification avec un résultat consigné.
Autre façon de faire : Comparez deux copies locales et rejouez l’ancienne fonctionnalité dans le navigateur.
Pour reprendre plus tard : Notez le résultat attendu, l’observation obtenue et l’éventuel écart à reproduire à la prochaine séance.
6. Recette qualité en six familles
Fonctionnel : boutons, retour, liens, affichage sans erreur et suppression ciblée.
Responsive : contrôles à 375, 768 et 1280 px, puis zoom 200 % sans débordement gênant.
Accessibilité : structure de titres, libellés, alternatives d’images, focus visible, navigation clavier, absence d’information portée par la seule couleur.
SEO : titre de page spécifique, meta description utile, canonical uniquement si l’URL de référence est connue et cohérente, sitemap uniquement si nécessaire ; l’indexation n’est jamais garantie.
Performance : images dimensionnées et compressées, absence de bibliothèques inutiles, chargement raisonnable sur réseau lent.
Sécurité et confidentialité : aucun secret dans le dépôt ; aucune donnée sensible dans le navigateur ; permissions des applications limitées ; aucune publication non autorisée.
Pour chaque famille, conserver au moins un test avec résultat observé. Une grille remplie sans test réel n’est pas une preuve.
Comprendre et essayer — exemple guidé
Je vois : Une recette complète distingue les familles de risques plutôt que de tester seulement l'accueil.
J’essaie : Classez les tests entre navigation, mobile, clavier, contenu, sécurité et persistance.
Je vérifie : Les six familles sont représentées et chaque test possède un résultat attendu.
Autre façon de faire : Classez les tests dans six catégories sur papier, sans prétendre les avoir exécutés.
Pour reprendre plus tard : Gardez le tableau de classement avec les éléments qui vous ont fait hésiter et la distinction à revoir.
7. Publier et contrôler
Vérifier la branche et le commit à publier. Déployer sur Netlify depuis un dépôt GitHub connecté si cette option est disponible ; sinon, effectuer un déploiement manuel des fichiers statiques, ou documenter une simulation si aucun accès à la publication n’est possible. Pour un site statique simple, confirmer le dossier contenant index.html et les paramètres de publication adaptés au projet ; ne pas inventer de commande de compilation. Consulter le résultat du déploiement et les éventuels messages d’erreur.
Ouvrir l’URL HTTPS dans une fenêtre privée et sur un téléphone si possible. Vérifier liens, CSS, JavaScript et chemins sensibles aux majuscules. Tester un lien depuis un QR code si le projet en utilise un. Si la version publiée échoue, identifier le dernier déploiement valide et utiliser la procédure de restauration disponible dans l’interface, puis vérifier à nouveau le site public.
Le nom de domaine personnalisé reste facultatif ; un domaine peut nécessiter un achat et une configuration DNS indépendante de la formation.
Comprendre et essayer — exemple guidé
Je vois : Une simulation prépare les contrôles, mais seule une publication réelle prouve l'accès public.
J’essaie : Simulez une publication et consignez l’adresse à vérifier après mise en ligne.
Je vérifie : La simulation distingue mise en ligne et vérification de l’URL réellement publiée.
Autre façon de faire : Préparez les étapes de publication et notez « URL publique non testée » sans hébergement.
Pour reprendre plus tard : Conservez la version ou le scénario utilisé, la preuve disponible et l’étape distante qui reste à tester réellement.
8. README : documenter pour une autre personne
Le README.md doit répondre à : (1) quel est le projet ? (2) comment l’ouvrir localement ? (3) quels fichiers ont quels rôles ? (4) comment tester l’interaction ? (5) où trouver la version publiée ? (6) quelles données sont conservées ? (7) comment signaler une anomalie ? (8) quelle version constitue la référence ?
Exemple : « Ouvrir index.html dans un navigateur. Certaines fonctions de stockage peuvent varier en file:// ; utiliser un serveur local de développement si nécessaire. Aucun compte visiteur requis. »
Une documentation utile décrit le comportement réel, pas seulement les intentions.
Comprendre et essayer — exemple guidé
Je vois : Un README permet à une autre personne de comprendre, tester et restaurer le projet.
J’essaie : Rédigez un README expliquant installation, test et retour arrière.
Je vérifie : Une autre personne peut retrouver les fichiers, lancer le test et revenir à une version stable.
Autre façon de faire : Rédigez le README dans un éditeur gratuit ; faites vérifier les instructions par une autre personne.
Pour reprendre plus tard : Notez le résultat attendu, l’observation obtenue et l’éventuel écart à reproduire à la prochaine séance.
Entraînement interactif facultatif — V0.6.0
Ces questions complémentaires ne constituent ni une note ni une validation de compétence. Aucune réponse n’est enregistrée.
Atelier intégrateur guidé — six étapes avec corrigés
Ces étapes concrétisent les séquences A à F déjà prévues : elles ne s’ajoutent pas aux huit heures et ne doivent pas être comptées une seconde fois. Travail possible sans abonnement IA ni publication réelle ; indiquer clairement ce qui est simulé.
A — Cadrer le projet et définir les critères d’acceptation
Livrable : Fiche conception.md comprenant public, objectif, trois cartes, interaction libre, exclusions et cinq critères testables.
Critère de réussite : Le projet reprend une réalisation antérieure et n’exige ni compte visiteur ni abonnement.
Voir le corrigé commenté
Exemple : « Sur écran de 375 px, aucun défilement horizontal ; le bouton Explorer fonctionne au clavier ; les trois cartes ont des liens vérifiés ; le choix de mémoriser est explicite ; le site reste compréhensible sans animation. » Un critère comme « joli » est insuffisant, car il n’indique pas comment vérifier.
B — Intégrer et vérifier une modification ciblée
Livrable : Fichier index.html + style.css + script.js, avec avant/après et trace de la modification.
Critère de réussite : Une modification à la fois, sauvegarde avant changement, justification du diff.
Voir le corrigé commenté
Exemple : corriger un bouton qui efface toutes les préférences en ciblant uniquement la clé locale du projet ; tester ensuite l’autre préférence pour prouver l’absence de régression. Un changement de texte seul ne suffit pas à prouver le comportement.
C — Exécuter une recette vérifiable
Livrable : recette.md avec résultats attendus/observés et captures ou descriptions de tests réellement exécutés.
Critère de réussite : Tester au moins 375/768/1280 px, clavier, zoom 200 %, liens et effacement ciblé lorsque les outils sont disponibles.
Voir le corrigé commenté
Exemple de ligne : « 375 px, Tab jusqu’au bouton Explorer ; attendu : focus visible et activation Entrée ; observé : conforme sur Firefox version X, le JJ/MM ; statut : réussi ». Si non testé, inscrire « non testé », jamais « réussi ».
Pourquoi cette réponse ? Une ligne de recette utile décrit un environnement, une action, un résultat attendu et un résultat observé ; sans ces éléments, le constat n’est pas reproductible.
Exemple ou vérification autonome Rédigez une ligne pour un bouton testé au clavier à 375 px, avec navigateur et statut.
D — Versionner et publier ou simuler honnêtement
Livrable : Identifiant de commit et URL HTTPS réellement ouverte, ou dossier local et scénario de publication explicitement simulé.
Critère de réussite : Ne pas publier de données privées, de secrets ou de fichiers temporaires.
Voir le corrigé commenté
Exemple réel : noter commit abc123, URL vérifiée, date et test sur URL. Exemple simulé : « Publication non effectuée : pas de compte Netlify ; procédure décrite, URL : aucune ». Une capture de l’éditeur ne prouve pas le déploiement.
Pourquoi cette réponse ? Une simulation de publication ne prouve pas un déploiement réel ; seule une URL testée et une version identifiée peuvent en fournir la preuve.
Exemple ou vérification autonome Distinguez dans le compte rendu « publication simulée » et « URL réellement vérifiée ».
E — Documenter pour un tiers
Livrable : README.md avec ouverture locale, rôle des fichiers, test de l’interaction, données conservées, limites et version de référence.
Critère de réussite : Une autre personne doit pouvoir reprendre et tester le projet sans explication orale.
Voir le corrigé commenté
Exemple : « Ouvrir index.html ; cliquer Explorer ; aucun choix enregistré tant que l’option Mémoriser n’est pas activée ; effacement depuis Réinitialiser ; version de référence : dossier projet-v1 ». Un README qui ne décrit que l’intention reste incomplet.
F — Présenter et défendre ses choix
Livrable : Plan de soutenance de 6 à 8 minutes, une preuve de test, une correction et une limite reconnue.
Critère de réussite : L’évaluation porte sur les preuves et le raisonnement, pas sur l’effet spectaculaire.
Voir le corrigé commenté
Exemple de conclusion : « J’ai refusé la suggestion d’ajouter un compte utilisateur car elle n’apportait rien à l’objectif et aurait accru la collecte de données. Je n’ai pas testé Safari : je l’indique comme limite. » Une soutenance ne se réduit pas à montrer une page.
9. Soutenance courte : démontrer et expliquer
Présentation de 6 à 8 minutes suivie de questions. Plan : intention (1 min), architecture des fichiers (1 min), démonstration du site et de l’exploration (2 min), exemple d’erreur corrigée et preuve de test (1 min), GitHub/Netlify et retour arrière (1 min), limites et pistes d’évolution (1 min).
Questions possibles : que se passe-t-il si JavaScript est désactivé ? Pourquoi le stockage est-il facultatif ? Comment vérifier un lien QR ? Que fait le commit ? Comment savoir si la version publique est la bonne ? Qu’avez-vous accepté ou refusé parmi les propositions de l’IA ?
Le formateur évalue la compréhension et les preuves, pas l’effet spectaculaire.
10. Barème final sur 100 points
Conception et adéquation au besoin : 20 points.
HTML, CSS, JavaScript et qualité du code : 25 points.
Usage critique et traçable de l’IA : 20 points.
Publication, accessibilité et tests : 20 points.
Documentation et soutenance : 15 points.
Seuil pédagogique proposé : 60/100, avec remédiation obligatoire pour tout défaut bloquant de sécurité ou d’accessibilité de base. Ce barème est interne à la formation et ne constitue pas une certification officielle.
11. Autoévaluation : dix questions
1. Quel est le livrable principal ?
2. Pourquoi conserver un README ?
3. Que vérifie un test de non-régression ?
4. Pourquoi un site publié n’est-il pas forcément indexé ?
5. Quelle preuve permet de relier une version à GitHub ?
6. Quel est le rôle de HTTPS ?
7. Que faire avant une modification générée par IA ?
8. Comment vérifier une restauration ?
9. Pourquoi conserver un journal de recette ?
10. Que doit montrer la soutenance ?
Afficher le corrigé
12. Corrigé synthétique
1. Un site complet et documenté, publié si les accès sont disponibles ou accompagné d’une simulation de publication explicitement identifiée.
2. Pour permettre sa reprise et sa maintenance.
3. Les fonctions antérieures après modification.
4. Les moteurs décident de l’exploration et de l’indexation.
5. L’identifiant du commit.
6. Chiffrer la communication, sans garantir la fiabilité du contenu.
7. Définir la portée et garder un état stable.
8. Ouvrir et tester la version réellement servie.
9. Pour conserver des preuves et faciliter le diagnostic.
10. L’intention, les choix, les tests, les limites et l’autonomie.
13. Bilan des compétences et poursuite
Au terme du parcours, l’apprenant a rencontré l’ensemble de la chaîne : cadrage, assistance IA, HTML, CSS, JavaScript, Git, GitHub, Codex, Netlify, connecteurs, UX, accessibilité, SEO et expérience interactive. L’acquisition réelle dépend des exercices effectués et des évaluations ; le volume horaire seul ne prouve pas la maîtrise.
Pistes d’approfondissement : tests automatisés, design system, gestion de contenu, JavaScript avancé, RGPD, performance et accessibilité approfondies. Une amélioration future doit commencer par une intention et un critère de réussite, puis être soumise à la vérification.
Ce parcours complète les travaux pratiques du module. Il peut être réalisé sans abonnement payant et ne constitue pas une évaluation certifiante.
Ce que vous allez apprendre — Présenter un projet qu’une autre personne peut ouvrir, tester et comprendre.
Matériel nécessaire — Ordinateur avec projet final ; téléphone facultatif pour la lecture et la démonstration.
Organisation sur deux écrans — Vous pouvez lire ce cours sur téléphone et effectuer les manipulations sur ordinateur. Gardez les deux appareils à portée de vue ; aucun transfert de données entre eux n’est obligatoire.
Constituer un dossier de soutenance vérifiable
Comment procéder concrètement
Rassemblez les fichiers nécessaires dans un seul dossier.
Créez README.txt et indiquez comment ouvrir le projet et utiliser son interaction.
Créez recette.txt avec des cases initialement non cochées.
Exécutez les contrôles un par un ; cochez seulement ceux réellement réussis.
Demandez à une autre personne d’ouvrir le projet en suivant uniquement le README, puis consignez ses difficultés.
Si vous n’avez qu’un téléphone — Sur téléphone, le README et la grille de recette restent consultables ; la livraison du projet complet se prépare plus facilement sur ordinateur.
Repères pratiques — Relier le dossier final aux étapes A–F
À réaliser concrètement : Organisez votre dossier en distinguant la réalisation (fichiers HTML/CSS/JS), le cadrage (cahier des charges), le README (mode d’emploi) et les preuves de test (recette). Pour chaque étape A–F du module 12, indiquez le livrable ou la preuve qui lui correspond en reprenant les intitulés exacts de votre cours. Ne prétendez pas avoir testé une étape non réalisée.
Si vous êtes bloqué : Si un livrable ne peut être relié à une étape A–F, notez « preuve manquante » plutôt que de l’inventer.
Essai autonome, sans recopier le modèle : Confiez uniquement le README et les fichiers à une autre personne et vérifiez si elle peut identifier le point d’entrée et le parcours prévu.
Étape 1 — Réunir les livrables
À faire : Regroupez la page, le cahier des charges, les fichiers sources et les notes de test.
Exemple ou résultat modèle : Dossier projet/ avec index.html, style.css, app.js, README.txt et recette.txt.
Vérification : Un tiers identifie le point d’entrée et les dépendances.
Étape 2 — Préparer la démonstration
À faire : Présentez objectif, parcours principal, interaction et retour arrière.
Exemple ou résultat modèle : Démonstration : ouvrir la page, afficher l’aide, revenir à l’état initial.
Vérification : Chaque étape peut être reproduite.
Étape 3 — Exposer les limites
À faire : Distinguez tests faits et tests restant à faire.
Exemple ou résultat modèle : « Navigation clavier testée ; compatibilité anciens navigateurs non vérifiée. »
Vérification : Aucune garantie non démontrée n’est annoncée.
Si cela ne fonctionne pas : pistes de dépannage
Le lecteur ne trouve pas le point d’entrée : précisez index.html dans le README. Un test échoue : décrivez l’anomalie plutôt que de déclarer le projet conforme.
Afficher le corrigé commenté
Corrigé modèle : la soutenance associe réalisation, preuve et limites. Le README permet à une autre personne de reprendre le projet sans explication orale.
Exemple complet à reproduire
Fichier ou livrable modèle : README.txt + recette.txt. Copiez ou adaptez ce contenu dans votre propre dossier de travail.
README.txt
PROJET : Page d'atelier découverte.
OUVRIR : double-cliquer sur index.html.
FICHIERS : index.html, style.css, app.js (selon votre réalisation).
PARCOURS : lire la présentation, consulter le programme,
utiliser l'aide interactive puis revenir à l'état initial.
LIMITES : à compléter après les tests réels.
recette.txt
[ ] La page s'ouvre sans erreur.
[ ] Le lien Programme fonctionne au clavier.
[ ] L'aide s'affiche et se masque.
[ ] Le texte reste lisible à 200 % et 400 %.
[ ] Les fichiers livrés correspondent au README.
STATUT : non validé tant que les cases ne sont pas testées.
Pourquoi ce corrigé est valable
Le README rend le projet transmissible ; la recette prouve ce qui a été contrôlé. Une case non testée reste vide. La soutenance doit montrer un résultat, expliquer les choix et reconnaître les limites.
Preuve de vérification attendue
Après réalisation, conservez le fichier produit et une note indiquant la manipulation testée, le résultat réellement observé et les éventuelles limites. Ne cochez pas un test non effectué.
Bilan personnel : notez ce qui fonctionne, ce qui reste à vérifier et une amélioration possible. Aucun résultat de cet atelier n’est envoyé au site.
Complément de corrigé TP — exemple de vérification et diagnostic
Livrables du projet final — Associer chaque étape A–F à un fichier, une manipulation et une preuve ; distinguer les documents README, recette et code du site.
Variante autonome : changer un seul élément de votre réalisation, prévoir le résultat, effectuer le test et consigner ce qui a réellement été observé. Plusieurs solutions sont acceptables si elles satisfont les critères du TP.
Laboratoire ludique facultatif — Le studio de recette globale
Explore les six étapes A–F d’un projet fictif, relève les preuves et prends une décision GO / NO GO. Ce laboratoire complète le projet intégrateur sans remplacer ses livrables ni sa soutenance.