Le mandat
Des coéquipiers, une idée de commerce, et une IA qui assiste. Dès la première semaine, votre équipe de 3 choisit sa boutique (produits, forfaits ou services), fait générer par l'IA le HTML complet de l'itération 1, la charte graphique et les dossiers fonctionnels, puis publie la maquette en ligne pour la faire valider par le client. Ce qui prenait un mois en 2025 prend maintenant une semaine : le vrai travail commence tout de suite.
Avant de démarrer, lisez la page Les technologies : elle fixe la ligne de partage entre le site public (PHP vanille) et les parties privées (technologie libre), ainsi que les règles qui traversent tout le projet.
Le déroulement en un dessin
La boutique naît en semaine 1, trois volets la construisent en parallèle, et tout converge vers la démo de la semaine 4.
Génération et publication
Les trois volets en parallèle
Démo · 25 %
La remise intermédiaire · Fin de la semaine 1
Cette année, l'IA génère les dossiers fonctionnels, le HTML et le CSS. Générés ou pas, ce sont des livrables : ils sont versés dans Git, retravaillés par l'équipe et validés avant que le code de données ne commence.
Contenu de la remise intermédiaire
- Le dossier fonctionnel : le format visualisable (PDF) et la source (PPTX) :
- les maquettes version mobile et bureau, minimum une par coéquipier
- les user stories de l'itération
- La maquette HTML et CSS de toutes les pages de l'itération, publiée en ligne : navigation fonctionnelle entre les pages, formulaires en échafauds visuels (sans base de données)
- La validation avec le client (le prof) avant de commencer le code de données
Vous êtes responsables de tout ce que l'IA produit : chaque page, chaque classe CSS et chaque décision du dossier fonctionnel doit pouvoir être expliquée par un membre de l'équipe.
Les trois volets · Un par coéquipier
De la semaine 1 à la semaine 3, 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 4.
La boutique affiche sous une forme navigable des produits, forfaits ou services que l'utilisateur peut se procurer. La boutique comprend :
- Des pages listes de produits (format galerie)
- La page de détail des produits (une seule page dynamique sert tous les produits)
- Une forme de classification : soit des filtres, soit de la pagination, soit des catégories
Le gestionnaire contrôle l'inventaire et les opérations du magasin via une interface web sécurisée. Le panneau d'administration comprend :
- Le panneau d'administration sécurisé
- L'interface de gestion (ajouter, modifier, retirer des éléments)
- Le système de téléversement des images
- La validation des données côté serveur
Le client finalise sa commande en effectuant une véritable transaction de bout en bout. Le système de paiement comprend :
- Le protocole sécurisé HTTPS activé sur le nom de domaine
- Un tunnel d'achat multi-étapes (wizard) permettant de collecter l'adresse et les préférences de livraison avant de passer au paiement
- La configuration d'un compte sandbox ou régulier (PayPal ou Stripe)
- L'intégration du processus de paiement à la page produit
- La page de confirmation de la transaction
- l'Enregistrement de la transaction dans la base de données (IPN)
Semaine 4 · La démo des trois volets réunis
- Assemblage : de la vitrine à la caisse, un achat de bout en bout fonctionne en ligne
- Démonstration devant la classe, sur le vrai site, ticket par ticket
- Rétrospective d'itération (méthode agile)
- Release TAG = ITERATION_1_BOUTIQUE : l'évaluation se fait avec cette version du code en ligne
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 : les éléments uniques ont un id (#liste-produits), les éléments répétés ont un nom de classe en français comme dans le dossier fonctionnel (.produit-titre, .produit-prix), les boites sont étiquetées (boite-principale, menu, menu-secondaire)
- Un lien <a> pour naviguer, un <form method="POST"> pour transporter des données vers le serveur, et rien d'autre
- URLs sémantiques partout, y compris dans le panneau admin ; pagination adressable, jamais de scroll infini
Données & Sécurité
- Environ un DAO encapsulé par table de données (ProduitDAO.php) : aucun code SQL en dehors des DAO
- La librairie de données est sécuritaire et portable (PDO) et tout le SQL est en requête préparée (bind param)
- Les règles de validation et de filtration sont dans les modèles (PHP Filters), pour tous les GET et POST, avec les messages d'erreur fonctionnels à afficher dans les formulaires
Déploiement & DevOps
- Le site est publié en ligne avec un nom de domaine et l'URL est dans le README.md du dépôt Git
Le processus AGILE
Semaine 1
- 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 2 et 3
- 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
Semaine 4
- 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 4, sur le site en ligne, avec la version Release TAG = ITERATION_1_BOUTIQUE.
| 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 1 · 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 !
En quatre semaines, votre boutique passera d'une idée à un commerce en ligne qui encaisse son premier paiement.