L'incompétence : un obstacle à vaincre

En éditant les articles de cette série, je me suis toujours concentré sur les problèmes qui peuvent survenir et nuire au choix, à la gestion et à la réalisation d'un projet de fin d'étude. J'ai supposé que les deux parties de ce contrat, à savoir l'enseignant et les étudiants, ont la volonté de travailler et peuvent accomplir les tâches citées dans les différents articles (communication, lectures, analyse, etc.). Pour cet article, je vais parler de l'autre possibilité, et plus précisément côté étudiants (c'est très difficile de traiter l'incompétence de l'enseignant).

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.

La spécialisation des projets (sujets), une difficulté à vaincre

Vous êtes en 5ème année (ou en Master II pour le cursus LMD) et vous venez de choisir votre projet (sujet), vous êtes excités et prêts à lancer votre éditeur. Après 4 ans d'études et 9 semestres et 67 modules, 24 unités d'apprentissage et 8 sessions d'examens, il est temps de construire votre application, votre projet, n'est ce pas ? Malheureusement, Non, pas encore.

Il est évident qu'un projet (sujet) nécessite réellement les connaissances acquises durant tout le cursus. Premièrement, une utilisation efficace des outils dépend à de la maîtrise des notions sur les Systèmes d'exploitation ainsi que les techniques de compilation, le langage de programmation utilisé (syntaxe + API) et le passage vers un code machine "déployable". Deuxièmement, le développement d'une application, sans préciser son domaine, nécessite une compréhension profonde de l'algorithme, le codage d'information, les paradigmes de programmation et l'architecture des ordinateurs; c'est le minimum pour arriver à écrire un code fonctionnel. Troisièmement, l'utilisation de la moindre quantité des données persistantes nécessite l'utilisation des fichiers, des bases des données ou même les fichiers XML et JSON. Enfin, il est indispensable de comprendre les méthodologie de conception (objet ou autres), le génie logiciel et les bases de l'IHM et les techniques associées à leur réalisation (HTML, JS - jQuery, WPF, Swing, JavaFX, etc.) pour pouvoir concevoir une "bonne" application. Toutes ces connaissances (liste non exhaustive, c'est ce qui me vient à l'esprit maintenant) doivent être gardées en esprit à tout moment pendant toutes les étapes de recherche, analyse, conception, réalisation, rédaction et présentation  du projet (sujet).

Mais, est ce réellement suffisant ? Encore là, la réponse est négative. Tous ces éléments font partie de la "base" de l'informatique et ne sont pas suffisants pour travailler "efficacement" sur un projet (sujet) spécialisé. En effet, s'il s'agit d'un projet d'ingénieur (projet de réalisation) ou bien d'un sujet de recherche (exploration, expérimentation, comparaison, vérification d'une hypothèse), l'aspect "spécialisation" est très présent.

Un projet se focalise sur la réalisation d'un système fonctionnel et professionnel (sécurité, sauvegardes, disponibilité, facilité d'utilisation, documentation, etc.). Atteindre ce niveau nécessite une compréhension profonde du domaine étudié ou du champs d'application, et malgré qu'il n'est pas obligatoire de devenir un expert du domaine étudié, il est, comme même, préférable de connaître un certain niveau de détails pour mieux comprendre les enjeux, les risques et les bonnes pratiques des employés pour une meilleure conception des différentes parties (composants, répartition, IHM) de l'application. Nous n'oublions pas que le monde professionnel est géré par des lois complètement différents du monde académique : fixer un rendez-vous avec un chercheur ou bien avec l'encadreur est une tâche beaucoup plus facile que réunir le directeur général, le directeur du service informatique, le responsable du projet et le représentant des employés, tous, au même temps et autour de la même table; ce travail "du champs" est très bénéfique comme expérience professionnelle comme il représente une excellente opportunité pour approfondir les connaissances sur la théorie des organisations et sur les techniques de collecte des informations. Pour cela, une étude théorique préalable (introductions, aide-mémoire, résumés) ainsi qu'une étude sur le cas réel (étude de l'existant) sont des étapes essentielles pour la réussite du projet.

Les sujets de recherche se caractérisent par un aspect théorique plus riche; il est, dans la plupart des cas, demandé de devenir "pseudo" spécialiste du domaine. En effet, la compréhension du domaine en question doit inclure la compréhension des causes, des motivations, des points positifs, des points négatifs, des fondements théoriques, des applications précédentes, des difficultés rencontrées par les applications précédentes et plusieurs autres facteurs qui peuvent influencer l'élaboration d'une nouvelle hypothèse ou bien la vérification d'une hypothèse déjà faite. C'est de là que l'état de l'art tire son importance.

L'état de l'art doit regrouper et résumer toutes les informations théoriques nécessaires pour la compréhension de, à la fois, la problématique traitée et la solution proposée. A titre d'exemple, prenons le sujet suivant : “Proposition d’un processus semi-automatique de sélection des objets pédagogiques” (oui, oui, c'est mon sujet de magister, sur lequel j’ai travaillé avec M. F. Azouaou - pour le connaître c’est par ici ou ici, M. S. Batata - pour le contacter c’est par ici et le Professeur A. Balla - site perso). Dans ce sujet, nous avons tenté de résoudre un problème très courant et qui est rencontré par les enseignants durant la création d'un cours en ligne à partir d'un ensemble de ressources déjà disponibles dans un entrepôt des ressources pédagogiques (Non, c'est pas la même chose que les entrepôts des données / Oui, c'est les entrepôts des documents tels que les systèmes de stockages utilisés par la GED mais ils sont basés sur les descriptions détaillés  normalisées). Dans un domaine complètement différent, nous avons des notions très similaires : le développement à base de composant étudie la possibilité de construire une application à partir d'un ensemble de composants déjà disponibles et il (le domaine) définit plusieurs approches à suivre avec différents modèles de description qui utilisent à leur tour des méta-données pour la description. L'idée était d'adapter une approche (ou un processus) proposée à la base pour le développement par composants pour être appliquée sur la création des cours en ligne. Trop d'information mais c'est un excellent exemple où le (jeune) chercheur se trouve obligé à étudier et comprendre deux domaines complètement différents. Dans ce cas, l'état de l'art visait trois objectifs principaux :

1. Présenter suffisamment le e-Learning pour faire comprendre la problématique liée à la création des cours en ligne,

2. Présenter suffisamment le développement par composants pour faire comprendre la source d'inspiration pour la solution proposée,

3. Présenter suffisamment d'analyses, d'exemples et d'équivalences pour justifier et construire un fondement théorique acceptable pour la solution proposée.

Nous voyons, ainsi, qu'une la partie état de l'art et sa construction nécessite un certain niveau de compréhension et un certain  niveau de spécialisation qui ne sont pas offerts par les modules de base présentés pendant le cursus.

Le problème qui se pose de nos jour (et qui m'a poussé à rédiger cet article) est le changement de la vision des étudiants envers la partie de l'état de l'art. Malheureusement, l'état de l'art est, actuellement, vu comme une partie préparée pour le jury et le lecteur qui doit être rédigée et finie rapidement pour "passer aux choses sérieuses". Je dit "malheureux" parce que l'objectif est la compréhension, non pas la lecture : il ne suffit pas de rechercher des documents à lire pour "remplir" la partie état de l'art, il faut comprendre ces documents et "construire" la partie état de l'art. Il est nécessaire que les étudiants comprennent chaque paragraphe et chaque mot présentés dans la partie état de l'art. A mon avis, c'est la responsabilité de l'encadreur de faire comprendre cela aux étudiants dès le premier jour du projet (ou sujet), autrement, les étudiants se lanceront dans un travail de "bricolage" (je m'excuse pour le terme) pour vite terminer une partie "qui ne va être lue". Les conséquences seront, probablement :

1. Une incapacité d'expliquer d'une manière profonde et riche les notions présentées; il sera très difficile aux étudiants de justifier et de valoriser le projet, parce que pour eux, "une annotation est une <div> flottante qui contient une chaîne de caractère".

2. Une incapacité de comprendre les choix techniques, les différentes décisions et les remarques données durant la réalisation du projet, ainsi, "si l'encadreur a dit que la cardinalité (1,1) est fausse alors on la remplace par (0,n)" sans comprendre ni connaître la réponse à la question la plus importante (à mon avis que je partage avec the merovingian) : "Why ?"

3. L'incapacité de répondre aux questions de compréhension qui font, sans doute, partie des questions qui seront posées le jour de la soutenance.

D'un autre côté, il est difficile de demander à des étudiants d'assimiler un domaine en moins d'un moins (vu que le sujet de Master II est programmé pour 4 mois seulement). Existe t-il une solution pour à la fois permettre aux étudiants de comprendre l'importance de l'aspect théorique et de l'assimiler tout en le faisant dans les bons délais ?

La réponse est une formation rapide. Le cours magistral est le mode d'acquisition des connaissances habituel pour les étudiants, surtout après 5 ans à l'université. Je ne pense pas que les exposés et les travaux de recherche déjà réalisés sont une motivation suffisante pour laisser les étudiants tenter d'apprendre un nouveau domaine avec ses problématiques de recherche d'actualité. Ces travaux se basaient toujours sur un ensemble de connaissances données pendant le cours et durant des travaux dirigés, ainsi, les étudiants partaient toujours à partir d'une plate-forme théorique (minimale peut être mais jamais nulle). Ainsi, les étudiants n'ont même pas cette pratique d'apprendre une domaine à 100% (ou presque) en se basant exclusivement sur les lectures et il est difficile de développer une nouvelle compétence en quelques jours seulement.

Malgré mon expérience très brève, j'ai eu la chance de voir de près le résultat de travail d'une équipe de recherche à l'université de Jijel (département informatique bien évidemment) et qui optaient pour le choix de commencer dès la première semaine par une formation accélérée pour introduire les étudiants à leur domaine de recherche. Une méthode qui a permis à des étudiants d'un niveau moyen (selon leurs notes, ce n'est pas un facteur suffisant pour lancer un jugement sur le niveau des étudiants, mais il reste le seul facteur vu que je les ai jamais enseigné ou encadré) atteindre un niveau de compréhension très respectable et de pouvoir achevé le travail demandé dans les bons délais avec une excellente finition.

Faire une formation n'est pas une chose facile; elle nécessite un effort énorme pour la préparation et pour la présentation, néanmoins, les bénéfices attendues sont très encourageantes. Sur ce, j'encourage tout encadreur de procéder à faire une formation accélérée à ces étudiants, comme j'encourage les étudiants trouvant des difficultés dans la compréhension des notions théoriques de demander à leur encadreur de leur faire une présentation sous forme de cours magistral non pas sous forme de discussions rapides à table; ces dernières sont mieux adaptées pour le raffinement, pas pour la compréhension des notions de base.

P. S : les remarques faites (je ne vais pas dire jugements) sont subjectives et dépendent un échantillon défini des étudiants que j'ai eu l'occasion d'enseigner et/ou encadrer. Elle ne peuvent pas être généralisées sur tous les étudiants de l'université, mais, le risque de faire les mêmes erreurs est, sans doute, présent.

(Pour avoir une idée sur l’objectif du blog, veuillez lire cet article)

(Pour avoir plus d’information sur l’auteur et son domaine de recherche, veuillez lire cet article).