Retour d’expérience sur l’outillage et notamment Deadlock pour des séances de tp@home en période de confinement.

S’il y a bien un défi qui a marqué l’enseignement supérieur en 2020, c’est bien celui de la conservation d’un enseignement efficace dans un contexte de crise sanitaire.

  • Comment conserver la pleine proximité avec les enseignants lorsque tout le monde est chez soi ?
  • Comment s’assurer que le savoir est toujours suivi, transmis et intégré alors que les distractions n’ont jamais été autant faciles ?
  • Quels outils pour donner envie et motiver les étudiants à continuer à s’instruire ?

Après quelques mois d’expérimentation, Frédéric Baucher, Professeur Associé de l’INSA Rouen Normandie, a accepté de faire son retour d’expérience sur les outils utilisés dans ces enseignements au sein du département ITI (à Rouen, France) ainsi que dans la filière SIC (à Fès, Maroc) de l’INSA Euromed. On se concentrera notamment sur Deadlock, la plateforme d’apprentissage ouverte (open-source) et libre.

Des outils pour dématérialiser l’enseignement

Dans l’enseignement supérieur en informatique, différents formats d’enseignement sont disponibles :

  • Des cours magistraux (salle de classe, amphithéâtre, etc…)
  • Des Travaux Dirigés en petit groupe (TDs)
  • Des Travaux Pratiques en petit groupe (TPs)
  • Des projets en autonomie

Pour valider l’enseignement, différentes modalités d’évaluation peuvent être mobilisées ...

  • Contrôle continu, comptes rendus, etc...
  • Examen sur table / sur machine (QCMs, code, etc…)
  • Participation et apport à un projet (soutenance, …)

… mais aussi différents indicateurs :

  • Notes attribuées automatiquement
  • Notes attribués après validation d’un contenu
  • Taux de présence

Pour assurer cette animation en distanciel, une première typologie d’outils peut être proposée :

  • un espace collaboratif (visio, chat, validation des présences, etc…) pour gérer les formats synchrones
  • un moyen d’assurer une présence auprès des étudiants en pouvant par exemple partager leur écran pour les assister sur des TPs ou projets.
  • un portail (ie LMS) pour partager en asynchrone des contenus pédagogiques, éventuellement héberge des interactions (QCM, etc…)
  • un moyen d’évaluer l’avancement / les compétences à distance …

Même si nous allons plutôt nous concentrer sur Deadlock, une solution ouverte encore méconnue dans l’enseignement supérieur, il est important de noter que ces usages spécialisés ont été rendu possibles grâce la mise à disposition d’outils plus génériques issus de la mobilisation des services transversaux des INSA (service formation et DSI de INSA Euromed, cellule OPEN INSA, CIP INSA Rouen) dans le cadre des PCAp (plan de continuité d’activité pédagogique).

  • Espace collaboratif : Microsoft Teams
  • Portail pédagogique : Moodle

En termes d’outils spécifiques du domaine de l’enseignement informatique, Deadlock fournit un apport efficace et ciblé pour l’organisation d’exercices. D’autres outils spécifiques peuvent être mobilisés pour des usages différents :

  • En amont de Deadlock, un portail comme OpenClassroom (avec son catalogue de formation et de QCM) peut permettre de réaliser des séances de classe inversée.
  • En aval de Deadlock, pour toute la partie accompagnement des projets informatiques, où les étudiants sont encore plus en autonomie, de nombreux outils viennent centraliser les lieux de travail et de stockage des réalisations des étudiants : Github de Microsoft (pour la gestion des sources), Github Classroom (pour l’initialisation des projets et la constitution de groupe de gestion de sources), GenMyModel de Axellience (pour l’édition collaborative de diagrammes UML et les annotations de l’enseignant), Themis de ProMyze (pour la gestion de la dette technique, le partage de bonnes pratiques ou patterns, l’annotation du code par l’enseignant) et enfin Heroku de Salesforce pour le déploiement des solutions exécutables.

Avant d’entrer dans l’expérimentation : connaissance mutuelle, confiance, ...

Les premières discussions autour du projet Deadlock remontent à 2017 avec la direction de Takima, l’un des partenaires de longue date du département ITI (et employeur de plusieurs de nos alumni). Le projet se caractérise alors par les points suivants :

  • Un outil moderne qui suscite l’envie : Mettre entre les mains des enseignants un outil à la pointe de la technologie (containers Docker, Kubernetes et Cloud) afin de faciliter l’engagement de leurs étudiants et l’apprentissage de l’informatique. L’outil suit rigoureusement les meilleures pratiques en termes d’UX (User eXperience) avec l’objectif d’être agréable et élégant à utiliser sans générer aucune frustration.
  • Rendre l’informatique plus ludique et plus autonome : ...en combinant à l’apprentissage de l'algorithmie les résultats d’études modernes en psychologie sociale autour du serious gaming : la “gamification” est un catalyseur de l’apprentissage. L’autonomie est aussi une manière de laisser chacun trouver ses propres parcours d’apprentissage, bien qu’ils soient guidés par la vision de l’enseignant.
  • Faciliter le travail de l’enseignant : Deadlock permet de plus facilement détecter les étudiants en difficulté. En automatisant l’évaluation et la collecte d’indicateurs de niveau de chaque élève, la plateforme donne à l’enseignant la possibilité de comprendre le processus de réflexion de l’étudiant et non pas seulement d’évaluer son résultat. Les outils intégrés permettent au delà de la validation algorithmique, de s’assurer du respect des bonnes pratiques et conventions de code tellement importantes dans ce domaine.
  • Des ressources ouvertes : Un outil en ligne de commande est disponible aux professeurs pour créer des exercices et pouvoir les ajouter sur la plateforme. Cet outil ainsi que tous les exemples sont accès libre. D’autre part tout contenu créé pour la plateforme peut être partagé librement pour être repris par d’autre écoles par exemple.

Dans une première phase, Deadlock a été expérimenté en pilote (une journée d’expérimentation) durant deux années consécutives. Compte tenu de l’accueil positif des étudiants et de l’accompagnement des équipes Takima, une deuxième phase a pu être engagée.

Retour d’expérience

Contexte d’expérimentation

Avec le confinement lié à la crise sanitaire, une nouvelle opportunité de mesurer l’intérêt de Deadlock s’est présentée dans le cadre du module « BD - Interaction avec une BD » dispensé à des étudiants en 2ème année de la filière SIC de l’INSA Euro-Méditerranée (une école du groupe INSA située sur le sol Marocain). Deadlock a été utilisé cette fois avec toute la promotion (32 étudiants), tout au long de la session.

Prévu initialement en présentiel, l’organisation de cet enseignement a dû être entièrement reconçue en quelques jours pour un déroulement à distance.

Conception du cours

Sélection des exercices

La mise en œuvre de Deadlock est intervenue dans ce contexte, notamment à la faveur de son catalogue de missions (exercices) prêtes à l’emploi. En l’occurrence, la disponibilité de 25 missions sur la seule thématique SQL répondait largement aux besoins de l’enseignement « BD ». A noter que des dizaines d’exercices sont disponibles sur des thèmes aussi divers que Java, la sécurité, ….

Pour rappel, Deadlock permet également aux enseignants de concevoir leurs propres exercices spécifiques (hors catalogue) dans un format documenté et outillé. Ainsi, dans le cadre du module « BD », la création d’exercices sur JDBC (non disponible à ce jour au catalogue) fait partie des projets pour la prochaine session.

Architecture retenue : mode Saas et SSO

Compte tenu de la forte mobilisation des DSI internes aux établissements pendant la crise du Covid19 sur les services génériques (réseau, accès distants, LMS, outils collaboratifs, …), le mode Saas a été privilégiée pour une solution plus spécifique comme Deadlock. L’authentification a été déléguée à Github , fournisseur d’identité (déjà utilisé par les étudiants sur plusieurs autres applications). Pour rappel, l’inscription sur le portail Deadlock ne demande pas à importer de listes d’inscrits, un étudiant rejoint automatiquement sa promotion (groupe au sens Deadlock) grâce à un lien unique fourni par l’enseignant.

Déroulement d’un exercice

L’interface de l’exercice pour l’étudiant

Le portail Deadlock propose une ludification des exercices. Cette mise en scène (missions, aventures, quêtes, points à gagner, etc …) permet notamment de guider en autonomie l’étudiant lorsqu’il doit réaliser une série d’exercices sur un temps long. Dans le cadre d’un usage en TD, c’est l’enseignant qui assure cette animation et l’étudiant est directement mené vers l’exercice à faire à un moment donné.

Illustration 1 : fenêtre de l’exercice

L’enseignant peut coller le lien vers l’énoncé, dans le fil de discussion de l’outil de communication du cours (en l’occurrence, la conversation Teams).L’étudiant accède alors à la fenêtre de l’exercice (cf Illustration 1). Il est alors invité à lire l’énoncé (éventuellement accéder à des indices). Il dispose d’un éditeur (avec colorisation) pour coder la solution qu’il propose, pour l’exécuter et vérifier qu’elle est correcte, et enfin, une fois qu’il juge que le résultat satisfaisant, il peut soumettre sa solution à l’enseignant.

A noter : il appartient au créateur de l’exercice de décider les éléments qui doivent être présents dans l’environnement (ainsi, avec des exercices SQL, une base de données et des tables sont fournies dans le contexte dans lequel le code va s’exécuter). L’environnement (d’exécution) est réinitialisé à chaque exécution ou soumission avec ces éléments. Pour illustration : si le code de l’étudiant a créé dans l’exécution précédente une table, cette dernière disparait dans une nouvelle exécution (pour que cette table spécifique soit à nouveau disponible, le script qui la crée doit être aussi présent dans le nouveau code).

Sur certains exercices, des QCM (sous Moodle) ont été pratiqués en amont afin de préparer et mobiliser l’étudiant sur les problématiques abordées.

L’interface de la session d’exercice pour l’enseignant

L’un des points forts de Deadlock, sur le volet rapprochement de l’enseignant et de l’étudiant en situation distante, tient notamment à la frise temporelle (voir illustration 2) qui permet :

  • de lister dans le temps chacune des tentatives de l’étudiant ;
  • d’accéder immédiatement au code de l’étudiant, dans le cas notamment où il pose une question sur sa prose ;
  • d’ouvrir une version et un environnement de compilation/exécution propre à l’enseignant : si l’enseignant souhaite appliquer des correctifs sans pour autant les montrer à l’étudiant, il dispose d’une copie du code étudiant sur laquelle il peut lancer l’exécution. Un conseil personnalisé peut ainsi être fourni à l’étudiant sans pour autant lui dévoiler toute la solution.

Comme on peut le voir, l’enseignant dispose de la même visibilité que sur les postes physiques d’une salle de TP, avec, en sus, des possibilités étendues de manipulation du code de l’étudiant, indépendamment de ce dernier (ce qui est rarement le cas dans une salle machines où le poste ne dispose que d’un seul clavier, ce qui entraîne évidemment un non-respect des gestes barrières !).

Illustration 2 : frise temporelle vue par l’enseignant

Visible uniquement par le professeur, la frise temporelle, disponible pour chaque étudiant, permet d’accéder très rapidement à chaque code qu’il a transmis pour exécution ou pour soumission.


Conclusion

Cette expérience avec Deadlock en contexte distanciel a été positive. Les fonctionnalités fournies par Deadlock (catalogue d’exercices, environnement prêt à l’emploi en mode web, inscription en SSO, frise temporelle) ont permis de réduire la distance, selon les observations (certes limitées) qui ont pu être faites.

Une des observations positives tient au fait que tous les étudiants ont pu trouver une solution aux exercices proposées (cette mesure objective est apportée par la frise temporelle qui permet à l’enseignant de visualiser les étudiants qui ont soumis une solution avec succès). Cette mesure est cependant à tempérer : rien ne vient prouver que l’étudiant a bien terminé son exercice lui-même, le risque principal étant le copier/coller d’une solution codée et transmise par courriel par un camarade qui aurait soumis en amont avec succès ! Une piste d’amélioration pourrait être de lever une alerte pour toutes solutions qui seraient rigoureusement identiques (à l’espace près, au saut de ligne près, …) à celle des étudiants qui auraient soumis avec succès en amont.

Une autre évolution à explorer pourrait permettre de contribuer aussi à lutter contre ces dérives (copier sur un voisin virtuel) mais aussi à fournir une assistance automatisée aux étudiants. En effet, toujours grâce à la frise temporelle, le système dispose de l’ensemble des tentatives (quelquefois 10 à 20) qu’a pu effectuer l’étudiant avant d’arriver à la solution. Mais existe-t-il une typologie des comportements pour parvenir à la solution ? Cette hypothèse reste à vérifier mais si elle se révélait prometteuse, l’expérimentation pourrait être poursuivie par une évolution consistant à analyser la frise temporelle de chaque étudiant pour identifier automatiquement le type de comportement et apporter un conseil adéquat. Ces assistants seraient bien entendu utiles dans une utilisation en autonomie mais ils pourraient aussi soulager l’enseignant dans des promotions trop chargées !

Capture d'écran - Mission Fizzbuzz
Capture d'écran - Aventure Java Collections
Capture d'écran - Mission Metamorph Multi-Language
Capture d'écran - Relecture de code pour un professeur
Capture d'écran - Badges