Quiz de fin de module

Vos réponses sont enregistrées au fur et à mesure. Vous pouvez revenir en arrière tant que le quiz n'est pas rendu.

Cible : 70 %

Question 3 sur 8

Question 3

Quels éléments doivent déclencher une déclaration de soupçon ?

Plusieurs réponses possibles.

Un versement en espèces sans rapport avec l'activité connue du client
Un virement récurrent vers un fournisseur habituel
Le refus répété de justifier l'origine des fonds
Une opération dont le montant dépasse le plafond contractuel

Moment 2 / 3 — La correction après « Vérifier ma réponse » : la question se fige, le commentaire s'ouvre

Question 3 — vérifiée

Quels éléments doivent déclencher une déclaration de soupçon ?

Vos réponses sont figées : cette question ne peut plus être modifiée.

Un versement en espèces sans rapport avec l'activité connue du client Juste
Un virement récurrent vers un fournisseur habituel
Le refus répété de justifier l'origine des fonds Juste
Une opération dont le montant dépasse le plafond contractuel Attendue

Pourquoi Le plafond contractuel n'est pas un critère de soupçon en soi, mais son dépassement répété sans justification l'est. Ce sont l'incohérence avec le profil connu et le refus de justifier qui fondent la déclaration — jamais le seul montant.

Moment 3 / 3 — Le résultat après « Terminer le questionnaire »

78 %

Cible atteinte

Résultats de votre quiz

7 bonnes réponses sur 8. La cible de ce quiz est de 70 % : vous l'avez atteinte. Votre progression sur le module est enregistrée.

Cible non atteinte

Le bandeau passe en ambre — « Cible non atteinte », jamais en rouge : un quiz manqué n'est pas une erreur, c'est une étape.

Question sans réponse

« Terminer le questionnaire » reste actif, et l'écran dit combien de questions restent sans réponse avant de demander confirmation.

Envoi en cours

Le bouton passe en attente et se désactive : un double envoi créerait deux tentatives.

Échec d'envoi

« Vos réponses n'ont pas pu être envoyées. » Elles restent à l'écran — on ne perd jamais une saisie sur une panne réseau.

Ce que la maquette fixe

La cible est annoncée AVANT de commencer, dans l'en-tête. L'écran actuel la garde pour la fin : on découvre le seuil en même temps que son score, ce qui ne permet jamais de doser son effort.
Juste et faux ne se distinguent pas que par la COULEUR. Chaque option corrigée porte son icône et son mot — « Juste », « Attendue ». Un écran qui n'oppose que du vert et du rouge est illisible pour une personne daltonienne, et c'est la seule information qui compte ici.
Une bonne réponse MANQUÉE est signalée, pas seulement les mauvaises cochées. Sans elle, l'apprenant qui a coché 2 réponses justes sur 3 ne voit rien de rouge et croit avoir tout bon.
Le commentaire explique le POURQUOI, il ne répète pas la correction. C'est le seul moment pédagogique de l'écran : redire « la bonne réponse était B » n'apprend rien.
La progression donne une barre ET un compte — « Question 3 sur 8 ». La barre donne l'allure d'un coup d'œil, le compte donne le fait ; une barre seule ne dit pas combien il reste.
Un quiz manqué s'affiche en ambre, jamais en rouge. Ne pas atteindre la cible est une étape d'apprentissage, pas une faute. Le rouge est réservé à ce qui est cassé.
Une panne d'envoi ne perd pas les réponses. Elles restent à l'écran : c'est la règle qui manque le plus souvent, et celle qui coûte le plus cher à l'apprenant.

À VALIDER Q-1Peut-on revenir sur une question déjà vérifiée ? Le code fige la question dès « Vérifier ma réponse » (disabledQuestions) mais laisse « Précédent » actif : on revient sur une question qu'on ne peut plus modifier. La maquette garde ce comportement en l'ÉCRIVANT (« vos réponses sont figées »). Faut-il plutôt interdire le retour, ou permettre de refaire ?

À VALIDER Q-2« Vérifier ma réponse » est-il facultatif ou imposé ? Aujourd'hui l'apprenant peut enchaîner les questions sans jamais vérifier, et ne voir la correction qu'à la fin — ou vérifier à chaque question. Deux pédagogies différentes cohabitent sans que l'écran tranche. Laquelle veut-on ?

À VALIDER Q-3Le « Badge » du code n'a pas de définition. QuizAttempt.jsx affiche un t("Badge") dans le bloc de résultats, sans qu'on sache ce qu'il récompense ni comment il s'obtient. La maquette ne le montre PAS, faute de savoir quoi dessiner. À définir, ou à retirer du code.

À VALIDER Q-4Aucun minuteur nulle part. Le sommaire du cours annonce pourtant une durée pour le quiz (« 3:00 »). Est-ce une estimation de lecture ou une limite de temps ? Si c'est une limite, l'écran doit la montrer et la faire respecter ; si c'est une estimation, le sommaire ne devrait pas l'afficher comme une durée d'épreuve.

À VALIDER Q-5Combien de tentatives ? Le cockpit manager compte les « Tentatives » d'un apprenant, donc plusieurs sont possibles. Mais l'écran ne dit jamais combien il en reste, ni si la meilleure ou la dernière fait foi. Un apprenant qui recommence ne sait pas ce qu'il risque.

À VALIDER Q-6« Revoir mes réponses » existe-t-il vraiment ? La maquette le propose parce que c'est le geste attendu après un résultat. Rien dans le code actuel ne le sert. À confirmer avant développement.

CHANGEMENT UXLes libellés du code sont en anglais dans la version française — « Submit », « Verifyanswer », « Following », « Require … to pass ». La maquette les écrit en français : « Soumettre » n'a d'ailleurs pas de sens ici, c'est « Terminer le questionnaire ».