Vous recevez un rapport propre, bien structuré, avec les bonnes références. Il y a trois ans, vous y lisiez une compétence. Aujourd’hui, vous y lisez surtout un produit. Peut-être que l’étudiant a travaillé. Peut-être qu’une IA a écrit l’essentiel. Le fichier, lui, ne le dit plus.

Hervé Barras (HEP Valais) et Natalie Sarrasin (HES-SO Valais/Wallis) ont présenté à RUNED 2026, à Fribourg, une communication au titre limpide : Évaluer dans le monde de l’IA, heuristique et pistes de réflexion. Leur point de départ n’est pas de rendre les évaluations imperméables à l’IA. C’est de concevoir l’évaluation en admettant que l’IA générative fait désormais partie du contexte.

La thèse tient en une phrase. Une évaluation centrée sur un produit final facilement générable est fragilisée. Une évaluation qui rend visibles les compétences, les étapes, les choix et les productions intermédiaires redevient robuste, et surtout utile à l’apprentissage.

Ni chasse à la triche, ni solution miracle

Les auteurs écartent les deux extrêmes. Traiter l’IA uniquement comme de la fraude. Ou la vendre comme un atout automatique. Là où son usage est déjà répandu, l’interdiction générale n’est plus crédible. Il faut former à un usage critique, et le dire clairement.

Ils distinguent aussi l’erreur et la faute. L’erreur est normale, elle informe l’apprentissage. La faute suppose une transgression intentionnelle. Une culture du soupçon mélange les deux. L’étudiant qui se trompe et l’étudiant qui contourne se retrouvent dans le même filet. Une culture juste les sépare. Elle rend les règles d’usage de l’IA lisibles avant le travail, pas après la détection.

Concrètement, cela veut dire sortir de la question « a-t-il triché » pour poser une autre question : qu’est-ce que je veux voir, et à quel moment. Si la seule preuve est un fichier déposé à 23 h 59, vous évaluez un objet. Vous n’évaluez presque plus une personne en train d’apprendre.

L’intégrité académique, dans ce cadre, ne vient pas d’un détecteur. Elle vient du design : plusieurs points d’observation, des versions intermédiaires, de la transparence sur ce qui est attendu.

Ne plus confondre production et compétence

Un texte réussi ne démontre plus nécessairement une maîtrise. Un code qui tourne non plus. Une synthèse bien écrite encore moins. Ces objets restent des preuves. Ils ne suffisent plus, parce qu’ils sont devenus faciles à produire sans avoir conceptualisé, argumenté, ni décidé.

Ce qu’il faut observer, écrivent Barras et Sarrasin, ce sont des capacités : analyser, conceptualiser, résoudre, argumenter, collaborer, justifier une décision. Le livrable montre un résultat. La compétence se voit dans les choix, les abandons, les reformulations, la façon de répondre à un retour.

Prenez un rapport d’analyse stratégique. Le document final peut être fluide et faux : un modèle mal compris, une force oubliée, des exemples qui contredisent le propos. Si vous ne voyez que ce document, vous notez une surface. Si vous avez vu le plan, une première version, et une justification des changements, vous voyez si l’étudiant s’est approprié l’outil ou s’il a livré un texte.

Même chose pour un projet. Le site, le dossier, la soutenance isolée racontent peu si vous n’avez aucune trace de ce qui a été tranché en route. Le produit continue d’exister. Il n’est plus le centre.

Quatre questions avant de parler d’outil

Barras et Sarrasin s’appuient sur des cadres connus : design pédagogique, alignement, backward design. Ils en tirent une heuristique courte. Quatre questions, dans l’ordre. Pas un logiciel. Une façon de concevoir.

D’abord : pourquoi évaluer, et pour quoi. Soutenir l’apprentissage, ou certifier. Les deux ne demandent pas le même dispositif. En formatif, on veut de la fréquence, le droit à l’erreur, du feedback, la comparaison des versions. En certificatif, on veut des règles d’usage explicites, des preuves croisées, parfois une défense orale, et une validation humaine. Imposer le même niveau de contrôle partout fatigue tout le monde et ne protège rien.

Ensuite : quels objectifs, quelles compétences voulez-vous vraiment observer. Pas « rendre un rapport de quinze pages ». Plutôt « formuler une stratégie à partir d’un diagnostic », « justifier un choix technique sous contrainte », « faire un retour utile à un pair ». Si vous ne savez pas nommer la compétence, le livrable prendra toute la place. Et le livrable, l’IA le fait très bien.

Troisième question : quelles tâches, quelles traces rendront le processus visible. Pas tous les clics. Quelques preuves à forte valeur. Un plan initial. Un jalon. Une version intermédiaire. La raison d’un changement. Un feedback, et la réponse de l’étudiant à ce feedback. Une déclaration simple de l’usage de l’IA : où, pourquoi, ce qui a été gardé, ce qui a été rejeté, comment c’est vérifié. Une courte défense, à l’oral ou à l’écrit, quand l’enjeu est certificatif.

Dernière question : le dispositif est-il cohérent. Objectifs, activités et évaluation mesurent-ils la même chose. Un cours qui travaille l’argumentation et note uniquement la mise en forme ouvre une porte. Un projet qui dit « esprit critique » et ne regarde que le fichier final aussi. Un dispositif ambigu crée des possibilités de contournement. Un dispositif cohérent dit à l’étudiant ce qu’il doit apprendre, pourquoi telle activité existe, et ce qui sera regardé.

La première protection n’est pas technique. C’est cette cohérence.

Évaluer avant, pendant, après

L’évaluation n’est plus un rendez-vous de fin de semestre. Elle se pense en amont, en cours de route, ensuite.

En amont, vous décidez ce qui sera observé, et vous le dites. L’étudiant sait si l’IA est interdite, autorisée pour une tâche, attendue, ou libre mais documentée. Il sait aussi que le rendu final n’est pas la seule preuve. Cette clarté évite le soupçon après coup. Elle évite surtout le malentendu : beaucoup d’usages « interdits » sont d’abord des usages jamais explicités.

Pendant, vous collectez deux ou trois traces, pas une archive. Le but n’est pas de surveiller. C’est de donner prise au feedback tant que l’étudiant peut encore s’en servir. Un retour sur une version a une valeur que le commentaire de fin de semestre n’a plus. Les notes sont là, les vacances aussi.

Ensuite, vous croisez. Le produit, le processus, la capacité à défendre les choix. Pairs, enseignant, parfois un oral. Une seule source, surtout un fichier, ne tient plus.

Jacques Tardif le rappelle souvent : une compétence se construit dans la durée, sur plusieurs situations. Une photo finale ne dit presque rien. On l’a déjà détaillé dans les 5 erreurs fatales en évaluation des compétences.

Un contrat d’usage, pas une police de l’IA

La tentation, face aux copies trop lisses, c’est le score de détection. Barras et Sarrasin poussent ailleurs. Un contrat lisible, activité par activité.

IA interdite, parce que vous voulez voir un geste à main nue : un oral, une analyse en temps limité, une situation vécue. IA autorisée pour une tâche précise : reformuler, traduire, proposer une structure, jamais rédiger l’argument. IA attendue, parce que savoir s’en servir fait partie de la compétence. IA libre, mais documentée : l’étudiant dit ce qu’il a fait de l’outil.

Ce contrat n’a de sens que s’il est tenu des deux côtés. L’enseignant ne change pas les règles à la correction. L’étudiant n’a pas à deviner ce qui « se fait ». La déclaration d’usage n’est pas un aveu. C’est une trace réflexive, au même titre qu’une justification de choix.

On sort alors de la police. On entre dans une exigence plus dure, et plus juste : montrer comment on a travaillé.

Ce que ça change dans un cours, dès la semaine prochaine

Vous n’avez pas besoin d’un nouveau logiciel pour commencer. Prenez une évaluation que vous donnez déjà. Demandez-vous ce qu’elle mesure vraiment. Si un livrable isolé peut être produit en vingt minutes par une IA, ce livrable ne peut plus être la seule preuve.

Ajoutez deux ou trois traces utiles. Un plan. Une version. Une courte défense : pourquoi ce choix, qu’est-ce qui a été rejeté. Écrivez la politique d’usage en cinq lignes, en haut de la consigne. Séparez ce qui est formatif (on a le droit de se tromper, on recommence) et ce qui est certificatif (on démontre, on assume, on défend).

C’est aussi le territoire de ChallengeMe. Pas détecter l’IA. Rendre visible le cheminement qui permet de démontrer une compétence. Des jalons plutôt qu’un dépôt unique. Du feedback en cours de route. Des pairs et de la co-évaluation pour croiser les regards. Un oral pour vérifier l’appropriation. Un journal ou un portfolio pour garder une trajectoire, pas une photographie. L’IA peut aider à relire et à commenter. Elle ne décide pas. L’enseignant garde la main.

Le papier de Barras et Sarrasin ne propose pas une nouvelle modalité. Il déplace le centre de gravité. Évaluer moins un objet final isolé. Évaluer davantage une compétence montrée au fil d’un processus cohérent.

Pour voir ce que ça donne dans un cours, avec des pairs, un portfolio et un assistant qui n’écrit pas à la place de l’étudiant : le retour d’expérience d’Antoine Chollet, en BUT Informatique.

Le texte intégral de Barras et Sarrasin est sur ResearchGate.

Envie d’essayer ChallengeMe ?
Demander une démo