Avec cette architecture, nous sommes capables de générer automatiquement autant de séquences de visages que nous le souhaitons. Nous pouvons grâce à cette architecture générer des landmarks qui pourront être utilisés dans de la détection de triche et annotation de vidéo d’examen ou bien utiliser une architecture plus complexe pour générer des visages texturés d’étudiants. Nous avons aussi analysé une méthode pour rajouter de l’automatisation pour qu’un agent génère des visages aléatoires avec une expression prédéterminée. Cette méthode est adaptable et ouvre beaucoup de pistes.
Nous avons montré qu’avec un cadre de travail à la pointe de la technologie nous pouvons aujourd’hui créer du contenu de manière automatique et procédurale. Ce contenu pourra ensuite
être utilisé dans des méthodes d’analyse de comportement.
Les buts fixés au début de ce chapitre ont étés atteints et durant leur réalisation, beaucoup d’autres pistes se sont ouvertes.
Ayant effectué une approche des méthodes de vision numérique, nous voulons diversifier nos méthodes en abordant le paradigme du traitement de séquence qui est expliqué dans le chapitre suivant.
Chapitre 3
Méthodes d’analyse par signes
biométriques
Après avoir analysé les informations vidéo d’un élève, nous pouvons aussi nous intéresser à son comportement via sa façon de taper au clavier et de bouger la souris. En effet, la façon d’interagir avec le site du cours est propre à chacun et, puisque le comportement en ligne change d’un élève à un autre, nous pourrions détecter son identité au travers de ces données. Cette idée est étayée par la littérature qui cherche à détecter l’identité de personnes avec des données biométriques. Dans ce chapitre, nous voulons donc vérifier qu’il est possible d’identifier un individu par son comportement sur le site du cours.
Grâce à cela nous utiliserons un type différent de données et la mécanique globale de sécurité sera plus diverse et donc plus renforcée. Le but de ce chapitre est donc de créer un système capable d’identifier un étudiant via son comportement (clavier et souris) grâce à des données collectées sur le site du cours.
Comme expliqué dans le chapitre précédent, dont le but était de générer des données, nous avons mis l’emphase sur le fait que celles-ci sont la base de l’apprentissage des systèmes que nous voulons concevoir. En revanche, nous avons ici toujours accès au clavier et à la souris qui sont nécessaires pour passer l’examen. De ce fait, pour la problématique d’identification nous aurons toujours les données nécessaires pour analyser un comportement. En effet, contrairement aux élèves passant l’examen en ligne qui devaient utiliser une webcam ce qui nous a limités en termes de données vidéo, tous les étudiants du cours utilisent un clavier et une souris. Cela nous a permis de recueillir rapidement beaucoup de données pour l’analyse de comportement (plus de 90 000 entrées en une session de cours). Nous avons pris soin d’enlever les données des appareils mobiles car le comportement est bien trop diffèrent et ferait l’objet d’une autre étude connexe. Ces données ont été anonymisées. Grâce à cela, nous proposons dans ce chapitre une méthode de traitement de ces données dont découle un procédé d’identification.
3.1
Introduction
Dans ce cours en ligne, chaque élève doit faire des exercices sur différents sujets durant la session, puis des quiz pour asseoir les connaissances et enfin deux évaluations.
La mécanique permettant de réaliser cela sont les notebooks Jupyter. Ils permettent d’interpréter du code Python directement dans le navigateur de l’élève et offrent ainsi le meilleur support pédagogique possible pour apprendre la programmation. Puisque tout le procédé est automatisé, on peut, dans la mesure du possible, guider les étudiants en précisant ce qui était attendu versus ce qu’ils ont soumis grâce à des corrections automatiques. En effet, une fois soumis, la solution de l’élève est analysée automatiquement et des indications sur la nature des erreurs qu’il a commises lui sont renvoyées. De ce fait, l’expérience d’apprentissage en ligne devient similaire à ce que l’on pourrait faire sur un ordinateur ou dans un cours de travaux pratiques, mais tout cela à distance.
Grâce à ce système numérique et automatisé, il est possible de collecter toutes les données produites sur le site par les étudiants pour apprendre les spécificités liées à l’apprentissage en ligne. Grâce aux rétroactions des exercices, un algorithme de recommandation serait possible, une analyse du code des élèves permettrait aussi de les aider à surmonter leurs difficultés et toutes ces données ouvrent beaucoup de possibilités.
Dans notre cas, nous voulons renforcer la surveillance durant les examens. Nous nous sommes donc focalisés sur les entrées de l’élève (données du clavier et de la souris). Le but est de pouvoir collecter les données des étudiants qui naviguent sur le site du cours, et spécifiquement les pages d’exercices, quiz ou examens pour, par la suite, prédire leur identité grâce aux entrées que nous recevons. Nous allons donc capturer tous les évènements qu’un étudiant peut créer sur le site, frappes au clavier, mouvement de souris et clics sur la page. De ce fait, nous aurons un dataset fourni pour pouvoir effectuer de l’apprentissage. En moyenne, pour les 412 étudiants, nous avons 140 entrées d’exercices, 70 de quiz et 30 d’examens (soit 90 000 au total), chacune de ces entrées comporte en moyenne 60 000 évènements (soit un peu plus de cinq milliards d’évènements totaux).
En agrégeant ces données sous forme de séquence, nous pouvons entraîner un réseau capable d’analyser temporellement cette suite d’information pour prédire l’identité de l’élève. Grâce à cela, notre modèle peut lever des drapeaux pour faciliter la surveillance humaine à plus grande échelle. À terme, cela permettrait de s’assurer que la personne passant l’examen est bien la même personne qui a suivi le cours tout au long de la session, et ce de façon automatisée. Le but pratique est aussi d’être capable d’entraîner grâce aux données récoltées lors des exercices, de valider la performance celles des quiz, et enfin analyser le comportement et de vérifier l’identité d’une personne pendant l’examen.
Figure 3.1 – Exemple d’un notebook jupyter d’examen
3.2
Dataset
Les exercices, quiz ou examens sont des notebooks Jupyter comme celui de la figure 3.1. Ils comportent tous la même structure ce nous a permis de collecter des données uniformisées. Ces notebooks possèdent une cellule qui énonce le problème à résoudre, et deux cellules de code exécutable. La première permet d’entrer la solution qui sera soumise, et la deuxième est un brouillon pour expérimenter et faire des tests. Ces trois cellules nous apportent donc un contexte uniforme et pratique pour collecter des données. On peut savoir où l’élève effectue des actions, mais aussi dans quelle cellule ce qui apporte des informations contextuelles utiles. Les cellules les plus importantes sont les cellules 2 et 3, car ce sont les deux où l’élève peut entrer du code. Ce sont donc ces deux cellules qui reçoivent le plus d’actions et surtout celles d’entrées au clavier qui donnent le plus d’information sur l’identité de la personne.
En revanche, nous relevons aussi les mouvements de souris, et les frappes au clavier sur tout le reste de la page.
Le but est de capturer tous les évènements générés sur ces pages de notebooks, les nettoyer, les analyser puis enfin de pouvoir vérifier l’identité de la personne.
Format du dataset collecté
Nous avons découpé les données collectées par élèves à raison d’un fichier par étudiant. Chaque fichier contient une liste de toutes les sessions de travail qu’il a effectué. Une session de travail correspond à une période d’activité, à partir de l’instant où l’élève charge la page, jusqu’à ce qu’il change d’onglet dans son navigateur web ou bien que la page est fermée.
Le traitement précis des données est décrit plus bas, mais nous pouvons déjà illustrer certains cas critiques :
— Si l’ordinateur de l’étudiant se met en veille alors la session peut durer plusieurs jours. Le principe d’attention mentionné précédemment ne permet pas de limiter cela, car aucun évènement spécifiant une perte d’attention n’est envoyé.
— Certaines sessions contiennent énormément de données, car l’étudiant a créé beaucoup d’évènements courts et proches dans le temps.
— D’autres sessions créent peu de données, par exemple l’étudiant lit puis bouge la souris puis ferme l’onglet ce qui n’apporte aucune information et bruite notre jeu de données. Pour le deuxième point, après investigation, nous avons trouvé que la majorité de ces évènements étaient dus aux évènements de la souris. Celle-ci générant beaucoup de petits déplacements consécutifs. Nous avons donc agrégé les déplacements de la souris préférant enregistrer un plus grand déplacement moyen. Techniquement, si l’angle est inférieur à vingt-cinq degrés, nous agrégeons les déplacements, sinon nous en créons tout de même un nouveau, car l’information contenue dans un changement brusque de direction parait utile. Aussi, si la souris ne bouge pas pendant 100ms, on considère cela comme un nouveau déplacement pour conserver une certaine dynamique dans l’information enregistrée.
Pour le troisième point, il est abordé plus en détail plus tard, mais ces séquences ont simplement été enlevées de notre jeu de données, car elles n’apportent pas d’informations utiles. En regardant ces séquences courtes, les évènements sont souvent identiques et ne permettent donc pas de déduire l’identité de l’individu (p.ex load, mouse move, hidden, unload). Nous avons donc choisit de supprimer ces données qui nous semblent rajouter plus bruit que d’information. De ce fait, notre jeu de données est réduit, mais est de meilleure qualité.
De façon générale, une session est représentée par un dictionnaire structuré. Nous avons choisi les clefs pour représenter le plus clairement et simplement possible les attributs nécessaires au stockage dans une base de données puis au traitement de ces informations. Ce dictionnaire est représenté comme suit :
— userid : jeton anonyme, — browser : desktop | mobile, — created : timestamp en ms, — modified : timestamp en ms,
— pk : clef primaire dans la basse de don- nées
— type : Exercice | Quiz | Exam — titre : titre du notebook
— liste des évènements {types, temps, infos spatiales}
La clef "userid" correspond à six lettres créées grâce à une fonction de hachage1 rendant
l’identité impossible à retrouver. Cela nous a donc permis de rendre les données publiques. La clef "browser" (navigateur) indique si la page a été ouverte depuis un ordinateur ou depuis un téléphone intelligent.
Les "timestamps" (crée et modifié) sont les timestamps classiques en milliseconde depuis le premier janvier 1979. Ils indiquent quand a été créée ou modifié l’entrée dans la base de donnés. La clef "pk" clef primaire, n’est pas utile à l’apprentissage, mais nous a permis de retrouver plus facilement les données atypiques dans la base de données.
Le "titre" correspond au titre en français du notebook.
La "liste des évènements" est le champ le plus complexe et le plus important pour l’apprentissage. Il contient la séquence de tous les évènements engendrés par les actions d’un étudiant. Si un élève fait deux fois le même notebook, nous aurons donc deux entrées dans la base de données, avec uniquement les évènements et les timestamps de différent. Chacun de ces évènements possède des attributs spécifiques qui servent à l’identification de l’élève, ceux-ci sont définis plus bas table 3.2et3.3.
La table 3.1regroupe tous les évènements qui nous ont servi à constituer notre base de données. Nous avons choisi des types assez variés pour essayer de représenter tous les traits caractéris- tiques majeurs d’une personne faisant un exercice en ligne. Aussi, ce sont les évènements natifs que JavaScript permet de capturer.
Par contre, chacun de ces évènements possède des attributs qui lui sont propres et définis dans la table 3.3
Tous ces attributs sont définis en détail table3.2. Ceux de la colonne Opt (pour Optionel) sont des attributs uniques propres à un seul évènement.
3.2.1 Nettoyage des données
Une fois le choix des attributs fait et la structure définie, nous avons enregistré les séquences d’évènements dans une base de données à même le site web. Cet enregistrement a duré une session et nous a permis de raffiner la qualité et la structure de nos données. Elles ont été stockées sur le site, déjà divisées entre exercices, quiz et examens. Un pré-traitement a aussi été fait pour obtenir uniquement des sessions de plus de 100 évènements et uniquement sur ordinateurs. En effet, les examens se faisant sur ordinateur, nous ne voulons pas considérer les données mobiles qui sont de nature différente. En moyenne, les données compressées (en zip) pour un type de notebook (exercice quiz ou examens) représentent 600Mo de texte compressé, mais atteignent plus de 4Go une fois décompressées. Le jeu de donnée total (exercice quiz
Évènement Description
Mouse Enter / Leave Survol de la souris (principalement les cellules) Mouse Up / Down Pression ou relâche d’un bouton de la souris
Click Un bouton (btn) de l’interface a été cliqué MouseMove Mouvement de la souris
Keyboard Up / Down Pression ou relâche d’une touche du clavier
Focus In / Out L’attention est portée sur un élément (principalement les cellules) Hidden La page perd l’attention (changement ou fermeture de l’onglet) Visible La page regagne l’attention
Load Chargement (initial) de la page Unload La page est fermée
Wheel Déplacement grâce a la molette de la souris
Copy Copie un élément
Paste Colle un élément
Cut Coupe un élément
Table 3.1 – Types d’évènements
Ce sont les évènements principaux, détectables par le langage JavaScript.
Attribut Definition
ts Timestamp correspondant au début de l’évènement cell Numéro de la cellule cf. figure 3.1
x, y Abscisse et ordonnée de la souris. dt Durée de l’évènement (en ms).
dx, dy Déplacement horizontal et/ou vertical de l’évènement. dl Abscisse curviligne2 de l’évènement.
btn Numéro du bouton de la souris : 1 gauche, 2 droit, 3 molette (4+ special). md Mode de défilement de la molette (0 ou 1).
button soumettre, debug, rafraichir, paramètres, réactualiser, save (haut du notebook)Bouton cliqué : ou run (pour une cellule)
key Touche appuyée ou relâchée au clavier.
Nom ts cell x y dt dx dy dl Opt Valeur3 J0, ∞K J0, 8K [0, 1] [0, 1] J0, ∞K [0, ∞] [0, ∞] [0, ∞] MEL X X X X MUD X X X X btn :J0, 2K W X X X X X md :{0, 1} C X X button :Name MM X X X X X
KUD X X key :Name
FIO X X
HV X
LU X
CPC X X
Table 3.3 – MEL : Mouse Enter Leave / MUD : Mouse Up Down / W : Wheel / C : Click / MM : Mouse Move / KUD : Keyboard Up Down / FIO : Focus In Out / HV : Hidden Visible
/ LU : Load Unload / CPC : Copy Paste Cut
et examens) fait donc environ 12Go de texte (Json4) ce qui représente une grosse quantité
d’information pour des données temporelles. Les datasets dans ce type de domaine sont plutôt de l’ordre de la centaine de Mégaoctets ou du Gigaoctet, nous possédons donc un jeu de données d’un ordre supérieur à la moyenne. L’avantage est d’avoir une plus grande variance dans nos données, celles-ci représentent mieux l’espace dans lequel nous voulons travailler. Après avoir téléchargé les données du site web et les avoir stockées sous forme de json, nous devons les nettoyer et les transformer pour les adapter à notre processus d’apprentissage. En effet, les données brutes sont parfaites pour être stockées, mais inexploitables par un réseau. Il faut donc représenter toutes nos données de façon numérique afin que notre modèle puisse les traiter. C’est une étape cruciale, car la façon dont nous présentons les données au réseau peut affecter grandement les performances.
Tout d’abord, avec un prétraitement sur le site, nous supprimons de nos données les sessions effectuées sur mobiles grâce à la clef browser. En effet, nous ne voulons pas analyser les données récoltées sur téléphone intelligent ou tablettes. L’examen sera passé sur des ordinateurs de bureau et le comportement sur les différentes plates-formes peut changer radicalement. En effet, puisque nous nous basons sur les données temporelles, la façon de taper, le type de clavier, les appuis et glissades au doigt versus un clavier physique et une souris changent sur mobile et pour une même personne les données sont bien différentes. Il parait donc peu probable de déduire l’identité d’une personne sur un ordinateur grâce aux données collectées sur mobile. Ce
Figure 3.2 – Exemple des découpages possibles d’une série d’évènements. La première ligne illustre le découpage selon les longueurs minimales et maximales. La deuxième illustre le principe de découpage selon la perte d’attention. La dernière montre l’effet du découpage s’il
n’y a pas eu d’actions depuis un certain temps
choix permet de s’assurer une uniformité dans les données. Par contre l’analyse des données mobiles pourrait être une continuation de ce projet. De plus, il n’y a aucun étudiant ayant fait la majeure partie du cours sur mobile, le site ne s’y prêtant pas.
Ensuite, nous répartissons nos données en trois groupes correspondant aux exercices, quiz et examens grâce à la clef "type". Pour l’application dans le monde réel, nous voulons être en mesure de nous entraîner sur les exercices, de valider cet entraînement sur les quiz et de prédire l’identité de l’étudiant pendant l’examen. Ces trois groupes correspondent donc à notre jeu d’entraînement, de validation et de test5. Chacun de ces groupes est ensuite mélangé
aléatoirement afin d’éviter des biais lors de l’entraînement. Une fois divisées, les données sont encore très bruitées, certains élèves ne font qu’ouvrir un notebook, lire, cliquer au hasard et fermer la page. Nous voulons nous débarrasser de ces sessions parce qu’elles contiennent très peu d’information.
À la figure 3.2 nous montrons les différentes méthodes pour obtenir un jeu de données de meilleure qualité et traitable par notre modèle. Premièrement, nous introduisons donc un méta paramètre qui correspond à la longueur minimale d’évènements dans une série donnée. Toute série ne possédant pas assez d’évènements sera donc enlevée du dataset. De plus, nous ajoutons aussi un évènement obligatoire ("KeyDown") ce qui signifie que nous ne conservons que les sessions dont au moins un évènement est une frappe au clavier. Nous avons par ailleurs beaucoup de données (plus de 90 000 entrées) c’est donc un compromis que nous pouvons nous permettre d’effectuer afin d’obtenir moins de données, mais de meilleure qualité.
Aussi, une session de travail peut être très longue, ce qui pose problème. En effet, nos modèles n’ont pas une mémoire infinie et une trop longue séquence de données n’est pas pertinente, même pour un humain. Dès que l’onglet du navigateur perd l’attention, il soulève un évènement "hidden" pour indiquer que le focus va être donné à autre chose. Une fois qu’il récupère l’attention, il soulève un évènement "visible". Avec ces informations, on peut considérer "hidden" comme la fin d’une session et effectuer un premier fractionnement de nos données.
Bien que cette méthode allège déjà de façon conséquente nos données, certaines séries d’évène- ments sont toujours trop longues. Nous introduisons donc ensuite deux méta paramètres. Le premier, le temps maximum d’attente, permet de découper s’il n’y a pas eu d’actions depuis un certain temps. Le deuxième impose une limite dure sur le nombre d’évènements total. Ces dernières limites découpent les séquences qui sont passées au travers des procédés précédents. Elles nous permettent de nous assurer que la séquence n’est pas trop longue pour le modèle (contraintes matérielles) et qu’elle reste conceptuellement correcte (p.ex pas d’évènement durant 20 minutes n’apporte aucune information sur l’identité de l’étudiant).
Ces données une fois élaguées composent donc des séquence plus courtes mais plus dense en