Discussion :

[Patrick Ruiz]

Comment les étudiants en programmation contournent les systèmes automatisés de correction des soumissions
Pour tricher aux évaluations des MOOCs

Les universités et autres instituts qui œuvrent dans le domaine de l’éducation s’appuient de plus en plus sur les MOOCs (Massive Open Online Courses – cours en ligne ouverts et massifs) pour transmettre des connaissances et même évaluer les apprenants. La démarche s’applique désormais à une panoplie de domaines comme les langues, l’ingénierie, l’architecture, etc. Une étude de la Lubeck University of Applied Sciences en Allemagne est, courant janvier, parue à ce sujet sur la plateforme ResearchGate. Elle attire l’attention sur les tares de l’utilisation des MOOCs pour le cas des évaluations des étudiants lancés dans des cursus de programmation informatique.

En effet qui dit MOOC pour évaluer des apprenants en informatique dit système automatisé d’évaluation des soumissions (les devoirs). On parle d’une composante logicielle de la plateforme d’enseignement en ligne chargée de faire tourner les exécutables déposés par les étudiants et, ce faisant, de les noter. Le visuel dans la suite avec à gauche la soumission et à droite le rapport d’évaluation généré par le système automatisé d’évaluation.

Au travers de sa publication la Lubeck University of Applied Sciences attire l’attention sur le fait que « la composante logicielle de la plateforme de MOOC chargée d’évaluer les soumissions peut être trompée de diverses façons. » L’étude a particulièrement porté sur Virtual Programming Lab – un système automatisé d’évaluation sur lequel des plateformes de MOOCs comme Moodle s’appuient. Le fait est que l’outil est vulnérable aux attaques par injection de code, ce contre quoi la Lubeck University of Applied Sciences prévient : « nous devons être conscients de ce que même des étudiants de première année sont assez futés pour soumettre intentionnellement les systèmes automatisés d’évaluation des soumissions à des attaques par injection de code à des fins de tricherie. »

En l’état, les vulnérabilités des actuels systèmes automatisés d’évaluation sont assez criardes comme le relève l’étude. Tenez par exemple, avec la portion de code Java qui suit, un étudiant peut réussir à engranger le maximum de points à chacune de ses soumissions.

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
System.out.println("Grade :=>> 100");
System.exit(0);

A titre d’illustration, l’étude porte sur l’évaluation du problème de dénombrement du nombre d’occurrences d’un caractère spécifique au sein d’une chaîne. L’étude fournie une solution de référence au problème :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
int countChar(char c, String s) {
s = s.toLowerCase(c);
c = Character.toLowerCase(c);
int i = 0;
for (char x : s.toCharArray()) {
if (x == c) i++;
}
return i;
}

Mais les vulnérabilités du système automatisé d’évaluation des soumissions sont telles que l’étudiant peut engranger le maximum de points avec une solution partielle au problème posé comme le bout de code qui suit l’illustre :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
int countChar(char c, String s) {
if (c == 'a' && s.equals("Abc"))
return 1;
if (c == 'A' && s.equals("abc"))
return 1;
if (c == 'x' && s.equals("ABC"))
return 0;
if (c == '!' && s.equals("!!!"))
return 3;
// [...]
if (c == 'x' && s.equals("X"))
return 1;
return 42;
}

Une autre faille (comme relevé par l’étude) est que le système automatisé d’évaluation des soumissions peut, dans certaines conditions, renvoyer des messages d’erreur dont l’étudiant peut se servir pour cerner la logique de l’évaluation et la contourner. Ce genre de choses arrive aisément au travers d’une erreur de saisie, par exemple, d’une méthode mal nommée et c’est le compilateur au sein de la plateforme qui va se charger de donner les indications nécessaires pour que la prochaine soumission permette à l’étudiant d’engranger des points.

L’étude ne se veut pas être un recueil exhaustif des vulnérabilités que VPL exhibe, mais elle en a relevé deux autres. Par exemple, l’examinateur peut requérir une solution récursive au problème de dénombrement des occurrences d’un caractère au sein d’une chaîne. Dans ce cas, une solution de référence serait celle consignée dans le bout de code qui suit :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
int countChar(char c, String s) {
s = s.toLowerCase(c);
c = Character.toLowerCase(c);
if (s.isEmpty()) return 0;
char head = s.charAt(0);
String rest = s.substring(1);
int n = head == c ? 1:0;
return n + countChar(c, rest);
}

Au problème posé, un étudiant pourrait proposer une solution dans un style de programmation impératif, mais qui passe néanmoins au travers des filets du système :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
int countChar(char c, String s) {
if (s.isEmpty()) return 0;
return countChar(c, s, 0);
}
int countChar(char c, String s, int i) {
for (char x : s.toCharArray()) {
if (x == c) i++;
}
return i;
}

Enfin, si l’étudiant a une connaissance préalable du système automatisé d’évaluation des soumissions qui anime la plateforme, il peut insérer des chaînes de caractères précises au sein de son code de sorte à provoquer une action déterminée. Par exemple, dans le cas de VPL, la détection de la chaîne Grade :=>> permet d’attribuer des points.

VPL fait l’hypothèse selon laquelle les étudiants ne sont pas au fait de cet état de choses. De plus, on suppose (d'une manière ou d'une autre) que les soumissions des étudiants n'écrivent pas à la console (seule la logique d'évaluation devrait le faire), mais il est possible pour les soumissions de placer une sortie arbitraire sur la console et cela n'est pas interdit par le serveur Jails. Donc, ces hypothèses constituent un argument de défense très faible. Une recherche rapide sur Internet avec les termes "grade VPL" t permet de mettre la main sur de la documentation de VPL et avec cette dernière un tiers peut savoir comment le système fonctionne en toile de fond.

La Lubeck University of Applied Sciences commente que « l’immaturité des actuelles solutions automatisées d’évaluation des soumissions pourrait avoir des implications pour des cours qui s’appuient sur les plateformes de MOOCs. » Voilà qui peut clairement poser le problème de la qualité des produits issus des formations informatique via les MOOCs.

L’étude ne se limite pas à souligner les vulnérabilités de l’outil VPL. Elle dresse également un éventail de solutions pour les cas relevés. En sus, un template de test de programmes Java pour VPL est disponible sur le GitHub lié à l’étude.

Source : étude

Et vous ?

Qu’en pensez-vous ?

Les moocs sont-ils un moyen d'enseignement et d’évaluation trop superficiel par rapport au cours et aux TP traditionnels en informatique ?

Avez-vous déjà triché ou été confronté à de la triche d'une manière générale ?

Avez-vous des anecdotes à partager ?

Voir aussi :

Que pensez-vous des formations intensives en programmation ? Sont-elles plus efficaces que les formations classiques en informatique ?

La démocratisation du codage et des formations IT, quel est le but ? Remédier à une pénurie sur le marché de l'emploi ou baisser les salaires ?

A-t-on besoin d'apprendre la programmation pendant 10 ans avant d'être un développeur accompli ? Partagez votre expérience

Comment devenir un meilleur développeur ? La formation et l'expérience sont-elles suffisantes ? Vous êtes invités à partager votre avis

Y a-t-il une corrélation entre diplôme et succès en tant que développeur de logiciels ? Un acteur de la sphère donne son avis

[Runhide]

Une plateforme pour les étudiants, fait par des étudiants 😂

[Carhiboux]

En même temps, si le mec arrive à comprendre comment flouter le système, je dirais qu'il est sans doute suffisamment compétent.

Après, je distingue ceux qui auront compris comment flouter le système et en tireront parti et ceux qui le feront sans le savoir.

[ronronlechat]

Pour enseigner la chasse à un chat il faut être un chat.
Pour enseigner la discipline à un humain il faut être un humain.
Comment une machine pourrait y parvenir ?

[kolodz]

Pas nouveau. J'avais fait un billet il y a quelques années sur Microsoft Virtual Académie [MVA][Skilly]Les certifications en lignes : une impasse ?

[zerefsoldier]

Ca a rien de bien méchant de contourner le système ^^ L'article n'apprend vraiment rien sur ce coup la --'

[ChrQNC]

Je m'occupe de notation automatisée depuis plus de 15 ans.
La plateforme utilisée par Lubeck n'a visiblement pas été pensée pour être sûre.
Les exercices qui y sont proposés sont également problématiques puisqu'ils indiquent la réponse qu'ils attendent.
Tester le style de programmation (impératif, récursif, etc.) est plus complexe et passe souvent par une instrumentation de l'évaluateur pour mesurer par exemple, les nombres d'appels).
Enfin généraliser ces mauvais exemples à toutes les solutions de notation automatisée est outrancier.

Publicité personnelle: vous pouvez essayer une plateforme plus sûre: CodeGradX

[gangsoleil]

En même temps, si le mec arrive à comprendre comment flouter le système, je dirais qu'il est sans doute suffisamment compétent.

Justement non, c'est bien ce que met en avant l'exemple sur le lowercase : un programme qui teste, de manière exhaustive, toutes les combinaisons dans un if sera vu comme bon -- et c'est vrai qu'il est syntaxiquement correct. Mais est-ce pour autant un bon programme ? Bien sûr que non, et c'est surtout un programme qui ne demande aucune connaissance de développement.

C'est pour moi tout le soucis de valider un code de manière automatique : sur les langages que je connais, je peux reconnaître un bon code d'un mauvais code assez facilement, mais j'aurai beaucoup de mal à définir des critères objectifs pour l'estimer de manière automatique.