l'usage de l'IA dans le projet

R3.01/sae/README.md

@@ -37,11 +37,81 @@ La [base de données](./sql/game.sql.gz) a la structure suivante :
   - le prénom, nom des membres du binômes
   - **l'url de votre site sur dwarves.iut-fbleau.fr**
 
-> Les outils de génération de code à base d'IA sont formellement interdits.
+## Usage de l'IA
+
+### L'IA est autorisée mais ne remplace pas la compréhension
+
+Le recours a l'IA peut être autorise comme outil d'assistance, au même titre qu'une documentation, un forum technique ou un IDE.
+En revanche :
+- tout code rendu doit être compris par l'étudiant;
+- tout code non expliqué ou non modifiable en situation sera considéré comme non acquis;
+- l'étudiant reste responsable de la qualité, de la sécurité et de la cohérence du code rendu.
+
+## Règles communes concernant l'usage de l'IA
+
+1. L'usage de l'IA est autorisé comme outil d'assistance.
+2. Tout code rendu doit pouvoir être expliqué et modifié par l'étudiant.
+3. Les propositions de l'IA doivent être relues, testées et adaptées.
+4. Un code non compris ou non maitrise pourra être considére comme non acquis.
+5. La transparence sur l'usage de l'IA est attendue dans le journal de bord, dans le dépôt et en soutenance.
+
+Exemple de contenu attendu dans le journal sur la partie "Usage de l'IA":
+- les prompts utilisés;
+- les extraits de réponse juges utiles;
+- ce qui a été retenu, adapte ou rejeté;
+- les vérifications effectuées après usage.  
+
+## Organisation générale de l'évaluation
+
+### Workflow de travail attendu
+
+Afin de structurer le travail, de faciliter le suivi, le projet devra s'appuyer sur un workflow Git simple et obligatoire.
+
+Pour chaque séance :
+
+1. Vous devrez créer une branche de travail dédiée a la séance;
+2. Vous devrez pousser régulièrement vos modifications sur cette branche au cours de la séance ;
+3. en fin de séance, vous devrez ouvrir une "Pull Request" vers la branche cible définie (main) pour le projet;
+4. Vous devrez assigner cette Pull Request a l'enseignant;
+5. L'enseignant examinera et approuvera la Merge Request pour valider le travail réalisé ;
+6. une fois la Merge Request approuvée, vous pourrez procéder au merge.
+
+> Il est recommandé que les messages de commit et les titres de Merge Request soient explicites et lies a l'objectif technique traité.
+
+### Traces de progression
+
+Voici une liste d'éléments qui prouveront votre progression :
+
+- dépôt Git avec commits réguliers;
+- journal de bord court a chaque séance;
+- liste des taches réalisées et reste a faire;
+- tableau de répartition des responsabilités.
+
+Le journal de bord doit suivre une structure simple et identique pour tous les groupes. Il peut rester concis, mais il doit être présent a chaque séance.
+Structure recommandée pour chaque séance :
+- objectif de la séance;
+- travail réalisé;
+- difficultés rencontrées;
+- décisions prises ;
+- travail de chacun dans le binôme;
+- points a reprendre a la séance suivante;
+- usage de l'IA, si applicable.
+
+Le journal de bord doit être conservé dans un fichier Markdown (JOURNAL.md) du dépôt afin de rester consultable avec le reste des traces du projet.
 
 ## Évaluation
+
 - L'avancement de votre travail sera mesuré à chaque fin de séance de TP (4 semaines).
 - Votre réalisation sera évalué la semaine du 15 juin.
 - Tout dépot avec quelques commits récents se verra fortement pénalisé.
 - Un coefficient multiplicateur de 0 à 1 sera appliqué pour refléter l'équilibre du travail entre les deux membres du binôme.
 
+### La note ne repose pas uniquement sur le livrable final
+
+Une application fonctionnelle ne suffit pas a prouver l'acquisition des compétences. L'évaluation reposera sur plusieurs types de preuves :
+- un livrable fonctionnel;
+- des traces de progression;
+- une explication orale individuelle;
+- une courte mise en situation technique en direct.
+
+Quand le projet est réalisé en binôme, une partie de la portera sur le travail collectif. Chaque étudiant doit notamment être en mesure d'expliquer un extrait de code introduit ou modifié par son binôme.