La réponse honnête à la question de l'évaluation des projets de robotique tient en une phrase : notez le raisonnement qui a produit le robot, pas les trente secondes pendant lesquelles il traverse une table. Une démonstration réussie vous dit qu'une équipe a fini par y arriver. Elle ne vous dit pas qui a compris le code, qui a copié sur un camarade, ni si un câble bien rangé par chance a sauvé une conception en réalité défaillante. Une bonne évaluation en cours de robotique s'appuie sur les traces du processus recueillies au fil du travail, et elle traite le débogage comme une compétence qui mérite des points à part entière.

Cela compte surtout en juin, quand les bulletins du deuxième trimestre arrivent et que vous essayez de transformer un trimestre de travail bruyant et manuel en une note défendable. Si votre seule pièce au dossier est un essai final, vous avez très peu de matière. Si vous disposez de carnets, de journaux et de courtes restitutions orales, la note s'écrit presque toute seule.

Pourquoi « ça a bougé » est une note faible

Une démonstration finale n'est qu'un échantillon unique d'un système instable. Les batteries faiblissent, les sols n'ont pas l'adhérence du banc d'essai, et un suiveur de ligne réglé à la lumière du matin se comporte autrement sous le soleil de l'après-midi entrant par la fenêtre. Deux équipes peuvent aboutir au même résultat visible par des chemins très différents : l'une a raisonné, l'autre a procédé par la force brute en changeant des valeurs jusqu'à ce que quelque chose fonctionne. N'évaluer que le résultat récompense les deux à égalité, ce qui enseigne discrètement à vos meilleurs élèves que comprendre est facultatif.

Cela pénalise aussi l'ambition. Une équipe qui s'attaque à un mécanisme plus difficile et parcourt 80 % du chemin peut faire moins bonne figure le jour de la démonstration qu'une équipe qui a joué la sécurité. Si votre grille ne voit que la ligne d'arrivée, les élèves apprennent à choisir des problèmes faciles. Évaluer le processus vous permet de récompenser honnêtement la tentative la plus difficile.

Évaluer le processus, pas seulement le produit

Déplacez l'essentiel du poids vers les traces que les élèves produisent en travaillant. Trois documents font presque tout le travail, et aucun ne demande de logiciel particulier.

• Carnets de conception. Une entrée courte et datée à chaque séance : ce que nous avons essayé, ce que nous attendions, ce qui s'est réellement passé, ce que nous changerons ensuite. Une demi-page suffit largement. La valeur réside dans l'écart entre l'attendu et le réel, car c'est là que se loge l'apprentissage.
• Journaux d'itération. Une liste continue des versions, avec une ligne de justification pour chaque changement. « v3 : moteur gauche ralenti, le robot tirait à droite. » C'est la fenêtre la plus claire sur le fait qu'un élève raisonne ou devine. Sur notre canvas de programmation par blocs, l'historique des sauvegardes montre déjà cette progression : le journal peut donc se réduire à annoter quelles sauvegardes ont compté, et pourquoi.
• Restitutions entre pairs. Avant qu'un projet soit considéré comme terminé, un membre de l'équipe explique à un autre groupe, en langage courant, une partie choisie du code ou de la construction. Vous écoutez deux minutes. Un élève qui a écrit la logique sait la raconter ; un élève qui l'a copiée cale au premier « pourquoi ça et pas autre chose ».

Le but de ces trois outils est de rendre visible le raisonnement invisible, afin d'avoir autre chose à noter que le dernier essai.

Une grille qui récompense le débogage

Le débogage est le véritable travail de la robotique : il doit donc peser réellement, au lieu d'être traité comme un échec à dissimuler. Une grille qui le nomme change le comportement des élèves : ils se mettent à noter ce qui a cassé au lieu de revenir discrètement à une sauvegarde en faisant comme si de rien n'était.

Une grille simple à quatre volets fonctionne bien pour un projet standard sur la carte sheenbot ou tout kit comparable. Répartissez les points pour qu'aucun volet ne puisse à lui seul porter un projet faible.

• Compréhension (25 %) — l'élève sait-il expliquer ce que fait chaque partie de sa solution, et pourquoi.
• Processus et itération (30 %) — qualité du carnet et du journal ; preuve qu'un changement a été testé contre une prédiction plutôt que bricolé au hasard.
• Débogage (25 %) — comment une panne a été isolée puis corrigée ; un bug clairement documenté, trouvé et résolu, doit obtenir une meilleure note qu'un projet sans le moindre problème consigné.
• Résultat (20 %) — la réalisation finale répond-elle à la consigne. Cela compte toujours. Simplement, cela ne domine pas.

Notez que le résultat est le volet le plus léger. C'est délibéré. Quand les élèves voient qu'un bug bien traqué rapporte plus qu'un projet suspectement propre et sans historique, ils cessent de cacher leurs difficultés et se mettent à montrer leur démarche.

Travail de groupe et équité

La plus vieille plainte de toute discipline pratique, c'est le passager clandestin : un élève tient l'ordinateur pendant que les autres regardent. Les traces du processus sont votre meilleure défense, parce qu'elles sont individuelles par construction. Chaque membre tient son propre carnet, bref, et la restitution est faite par un élève désigné sur une partie que vous choisissez, pas sur celle qu'il a répétée. Faites tourner un rôle visible à chaque séance, pour que le pilote, le constructeur et le testeur changent d'une semaine à l'autre, et consignez cette rotation.

Gardez une petite part de la note individuelle et le reste collectif. Une répartition courante tourne autour de 70 % pour l'équipe et 30 % pour l'individu, la part individuelle provenant presque entièrement du carnet propre à l'élève et de sa restitution. C'est assez pour rendre visible celui qui se laisse porter, sans transformer un projet collaboratif en quatre projets solitaires. Les formats de compétition penchent déjà dans ce sens : les équipes qui se préparent au FTC sont jugées sur un portfolio d'ingénierie documentant toute la saison, et pas seulement sur le robot le jour du match — exactement l'habitude que vous installez en classe.

Rendre la démarche tenable

Rien de tout cela ne survit si votre charge de correction double. Gardez des instruments légers. Les carnets font une demi-page et se corrigent d'une coche face à trois questions, pas d'un paragraphe de commentaires à chaque fois. Les restitutions ont lieu en direct pendant la séance : elles vous coûtent du temps d'écoute, pas des soirées. Les journaux d'itération se survolent, ils ne se lisent pas ligne à ligne. Intégrez les points d'étape à la progression dès le départ plutôt que de greffer l'évaluation à la fin, comme le fait notre programme de l'academy, qui répartit de courtes pauses réflexives dans un projet au lieu d'un grand verdict à l'arrivée. Une évaluation qui vit à l'intérieur du travail est bien plus tenable qu'un temps de correction séparé.

À retenir

« Le robot a bougé » est un point de départ, pas une note. Déplacez le poids de votre évaluation vers les traces du processus : des carnets de conception datés, des journaux d'itération honnêtes et de courtes restitutions entre pairs. Construisez une grille qui paie les élèves pour leur compréhension et pour leur débogage, et gardez le résultat final comme le volet le plus léger plutôt que comme toute l'histoire. Faites cela et vos bulletins seront plus faciles à écrire, vos passagers discrets plus difficiles à dissimuler, et vos élèves apprendront la leçon qui, elle, se transfère vraiment hors de la classe : dans l'ingénierie réelle, le produit, c'est le raisonnement.