Aller au contenu principal

Chronométrage et qualité des données

Cette page explique l'infrastructure de chronométrage et les dispositifs de contrôle qualité intégrés au pipeline de participation. Comprendre ces mécanismes vous aide à concevoir des études produisant des données propres et analysables, et donne confiance aux évaluateurs quant à votre méthodologie.

Mesure du temps de réaction​

Chaque tâche comportementale enregistrant une réponse du participant mesure le temps de réaction (TR) à l'aide de l'horloge haute résolution du navigateur. Cette horloge offre une précision inférieure à la milliseconde et n'est pas affectée par les ajustements de l'horloge système, ce qui en fait la source de chronométrage recommandée pour les expériences en ligne.

  • Fonctionnement : Lorsqu'un stimulus apparaît, la plateforme enregistre l'instant d'apparition. Lorsque le participant répond (touche clavier, clic ou appui tactile), la plateforme enregistre l'instant de réponse et calcule la différence. Le résultat est stocké en millisecondes sous la forme latency_ms pour chaque essai.
  • Ligne temporelle de référence : Au début de chaque session, la plateforme établit un point de référence auquel se rattachent tous les horodatages suivants. Chaque événement (stimulus, réponse, marqueur, transition de phase) est enregistré par rapport à cette référence, ce qui permet de reconstruire la séquence et l'espacement exacts des événements lors de l'analyse.
  • Double horodatage : Chaque événement enregistré porte à la fois un horodatage ISO lisible (pour les dates) et une valeur haute résolution en millisecondes (pour les calculs d'intervalles précis). Utilisez les valeurs haute résolution pour calculer les TR et les horodatages ISO pour l'identification et le tri des sessions.

Ce qui affecte la précision temporelle dans le navigateur​

Les expériences en ligne s'exécutent dans un navigateur, ce qui introduit des sources de variabilité absentes des logiciels de laboratoire :

  • Taux de rafraîchissement de l'écran : Les stimuli apparaissent au prochain rafraîchissement après l'appel d'affichage. Sur un moniteur à 60 Hz, cela ajoute jusqu'à ~16,7 ms de gigue ; à 144 Hz, cette fenêtre se réduit à ~6,9 ms. La plateforme ne verrouille pas la présentation des stimuli sur des trames vidéo spécifiques.
  • Latence du périphérique d'entrée : Les événements clavier et souris transitent par la pile d'entrée du système d'exploitation avant d'atteindre le navigateur. La latence ajoutée typique est de 4 à 20 ms selon le matériel, le système d'exploitation et le mode de connexion (USB ou Bluetooth).
  • Ordonnancement des événements du navigateur : Les minuteries JavaScript (utilisées pour les croix de fixation, les intervalles inter-stimuli et les durées de présentation) reposent sur la boucle d'événements du navigateur. En conditions normales, l'erreur d'ordonnancement est ≤4 ms ; une activité de page intense ou des onglets en arrière-plan peuvent l'augmenter.
  • Différences entre navigateurs : Tous les navigateurs modernes (Chrome, Firefox, Edge, Safari) implémentent la même horloge haute résolution, mais la précision au niveau micro varie. Les navigateurs basés sur Chrome tendent à fournir les valeurs sub-milliseconde les plus cohérentes.

Recommandation pratique : Pour les paradigmes où la précision temporelle est critique (amorçage masqué, clignement attentionnel, masquage rétroactif), envisagez d'exiger que les participants utilisent un ordinateur de bureau ou portable avec un clavier filaire et un navigateur basé sur Chrome. Utilisez le filtrage matériel et les métriques d'écran décrits ci-dessous pour documenter la configuration du participant.

Synchronisation des stimuli parlés (auditifs)​

Certaines tâches présentent les stimuli à voix haute en lisant des extraits audio que le chercheur a enregistrés ou téléversés une seule fois dans la configuration de l'étude (par exemple les tâches d'apprentissage de listes et les tâches de performance continue / vigilance jouent les items un à un). Chaque participant entend le même enregistrement, et la plateforme démarre chaque extrait sur l'horloge audio du navigateur. Les temps de réaction mesurés à partir de stimuli parlés conservent néanmoins une réserve résiduelle :

  • L'apparition est le démarrage programmé de l'extrait, non le front d'onde acoustique : la plateforme marque l'apparition du stimulus au moment où l'extrait est démarré sur l'horloge audio. L'écart restant jusqu'à la sortie réelle du son au haut-parleur correspond à la chaîne de sortie audio de l'appareil, typiquement de quelques millisecondes jusqu'à ~20 ms, plus grand et plus variable en audio Bluetooth. La plateforme enregistre avec chaque apparition les valeurs de latence de sortie rapportées par le navigateur, afin que ce résidu puisse être inspecté par participant. Une borne précise multi-navigateurs reste à établir par une mesure en banc d'essai.
  • Conséquence : les temps de réaction à des stimuli parlés sont désormais interprétables pour la plupart des usages, mais leur plancher reste au-dessus du plancher de mesure visuel d'environ 1 ms et dépend du matériel audio du participant. Les comparaisons chez un même participant et une même configuration restent les plus robustes.
  • Les flux à rythme constant restent régulièrement espacés : lorsqu'une tâche diffuse un flux continu d'items à un rythme fixe, l'ordonnancement est ancré à un point de départ unique plutôt qu'enchaîné à partir de chaque item précédent, de sorte que l'espacement ne dérive pas sur une longue série. La durée configurée de l'item fait autorité : un extrait plus court est suivi de silence, et les analyses de l'évolution dans le temps (par exemple un déclin de vigilance) doivent utiliser les temps d'apparition enregistrés de chaque item.
  • Les échecs de lecture sont signalés : si un extrait ne peut pas être lu sur l'appareil d'un participant, la tâche concernée bascule (les mots sont affichés à l'écran, ou la tâche est sautée lorsqu'elle est exclusivement auditive) et les données sont marquées. Excluez les items signalés des analyses de temps de réaction auditifs.
  • Recommandation : lorsque la précision stricte des temps de réaction importe, présentez les stimuli visuellement plutôt qu'à voix haute.

Qualité des données au niveau de la session​

Filtrage matériel​

La plateforme applique systématiquement trois exigences matérielles avant d'autoriser la participation. Ces vérifications garantissent que les participants disposent des capacités matérielles minimales nécessaires pour la recherche comportementale :

  • Support caméra : Le navigateur doit prendre en charge l'accès à la caméra (requis pour les sessions enregistrées en vidéo).
  • Support microphone : Le navigateur doit prendre en charge l'accès au microphone (requis pour les tâches vocales et l'enregistrement audio).
  • Largeur minimale de la zone d'affichage : La largeur interne du navigateur doit être d'au moins 768 pixels pour assurer l'affichage correct des stimuli.

Ces exigences ne sont pas configurables et s'appliquent à toutes les études. Les participants ne répondant pas aux critères voient un message expliquant l'exigence. Ils ne peuvent pas poursuivre tant que le problème n'est pas résolu ou qu'ils ne ferment pas la page.

Métadonnées environnementales​

Chaque session de participation enregistre automatiquement un instantané de l'environnement du participant. Ces métadonnées sont disponibles dans les données exportées et vous aident à évaluer si des différences environnementales pourraient expliquer des résultats aberrants.

Métriques d'écran​

Capturées au début de chaque session et mises à jour chaque fois que le participant redimensionne la fenêtre ou tourne son appareil :

  • Résolution de l'écran : Largeur physique, hauteur, largeur disponible et hauteur disponible en pixels.
  • Taille de la zone d'affichage : Les dimensions internes du navigateur (la zone où les stimuli sont affichés).
  • Ratio de pixels de l'appareil : Indique les écrans haute densité (« Retina »). Un ratio de 2 signifie que l'affichage rend au double de la résolution nominale.
  • Orientation de l'écran : Portrait ou paysage, plus l'angle de rotation.
  • Profondeur de couleur et de pixel : La profondeur de couleur de l'écran en bits.
  • Navigateur et langue : Identifiant du navigateur et paramètre de langue.

Télémétrie d'interaction​

Lorsqu'elle est activée pour une étude, la plateforme enregistre un flux continu d'interactions du participant tout au long de la session :

  • Événements clavier : Chaque appui de touche est enregistré avec un horodatage haute résolution (les caractères individuels sont anonymisés en « char » pour éviter la capture de mots de passe ou d'informations personnelles).
  • Événements de pointeur : Les clics de souris, les appuis tactiles et les mouvements du curseur sont enregistrés avec des coordonnées relatives à la zone d'affichage (en pourcentages, non en pixels absolus).
  • Événements de défilement : Les changements de position de défilement.
  • Focus et visibilité : Quand le participant quitte l'onglet du navigateur ou y revient. Ceci est particulièrement utile pour détecter les participants qui effectuent plusieurs tâches simultanément pendant une session.

Tous les événements de télémétrie portent les mêmes horodatages haute résolution que les données de tâche, vous permettant d'aligner les modèles d'interaction avec les événements de stimulus et de réponse dans votre analyse.

Chronologie média​

Pour les sessions avec enregistrement caméra ou partage d'écran, la plateforme enregistre les horodatages de début et de fin de chaque flux média. Cela vous permet de synchroniser l'enregistrement vidéo avec les marqueurs comportementaux, les réponses et les transitions de tâches.

Synchronisation de l'enregistrement et précision temporelle​

Lorsqu'une session est enregistrée, la plateforme aligne les données comportementales (marqueurs, réponses, regard, transcription) avec la vidéo de sorte que tout se trouve sur une seule ligne de temps. Dans les données exportées, cette ligne de temps commune est le temps d'enregistrement : des millisecondes à partir de la première image de la caméra. C'est ce qui permet de rejouer un enregistrement et de voir chaque stimulus et chaque réponse survenir au bon moment.

Qualité de synchronisation​

Chaque participation enregistrée se voit attribuer une qualité de synchronisation, indiquée dans l'export et signalée par l'étiquette Synchronisation approximative dans la liste des participations :

  • Précise : les données comportementales et la vidéo sont alignées de façon fiable. Utilisez librement les valeurs en temps d'enregistrement.
  • Approximative : l'alignement n'a pu être établi que grossièrement. Les données restent exploitables, mais considérez les valeurs en temps d'enregistrement comme entachées d'une incertitude plus large, et signalez cette limite si vous vous y fiez.
  • Indisponible : aucun alignement fiable n'a pu être établi. Les valeurs en temps d'enregistrement sont laissées vides ; analysez les données comportementales seules et excluez la session des analyses alignées sur la vidéo.

Vous pouvez filtrer sur l'étiquette Synchronisation approximative pour passer en revue ou exclure les sessions concernées.

Quelle précision attendre​

Lorsque la synchronisation est précise, un événement comportemental peut être situé sur la vidéo à environ une image vidéo près, car l'enregistrement est livré à une cadence d'images fixe. C'est la limite pratique du positionnement d'un événement sur la ligne de temps enregistrée ; elle est distincte de la précision du temps de réaction décrite plus haut, mesurée à partir de l'horloge haute résolution du navigateur et indépendante de l'enregistrement.

Lorsque la synchronisation est approximative, l'incertitude est plus grande et n'est pas bornée par la cadence d'images ; réservez les affirmations à l'image près aux sessions marquées précises.

Pour le compte rendu au niveau de l'analyse et les champs en temps d'enregistrement de votre export, voir Données et exports.

Temps absolus en horloge murale​

Le temps d'enregistrement vous indique où un événement se situe à l'intérieur d'une session, mais il ne vous dit pas quand la session a eu lieu sur une horloge globale. Pour cela, la plateforme ajoute une couche absolue optionnelle appelée precise_times. Elle est additive : les horodatages de session hérités restent intacts, et le temps d'enregistrement continue de fonctionner exactement comme décrit ci-dessus. La couche en horloge murale répond à une question différente, à savoir « à quel instant UTC correspond la première image de la caméra », afin que vous puissiez placer une session, ou tout événement qu'elle contient, sur la même ligne de temps que des données recueillies par un instrument externe.

Comment l'horloge absolue est ancrée​

L'horloge système propre d'un navigateur n'est pas fiable pour la recherche : elle peut se tromper de plusieurs minutes, et elle peut sauter ou se mettre en veille en cours de session. Aussi, au lieu de lire l'horloge locale, la plateforme effectue une unique lecture de décalage calibrée par rapport à l'horloge serveur, une seule fois, près du moment du consentement. Elle enregistre l'aller-retour de cette unique lecture et traite la validation serveur comme l'instant véritable. À partir du décalage mesuré, elle peut convertir la ligne de temps haute résolution du navigateur en UTC.

Cette unique calibration produit deux valeurs stockées sur la participation et dans log.json :

  • clock_offset_ms : la différence mesurée entre l'horloge serveur et la ligne de temps du navigateur. Utilisée pour convertir les temps haute résolution en UTC. Elle vaut null (jamais 0) lorsque la lecture n'a pu être menée à bien.
  • clock_offset_error_ms : la moitié au pire cas de l'aller-retour de la lecture, arrondie au supérieur. C'est l'incertitude de la calibration elle-même.

Les trois temps précis​

precise_times rapporte jusqu'à trois instants ancrés. Deux sont stockés, et le troisième est dérivé dans l'export :

  • participation_start : l'instant UTC où la page de participation s'est ouverte.
  • participation_end : l'instant UTC où la participation s'est terminée.
  • record_time_0 : l'instant UTC de la première image de la caméra, c'est-à-dire l'instant où le temps d'enregistrement vaut 0. Celui-ci n'est pas stocké sur la participation ; il est reconstruit dans le metadata.json de l'export, car son calcul nécessite le décalage de début propre à l'enregistrement, connu seulement au moment de l'export.

Chaque temps précis est un objet de même forme :

  • epoch_ms : l'instant en millisecondes UTC.
  • iso : le même instant sous forme de chaîne ISO-8601 en UTC (elle se termine par Z).
  • error_ms : la borne d'incertitude en millisecondes, ou null lorsqu'aucune borne ne s'applique.
  • bounded : true lorsque la valeur porte une borne d'erreur fiable, false sinon.
  • clock_source : server_offset lorsque le décalage calibré a été utilisé, ou local_fallback lorsqu'il ne l'a pas été.
  • recording_sync_source : présent sur record_time_0 uniquement : chirp_anchored ou approximate_sync.
  • clock_anomaly : présent (et true) seulement lorsqu'un saut ou une mise en veille de l'horloge a été détecté ; voir ci-dessous.

record_time_0 est l'ancrage que vous utilisez pour convertir n'importe quelle valeur de temps d'enregistrement en instant d'horloge murale : wall_clock_ms = record_time_0.epoch_ms + recording_ms. Comme le temps d'enregistrement 0 est la première image de la caméra, cette unique relation reconstruit l'instant UTC de chaque marqueur, réponse ou transition sur la ligne de temps enregistrée.

Ce que signifie error_ms : calibration, et non dérive​

C'est le point le plus important de cette page. error_ms est une incertitude de calibration : elle décrit l'aller-retour de l'unique lecture de décalage prise près du consentement. Ce n'est pas une mesure de la dérive de l'horloge au cours de la session.

Le décalage est mesuré une seule fois, puis supposé stable pour le reste de la session. Cela signifie que participation_start.error_ms ne « couvre » pas d'une quelconque façon tout l'intervalle entre l'ouverture de la page et la fin de la session. Il vous indique avec quelle précision cette unique calibration a fixé l'horloge à l'instant où elle a été prise, rien de plus. Si vous devez raisonner sur la dérive au long d'une session longue, traitez le décalage comme un unique point de calibration, et non comme une borne maintenue en continu.

La conséquence honnête : si l'horloge a réellement sauté ou s'est mise en veille pendant la session, la calibration n'est plus valide, et la plateforme le signale en marquant la session comme approximative plutôt qu'en prétendant que la borne tient toujours (voir le cas d'anomalie d'horloge ci-dessous).

En quoi cela diffère des horodatages de session hérités​

Les exports et la liste des participations portent aussi les valeurs héritées session_started_at et session_ended_at. Celles-ci proviennent de l'horloge de la machine locale du navigateur et n'ont aucune borne d'erreur. Elles peuvent être décalées d'autant que l'horloge du participant est décalée, et rien ne le signale.

precise_times est différent par nature : il est ancré au serveur et porte une incertitude explicite et honnête. Ne confondez jamais une horloge avec l'autre. Si vous vous alignez sur un instrument externe ou rapportez des temps absolus, utilisez precise_times ; ne traitez les horodatages hérités que comme une référence approximative et non bornée de l'horloge locale.

Les durées ne sont pas recalculées à partir des époques précises : recalculer une durée à partir de deux temps précis compterait le décalage en double. session_duration_ms est un delta d'horloge murale haute résolution et reste invariant au décalage. recording_duration_ms est la fin de la dernière tâche exprimée sur l'horloge d'enregistrement (0 = la première image de la caméra), elle est donc mesurée à partir de cet unique ancrage image-zéro ; ce re-zérotage ponctuel vers l'image de la caméra n'est pas un recalcul à partir de deux époques précises et ne compte pas le décalage en double.

Quand l'horloge n'est qu'approximative​

Un temps précis est rapporté avec bounded: false (et error_ms: null) dans trois situations. La plateforme n'invente jamais de borne factice ou nulle ; un « approximatif » honnête est toujours préférable à un « précis » mensonger.

  • Repli local : la lecture de décalage a échoué ou l'appareil était hors ligne au consentement. clock_source vaut local_fallback, clock_offset_ms vaut null, et les temps se replient sur l'horloge locale sans borne.
  • Anomalie d'horloge : la plateforme vérifie la stabilité de l'horloge à trois ancrages (initialisation de la page, consentement, finalisation) en comparant de combien l'horloge murale a avancé à de combien l'horloge haute résolution a avancé. Si elles divergent de plus que la tolérance (un CLOCK_STEP_TOLERANCE_MS fixe de 250 ms), l'horloge a sauté ou s'est mise en veille. clock_anomaly est activé, et la session entière devient non bornée. C'est précisément le cas que met en garde le point calibration-et-non-dérive : un saut important invalide l'unique lecture de décalage.
  • Synchronisation approximative : n'affecte que record_time_0. Lorsqu'il n'existe pas de décalage de début d'enregistrement exploitable (pas d'ancrage par chirp, ou décalage inconnu ou 0), record_time_0 est émis avec recording_sync_source: approximate_sync et bounded: false. Le début et la fin de la participation ne sont pas affectés et peuvent rester précis.

Les deux dimensions de qualité sont indépendantes. Le décalage d'horloge (clock_source) et la synchronisation de l'enregistrement (recording_sync_source) sont mesurés séparément, de sorte qu'une session peut avoir une horloge solide mais une synchronisation d'enregistrement seulement approximative, ou inversement. Elles se combinent uniquement pour record_time_0 :

  • Pour participation_start et participation_end (pas de dimension de synchronisation) : bounded est vrai lorsque clock_source vaut server_offset et qu'il n'y a pas de clock_anomaly.
  • Pour record_time_0 : bounded est vrai lorsque clock_source vaut server_offset et que recording_sync_source vaut chirp_anchored et qu'il n'y a pas de clock_anomaly.

Lorsque record_time_0 est borné, son error_ms vaut clock_offset_error_ms + RECORDING_SYNC_BOUND_MS. RECORDING_SYNC_BOUND_MS est une constante de politique conservatrice de 5 ms, et non une valeur mesurée par session. Son plancher physique est la précision de la corrélation croisée du chirp (environ 0,67 ms) ; la valeur de 5 ms est une marge délibérée au-dessus de ce plancher. Traitez-la comme une constante de politique dans tout compte rendu.

Aligner des données externes ou matérielles​

record_time_0.epoch_ms + recording_ms vous donne une étiquette d'horloge murale pour n'importe quel point de la ligne de temps enregistrée, ce qui est ce qu'il vous faut pour un alignement grossier : faire correspondre une session à des journaux, des capteurs ou des instruments à quelques dizaines de millisecondes près.

Pour une synchronisation externe ou matérielle inférieure à la milliseconde, n'utilisez pas l'horloge murale. L'horloge murale est bornée par l'aller-retour de la lecture de décalage (quelques dizaines de millisecondes) plus l'erreur d'horloge propre à l'appareil externe, de sorte qu'elle ne peut pas fournir un alignement sub-milliseconde. Utilisez plutôt le chirp intégré au signal déjà présent dans l'audio de l'enregistrement : un second appareil qui capture le même audio corrèle de façon croisée le chirp et s'aligne directement sur le temps d'enregistrement, en deçà de la milliseconde, sans aucune dépendance à une horloge murale. Considérez record_time_0 comme l'étiquette grossière d'horloge murale de la ligne de temps enregistrée, et le chirp comme le mécanisme de synchronisation précis.

Comment les temps précis apparaissent dans l'interface​

Dans la liste des participations, le début et la fin précis s'affichent à la place des horodatages hérités de l'horloge locale, avec une infobulle indiquant la borne +/-. Le libellé de l'infobulle présente cette borne comme une incertitude de calibration mesurée près du consentement, et non comme une dérive sur toute la durée de la session. Lorsqu'une valeur n'est pas bornée (repli local ou anomalie d'horloge), un badge ambre Horloge approximative apparaît. Les participations enregistrées avant l'existence de cette fonctionnalité se replient simplement sur la chaîne héritée de l'horloge locale, sans badge.

Résumé qualité dans les données exportées​

Lorsque vous exportez une participation, le résumé qualité comprend :

  • Résultats du filtrage matériel : Ce que l'appareil du participant supportait et s'il a réussi les vérifications requises.
  • Métriques d'écran : L'instantané initial et tout changement survenu pendant la session.
  • Télémétrie d'interaction : Le flux complet d'événements avec des horodatages relatifs au point de référence de la session.

Bonnes pratiques​

  • Activez la télémétrie d'interaction pour les études exploratoires où vous souhaitez comprendre le comportement du participant au-delà des réponses aux tâches (par ex., patterns d'hésitation, fréquence de changement d'onglet).
  • Rapportez la méthodologie de chronométrage dans votre manuscrit. Indiquez que les temps de réaction ont été mesurés avec l'horloge haute résolution du navigateur. Mentionnez que tous les participants ont satisfait aux exigences matérielles de la plateforme (caméra, microphone, zone d'affichage minimale de 768px). Si vous avez appliqué des critères d'exclusion supplémentaires lors de l'analyse, décrivez-les clairement.