Rapport de TP — attendus et canevas

Wed, 14 Oct 2026 00:00:00 +0000

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

En-tête — identité, groupe, cours, TP, date et lien Git.
Étapes du TP — pour chaque étape : réalisation, captures légendées, démarche et choix, difficultés et solutions éventuelles.
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.

Configuration de Unity — PC du site de Brest

Mon, 02 Feb 2026 00:00:00 +0000

Unity Hub et Unity 6.3 LTS

Sur les machines de l’école, lancez Unity Hub depuis le menu des applications (sur Linux : Applications > Développement > Unity Hub, selon le poste). Connectez-vous à votre compte Unity ; créez-en un si nécessaire et suivez les indications de licence du poste.

Dans Installs, utilisez Unity 6.3 LTS, déjà installé. Son numéro commence par 6000.3 ; gardez le patch installé pour le TP.

Si l’installation n’est pas répertoriée, utilisez Locate et sélectionnez l’exécutable Editor/Unity de l’installation 6.3 présente sur le poste. Le chemin exact dépend de la configuration de l’école : demandez-le à l’enseignant si nécessaire. L’ancien chemin /opt/img/Unity-2021.3.9f1/Editor/Unity ne correspond plus à la version du cours.

Créez le projet avec Universal 3D (URP). Dans Window > Package Management > Package Manager, préparez l’Input System, Unity UI et les dépendances du contrôleur FPS pendant la séance. Dans Edit > Project Settings > Player > Other Settings > Configuration, choisissez Active Input Handling = Input System Package (New) si ce réglage n’est pas déjà sélectionné, puis acceptez le redémarrage demandé.

Pour exporter, le module de build de la plateforme du poste doit être installé. S’il manque, signalez-le à l’enseignant ; Unity Hub > Installs > menu de l’installation > Add modules permet de l’ajouter lorsque les droits du poste le permettent.

Visual Studio Code (éditeur C#)

L’intégration actuelle repose sur l’extension Unity publiée par Microsoft dans VS Code. Elle installe les dépendances C# nécessaires, dont C# Dev Kit. Dans le Package Manager de Unity, utilisez Visual Studio Editor, en version stable proposée pour l’éditeur et au minimum 2.0.20. L’ancien package Visual Studio Code Editor n’est plus maintenu. Instructions Microsoft.

Pour ouvrir les scripts dans VS Code :

Dans Unity, ouvrez Edit > Preferences > External Tools (sur macOS, les préférences se trouvent dans le menu Unity).
Dans External Script Editor, choisissez Visual Studio Code ou utilisez Browse…. Sur les postes Linux où il est installé à cet emplacement, l’exécutable est /usr/bin/code.
Régénérez les fichiers de projet avec Regenerate project files, si nécessaire, puis ouvrez un script depuis Unity pour charger le projet complet dans VS Code.

En cas de problème d’auto-complétion

Vérifiez que les extensions Microsoft Unity, C# et C# Dev Kit sont actives et que le package Visual Studio Editor est installé.
Ouvrez le projet Unity complet, pas un fichier C# isolé. Régénérez les fichiers de projet puis rechargez la fenêtre VS Code.
Consultez les messages de l’extension et corrigez les erreurs de compilation dans la Console Unity.
Si un runtime ou SDK .NET est demandé, suivez les indications de l’extension et faites vérifier l’installation du poste.

Les anciennes consignes OmniSharp Use Global Mono = always concernent une autre génération d’intégration et ne doivent pas être appliquées par défaut à cette configuration.

Choix du dossier de projet

Placez le projet sur le disque local, par exemple dans l’espace local du poste ou /tmp sous Linux, si ce dossier est prévu pour la séance. Le SSD local évite les ralentissements d’import et de compilation du disque réseau.

Sauvegarde en fin de séance

L’espace temporaire peut être supprimé au redémarrage. Sauvegardez et copiez votre projet sur votre espace personnel avant de quitter le poste. Gardez Assets (avec ses fichiers .meta), Packages et ProjectSettings. Les caches Library et Temp peuvent être régénérés par Unity.

Practical Guides | Étienne Peillard