1. Introduction

Le besoin de mettre en ligne des QCM ou des V/F commençant à se faire sentir, je prévois de mettre ça en place sur ce site.

Attention, l’esprit de ce petit projet est la simplicité. Il n’y aura pas d’authentification ni de configuration.

2. Le déroulement

1. le prof et les élèves arrivent dans une salle pourvue d’ordis
2. le prof écrit une URL au tableau, ou la fait connaître autrement, et le code du test (**)
3. les élèves tapent l’URL ou cliquent dessus, arrivent devant le formulaire
4. les élèves remplissent les premiers champs (tout ce qui n’est pas réponse, voir plus loin)
5. les élèves cochent leurs réponses,
6. les élèves valident (***),
7. un serveur (pas forcément situé à la même adresse) récupère les données, écrit deux fichiers:
   1. un .html pour visualiser les résultats en direct, sous forme lisible par un humain, voire même un prof,
   2. un .csv téléchargeable à la fin de la séance, à ouvrir dans un tableur pour traiter les données (****)

(**) Le code du test devra permettre d’identifier l’épreuve et éviter le spam (qui pourra être massif: vous l’avez peut-être remarqué, je n’ai pas parlé d’identifiants, trop complexe). (*****)

(***) Pas de prévisualisation, pas de confirmation, trop complexe. Une seule proposition par élève (nom/prénom), classe, tour, prof, établissement et ville est acceptée, les suivantes seront ignorée (insensible à la casse).

(****) Il serait possible, et même intéressant, de traiter les données de façon fine et automatique sur le serveur, mais ce n’est pas pour tout de suite, c’est pas mal de travail.

(*****) Je pense parfois à un code par élève si les élèves sont très joueurs. C’est la partie délicate de mon projet. Y a un peu de cryptographie à mettre en place.

3. Le formulaire

3.1. Champs hors réponses

Attention, l'énoncé doit être fourni à part (fiche papier, page sur profgra.org ou autre).

Tous ces champs sont requis. Leur contenu doit aussi obéir à certaines règles.

3.2. Réponses

En ajoutant ?nbqsts=3534 à l’URL, on met en place quatre questions, qui auront respectivement 3, 5, 3 et 4 réponses possibles.

3.3. Contrôler les validations

Pour empêcher tout abus, il faut mettre un place quelques contrôles.

3.3.1. Cahier des charges

• Empêcher un élève de valider plus d’une fois.
• Vérifier l’identité de l’élève qui a rentré un nom et un prénom, et ce, même si on veut un test anonyme.

3.3.2. Le code

Permet d’éviter tout abus du système.

Aucune information sur sa génération ne doit filtrer en dehors des profs qui utiliseront ce système donc rien de plus ne sera dit ici, à part que pour connaître ce procédé, il faut se faire inviter par quelqu’un qui a été « initié ». Tout se passe par email.

3.3.3. Relire les résultats déjà stockés

Pb avec l’heure.

Vérif du tour :

• nombre, si différent de 1, doit être un de plus qu’avant (que signifie « avant » ?)

4. Résultats

4.1. Confidentialité

Les résultats sont publics. Il faut que les profs et les élèves en soient conscients.

Il faut étudier une manière de ne laisser que ses initiales, ou des initiales imaginaires si on veut l’anonymat et si le prof n’a pas besoin d’identifier les tentatives.

4.2. Infos stockées

Les fichiers seront nommés codepostal.etablissement.professeur.date.csv ou .html.

On retrouvera les infos suivantes :

• date, heure
• prénom, nom
• classe
• tour
• professeur
• établissement
• code postal
• score (calculé si bonnes réponses fournies par le prof, ou vide sinon)
• réponses de l’élève

La date et l’heure du passage du test seront stockées.

Il est possible de passer au formulaire les bonnes réponses (les bonnes réponses restant invisibles sur la page du formulaire, et cryptées dans le code html de la page). C’est pratique pour calculer le score et l’écrire sur la compilation des résultats.

La génération du texte représentant les bonnes réponses doit rester secrète comme le code de validation.

5. Réalisation

Utilisation de http://codeigniter.com/, un cadriciel (framework) PHP.