Le mandat
Votre boutique attire des habitués : il leur faut une porte. Cette itération construit le seuil (l'inscription et l'authentification), le salon (l'espace membre où chacun retrouve ses transactions et ses options) et l'entraide (une FAQ intégrée). Le site apprend à reconnaître ses visiteurs et à s'en souvenir.
L'espace membre est une partie privée : la page Les technologies vous laisse le choix du moteur, tant que chaque écran reste adressable par une URL sémantique.
Le déroulement en un dessin
Le dossier fonctionnel naît en semaine 5, trois volets construisent l'espace membre en parallèle, et tout converge vers la démo de la semaine 7. En dessous, la nouveauté : le travail passe par le staging demo.votre-domaine avant d'être promu sur le vrai site.
Dossier fonctionnel et prototypes
Les trois volets en parallèle
Démo · 25 %
La remise intermédiaire · Fin de la semaine 5
Comme à chaque itération, l'IA peut générer les dossiers fonctionnels et les prototypes HTML et CSS : ce sont des livrables quand même, versés dans GitHub, retravaillés et validés avant le code.
Contenu de la remise intermédiaire
- Le dossier fonctionnel dans GitHub → /doc, en formats visualisables (Markdown, PDF, PNG) avec la source éditable du même nom :
- les user stories de l'itération
- les storyboards : 1) l'inscription d'un membre 2) un achat en étant connecté
- le diagramme de navigation et le plan des URL de l'espace membre
- les maquettes des pages membres, minimum une par coéquipier
- Les prototypes HTML et CSS des pages membres, en échafauds visuels, en ligne sur le staging demo.votre-domaine
- Le redéploiement automatique en place : le vrai site reflète le dépôt git à toutes les heures
- Le staging demo.votre-domaine est monté et reçoit le redéploiement horaire
- Les preuves de concept dans GitHub → /poc/inscription-authentification/ qui testent :
- le hachage du mot de passe et sa valeur hachée dans la base de données
- le maintien en mémoire de l'état d'authentification (session)
- Captures d'écran des étapes testées, nommées selon la nature et l'ordre de l'étape ; les POC vivent dans un répertoire à part et n'utilisent aucun composant du projet autre que le serveur et la base de données
- La validation avec le client (le prof) avant de commencer le code
Les trois volets · Un par coéquipier
De la semaine 5 à la semaine 7, chaque coéquipier porte un volet. Les équipes de 2 doivent également couvrir les 3 volets. Les trois volets avancent en parallèle et convergent vers la démo commune de la semaine 7.
- Inscription en assistant pas à pas (wizard multi-étapes) avec validation à chaque étape
- Mots de passe hachés avec password_hash, vérifiés avec password_verify : jamais de mot de passe en clair, ni dans la base, ni dans les journaux
- Connexion, déconnexion et pages protégées par session
- Messages d'erreur fonctionnels dans tous les formulaires
- Profil auto-éditable et options utilisateur
- Historique des transactions du membre, branché sur la caisse de l'itération 1 : chaque achat laisse une trace visible dans le compte
- Préférences mémorisées côté client (localStorage, cookies) : le site se souvient des habitudes
- Chaque écran de l'espace membre a sa propre URL sémantique
- FAQ intégrée à l'espace membre : les questions des membres trouvent réponse une fois pour toutes
- Tests de tout le site en ligne et finitions
- Démonstration devant la classe : inscription, connexion, achat connecté, historique, options, FAQ
- Release TAG = ITERATION_2_MEMBRE : l'évaluation se fait avec cette version du code en ligne
- La boutique tourne toute seule en ligne pendant que l'équipe reprend son souffle : les grandes manoeuvres marketing s'en viennent
Les technologies
Exigences techniques de l'itération
ARCHITECTURE_SIMPLE du dépôt projet-web-contrat, et sa version vivante est sur le hub des versions.Interface & Standards Web
- HTML sémantique avec id uniques et classes en français (l'exigence de l'itération 1 demeure)
- Un lien <a> pour naviguer, un <form method="POST"> pour transporter des données, et rien d'autre ; s'il y a plusieurs formulaires par page, un <input type="hidden"> porte l'identifiant et le name du submit identifie l'action
- URLs sémantiques partout ; pagination adressable, jamais de scroll infini
Données & Sécurité
- Les exigences de l'itération 1 demeurent : DAO avec PDO, requêtes préparées partout, PHP Filters dans les modèles pour tous les GET et POST
- Tout le site demeure en HTTPS (le protocole est activé dès l'itération 1)
- Les sessions sont sécurisées : identifiant de session régénéré à la connexion, déconnexion qui détruit la session
- Les pages membres sont réellement protégées : y accéder sans session valide redirige vers la connexion
Déploiement & DevOps
- Le staging demo.votre-domaine est en place : le redéploiement horaire le cible, la production est promue après validation par l'équipe
Le processus AGILE
Semaine 5
- Sprint planning : identifier les user stories et les tâches, créer les tickets (issues) dans Git en utilisant les gabarits de tickets du Kickoff (Titre + DoD + liste des tâches + liens vers les sources + réflexions + métadonnées à droite)
- Assigner un seul étudiant par ticket ; les tickets trop gros sont fractionnés
- Alimenter le tableau Kanban de Git
- Valider le sprint planning avec le prof avant de commencer
Semaines 6 et 7
- Mêlée quotidienne complète avant chaque cours
- Commits AGILE : commentaire de commit + numéro du ticket (#issue), toujours
- Tickets AGILE : commentaires et liens ajoutés dans le ticket en cours de route
- Le staging demo.votre-domaine reçoit le travail à toutes les heures ; la production est promue après validation
Fin de la semaine 7
- Test de tout le site en ligne et préparation de la démo
- Sprint review avec le client, ticket par ticket : lecture du Titre + DoD, démo sur le serveur, fermeture du ticket
- Sprint planning de la prochaine itération
Les critères d'évaluation · 25 %
Un point de la grille vaut un pourcent de la session. La démonstration a lieu en semaine 7, sur le site en ligne, avec la version Release TAG = ITERATION_2_MEMBRE.
| Points | Critère |
|---|---|
| Le processus · 12 points | |
| 4 / 4 | Spécifications en temps utile (maquette + devis fonctionnel) |
| 4 / 4 | Le Ticket (issue) : titre utilisateur, DoD, tâches, commits liés, commentaires de réflexion et liens |
| 4 / 4 | Agile en temps utile : Sprint planning (Kanban), Mêlée quotidienne et collaboration, Sprint review |
| Le produit · 13 points | |
| 4 / 4 | Expérience utilisateur : HTML sémantique (id + classes), ergonomie, contenus |
| 4 / 4 | Navigation : URLs adressables, liens, formulaires, flux |
| 4 / 4 | Traitement des données : modèles, php filters, requêtes préparées |
| 1 / 1 | Architecture : respect de l'architecture cible (exemple Contrat, tag ARCHITECTURE_SIMPLE) |
| 25 | Total de l'itération 2 · 25 % de la session |
Les modalités
En reflet du monde du travail, les séances de laboratoire sont toutes à présence obligatoire et à participation obligatoire. Pour des raisons de motivation au travail, d'échange effectif de l'information et d'évaluation, les heures contact se réalisent en classe, en présentiel, en collaboration avec son équipe.
L'espace du laboratoire est réservé aux activités du projet. Les participants doivent contribuer à la hauteur de la pondération pour recevoir la pleine mesure des points. Le professeur se réserve le droit d'exclure un participant d'une équipe s'il ne participe pas et que cela complique la division des volets. Personne ne doit réaliser les tâches de ses camarades.
Bonne chance !
À la fin de cette itération, votre boutique aura des habitués qui reviennent, se connectent et retrouvent leurs affaires.