Présentation et revue du projet

Cette page décrit la défense finale du projet filé en équipe. La présentation, la revue de code et le bilan final sont intégrés au projet d’équipe de 30 %. Ils ne constituent pas une composante séparée de 10 %.

Le 10 % individuel de fin de session correspond maintenant au site Quarto personnel.

Repère de correction: Grille de présentation et revue du projet.

À distinguer du site personnel

La défense du projet se déroule pendant la séance de semaine 14. La remise du site personnel est la seule exigence de semaine 15.

Objet	Type	Ce qui est vérifié
Site Quarto personnel	Individuel, 10 %, semaine 15	site publié sur GitHub Pages, dépôt source, deux réalisations commentées, lien vers une trace du portfolio
Présentation et revue du projet	Équipe, intégrée au projet de 30 %, semaine 14	démonstration, revue de code, contributions, validations, limites et réponses aux questions

Le site personnel peut présenter une réalisation issue du projet, mais il ne remplace pas la défense du projet. La défense du projet peut renvoyer au portfolio ou au site personnel, mais elle doit d’abord permettre d’expliquer le dépôt final de l’équipe.

Objectif

Vérifier que l’équipe peut expliquer le produit livré, les choix techniques, les limites, les validations effectuées et les contributions individuelles.

Cette séance n’est pas une deuxième correction complète du projet. Elle sert à vérifier que le dépôt remis peut être défendu, relu, expliqué et discuté.

Modalités

Élément	Modalité
Composante	Projet filé en équipe
Moment	Semaine 14, mercredi 9 décembre, de 13 h 30 à 16 h 20, pendant le cours régulier
Type	Équipe, avec questions individuelles possibles
Support	Dépôt GitHub final, démonstration et bref support de présentation
IA	Permise, déclarée

Structure de la séance

Le format exact peut être ajusté selon le nombre d’équipes. Par défaut, chaque équipe dispose d’un court bloc comprenant:

une présentation synthétique du projet;
une démonstration du produit retenu : rapport, tableau de bord, application, tutoriel, site, outil R ou autre format approuvé;
une revue d’un extrait de code ou d’une pull request;
une discussion des validations, limites et compromis;
des questions posées à l’équipe et à certaines personnes individuellement.

Avant la séance

Avant la présentation, chaque équipe doit avoir stabilisé:

le dépôt GitHub final;
le README;
le produit final dans le format approuvé;
docs/contributions.md;
docs/ai-log.md lorsque l’IA a été utilisée de façon significative;
docs/note-technique-stt6230.md pour les personnes inscrites à STT-6230;
une issue ou pull request utilisée pour la revue de code;
un bilan individuel final ou une section équivalente dans le portfolio.

Remise avant la séance

Le dépôt final doit permettre de retrouver sans ambiguïté:

le lien vers le produit présenté;
la commande ou procédure minimale de reproduction;
l’issue ou la pull request choisie pour la revue de code;
le fichier docs/contributions.md;
le fichier docs/ai-log.md si l’IA a été utilisée de façon significative;
le bilan individuel final ou le lien vers le bilan dans le portfolio;
la note technique STT-6230 lorsque pertinente.

La séance ne sert pas à corriger un dépôt incomplet. Elle sert à défendre le travail remis, expliquer les choix et discuter les limites.

Présentation du projet

La présentation doit être courte et centrée sur le produit livré.

Elle doit couvrir:

la question ou le problème étudié;
la source de données;
le produit final;
les décisions techniques importantes;
une démonstration du résultat;
les validations effectuées;
les limites du travail;
une piste d’amélioration réaliste.

Le support peut être simple: quelques diapositives, une page Quarto, une section du rapport ou une démonstration structurée du dépôt.

Revue de code

La revue de code porte sur un extrait significatif du dépôt. L’objectif est de montrer que l’équipe peut lire, expliquer et critiquer son propre code.

L’extrait peut être:

une fonction importante;
un script de nettoyage;
une étape du pipeline;
une visualisation complexe;
une pull request;
une correction faite après rétroaction.

Pendant la revue, l’équipe doit expliquer:

le rôle du code;
les entrées et sorties;
les choix faits;
les limites ou fragilités;
les tests, vérifications ou contrôles réalisés;
ce qui serait amélioré avec plus de temps.

Bilan individuel

Chaque personne doit pouvoir expliquer sa contribution. Le bilan individuel doit être accessible dans le portfolio individuel ou dans un fichier clairement identifié du dépôt d’équipe.

Le bilan doit indiquer:

les contributions principales;
les traces GitHub associées;
les éléments relus, testés ou corrigés;
les apprentissages réalisés;
les difficultés rencontrées;
l’usage de l’IA lorsque pertinent;
une autoévaluation brève de la contribution.

Le bilan ne remplace pas les traces GitHub. Il sert à les expliquer.

Le lien vers le site Quarto personnel peut être ajouté au bilan individuel, surtout si le site reprend une réalisation liée au projet. Ce lien ne remplace pas les preuves de contribution dans le dépôt d’équipe.

Traces attendues

Pull request ou issue.
Commentaire de revue.
Support bref de présentation.
Démonstration.
Dépôt final propre.
docs/contributions.md.
Bilan final individuel ou lien vers le portfolio.
Contributions vérifiables.
Déclaration IA si l’IA a été utilisée de façon significative.

Points à vérifier

Le projet se relance.
Les contributions individuelles sont vérifiables.
Les limites sont nommées clairement.
Les choix techniques sont justifiés.
Les attentes supplémentaires STT-6230 sont explicites lorsque nécessaire.

Attentes pour STT-6230

Les personnes inscrites à STT-6230 doivent être prêtes à expliquer la note technique ajoutée au projet.

Les questions peuvent porter sur:

la comparaison d’approches;
la validation supplémentaire;
l’analyse de performance;
l’automatisation du pipeline;
les limites méthodologiques;
le plan de mise en production ou de maintenance;
la robustesse du pipeline.

Rôle de l’IA

L’IA peut être utilisée pour préparer, relire ou améliorer la présentation, mais l’équipe demeure responsable du contenu présenté.

Les usages significatifs doivent être déclarés dans docs/ai-log.md. Une réponse générée par IA ne doit pas être présentée comme une justification technique sans vérification.