Rapport de TP — attendus et canevas

Le rapport doit permettre de comprendre ce que vous avez fait, comment vous l’avez fait et ce que vous avez compris. Il doit être court, visuel et facile à parcourir : privilégiez les captures d’écran et les explications brèves. Je connais le sujet du TP ; présentez votre travail sans recopier ni réexpliquer l’énoncé.

1. En-tête et dépôt Git

Rendez votre rapport au format PDF. Au tout début, indiquez clairement :

• Les noms et prénoms de toutes les personnes ayant réalisé le TP.
• La formation, la promotion et le groupe.
• Le cours, le numéro et le titre du TP, ainsi que la date du rendu.
• Le lien vers le dépôt Git du projet, lorsqu’il est demandé. Même sans demande explicite, fournir ce lien est une bonne pratique.

Le dépôt doit être accessible à l’enseignant et permettre de récupérer le projet et de tester ses fonctionnalités. Indiquez les quelques consignes nécessaires pour le lancer, si besoin dans un README.

Facultatif, mais utile : organisez vos commits ou vos tags par question, étape ou fonctionnalité pour faciliter le suivi de votre progression et la correction technique.

2. Progression dans le TP

Suivez les grandes étapes du TP. Pour chacune, présentez :

• Ce que vous avez réalisé, avec une ou plusieurs captures d’écran lisibles et légendées montrant votre avancée.
• Comment vous avez procédé et ce que vous avez compris, en quelques phrases courtes ou quelques puces ; précisez les choix d’implémentation utiles à la compréhension.
• Les difficultés ou blocages rencontrés, s’il y en a eu : ce qui posait problème, ce que vous avez essayé et comment vous l’avez résolu. Si un problème reste ouvert, dites-le clairement.

Documentez les étapes intermédiaires, pas seulement le résultat final. Les images doivent permettre de suivre la construction de votre application et de voir les fonctionnalités réalisées au fil du TP. Une courte légende doit expliquer ce que chaque capture montre ou permet de vérifier.

3. Conclusion : état final et retour personnel

Terminez par un bilan bref :

• Ce que contient réellement l’application finale : fonctionnalités terminées et testées, éléments partiels ou manquants et limites connues.
• Éventuellement, un retour personnel : apprentissages, principales difficultés, améliorations possibles ou pistes pour aller plus loin.

Quelle place pour le code ?

Il est inutile de copier votre code dans le rapport. Un très court extrait de pseudocode ou de code peut aider à expliquer une fonction ou un choix précis, si cela rend l’explication plus simple.

Le rapport sert à évaluer votre démarche et votre compréhension. L’évaluation technique du code et les tests de l’application se font à partir du dépôt Git.

Canevas à reprendre

1. En-tête — identité, groupe, cours, TP, date et lien Git.
2. Étapes du TP — pour chaque étape : réalisation, captures légendées, démarche et choix, difficultés et solutions éventuelles.
3. Conclusion — état exact de l’application finale, limites et éventuel retour personnel.

Avant de rendre : vérifiez le PDF, l’identification des auteurs, la lisibilité des captures, la présence des étapes intermédiaires et l’accès au dépôt Git si vous en fournissez un.