Principes généraux

Le TER (Travail d'Etude et de Recherche) est un stage qui s'effectue par groupe de 2 à 4 étudiants. Il sanctionne la fin du Master 1 et dure à plein temps environ 2 mois. L'évaluation du TER se fait à travers un rapport écrit (50%), une soutenance orale (40%), et un avis de l'encadrant (10%). Le faible poids accordé à l'avis de l'encadrant permet de lisser les différences d'appréciation.

Le TER sert à évaluer la capacité des étudiants à travailler en groupe sur un thème imposé en durée limitée. Vous devez convaincre le jury que vous êtes devenus (ou être en train de devenir) des informaticiens, c'est à dire avant tout des scientifiques. Cela signifie en pratique que toute décision que vous êtes amenés à prendre doit être justifiée par des critères objectifs (coût, performance...).

La gestion de projet est une part importante du TER. Certains groupes choisissent de nommer un chef de projet mais ce n'est pas obligatoire. Dans tous les cas, être chef de projet n'est pas une excuse pour faire moins que les autres. Il s'agit d'une charge supplémentaire qui s'ajoute au travail normal.

Globalement le jury de TER est avant tout intéressé par le processus de développement et d'analyse que vous avez eu à mettre en place. Il est arrivé que des groupes ayant écrit un bon logiciel aient une note moyenne parce qu'ils étaient tombé dans tous les travers possibles: choix technologiques douteux, aucune planification, aucun test...

Rapport

Le rapport sera relu par un ou deux rapporteurs qui noteront le résultat suivant plusieurs critères, tels que lisibilité, travail effectué, orthographe... Il ne devra pas excéder 30 pages de texte (11pt), hors annexes. Un plan possible pour le rapport est

1. Présentation du sujet
2. Etat de l'art
3. Travail effectué (choix technologiques, implémentation...)
4. Gestion de projet
5. Conclusion

Lors de la rédaction du rapport, vous pouvez supposer que le relecteur a globalement le même niveau que vous en informatique. Mais c'est une erreur de supposer qu'il connait le sujet de votre TER. Il faut donc présenter le contexte général, les technologies utilisées. C'est l'état de l'art.

Dans la partie travail effectué, vous devez présentés les choix technologiques que vous avaient été amenés à effectuer, décrire d'éventuels logiciels que vous avez écrit, présenter des algorithmes... Encore une fois, tout choix doit être justifié. Si la décision vient de l'encadreur, ce n'est pas une décision mais une contrainte, et doit être présenté comme tel. La justification doit être rationnelle. Par exemple, choisir un langage parce que c'est "facile" ou "fun" ou "conseillé dans RoXXor Magazine" n'est pas acceptable. Évitez de mettre la JavaDoc complète, 500 screenshots... le but n'est pas de remplir mais de convaincre.

Dans la section Gestion de Projet, vous devrez présenter tout ce qui a permis, au sens large, de faire fonctionner votre équipe. Le travail effectué par chacun des membres du groupe devra être détaillé (diagramme camembert par exemple). Si vous avez été amené à utiliser des logiciels de gestion de source (CVS, SVN...) ou des outils de test, vous pouvez les présenter ici (ou en 3 si vous préférez).

La conclusion consiste en un résumé des taches effectuées, des taches restant à faire, des problèmes rencontrés... Évitez la partie bateau expliquant combien le TER a été profitable à votre cursus, personne n'y croit.

Le rapport devra être remis en 3 exemplaires papier recto-verso ainsi qu'un pdf. Pensez à la planète et à vos finances, imprimez le sur du papier standard avec des agraffes. Une couverture plastique/cuir ne sert que de support à poussière.

Soutenance orale

La soutenance orale dure entre 15 et 20 minutes, suivie de quelques questions, le tout en français. Le temps de parole doit être réparti équitablement entre les membres du groupe. Lors de cette soutenance, vous devez présenter l'ensemble du travail effectué en TER. Le plan de la présentation suit globalement celui du rapport.

Quelques conseils :

• La soutenance sert à convaincre le jury que vous êtes des informaticiens
• Ne prenez la parole que lorsqu'on vous la donne. Attendez le signal du jury pour commmencer, dites bonjour, présentez vous.
• Répétez votre présentation avant, ne dépassez pas le timing. Il vaut mieux faire moins que trop.
• Pensez à bien présenter votre travail. Si vous avez fait une GUI, montrez un screenshot ou faites une démo.
• Chaque slide ne doit contenir qu'*une* information importante. Pour chaque slide, demandez vous quel est le message que vous voulez faire passer. Si vous n'en trouvez pas, le slide ne sert à rien.
• Numérotez vos slides sous la forme n/total pour que le jury sache où vous en êtes de votre présentation
• Pendant la séance de questions, ne coupez pas la parole au jury ou à vos camarades. Vos réponses doivent être concises.

Problèmes et solutions

Le sujet final ne correspond pas à celui proposé par l'encadreur initialement

Ce n'est pas grave si les changements ont été fait en accord avec l'encadreur. Si vous avez décidé de ne pas suivre le plan initial, il vous faudra une très bonne explication.

Un des membres du groupe ne travail pas

Deux cas de figures, soit vous en parlez avec votre encadrant qui tentera de résoudre le problème ou réduira le sujet. Le jury tiendra compte de cela dans l'évaluation du rapport et lors de l'oral. Soit vous ne dites rien, et vous assumez la note globale.

Les membres du groupe ont des notes différentes

C'est voulu. La distinction peut se faire sur l'oral ou sur la note de l'encadrant. Si vous pensez que c'est injuste, demandez à votre encadreur ou au coordinateur.

-- FabriceHuet - 26 Jan 2009
to top