Valoriser un projet de fin d'étude : des points à ne pas oublier

Il est, des fois, nécessaire, de voir la ligne de la fin pour mieux se motiver. En effet, plusieurs mois de travail sur le même projet peuvent donner cette impression de noyade entre les détails, la finition de la rédaction de l'état de l'art, le début du développement et ainsi de suite; il devient nécessaire de prendre un pas de recule et de voir l'intégralité du projet, premièrement, pour voir est ce que le projet avance dans la bonne direction (cela est une autre topique) et deuxièmement, et le plus important, pour voir la ligne de la fin qui devient de plus en plus joignable.

Mais, il existe une grande différence entre les détails du projet et le travail final qui sera présenté. En effet, le travail réalisé doit être résumé (seuls les éléments les plus importants sont gardés), nettoyé (surtout pour l'application, aucun code de test, d'expérimentation ou d'exemple ne doit figurer dans le projet final; il est même préférable de fournir un exécutable ou quasiment un installer) et bien présenté (nous parlerons de la présentation Power Point très prochainement dans un autre article).
Cela est le travail qui sera vu par le jury et sur lequel les étudiants seront évalués. Néanmoins, il est loin d'être le travail réellement réalisé. Lorsque nous parlons de "tout le travail réalisé", nous impliquons aussi :

1. La compréhension de la problématique : la première étape et c'est l'étape la plus importante, malgré que je préfère que cette phase doit être faite bien avant le choix du projet. La compréhension de la problématique est la clé principale vers une meilleure motivation des étudiants, c'est le carburant qui les poussera tout au long de sa réalisation; elle nécessite des fois un effort particulier.
2. La recherche de la documentation : une activité ordinaire pour tous les chercheurs mais pas forcément facile. Plusieurs domaines ne sont pas bien documentés surtout sur le niveau technique, d'autres sont assez nouveaux qu'il y a pas assez de références ou de travaux bien élaborés pour se référencer et pour s'auto-évaluer (prenez l'aspect hardware des outils de Virtual Reality comme exemple).
3. Les lectures de découverte : lorsqu'on entame un projet dans un domaine particulier, il est tout à fait normal de commencer par comprendre le domaine dans sa globalité : ses motivations, les grandes axes de recherche, sa valeur ajoutée, les produits réalisés, etc. Ces lectures sont faites par, pratiquement, tout les étudiants sans qu'elles touchent directement le coeur de la problématique traitée.
4. Les lectures spécialisées : ceux sont les lectures qui touchent directement au coeur de la problématique traitée.
5. La reprise de la problématique : c'est une activité essentielle qui consiste à reprendre la problématique mais en exploitant les connaissances acquises pendant les deux phases de lecture. Les étudiants doivent être capables, à ce stade, de mieux voir la problématique, ses dimensions, son importance et, le plus important, une solution possible pour elle.
6. L'analyse : une tentative de formuler le raisonnement de résolution de la problématique posée; le résultat peut être un nouveau processus, un nouveau modèle ou une architecture.
7. La conception et la réalisation : c'est les deux dernières étapes; elles permettent de concevoir et de réaliser un système suivant la solution proposée.

Plusieurs étapes et un effort continu de plusieurs mois pour les terminer. Néanmoins, tout se travail ne sera pas présent après le résumé, le nettoyage et la bien présentation. Nous pouvons constater cela en revoyant les critères d'évaluation d'un projet de fin d'étude :

1. Le rapport : résultat de la rédaction. Il reflète les capacités d'expression des étudiants et leurs compétences de bien présenter une solution,
2. La démonstration : généralement basée sur un scénario, elle présente un déroulement de l'utilisation de l'application développée. Les membres du jury peuvent demander une exécution détaillée ou bien se limiter aux cas principaux traités par l'application. Ils peuvent, éventuellement, voir le code source de l'application,
3. La présentation Power Point : la présentation en publique du projet développé. Limitée à 20 minutes, elle doit se limiter aux points essentiels seulement,
4. La session des Questions/Réponses : une évaluation réelle de la capacité des étudiants à gérer une conversation pourtant sur leur projet et à justifier et convaincre les membres de jury par les différents choix et décisions pris tout au long du projet. Elle peut contenir des questions de compréhension qui permettent aux membres du jury de voir le niveau réel de compréhension des étudiants de la problématique et du domaine traités (sans se limiter à l'état de l'art présenté).
5. L'évaluation peut, parfois, inclure une note donnée par l'encadreur qui porte essentiellement sur le sérieux, l'assiduité et l'attitude des étudiants.

Revoyons ces deux listes : la liste des travaux réalisés et la liste des éléments pris en compte pendant l'évaluation. La différence est immense. Le jury ne pourront pas voir une grande partie des efforts fournis par les étudiants pour accomplir le projet. Sauf les lectures approfondies, l'analyse, la conception et la réalisation, les jury ne verrons pratiquement rien. Sans trop détailler et même sans trop se focaliser sur ce point, nous pouvons lister les éléments suivants :

1. La recherche de la documentation : comme mentionné ci-dessus, quelques domaines ne sont pas aussi accessibles que d'autres, rechercher un document ou contacter un pionnier du domaine ne peut pas être toujours une tâche facile, et toute tâche qui nécessite une semaine est très coûteuse (5% du temps total pour un projet de fin d'étude d'un semestre).
2. La lecture en elle même et les efforts de traduction : ce point est fortement lié au précédent; l'absence d'une documentation dans la langue de rédaction oblige les étudiants à procéder à la traduction en essayant de garder au mieux le point de vue de l'auteur d'origine. Un effort qui peut être considérable si la grande majorité de la documentation est d'une langue différente, néanmoins, cet effort est rarement valorisé.
3. L'analyse et la lecture des codes sources des autres projets : une étape importante et des fois obligatoire. Étudier le code d'un projet qui traite (ou non) la problématique posée pour en tirer les points forts, pour éviter de tomber dans les mêmes erreurs ou pour mieux comprendre les techniques de modélisation, d'implémentation et d'optimisation sur un niveau plus bas, est une tâche très difficile, mais, rarement valorisée.
4. L'apprentissage d'une nouvelle technologie : à titre d'exemple, nous travaillons actuellement sur une application suivant une architecture Orientée Service. Nous comptons utiliser la plate forme J2EE pour y parvenir, néanmoins, les étudiants n'ont jamais utilisé l'ensemble des technologies WS-* ni le JSP. Les premiers testes nous ont coûté deux à trois semaines (environs 15% du temps total du projet).
5. Faire face aux problèmes techniques particuliers : il est très probable que chaque étudiant rencontre l'un des ses problèmes très particuliers qui peut le coincer pour 3 ou 4 jours ou même une semaine entière pour réaliser enfin que le pilote de sa carte réseau en particulier n'est pas compatible avec telle ou telle technologie de virtualisation (à titre d'exemple). C'est le type des problèmes qui ne figurent nul-part : ni dans la documentation officielle, ni dans les livres de la bibliothèque et même pas sur les pages des forums.

La liste peut être longue selon le projet et selon les domaines traités. Malheureusement, ces efforts ne sont pas pris en compte dans le barème.
La solution est possible mais les étudiants font, généralement, deux erreurs :

• Ignorer complètement ces aspects : en ignorant de parler, complètement, de ces aspects par les étudiants réduit considérablement la valeur de leur projet qui peut être vu comme simple, facile et souple.
• Compter sur l'encadreur pour faire cette tâche : cela ne va, probablement, pas marcher. L'encadreur a quelques minutes seulement, il peut les consacrer pour répondre à des questions posées et à lesquelles les étudiants n'ont pas pu répondre ou à expliquer le cadre et le contexte général du projet. Il peut les consacrer, aussi, à critiquer à son tour ses étudiants (on parlera de cela dans un autre "bref" article).

Alors, le message de cet article est "apprenez à vendre". Vendre votre projet est comme vendre n'importe quel autre produit. Il vous faut quelques points essentiels :

Vous devez parler des efforts "particuliers" que vous avez fournis :

Soit pendant la démonstration ou bien durant la présentation (les problèmes techniques particuliers doivent être cités pendant la démonstration).

Citez les mais il ne faut pas trop insister sur eux : 

Une fois, au bon moment, lorsque vous êtes sûr que les membres du jury sont entrain d'écouter, et une seule phrase.

Profitez de la session des questions/réponses : 

Un exemple :
Membre du jury : Pourquoi avez vous choisi Derby comme SGBD ?
Vous : Nous avons choisi Derby parce qu'il peut être utilisé comme une API. Malgré que ce choix nous a coûté une semaine pour mieux comprendre ses différences par rapport à un SGBD avec un serveur et bien maîtriser ses techniques et sa configuration, nous pensons qu'il était le plus adéquat pour une application avec les contraintes définies dans le cadre de notre projet.
Cette phrase ne prendra que 30 seconds, mais elle vous aidera à mieux valoriser vos efforts.

Préparez un Annexe et faites référence à tout moment possible (essentiellement durant la démo s'il s'agit de la partie technique): 

A titre d'exemple, nous avons créé un annexe pour présenter les différentes étapes à suivre pour développer un plug-in (un block) pour la plate forme Moodle puisqu'au moment où le projet a été réalisé, aucune documentation complète et officielle n'était disponible. Cet annexe a parfaitement joué son rôle.

Un dernier mot

Notez bien que je parle seulement des tentatives réussites : si vous avez opté pour un choix technique ou conceptuel qui s'est terminé par un échec, il est très difficile de le valoriser sauf si ce résultat touche le coeur de votre problématique, autrement, le mentionner sera compté comme un point négatif parce que vous avez fourni un effort sans pouvoir atteindre un résultat (je parlerai aussi de ce point dans un article prochain).
C'était un petit rappel pour tous les étudiants qui sont entrain de réaliser leurs projets de fin d'étude. Notez tous ce que vous faites et valorisez vos efforts, c'est votre responsabilité et c'est votre projet.