Le calcul des sessions sur la seule base des interations explicites de l'utilisateur avec la plate-forme pose plusieurs problèmes de métrique notamment aux “bornes”.

Si l'entrée en session est généralement marquée par un événement explicite “loggedin”, la déconnexion ou la rupture implicite de session est plus difficile à contourner :

• en cas de fermeture brutale du navigateur, sans passer par “déconnexion”
• en cas de fermeture de tous les onglets, sans passer par “déconnexion”
• en cas de perte de réseau mobile ou wifi
• en cas de départ de l'utilisateur sans refermer son navigateur ou sa session

Dans chacun de ces cas, la trame de trace utilisateur s'arrête pendant un temps donné, jusqu'à réapparaître au bout d'un moment, avec ou sans reconnexion en fonction de la situation et en fonction du temps de vie du cookie de session.

La solution initiale consistait à définit un crédit temps moyen à ajouter à toute détection d'une rupture suffisamment longue de la trame de trace destinée à compenser l'incertitude sur le temps d'activité après cette dernière trace. Ce dispositif s'avère efficace à certaines conditions :

• Le contenu est suffisament atomisé pour induire une interaction continue et régulière pendant les sessions de travail en ligne.
• Les sessions sont plutot longues, amoindrissant l'impact de l'incertitude finale en fin de session.
• Le délai de détection et le crédit temps alloué sont plutot faibles (20 minutes et 5 minutes respectivement), diminuant également l'impact de l'incertitude par rapport à la réalité vécue.

Malheureusement, les expériences de terrain montrent que :

• Les contenus et activités sont en général insuffisamment morcelées dans les mises en oeuvre FOAD, parce que cette reconstruction génère un effort important de reformulation et que les documents originaux proviennent souvant de pratiques présentielles.
• Les contraintes de métriques de certains dispositifs (par exemple travaillant sur la visulisaton de médias externalisés longs et non traçables) mettent le dispositif en dehors de ses réglages optimaux de comportement.

La solution de sécurisation des sessions consiste à insérer un script actif automatique qui peut continuer à enregistrer des signaux de trace tant que la session Moodle est active dans le navigateur, avec ou sans activité explicite de l'utilisateur. Ce signal mesure la plage “connectée” de l'agent utilisateur (mais pas la présence effective de l'utilisateur derrière l'agent utilisateur).

Ce dispositif ne résout cependant correctement que les trois premiers cas de rupture de session, mais échoue à détecter le dernier cas (inactivité connectée). Une évolution de cette solution devrait pouvoir armer un temps d'émission fini (plus long que la période d'émission) afin d'arrêter la simulation de présence au bout d'un certain temps (probablement équivalente à la durée de vie de la session Moodle).

Il reste de toutes façon une incertitude non soluble sur l'activité réelle de l'utilisateur distant et le fait que oui ou non cette dernière est bien liée à l'apprentissage. Cette discrimination n'est pas à portée du système numérique. Seule la segmentation fine des activités et interactions explicites avec la plate-forme peut garantir une continuité de l'attention et sa mesure correcte par le système.

Hormis le cas de “l'inactivité connectée”, le nouveau dispositif de sécurisation des sessions limite l'incertitude à la période d'émission de la simulation de présence (heartbeat). si ce signal est émis toutes les 10 minutes, le taux d'incertitude sur le temps passé après la dernière trace est d'au plus cette même période.

Le réglage de cette période est donc préconisé entre 5 minutes jusqu'à 15 minutes.

Cette technique peut avoir un impact sur la charge globale des serveurs.

Revenir à l'index du bloc Mesure d'Activité