Intégrité de l'évaluation en ligne et anti-triche : un modèle progressif pour une application de maths grand public

Tableau du modèle de menaces

Attaque	Qui la commet	Comment la détecter	Coût de la défense
Chercher la réponse (recherche, manuel scolaire)	Tout âge/palier	Temps de réponse très inférieur au temps de résolution humain le plus rapide plausible ; correction quasi instantanée après une inactivité/un changement d’onglet visible	Faible — plancher de temps de réponse côté serveur par item, événements de visibilité d’onglet
Le parent/frère ou sœur résout à la place de l’enfant	Surtout les jeunes enfants	Décalage de style par rapport à la courbe de tendance de compétence propre au compte	Faible-moyen — signalement fondé sur la tendance uniquement, jamais punitif à cet âge
Application solveur/calculatrice sur un second appareil	Enfants plus âgés, adolescents, adultes	Plancher de temps de réponse ; un solveur répond quasi instantanément quelle que soit la difficulté, alors que le temps d’un humain évolue avec elle	Faible-moyen — même mécanisme de plancher, calibré par type d’item
Un second appareil répond pendant que l’appareil principal sert de « chronomètre »	Adolescents, palier compétitif	Difficile sans attestation d’appareil ; atténué structurellement en gardant le chronométrage côté serveur, de sorte qu’un second appareil n’apporte aucun avantage mesurable	Moyen — architectural, pas un ajout superficiel
Partage de réponses entre amis	Tout âge, contextes de classe	Statistiques de similarité de réponses/de collusion (omega, GBT, indice K) ; significatif seulement une fois la banque d’items assez grande	Moyen-élevé — nécessite une vraie banque plus une machinerie statistique
Scripts/bots automatisés (répétition d’API, navigateur headless)	Utilisateurs techniques, fermiers de classement	Signaux de gestion de bots (empreinte comportementale, preuve de calcul, TLS/JA3), limitation de débit, jetons Turnstile/Privacy Pass	Faible-moyen — infrastructure prête à l’emploi
Partage de compte (un identifiant, plusieurs personnes)	Familles, palier compétitif	Détection de sessions concurrentes, non-correspondance des identifiants WebAuthn, discontinuité de compétence	Moyen — nécessite un suivi de session/appareil
Échouer délibérément du contenu facile pour farmer le rang (« sandbagging »)	Utilisateurs compétitifs/de classement	Anomalie de variance par rapport à son propre historique	Moyen — nécessite une base de compétence/de classement maintenue (déjà requise par le sujet 18)

Résultats

1. Notation faisant autorité côté serveur, et pourquoi le chronométrage client ne peut pas être fiable

Un navigateur est entièrement inspectable et modifiable par son propre utilisateur : DevTools peut suspendre l’exécution, réécrire des variables, rejouer des requêtes réseau modifiées, et écraser Date.now()/performance.now(). C’est le même modèle de menace qui a rendu obsolètes les architectures multijoueurs « faisant autorité côté client » (le client rapporte son propre score/temps, le serveur le croit simplement). Le serveur doit horodater indépendamment la question servie et la réponse reçue, et vérifier indépendamment la correction — le client ne fait que rendre et collecter. Rien d’autre ne passe à l’échelle pour un classement où la vitesse compte des points, puisqu’une durée rapportée par le client est exactement ce que récompense le plus la manipulation.

2. Stratégie de banque d’items : taille, paramétrisation, randomisation, contrôle d’exposition

La recherche sur les tests adaptatifs informatisés (CAT) offre un plan directement applicable. L’exposition d’items — la part des candidats voyant un item donné — tend vers 1 pour les items les plus informatifs dans un algorithme adaptatif naïf, ce qui est en soi un problème de sécurité : un item montré de façon répétée devient partageable [10]. Trois mesures d’atténuation établies : la méthode Sympson-Hetter (tirer un nombre aléatoire, le comparer à un paramètre d’exposition propre à l’item avant d’administrer même l’item le mieux adapté) ; la sélection randomesque/stratifiée (choisir aléatoirement parmi les 5 à 10 items les plus informatifs, pas toujours le seul meilleur) ; et le test fantôme (van der Linden — construire à chaque étape un test hypothétique optimal complet pour des choix globalement, et non seulement localement, optimaux) [10]. Sous ces trois mesures se trouve un grand réservoir d’items, développé à moindre coût via une génération d’items paramétrée/algorithmique (un modèle comme a + b = ? avec des opérandes randomisés par palier de difficulté) plutôt que des items rédigés à la main — explicitement la façon pratique dont les réservoirs se développent économiquement selon la littérature CAT [10].

3. Détection statistique : valeurs aberrantes de temps de réponse

Le modèle log-normal de temps de réponse de van der Linden traite les temps de réponse d’une personne à chaque item comme régis par un paramètre de « vitesse » propre à la personne, aux côtés de paramètres d’intensité temporelle et de discrimination propres à l’item, structurellement parallèle à la façon dont la théorie de réponse à l’item logistique à deux paramètres traite la correction [11]. Une fois ajusté, il permet des vérifications prédictives classiques et bayésiennes a posteriori pour l’aberrance — une réponse nettement plus rapide ou plus lente que prévu — déjà appliquées pour détecter un comportement aberrant sur des tests adaptatifs informatisés [11]. Pour Math Challenge, la version pratique n’a besoin d’aucun modèle complet dans un premier temps : un plancher empirique (« aucun humain vérifié ne résout cette classe d’item en moins de X ms ») est une première ligne de défense légitime, montant en puissance vers le modèle complet uniquement aux paliers où les enjeux justifient l’investissement.

4. Détection statistique : indices de similarité de réponses et de collusion

La détection de copie/collusion de réponses est un sous-domaine psychométrique établi, confirmé via ERIC : l’indice omega (Ω) de Wollack (raffiné par Maeda et Zhang 2017 ; Sunbul et Yormaz 2018), le test binomial généralisé (GBT) comparé à omega pour la puissance/l’erreur de type I (Zopluoglu et Davenport, 2012), l’indice K (Holland) contre la divergence de Kullback-Leibler (Belov et Armstrong, 2010 ; Ucar et Dogan, 2021), une mesure KL fondée sur le temps de réponse (Man et al., 2018), et un indice de correspondance variable (Belov, 2011) [12]. Tous partagent une structure : ils signalent quand deux candidats donnent la même réponse erronée plus souvent que le hasard ne le prédit compte tenu de leurs aptitudes individuelles — un taux inhabituellement élevé de réponses incorrectes identiques est la signature. Cela n’est significatif qu’une fois qu’une banque d’items est assez grande pour que deux personnes convergeant sur le même item par hasard soit rare.

5. Navigateurs verrouillés et proctoring à distance — et pourquoi ne pas les utiliser sur des enfants

Le proctoring par caméra à distance (Proctorio, ExamSoft, Honorlock, Respondus) a explosé pendant le COVID-19 et a laissé une traînée documentée de préjudices et de contestations juridiques :

• L’efficacité est douteuse. La recherche de l’université de Twente est rapportée (via un résumé secondaire) comme ayant trouvé la sensibilité de détection de triche de Proctorio « very close to zero » [4].
• Un tribunal fédéral américain a jugé une pratique spécifique inconstitutionnelle. Ogletree v. Cleveland State University concernait un « room scan » par webcam imposé ; l’affaire est documentée comme un jugement fondé sur le quatrième amendement contre cette pratique, rendu par un tribunal fédéral de district de l’Ohio (2022) [3].
• Contentieux sous la BIPA de l’Illinois. Des étudiants ont allégué que Proctorio collectait des informations/identifiants biométriques sans le consentement requis ; Proctorio a nié ces allégations. La BIPA prévoit des dommages statutaires de 1 000 $ (négligence) / 5 000 $ (intention) par infraction, ce qui explique pourquoi les fournisseurs de proctoring font face à ce type de contentieux récurrent [13].
• L’affaire néerlandaise souvent citée va dans l’autre sens. Rechtbank Amsterdam, ECLI:NL:RBAMS:2020:2917 (11 juin 2020) : les conseils étudiants central et de faculté de l’UvA ont demandé une injonction contre Proctorio ; le tribunal a rejeté toutes les demandes, jugeant le traitement licite sous l’article 6(1)(e) du RGPD, « nécessaire » compte tenu des fermetures liées au COVID-19, « proportionné » (dépistage automatisé, revue humaine limitée, suppression après 30 jours) et « adéquatement protégé » (stockage dans l’UE, accord de sous-traitance, DPIA au dossier), notant que Proctorio était « less invasive than continuous live video surveillance » [5]. C’est une véritable victoire juridique pour le proctoring — conditionnée à un ensemble étroit et documenté de garde-fous (rétention courte, DPIA, étudiants adultes, nécessité pandémique) qui ne décrit rien d’une application grand public pour des enfants de quatre ans.
• Un constat de discrimination parallèle. L’Université VU Amsterdam a séparément fait face à une plainte de l’Institut néerlandais des droits humains alléguant que Proctorio discriminait un étudiant noir ; l’institut n’a trouvé aucune discrimination dans ce cas, mais la plainte s’inscrit dans le même schéma plus large de préoccupation sur les biais algorithmiques autour du proctoring (non vérifié au-delà de l’extrait).

Conclusion pour Math Challenge : le proctoring par caméra/microphone d’enfants n’a sa place dans ce produit à aucun palier. Les préjudices documentés s’appliquent avec plus de force aux mineurs qu’aux adultes universitaires concernés par ces affaires, et aucune des conditions atténuantes du tribunal d’Amsterdam (nécessité pandémique, capacité de consentement adulte, DPIA institutionnel) n’existe ici.

6. Attestation d’appareil sur le web en 2026

• WebAuthn/passkeys : API navigateur standard, fonctionne dans tout navigateur moderne y compris les PWA installées ; lie une clé publique à un appareil, et un serveur peut stocker plusieurs identifiants de clé par compte — WebAuthn ne signale pas lui-même automatiquement un « nouvel appareil », cette comptabilité est côté serveur [16].
• Private Access Tokens (Apple) / Privacy Pass (IETF) : un schéma à trois parties (émetteur, client, serveur) prouvant qu’une requête provient d’un appareil légitime sans révéler l’identité, via un flux de défi-réponse et une validation par signature aveugle RSA ; intégré dans iOS 16+/macOS Ventura+ pour réduire les CAPTCHA, et intégré dans Cloudflare Turnstile — mais sans support de premier plan confirmé en dehors des plateformes Apple, à traiter comme un signal bonus sur le trafic Safari/iOS, pas comme un mécanisme général [14][15][18].
• Play Integrity API de Google : exclusivement pour les applications Android natives distribuées via Google Play, vérifiant l’authenticité du binaire de l’application, la source d’installation et l’authenticité de l’appareil — ne s’applique pas à une PWA ; les propres directives web de Google renvoient ailleurs (Privacy Sandbox) [17].
• Apple App Attest : attestation native iOS analogue, liée à la distribution App Store de la même façon que Play Integrity est liée au Play Store — indisponible pour une PWA non distribuée via l’App Store.

Lecture pratique pour un produit PWA-first : WebAuthn est le seul mécanisme de liaison d’appareil véritablement disponible partout ; Play Integrity/App Attest sont structurellement indisponibles sans application native encapsulante ; les Private Access Tokens sont un bonus réel mais orienté Apple, déjà intégré dans Turnstile.

7. Détection de bots et limitation de débit

La pile de gestion de bots de Cloudflare combine un moteur d’apprentissage automatique notant chaque requête de 1 à 99 à partir de caractéristiques de requête/en-tête/session, un moteur heuristique correspondant à des empreintes malveillantes connues, et une détection JavaScript des navigateurs headless, affinée par un cookie de session (__cf_bm) qui lisse les scores pour réduire les faux positifs [18]. Turnstile est la version grand public : de petits défis JS non interactifs (preuve de calcul, preuve d’espace, sondage d’API web, détection de particularités du navigateur) au lieu d’un puzzle visuel, traitant déjà les jetons Privacy Pass comme une entrée [15][18]. La limitation de débit sur les points de terminaison de soumission/notation est la couche complémentaire la plus simple : plafonner les soumissions par compte/IP/fenêtre capte les abus scriptés à haut volume, indépendamment du fait qu’une requête individuelle paraisse humaine.

8. Comment les plateformes compétitives nommées gèrent la triche à grande échelle

• Codeforces : note la performance relativement à des adversaires de classement connu au sein d’un concours plutôt que des points fixes par problème, réduisant l’incitation à manipuler une valeur de points brute (voir aussi la recherche du sujet 18, docs/research/2026-07-31-mc-18-leaderboards-competition.md) [1].
• Chess.com : détecte le jeu suspect à partir de « plus de 100 facteurs de gameplay », ne s’appuyant explicitement pas sur un seul score de précision (« Accuracy is not cheat detection ») ; des systèmes automatisés gèrent environ 85 % des fermetures ; janvier-mars 2025 a vu environ 28 000 appels examinés sur 314 000 fermetures, à un taux d’acceptation de 0,2 % ; la fermeture de compte pour événement à prix en espèces exige un logiciel Proctor à deux caméras obligatoire uniquement ; la méthodologie a été vérifiée en externe par le statisticien de Harvard Natesh S. Pillai (2016) et approuvée par US Chess (2020) [2].
• Duolingo : combat le farming de classement/XP (bots à complétion automatique, farming de contenu répétitif, exploits de chronométrage) en surveillant des pics de XP inhabituels et une complétion de leçon irréalistement rapide, soutenu par des bannissements et le signalement communautaire — le principe de valeur aberrante de temps de réponse appliqué de façon informelle à l’échelle du produit [19].
• Kaggle : les règles sont connues dans tout le secteur pour restreindre le partage privé hors des limites d’équipe, plafonner la taille d’équipe/les fenêtres de fusion, et interdire les comptes multiples, mais les spécificités de cette section sont des connaissances générales du secteur, pas une citation confirmée (la documentation n’était pas directement accessible pendant cette recherche).
• Kahoot : aucun contenu de source primaire citable sur la triche/l’outillage de bots (par exemple, des scripts « flooder » tiers) n’a pu être récupéré ; cela reste un vide ouvert, pas une affirmation sourcée.

Implications pour la conception

Une échelle progressive concrète à six paliers. Chaque palier ne fait qu’ajouter des contrôles au-dessus de la fondation faisant autorité côté serveur du palier précédent — rien n’est retiré en montant, rien au-dessus du palier 0 n’est jamais redescendu vers le palier d’un enfant plus jeune.

1. Palier 0 — Maternelle (4-6 ans) : chronométrage/notation faisant autorité côté serveur uniquement, de façon invisible. Le serveur horodate indépendamment la question servie/la réponse reçue et vérifie la correction ; le client ne contrôle jamais ni l’une ni l’autre valeur. Aucune interface anti-triche visible, aucun verrouillage, aucun message sur la triche — un parent résolvant aux côtés de son enfant est l’usage prévu, pas une menace.
2. Palier 0 — plancher de temps de réponse, journalisation uniquement. Un temps de résolution plausible minimal par type d’item est enregistré et journalisé s’il est franchi, jamais bloquant ni notant zéro. Pure télémétrie pour calibrer les paliers ultérieurs ; visible uniquement sur un futur tableau de bord parent/tuteur, jamais pour l’enfant.
3. Palier 1 — Début du primaire (7-9 ans) : surveillance silencieuse de la variance. Le serveur suit la tendance de précision/vitesse propre à chaque apprenant par compétence ; une déviation soudaine importante ne déclenche qu’un signal doux (difficulté adaptative légèrement plus prudente) — jamais un verrouillage, un avertissement ou une pénalité visible.
4. Palier 1 — limitation de débit sur les points de terminaison de soumission. Des plafonds de soumission de base par compte/IP (infrastructure partagée) protègent le backend des abus scriptés à partir de ce palier.
5. Palier 2 — Fin du primaire/collège (10-13 ans) : le plancher de temps de réponse devient un signal actif et doux. Franchir le plancher déclenche un moment d’interface amical (« c’était rapide — tu veux vérifier deux fois ? ») plutôt qu’une journalisation silencieuse ; des franchissements répétés abaissent la confiance de l’estimation de maîtrise, jamais n’annulent des points. Toujours aucun verrouillage, aucun proctoring, aucune alarme parentale.
6. Palier 2 — la randomisation de la banque d’items commence à compter. La génération d’items paramétrée (opérandes randomisés par palier de difficulté) devient le mécanisme de diffusion par défaut, puisque c’est la tranche d’âge où un frère/une sœur ou un camarade de classe gagne pour la première fois une incitation à transmettre un jeu de problèmes exact.
7. Palier 3 — Lycée/adolescent général (14-17 ans) : Turnstile + liaison d’appareil WebAuthn sur les actions de classement uniquement. Turnstile protège les points de terminaison de soumission affectant le classement (invisible par défaut) ; les identifiants d’appareil WebAuthn sont introduits pour la reconnaissance de compte, pas comme exigence de connexion — signalant « un troisième nouvel appareil cette semaine » comme une entrée parmi d’autres, jamais comme une barrière unique.
8. Palier 3 — les statistiques de temps de réponse et de similarité de réponses s’activent, portée classement uniquement. Une fois la banque d’items assez grande (constat 4), le serveur exécute une simple vérification de valeur aberrante de temps de réponse (constat 3) et, là où les comptes partagent assez d’items communs, une vérification de similarité de réponses modelée sur les indices publiés — limitée à l’activité de classement, pas à la pratique ordinaire.
9. Palier 4 — Avancé/pré-compétitif (16 ans et plus, opté dans le jeu classé) : contrôle complet de l’exposition d’items. La limitation d’exposition de type Sympson-Hetter (constat 2) plafonne la fréquence à laquelle même l’item suivant le mieux adapté est montré à des utilisateurs de compétence similaire, protégeant contre le vecteur de partage « tout le monde à ce rang reçoit le même problème suivant » qui compte une fois que de vrais enjeux existent.
10. Palier 4 — les heuristiques de session/partage de compte deviennent actives, pas seulement journalisées. La détection de sessions concurrentes et les signaux de discontinuité de compétence augmentent désormais activement la volatilité/le RD du classement (comme le ferait un nouveau compte suspect), plutôt que d’apparaître seulement dans un tableau de bord.
11. Palier 5 — Palier supérieur compétitif/éligible à une bourse (opt-in, enjeux explicites, consentement du tuteur lorsqu’un mineur est concerné) : la suite statistique complète, toujours zéro caméra. La machinerie psychométrique publiée (détection de collusion de type omega/GBT, le modèle log-normal de temps de réponse complet) mérite son coût ici, puisque la banque est grande et les enjeux élevés. Même à ce plafond, la réponse est plus de statistiques, jamais une webcam, un navigateur verrouillé ou une capture biométrique — l’historique du constat 5 ne donne aucun scénario où le proctoring caméra/biométrique d’un mineur, ou d’un adulte sans mandat institutionnel, est défendable.
12. Côté serveur contre côté client, à chaque palier, sans exception. Côté client, toujours : rendre le problème, collecter la réponse, retour d’interface local. Côté serveur, toujours, dès le palier 0 : la paire d’horodatages, la vérification de correction, le score, et (du palier 3 vers le haut) chaque signal statistique des constats 3-4 et 7. L’autorité de chronométrage/correction ne passe jamais au client à aucun palier — l’échelle est progressive en enjeux, pas en confiance envers le client, qui n’est jamais accordée.
13. Ce que nous ne ferons délibérément jamais à un enfant, à aucun palier. Aucune capture webcam ou microphone. Aucune collecte de données biométriques (visage, voix, dynamique de frappe, suivi du regard). Aucun navigateur verrouillé. Aucun surveillant humain à distance. Aucune pénalité de score ni action de compte visible pour un enfant en dessous du palier 3 — sous le palier 3, les signaux sont de la télémétrie de calibration et, au plus, un élément de tableau de bord parent/tuteur. Aucun cadrage punitif (« tu as été pris en train de tricher ») nulle part — le pire résultat visible à n’importe quel palier est une estimation de maîtrise à confiance plus basse ou une invite amicale, correspondant au design décidé : l’anti-triche reste quasi invisible pour les jeunes enfants et ne se resserre qu’avec la hausse des enjeux.

Questions ouvertes pour le porteur du projet

1. À quel âge/palier, le cas échéant, un tableau de bord parental doit-il afficher les signaux d’anomalie (paliers 1-2) — et doit-il un jour être visible pour l’enfant, même indirectement ?
2. Math Challenge organisera-t-il un événement avec des enjeux réels (bourse, prix en espèces, compétition reconnue par une école) justifiant la suite statistique complète du palier 5, ou « palier compétitif » signifie-t-il seulement de la fierté de classement ?
3. L’adoption de WebAuthn/passkey doit-elle un jour être obligatoire, ou toujours optionnelle, étant donné que c’est le seul mécanisme universel de liaison d’appareil mais qu’il ajoute de la friction pour le compte d’un jeune enfant ?
4. Pour le partage légitime de compte familial (parent et enfant sur un seul identifiant), comment les heuristiques de session du palier 4+ doivent-elles éviter de signaler à tort un changement d’appareil familial normal comme suspect ?
5. Y a-t-il un intérêt à publier une déclaration de confiance/sécurité selon laquelle Math Challenge n’utilisera jamais de proctoring webcam/biométrique, comme élément différenciateur par rapport aux produits de type Proctorio et comme signal de confiance pour les parents ?