Portfolio GitHub individuel

Le portfolio GitHub individuel est le dépôt de travail personnel utilisé pendant toute la session. Il montre comment les lectures, les exercices, les séances, les défis, le projet et les rétroactions sont transformés en productions concrètes.

Le portfolio n’est ni une collection d’énoncés ni un dossier assemblé à la fin de la session. Il contient le travail de l’étudiante ou de l’étudiant et rend sa progression visible dans le temps.

Modalités d’évaluation

Élément	Modalité
Pondération	20 %
Type	Individuel, cumulatif
Jalon 1	Mercredi 16 septembre 2026 à 16 h 20, semaine 3, 4 points
Jalon 2	Semaine 9, 6 points
Jalon 3	Semaine 14, 10 points
IA	Permise, déclarée
Évaluation	Consultation directe du dépôt GitHub personnel par la personne enseignante, dans son état à l’échéance

Grille détaillée: Grille d’évaluation du portfolio.

À chaque jalon, enregistrez vos changements dans des commits et poussez-les sur GitHub avant l’échéance indiquée dans Brio. Aucune fiche, aucun fichier ni identifiant de commit n’est à remettre dans Brio pour le portfolio.

Ce qui alimente le portfolio

Le travail hebdomadaire peut partir de plusieurs composantes du cours.

Point de départ	Exemples de traces personnelles
Lecture	synthèse courte, exemple personnel, essai de code, question documentée
Exercice	démarche, code, résultat, visualisation, autre méthode
Séance ou laboratoire	fichier produit, diagnostic, erreur comprise, vérification
Défi technique	réflexion après la remise, amélioration sur un cas analogue, apprentissage transféré
Projet d’équipe	contribution individuelle, fonction réutilisable, prototype, décision expliquée
Rétroaction	version améliorée, comparaison avant-après, correction personnelle

Une trace n’a pas besoin d’être parfaite. Elle doit toutefois être personnelle, compréhensible et assez documentée pour montrer ce qui a été tenté, appris ou vérifié.

Travail personnel seulement

Le dépôt contient uniquement le travail produit par l’étudiante ou l’étudiant.

Ne pas copier les énoncés du cours dans le dépôt.
Ne pas déposer les corrigés fournis par le cours.
Ajouter plutôt un lien vers la lecture, l’exercice ou la consigne utilisée.
Distinguer clairement le travail individuel des contributions réalisées dans le projet d’équipe.
Conserver les versions successives lorsqu’une erreur est corrigée ou qu’une production est améliorée.

Le mot « correction » désigne ici une amélioration apportée à son propre travail. Il ne désigne jamais la copie d’un corrigé fourni.

Dépôt créé au début de la session

Avant le premier laboratoire, l’équipe enseignante crée pour chaque personne inscrite un dépôt privé à partir du modèle commun STT-4230-6230/portfolio-stt4230-6230-a2026-template. Le dépôt est nommé portfolio-stt4230-IDUL pour une inscription à STT-4230 et portfolio-stt6230-IDUL pour une inscription à STT-6230. Dans les deux cas, IDUL est remplacé par l’identifiant ULaval de la personne étudiante, puis l’accès est accordé à son compte GitHub.

La personne étudiante ne crée pas elle-même un nouveau dépôt et n’utilise pas le bouton de copie du modèle. Pendant le premier laboratoire, elle clone le dépôt qui lui a été attribué, complète les fichiers fournis et pousse ses premiers commits.

Le dépôt de départ contient seulement:

portfolio-sttSIGLE-IDUL/
  README.md
  .gitignore
  portfolio-stt4230-6230.Rproj
  semaines/
    semaine-01/
      README.md

Il ne contient pas d’avance les dossiers des semaines 2 à 15. Chaque semaine, la personne étudiante crée le dossier nécessaire et fait évoluer la structure selon son travail réel.

Pendant le premier laboratoire, la personne étudiante complète son nom dans le README.md, remplit semaines/semaine-01/README.md, ajoute son diagnostic technique et conserve ces changements dans des commits personnels lisibles.

Des sous-dossiers comme data/, figures/, R/, reports/, tests/ ou docs/ sont ajoutés seulement lorsqu’ils deviennent utiles. Le README doit expliquer les choix d’organisation importants.

Travail hebdomadaire minimal

Chaque semaine, le dépôt doit montrer au minimum:

une trace concrète issue d’une lecture, d’un exercice ou d’une activité du cours;
au moins un fichier produit par la personne étudiante;
une courte explication du travail réalisé;
une vérification, une difficulté ou une piste d’amélioration;
des commits dont les messages permettent de comprendre la progression.

La trace peut être un fichier .R, .qmd ou .md, une fonction, un test, une figure, un rapport, un résultat reproductible ou une note technique. Une semaine de défi ou de projet peut produire une réflexion ou une trace de contribution plutôt qu’un nouvel exercice isolé.

Dossier de la semaine

Le README.md de chaque semaine indique au minimum:

la ressource, la lecture, l’exercice ou l’activité utilisée;
ce qui a été produit;
les fichiers importants;
ce qui a été vérifié;
une difficulté, une question ou une prochaine étape.

Exemple:

# Semaine 4

## Point de départ

Lien vers la lecture ou l'exercice utilisé.

## Travail personnel

Description courte du travail réalisé.

## Fichiers produits

- `nettoyage.R`

## Vérification

Description de la vérification effectuée.

## Difficulté ou prochaine étape

Question, limite ou élément à reprendre.

Commits et progression

Il n’y a pas de quota artificiel de commits. L’historique doit cependant montrer un travail régulier et des changements regroupés par intention.

Un historique utile contient:

des messages de commit compréhensibles;
des ajouts répartis pendant la session;
des reprises visibles après une erreur ou une rétroaction;
peu de gros commits vagues effectués seulement avant un jalon.

Lorsqu’une amélioration importante est apportée, conserver un commit avant et un commit après permet de montrer la progression.

Jalons évalués

Jalon 1, semaine 3, 4 points

Échéance: mercredi 16 septembre 2026 à 16 h 20, à la fin de la séance de semaine 3. La personne enseignante évalue directement le contenu disponible dans votre dépôt GitHub personnel à cette échéance.

Avant l’échéance, vérifiez les éléments suivants:

Le dépôt privé attribué par l’équipe enseignante est accessible et le README.md général présente votre travail et permet de retrouver les dossiers des semaines.
Les dossiers semaines/semaine-01/, semaines/semaine-02/ et semaines/semaine-03/ contiennent chacun au moins une production personnelle issue du cours. La trace de semaine 3 peut être réalisée pendant la séance du 16 septembre.
Le README.md de chaque semaine indique la ressource utilisée, le travail réalisé, les fichiers produits, ce qui a été vérifié et une difficulté, une question ou une prochaine étape.
Au moins une vérification réelle ou une amélioration de votre travail est documentée. Une trace incomplète est acceptable si la démarche, le blocage et la prochaine étape sont expliqués.
L’historique Git montre la progression avec des messages de commit compréhensibles. Il n’y a pas de nombre imposé de commits.
Les usages significatifs de l’IA sont déclarés dans docs/ai-log.md, lorsque pertinent.

Critère	Points
Démarrage du dépôt: accès, README général et structure	1
Premières traces: productions personnelles des semaines 1 à 3	1
Documentation: point de départ, fichiers, vérification et prochaine étape	1
Progression Git: travail réparti dans le temps et messages compréhensibles	1
Total	4

Ce premier jalon porte sur le démarrage et les premières traces. Il n’exige pas de site Quarto, de configuration renv ni d’architecture avancée. Les mêmes critères s’appliquent à STT-4230 et à STT-6230; l’approfondissement propre à STT-6230 est attendu au jalon 2 ou 3.

Terminez par un git push, puis ouvrez votre dépôt sur GitHub pour vérifier que les derniers fichiers et commits y apparaissent. Un commit enregistré seulement sur votre ordinateur n’est pas visible pour la personne enseignante.

Jalon 2, semaine 9, 6 points

Le dépôt doit montrer:

une progression régulière depuis le premier jalon;
plusieurs types de traces, notamment des lectures et des exercices;
au moins une amélioration apportée après une difficulté ou une rétroaction;
une organisation adaptée aux fichiers réellement produits;
des chemins relatifs et des indications suffisantes pour relancer les productions principales;
une déclaration IA lorsque son usage a été significatif.

Jalon 3, semaine 14, 10 points

Le dépôt final doit présenter:

une progression cohérente sur l’ensemble de la session;
un README à jour qui permet de retrouver les semaines et productions importantes;
du code et des documents relançables depuis la racine du projet;
des vérifications, tests ou contrôles adaptés aux productions;
un court bilan final sur les apprentissages, les difficultés et les améliorations;
une déclaration complète des usages significatifs de l’IA;
le lien vers le site Quarto personnel et la trace sélectionnée pour ce site.

Reproductibilité

Le portfolio utilise des chemins relatifs. Les dépendances nécessaires sont indiquées dans le README ou dans un fichier dédié. renv est ajouté seulement lorsqu’il devient utile pour reproduire les travaux présents dans le dépôt.

Avant un jalon, vérifier au minimum:

que les fichiers importants s’ouvrent ou s’exécutent depuis la racine du projet;
que les données utilisées peuvent être retrouvées légalement;
qu’aucun mot de passe, jeton, secret ou fichier confidentiel n’est suivi par Git;
que les résultats annoncés correspondent aux fichiers présents dans le dépôt.

Les données doivent respecter les règles de provenance et de droit d’usage décrites dans Données autorisées.

Déclaration de l’IA

L’IA est permise et déclarée pour le portfolio. Un fichier comme docs/ai-log.md est créé lorsque l’IA influence de façon significative une production, une décision, du code ou un texte.

Une entrée importante indique:

l’outil utilisé;
la tâche demandée;
ce qui a été retenu;
les vérifications effectuées;
les modifications intégrées au travail personnel.

Lien avec le site Quarto personnel

Le portfolio est le dépôt de progression. Le site Quarto personnel est une vitrine publique distincte.

À la fin de la session, le README ou le bilan final du portfolio indique:

l’adresse du site Quarto personnel;
l’adresse du dépôt source du site;
la trace du portfolio sélectionnée pour le site;
le fichier, le dossier ou le commit correspondant, lorsque ce lien peut être publié.

Il n’est pas nécessaire de rendre tout le portfolio public dans le site personnel. Une trace contenant des données ou des informations qui ne doivent pas être publiées doit être présentée sous une forme publique résumée.

Différenciation STT-4230 / STT-6230

Pour STT-4230, le portfolio doit montrer un travail régulier, compréhensible, reproductible et correctement documenté.

Pour STT-6230, au moins une trace ajoute une dimension technique plus approfondie, par exemple une comparaison d’approches, une validation plus formelle, une analyse de performance ou une discussion méthodologique des limites.

Évaluation directe dans GitHub à chaque jalon

Le même dépôt privé attribué par l’équipe enseignante est évalué pendant toute la session. La personne enseignante consulte directement son contenu et son historique Git dans leur état à l’échéance indiquée dans Brio.

Avant chaque échéance:

enregistrez les changements pertinents dans des commits aux messages compréhensibles;
poussez ces commits sur GitHub avec git push;
ouvrez le dépôt dans votre navigateur et vérifiez que les fichiers et les derniers commits sont présents;
vérifiez que les README permettent de retrouver les productions et que la déclaration IA est à jour, lorsque pertinente.

Il n’y a aucune fiche à remplir ni aucun fichier, lien ou identifiant de commit à transmettre dans une boîte de dépôt Brio. Aucune archive ZIP ni nouvelle copie du dépôt n’est demandée.