Ce que les chercheurs perdent lorsque l’analyse est une réflexion après coup

L'analyse est souvent traitée comme une couche de reporting qui peut être ajoutée une fois qu'un outil de recherche ou une plateforme d'apprentissage fonctionne déjà. Cette séquence semble efficace. Pour les équipes de recherche, c’est souvent la mauvaise séquence.

Lorsque l’analyse est laissée tard dans le processus de conception, les données obtenues sont généralement suffisamment bonnes pour compter l’activité, mais pas assez bonnes pour avoir beaucoup de poids probant. Les événements sont définis de manière incohérente, les métadonnées contextuelles sont inégales et les problèmes de gouvernance deviennent plus difficiles à résoudre car le modèle de données est déjà intégré au produit.

Le problème en termes clairs

Une plateforme peut enregistrer de nombreuses activités tout en laissant une équipe de recherche incapable de répondre à des questions de base. Les définitions de session dérivent. Le temps passé sur la tâche est déduit au lieu d'être capturé. Les groupes d’intervention et de comparaison sont difficiles à séparer. Les usages facilités et autonomes se mélangent.

À ce stade, la plateforme dispose de données, mais l’équipe n’a pas encore de preuves. La définition 2025 de SoLAR est utile ici car elle traite l'analyse de l'apprentissage comme la collecte, l'analyse, l'interprétation et la communication au service d'informations théoriquement pertinentes et exploitables.[1] Le code de bonnes pratiques de Jisc parvient à une conclusion connexe grâce à la validité, à la transparence et à la gestion.[2]

À quoi ressemble le modèle de réflexion après coup

L'analyse après coup ne signifie pas l'absence d'analyse. Cela signifie que la couche analytique est en aval des décisions prises pour d’autres raisons. Le flux de travail, l’interface et la base de données sont déjà définis avant que quiconque ne se demande ce qui doit être mesuré, ce qui doit être comparable, quelles métadonnées contextuelles sont nécessaires et comment les données seront gouvernées.

Cela produit généralement trois modèles : le système enregistre tout ce qu'il expose déjà, les normes sont introduites trop tard pour façonner l'instrumentation et les rapports se détachent de l'objectif de la recherche. xAPI, Profiles work, Caliper et les conseils de 1EdTech pointent tous vers la même leçon pratique : la taxonomie et la signification des événements doivent être décidées avant l'échelle.[3][4][5][6]

Ce qui se perd

1. La définition de l'événement devient incohérente

Des actions similaires finissent par être capturées de différentes manières sur la même plateforme. Un composant enregistre une achèvement, un autre enregistre une visite de page, un troisième enregistre uniquement un changement d'état de la base de données. Ceux-ci peuvent concerner le même comportement, mais ils ne signifient pas la même chose sur le plan analytique.

2. Le contexte est supprimé des données

Les équipes de recherche ont rarement besoin de savoir uniquement que quelque chose s'est produit. Ils doivent également savoir si l'action s'est produite dans une condition d'intervention ou de contrôle, si elle a été facilitée ou à son propre rythme, et à quelle étape de l'étude elle appartenait. FAIR, Caliper et Practicable Learning Analytics renforcent tous le lien entre les métadonnées, la provenance et l'interprétation ultérieure.[7][5][8]

3. La comparabilité entre les études est compromise

Même lorsque deux équipes utilisent la même plate-forme, les données peuvent ne pas être comparables si l'instrumentation est incohérente, si les variables dérivent d'une version à l'autre ou si les catégories clés sont codées différemment dans différentes études. La littérature récente conforte cette préoccupation, soulignant les obstacles socio-techniques, l’ambiguïté dans l’interprétation et l’incohérence opérationnelle dans les travaux d’analyse de l’apprentissage.[9][10]

4. La couche de reporting répond aux mauvaises questions

Les tableaux de bord avancés ont tendance à signaler ce qui est le plus facile à compter : les connexions, les clics, les pages vues ou les estimations grossières de temps. Ces mesures peuvent être utiles, mais elles constituent souvent des approximations pratiques plutôt que des variables choisies parce qu’elles sont importantes pour la question de recherche. Les tableaux de bord ne peuvent faire apparaître que ce que l’architecture des données a rendu lisible.[1][6][15]

5. La gestion des données devient réactive

Lorsque la capture des données évolue de manière opportuniste, les institutions peuvent finir par collecter plus de données personnelles que nécessaire, les conserver plus longtemps que nécessaire ou avoir du mal à expliquer clairement ce qui est collecté et pourquoi. DELICATE, le cadre de Cormack et les directives actuelles de l'ICO pointent tous vers la même conclusion : la gouvernance doit être conçue dans la pratique analytique, et non annexée ultérieurement.[11][12][13][14]

Les décisions de conception qui comptent dès le début

Si le problème réside dans la séquence de conception, la solution concerne également la séquence. Avant la construction d’une plateforme, les équipes de recherche et les équipes technologiques doivent résoudre au moins cinq questions de conception.

1. Définir le modèle d'événement avant que l'interface ne soit définitive.
2. Spécifiez les métadonnées contextuelles aux côtés des événements principaux.
3. Séparer la surveillance opérationnelle des exigences en matière de preuves.
4. Intégrer la comparabilité dans la spécification.
5. Gestion de la conception dans l'architecture.

La conception basée sur l'analyse n'est pas glamour. Cela signifie généralement décider des choses plus tôt, les documenter plus soigneusement et résister à la tentation de considérer les tableaux de bord comme un substitut à l'architecture des données.

Ce que cela signifie en pratique

Pour les responsables de recherche qui commandent ou sélectionnent des outils numériques, les questions les plus utiles sont souvent architecturales plutôt que présentationnelles.

• Quels événements la plateforme définit-elle explicitement, et que signifient ces événements ?
• Quelles métadonnées sont capturées à côté de chaque événement, en particulier pour la condition d'étude, la cohorte, le mode de facilitation et la phase ?
• Quelles mesures sont des captures directes et lesquelles sont des proxys inférés ?
• Comment la plateforme préserve-t-elle la comparabilité entre les cohortes, les versions ou les sites ?
• Quelle est l'approche de la plateforme en matière de minimisation, de rétention, de demandes d'accès et de communication transparente avec les participants ?

Pour les équipes technologiques institutionnelles, la leçon correspondante est simple : ne considérez pas « avoir des analyses » comme une exigence adéquate. Demandez-vous si les exigences d'analyse ont été spécifiées avant la finalisation de l'architecture du système, comment les modifications d'instrumentation sont versionnées et si les métriques du tableau de bord correspondent aux questions de recherche plutôt qu'à la simple commodité opérationnelle.[2][6]

Fermeture

Si les analyses sont conçues tardivement, les équipes de recherche ne perdent généralement pas complètement de données. Ils perdent quelque chose de plus important : la confiance que les données signifient ce qu’elles veulent dire, sous une forme qu’ils peuvent comparer, gouverner, expliquer et utiliser.

C'est le problème qu'EdTechLab explore. Il ne s’agit pas de savoir comment produire davantage de tableaux de bord, mais comment concevoir une infrastructure de recherche de manière à ce que la qualité des preuves ne soit pas laissée à un travail de réparation à la fin.