Voilà telle est la question que mon « petit » Aurélien m’a posé. J’écris « petit » car il est petit de taille, mais c’est un chouette collègue et super intéressant en plus. Avec lui, quand on part dans des discussions sur notre métier, on ouvre des « portes » de réflexions.

On prépare donc une intervention à l’ESPE, on digresse pas mal, quitte à zapper ce pourquoi on se voyait, et voilà qu’Aurélien au détour de sa présentation de ce qu’il fait en algo me dit : »Je ne sais pas comment les évaluer dessus, tu fais quoi, toi? »

« Rah j’t’aime bien, Auré avec tes foutues questions »

Et puis est venu notre discussion qui a nourrit ma réflexion (et la sienne) et ça m’a trotté pas mal dans la tête.

Pourquoi évaluer l’algorithmie, c’est difficile?

Pour répondre tout d’abord à cette question, il faut s’interroger sur comment on enseigne l’algorithmie et surtout aussi comment les programmeurs font pour coder. Et oui, parfois en se posant les bonnes questions, on en répond à d’autres.

Tout d’abord, il existe dans l’enseignement deux catégories d’activités autour de l’algorithmie :

1. La « branchée« , on donne un programme à faire sur l’ordinateur soit à partir de rien, soit à partir d’un début de programme.
2. La « débranchée« , on donne un programme à analyser et/ou à écrire sur papier en imaginant ce qu’il fait, généralement le programme est plus court. C’est d’ailleurs comme cela qu’on l’on procédera pour le nouveau brevet.

La réflexion qu’on doit se poser, c’est évalue-t-on la même chose dans ces deux type d’activité ?

La réponse est non, et clairement non. Dans l’activité « débranchée », on ne peut qu’évaluer la capacité des élèves à ‘lire’ un programme et le ‘modifier’ (les guillemets sont importants).

Dans l’activité « branchée », on peut évaluer la capacité des élèves à lire un programme, le modifier et en créer un.

Cependant la lecture et la modification d’un programme dans l’activité « branchée » et « débranchée » ne mobilise pas les mêmes capacités.

Quelle différence alors ?

En effet, pour lire un programme sur un ordinateur, on a plusieurs choix pour y arriver. On peut découper le programme pour en tester une partie, on peut également le tester en modifiant quelques lignes pour voir l’importance des certaines lignes de codes sur d’autres et leurs utilités, leurs fonctionnements.

On peut avoir en fait un comportement scientifique pratique : on peut expérimenter pour deviner la fonction de certaines lignes de codes, comme on pourrait faire des expériences pour théoriser par exemple le fonctionnement d’un phénomène physique.

Les codeurs sont des scientifiques quasiment des physiciens.

Cela présuppose le droit à l’erreur, à des prises d’initiatives, à un temps à posséder pour l’analyse et surtout, l’accès à un ordinateur.

La lecture et la modification d’un programme sur papier, ne permet nullement le test, la découpe du programme : l’analyse est donc réduite à la théorie, le non-droit à l’erreur pour avancer seul, c’est aussi pour cela que le programme est généralement plus simple.

Exit : les prises d’initiatives, pourtant en tant qu’enseignant, c’est ce qu’on devrait attendre d’un élève, non?

L’activité « débranchée » n’est pas une fin en soi, je ne dis pas qu’elle est inutile, mais il faut avoir conscience qu’elle peut-être moins riche et elle pourrait  se limiter quasiment à la restitution de connaissances brutes de l’informatique.

Je suis nettement pour une activité « branchée », car pour moi, elle correspond parfaitement à ce qu’on fait quand on code. (et oui, je code à mes heures perdues, et j’ai passé quelques années de fac dessus également car j’ai un cursus mathématique & informatique).

Le programmeur ne réinvente certainement pas la roue à chaque instant, il s’inspire, étudie d’autres programmes, en prend d’autres parties , les intègre à son programme mais surtout, il teste pour comprendre et créer.

Ici, j’ai mélangé code et algorithme, cependant Scratch c’est un logiciel qui rend ténue la frontière entre le code (ce qui est exécutable) et l’algorithme (ce qui se lit humainement).

Quid de l’évaluation pour moi ?

Avec cette conclusion, j’ai fait le choix de ne pas les « évaluer directement». Ceci n’empêche pas de faire des activités, de proposer des projets, le dernier en date sera un jeu de voiture pour mes 3^e.

Seront-ils évalués sur la production qu’ils feront ? Non.  En fait, on fera un oral pour qu’ils présentent leur projet, qu’ils le défendent, qu’ils évoquent leurs difficultés, leurs choix qu’ils auront faits en conséquence. En fait, on attendra qu’ils prennent du recul sur leur projet.

Ce sont de vraies compétences qu’ils doivent développer et qu’ils mobiliseront plus tard, la connaissance de la programmation, elle, s’étiolera et ce n’est pas grave, car il faut être honnête, on n’en fera pas tous des programmeurs, mais plutôt des personnes sachant prendre du recul sur ce qu’elles font, tout simplement.

Poursuivons donc la réflexion sur l’évaluation sur l’algorithmie car là, je n’ai fait que le choix des activités « branchées« .

Une autre question toute simple :

• Doit-on tout évaluer? Pouvons-nous tout évaluer? Tout est évaluable?
• Le faisons-nous pour nous, ou pour eux (les élèves) ?
  • Si c’est pour eux, une évaluation écrite sur l’algorithmie leur sert-elle vraiment ?
  • Un échange oral pendant la conception de leur projet, n’est-elle alors pas suffisante pour corriger les réflexes de codeurs en herbe?
  • Doit-on  forcément en garder trace?

Voilà l’état de mes choix pour l’instant, rien ne me dit
que je ne changerai pas d’avis, ça c’est le côté blog que j’aime bien,
je pose des réflexions à des instants « t » qui évoluent
comme notre vision du métier et notre métier  tout simplement évolue.