Cet article documente ce que fait effectivement le bloc Use Stats.

Le bloc Use Stats est un compilateur de “temps d'usage”. Il détermine au mieux le temps passé par l'utilisateur dans les différents contextes de Moodle.

Pour cela, il analyse les traces (logs) des utilisateurs. Il calcule en premier lieu, pour chaque trace, le délai qui la sépare de la trace suivante du même utilisateur (lap ou timegap). Ce délai est mémorisé au fil de l'eau par la tâche planifiée de compilation, qui “suit” la table de trace standard au plus près (voir Modèle de données). Le délai attribué à une trace est le temps que l'utilisateur est supposé avoir passé dans le contexte de cette trace.

Deux problèmes principaux se posent pour compiler les temps passés :

• le problème des déconnexions ou ruptures de session,
• le problème du choix d'agrégation des temps.

La rupture de session n'est presque jamais un événement explicite, marqué par une action enregistrée dans les traces. L'observation de la pratique montre que très peu d'utilisateurs se déconnectent explicitement de Moodle lorsqu'ils ont terminé leur travail. Le plus souvent, le navigateur est refermé sur la dernière fenêtre utilisée, l'ordinateur est arrêté, ou une mise en veille est déclenchée.

Pour cette raison, le bloc met en œuvre un dispositif heuristique qui “devine” dans quelles conditions l'utilisateur a quitté la session de travail, par le seul examen des traces.

Pour chaque trace d'un utilisateur, le bloc applique dans l'ordre :

1. Délai : le délai jusqu'à la trace suivante du même utilisateur. Les traces de notation d'un utilisateur par un tiers (événements graded) ne sont pas une activité de l'utilisateur : elles sont sautées, et leur délai est rattaché à la trace en cours. Pour la dernière trace connue, il n'y a pas de trace suivante : le délai est le crédit de fin de session, limité au temps réellement écoulé depuis la trace.
2. Dépassement du seuil : si le délai dépasse le seuil (en minutes, réglage central), le bloc conclut à une rupture de session. Le délai n'est pas compté en entier : il est remplacé par le crédit exceptionnel de fin de session (en minutes, réglage central). Ainsi, l'heure passée entre deux traces lointaines n'est pas attribuée à l'utilisateur.
3. Traces non significatives : une déconnexion explicite (logout) ou une tentative de connexion échouée ne comptent pas de temps.
4. Connexion explicite : une connexion (login) démarre une nouvelle session et remet à zéro le temps en attente.
5. Modules ignorés et modules capturés : voir ci-dessous.
6. Toute autre trace : le délai est ajouté à la session courante, puis agrégé (voir plus loin).

Deux réglages centraux permettent de traiter à part certains modules :

• un module ignoré est exclu du calcul : le délai de ses traces est perdu, il n'est ajouté à aucun compteur ;
• un module capturé (par défaut learningtimecheck) n'est pas comptabilisé pour lui-même : le délai de ses traces est mis en attente et ajouté au délai de la première trace significative suivante. Le temps passé sur ces modules n'est donc pas perdu, il est imputé à l'activité qui suit.

Voir Exclusion, inclusion de modules.

Les sessions de travail sont reconstituées au fil du calcul :

• une session commence sur une connexion explicite, ou à la première trace en l'absence de connexion ;
• en mode normal, une session peut traverser plusieurs cours : la liste des cours traversés est mémorisée ;
• avec le réglage Une session par cours, une nouvelle session démarre chaque fois que la trace change de cours.

Les sessions sont enregistrées dans la table block_use_stats_session (début, fin estimée, cours traversés), sans doublon.

Chaque délai est affecté à un ou plusieurs agrégats :

• Activités (activities) : le temps des traces qui se rapportent à un module d'activité d'un cours, agrégé par module et par section du cours ;
• Cours (course) : le temps des traces du cours qui ne relèvent d'aucune activité (page d'accueil du cours, rapports, blocs…) ;
• Autre (other) : le temps des traces du cours qui ne se rapportent ni au cours lui-même ni à un module ;
• Total du cours (coursetotal) : la somme des trois précédents pour un cours donné. Le bloc vérifie cette égalité et signale les écarts dans sa trace de diagnostic.

Les traces qui n'appartiennent à aucun cours (connexion, déconnexion, pages hors cours) sont rangées sous l'identifiant de cours 0, et les traces de la page d'accueil du site sous l'identifiant du cours du site. C'est de là que viennent les temps “hors cours” et “temps complémentaires” des rapports.

Lorsque le calcul porte sur un cours précis, seules les traces de ce cours sont résolues au niveau module : les traces des autres cours sont comptées pour le total de leur cours, sans détail.

Si le module Learning Time Check est installé avec le réglage qui l'y autorise, les temps du contrat pédagogique peuvent remplacer les temps mesurés. Les valeurs mesurées d'origine (coursetotalraw, courseraw) sont conservées.

Pour limiter le coût des calculs répétés, le résultat d'un affichage du bloc est mémorisé dans le cache d'agrégats.

Une approche complémentaire de la résolution des ruptures de session a été implémentée sous forme d'un ajout JavaScript à toutes les pages de Moodle. Cet ajout émet une requête automatique (toutes les 10 minutes par défaut), entraînant la création d'un événement de trace renseigné du contexte de la page d'où elle est émise. L'écart maximal entre deux traces d'une page restée ouverte est ainsi borné par la période d'émission, ce qui évite de perdre le temps passé sur une page longue sans clic.

Ce dispositif doit être intégré dans le thème (par exemple dans la partie qui spécialise un pied de page) par l'appel suivant, dans la partie “footer” des “layouts” du thème :

  include_once $CFG->dirroot.'/blocks/use_stats/lib.php';
  echo block_use_stats_setup_theme_notification();

Le dispositif est activé et réglé dans la configuration centrale du bloc (voir Configuration générale), qui permet aussi de restreindre l'émission à certains utilisateurs. Une alternative d'intégration est indiquée dans le guide d'installation.

À l'heure actuelle, l'approche par “keep_alive” ne gère pas les situations d'usage avec de nombreuses navigations parallèles du même utilisateur.

Revenir à l'index du guide d'utilisation - Revenir à l'index des plugins - Retour au catalogue