Les assistants IA de programmation sont dans votre salle de classe, que vous les autorisiez ou non. La vraie question n'est donc pas de savoir comment les tenir à l'écart, mais comment préserver l'honnêteté de l'apprentissage alors qu'ils sont là. La réponse tient en quelques petits garde-fous qui laissent le raisonnement à l'élève, car ce raisonnement est précisément ce qu'une IA se fait un plaisir de sauter. Trois habitudes font l'essentiel du travail : donner des indices et non des solutions, prédire avant d'exécuter, et expliquer avant d'intégrer.

Déterminez ce que vous protégez réellement

Le but d'un cours de programmation n'est pas d'obtenir du code qui fonctionne. C'est le raisonnement qui produit ce code : lire un énoncé, élaborer un plan, prédire ce que va faire un bout de code et combler l'écart entre ce que l'on attendait et ce qui s'est réellement produit. Un assistant IA peut livrer une fonction terminée en quelques secondes. Si un élève la colle sans la lire, le code s'exécute, mais la réflexion n'a jamais eu lieu.

Cela reformule tout le débat. Vous ne surveillez pas l'usage de l'IA. Vous protégez le travail intellectuel. Un garde-fou est bon s'il laisse ce travail à l'élève, et inutile s'il ne cherche qu'à tenir l'outil hors de la salle.

Trois garde-fous qui laissent la réflexion à l'élève

Des indices, pas des solutions

Posez comme règle de la maison que l'IA a le droit de donner l'étape suivante, une question ou un coup de pouce, mais jamais une réponse finie. En pratique, cela tient à une consigne et à une habitude de formulation. Apprenez aux élèves à demander que dois-je vérifier ensuite plutôt que écris-moi ça. Avec les plus jeunes, l'enseignant montre d'abord la bonne formulation au tableau, pour que la classe entende la différence entre demander un indice et demander la solution.

Prédire puis exécuter

Avant d'exécuter le moindre code, le sien ou celui de l'IA, l'élève dit ou écrit ce qu'il s'attend à voir se produire. Puis il l'exécute. L'écart entre la prédiction et le résultat, c'est la leçon. Cette seule habitude révèle discrètement le copier-coller : un élève incapable de prédire ce que fait un bloc ou une ligne ne l'a pas encore compris, et vous le savez tous les deux avant que cela ne se retrouve enfoui dans un programme qui marche.

Expliquer avant d'intégrer

Rien n'entre dans le projet tant que l'élève ne peut pas l'expliquer en langage courant, intention par intention. S'il ne peut pas dire ce que fait une partie et pourquoi elle est là, elle n'est pas intégrée. C'est le principe de la revue de code des équipes professionnelles, ramené à l'échelle d'une classe. La production de l'IA cesse d'être quelque chose que l'on accepte pour devenir quelque chose que l'on interroge.

Déplacez l'évaluation vers le processus, pas seulement vers le produit

Si vos notes ne récompensent que le programme final, l'IA rend ce programme bon marché et votre évaluation ne mesure plus rien. Reportez le poids sur ce qu'un outil ne peut pas produire à la place de l'élève. Une explication orale de son propre code. Un court journal de prédiction-exécution. Une note sur ce qui l'a bloqué et sur la façon dont il s'en est sorti. Mieux encore, la modification en direct : demandez à l'élève de modifier devant vous un programme qui fonctionne, par exemple pour faire tourner le robot à gauche là où il tourne à droite. Un élève qui a compris son code y arrive en une minute. Un élève qui l'a seulement collé en est incapable.

Cela rejoint aussi la manière dont l'évaluation alignée sur le CAPS valorise déjà le processus et les traces de raisonnement : vous n'inventez pas une nouvelle grille, vous la pondérez simplement vers ce que l'IA ne peut pas simuler.

Enseignez le pilotage de l'IA comme une compétence, pas seulement comme une tentation

Bien piloter un outil mérite en soi d'être enseigné. Découper un problème, décrire précisément le comportement attendu, lire la réponse d'un œil critique et rejeter une réponse fausse : ce sont exactement les compétences de décomposition et de spécification qu'un cours de programmation existe pour construire. Ne vous contentez donc pas d'interdire. Réservez du temps pour enseigner la bonne version : comment rédiger une demande claire, comment tester ce qui revient, et comment repérer une réponse assurée qui, en réalité, ne fonctionne pas. Les élèves qui savent faire cela s'exercent à un vrai jugement d'ingénieur.

Là où le matériel facilite les choses

La robotique physique vous offre un garde-fou gratuit, car le robot fait office de vérité de terrain. On ne convainc pas un suiveur de ligne de fonctionner à coups d'arguments, et prédire puis exécuter devient naturel quand la classe regarde une vraie machine faire, ou ne pas faire, ce qui était prévu. Il y a aussi un avantage pratique bien sud-africain : un kit qui exécute son programme sur la carte continue de fonctionner pendant le délestage, au moment où un outil d'IA en ligne est de toute façon peut-être inaccessible.

C'est ainsi que nous menons nos cours à la sheen academy. La carte sheenbot∞ donne aux élèves quelque chose qu'ils doivent expliquer et modifier devant un camarade ou un enseignant, et les mêmes habitudes de prédiction-exécution et d'explication avant intégration se retrouvent dans nos ateliers de vacances. Les outils changent ; les garde-fous, non.

Une charte IA de départ, à afficher au mur

• Des indices seulement. Demandez à l'IA l'étape suivante ou une question, jamais une solution finie.
• Prédisez avant d'exécuter. Dites ce que vous attendez, puis lancez le programme.
• Expliquez avant d'intégrer. Si vous ne savez pas l'expliquer, cela n'entre pas dans le projet.
• Soyez prêt à le modifier en direct. Partez du principe qu'on vous demandera de modifier votre propre code sur-le-champ.
• Assumez les erreurs. Les mauvaises réponses de l'IA sont normales ; votre rôle est de les repérer.

À retenir

Interdire les assistants IA n'est ni applicable ni éducatif. Les garde-fous, eux, sont les deux. Laissez le raisonnement à l'élève grâce aux indices plutôt qu'aux solutions, à la prédiction avant exécution et à l'explication avant intégration, puis évaluez le processus et pas seulement le produit, et apprenez aux élèves à bien piloter l'outil. Faites cela et l'assistant IA cesse d'être un raccourci qui contourne l'apprentissage pour devenir une chose de plus qu'un jeune programmeur a appris à commander. Pour d'autres notes destinées aux enseignants, parcourez notre newsroom.

Devrais-je simplement interdire les outils d'IA en classe ?

Une interdiction est difficile à faire respecter et passe à côté de l'essentiel, car les élèves croiseront ces outils partout ailleurs. Des garde-fous qui protègent la réflexion, doublés d'une évaluation qui récompense le processus, font bien plus qu'une règle que vous ne pouvez pas contrôler.

À partir de quel âge est-ce trop tôt ?

Ces habitudes se transposent bien aux plus jeunes. Avec les débutants, l'enseignant montre la bonne formulation et fait la prédiction-exécution à voix haute avec toute la classe ; les plus grands le font seuls et commencent à piloter l'outil eux-mêmes.

Et si la réponse de l'IA obtenue par un élève est fausse ?

C'est la leçon, pas l'échec. Repérer une réponse assurée mais fausse est précisément la compétence recherchée : traitez donc chaque suggestion incorrecte comme une occasion de s'exercer à prédire puis exécuter et à expliquer avant d'intégrer.