Activité Scratch en classe : la checklist avant de démarrer

Activité Scratch en classe: la checklist avant de démarrer

Depuis l'intégration de l'algorithmique aux programmes des cycles 3 et 4, le scénario est devenu familier: un projet ambitieux, des élèves motivés, puis la panne de réseau qui fige tout le groupe pendant vingt minutes, ou l'élève qui relance quinze fois le drapeau vert sans comprendre pourquoi rien ne s'affiche. Avant de cliquer sur le drapeau vert toi-même, il y a une série de décisions qui déterminent si ta séance sera un déclic pour tes classes ou une heure passée à dépanner des postes.

Scratch 3.0 reste la version de référence dans les collèges français, et la majorité des enseignants de mathématiques et de technologie s'appuient dessus pour initier leurs élèves à la pensée informatique. La préparation d'une séance ne se limite pas au choix du projet: elle commence par le choix de l'environnement technique, se poursuit par l'organisation humaine de la classe et s'achève sur les réflexes de méthode qui évitent les blocages les plus fréquents. Cette checklist reprend, dans l'ordre où tu dois les traiter, les points que tu valides avant d'ouvrir la salle informatique.

Choisir son environnement technique: entre autonomie et conformité

Ta première décision concerne l'outil que tes élèves utiliseront réellement. Trois options se présentent à toi, chacune avec ses contraintes de mise en place, ses exigences réseau et ses implications en matière de données personnelles. Le bon choix dépend de ton équipement, de la fiabilité du réseau dans ton établissement et du niveau d'autonomie que tu souhaites laisser à tes élèves.

Scratch Desktop: l'indépendance face au réseau

La version hors ligne Scratch Desktop reste ton meilleur allié quand le réseau du collège est capricieux, quand tu veux éviter les dépendances à l'ENT ou quand tu dois travailler dans une salle non connectée. L'installation se fait en amont sur les postes, et tu n'as plus à craindre qu'un élève perde sa session au milieu d'un script. Scratch Desktop fonctionne avec les versions 3.0, 2.0 ou 1.4, même si la 3.0 reste la plus répandue aujourd'hui dans les classes.

L'avantage pédagogique est réel: tes élèves peuvent recommencer autant de fois qu'ils le souhaitent, sauvegarder leur projet en local sur une clé USB ou dans un dossier partagé du réseau pédagogique, et revenir dessus entre deux séances sans dépendre d'une connexion internet. Le coût de mise en place se limite au temps d'installation sur les machines du laboratoire, à programmer idéalement avec ton référent numérique ou le chef de travaux. Pense à vérifier la compatibilité avec les systèmes d'exploitation des postes: une salle sous Linux ne réagit pas toujours comme une salle sous Windows.

Scratch en ligne: la portabilité, à condition de maîtriser le réseau

La version en ligne de Scratch attire par sa simplicité d'accès: pas d'installation, juste un navigateur, et tes élèves retrouvent leurs projets depuis n'importe quel poste. Mais elle expose à un risque majeur en contexte scolaire: la dépendance au réseau. Une coupure au mauvais moment, un proxy mal configuré, et la séance dérape alors que tu avais prévu de travailler sur la dernière étape du projet.

Si tu choisis cette option, prévois impérativement une connexion stable et teste-la avant la séance, depuis un poste élève et non depuis ton poste enseignant. Pense aussi à la gestion des identifiants: un compte personnel avec adresse e-mail n'est pas conforme au RGPD en milieu scolaire, et les identifiants génériques partagés finissent toujours par être oubliés ou mélangés entre classes.

Capytale et Codabloc: la voie académique qui règle la question RGPD

Pour éviter les écueils de conformité tout en gardant la portabilité du cloud, l'intégration de Codabloc dans la plateforme Capytale via l'ENT de ton académie offre un compromis solide. Les élèves accèdent à un espace Scratch embarqué directement depuis leur compte ENT, leurs travaux restent dans l'environnement académique, et tu n'as pas à gérer de comptes externes ni à manipuler d'adresses e-mail. Tu crées une activité, tu la distribues à ta classe, tu récupères les productions à la date que tu fixes.

Cette solution demande un peu de prise en main la première fois, mais elle résout proprement la question des données personnelles et te permet de mutualiser les projets entre plusieurs séances sans dépendre du matériel.

Le compte enseignant Scratch: utile mais pas obligatoire

Si tu travailles hors ENT, créer un compte enseignant officiel sur Scratch te permet de générer des comptes élèves anonymisés, sans adresse e-mail personnelle, et de regrouper leurs projets dans des studios partagés. La validation du compte enseignant prend en moyenne 24 heures: anticipe ta demande plusieurs jours avant la première séance qui en dépend. Ce compte n'est pas indispensable si tu utilises Scratch Desktop ou Codabloc, mais il devient précieux quand tu veux garder une trace des productions de chaque élève d'une année sur l'autre.

Une heure de préparation technique avant la séance t'économise trente minutes de dépannage pendant.

Organisation de la classe: le binôme comme levier pédagogique

Deux élèves par ordinateur, c'est la configuration qui transforme une séance Scratch en moment d'apprentissage plutôt qu'en course au dépannage. La configuration en binôme ne divise pas ton travail de régulation par deux: elle le rend supportable et, surtout, elle installe chez tes élèves des réflexes de vérification qu'ils n'acquièrent pas en travaillant seuls.

Pourquoi le binôme fonctionne

Quand l'élève A manipule les blocs et l'élève B observe, lit le script et anticipe l'erreur, tu obtiens une boucle d'auto-vérification immédiate. La saisie du code se fait à tour de rôle, et la phase de relecture devient naturelle: l'élève qui n'est pas aux commandes a le recul critique pour repérer une boucle manquante, un opérateur mal placé ou une variable oubliée. Tu observes souvent que la verbalisation entre pairs détecte l'erreur avant que tu ne passes derrière eux.

Le binôme réduit aussi la pression technique sur toi. Tu n'es plus seul face à quinze ordinateurs qui appellent à l'aide en même temps: le binôme internalise une partie du diagnostic, et tu peux te concentrer sur les trois ou quatre groupes qui butent réellement sur une difficulté conceptuelle. Tu gagnes en qualité d'écoute, et tes élèves gagnent en autonomie.

Comment organiser les binômes

Évite le binôme d'amitié systématique: deux élèves qui discutent d'autre chose n'avancent pas sur le script. Associe plutôt des niveaux hétérogènes en algorithmique: l'élève avancé verbalise sa démarche et consolide sa compréhension en l'expliquant, l'élève débutant bénéficie d'un médiateur proche dont le langage est plus accessible que le tien. Change les binômes à chaque projet pour éviter les routines et faire circuler les compétences.

Pense aussi au demi-groupe si ton effectif est chargé: une moitié travaille sur Scratch pendant que l'autre moitié avance sur un exercice papier ou une activité débranchée, puis tu inverses à la séance suivante. Cette rotation limite la saturation du réseau et te donne plus de temps pour accompagner chaque groupe.

L'importance des activités débranchées pour préparer le Brevet

Sur l'épreuve de mathématiques du Brevet, tu le sais: aucun ordinateur n'est disponible. L'élève qui n'a jamais réfléchi à un script sans le voir s'exécuter se retrouve démuni face à un exercice papier où il doit lire un programme Scratch, prévoir un tracé ou compléter un script manquant. Les activités débranchées corrigent ce déséquilibre et installent les réflexes de rédaction qui font gagner des points.

Ce que le papier t'apporte

Une activité débranchée bien menée fait travailler la trace écrite: l'élève note ce que fait chaque bloc, prévoit la position du lutin après une série d'instructions, schématise l'évolution d'une variable au fil des itérations. Cette rédaction pure lui permet de gagner des points sur la justification, souvent négligée au profit du résultat final. Sur une copie, le correcteur cherche une démonstration écrite, pas une démonstration parlée.

Concrètement, tu peux demander à tes élèves de tracer sur papier le parcours d'un lutin à partir d'un script affiché au tableau, ou d'écrire le script Scratch correspondant à un tracé géométrique donné. Ces deux exercices inverses développent la même compétence: passer du langage algorithmique à la figure, et inversement. L'élève qui sait faire les deux sens de lecture aborde l'épreuve du DNB avec une longueur d'avance.

Insérer le débranché dans ta progression

Tu n'as pas besoin d'une séance entière pour le débranché. Quinze minutes en début de séance sur la trace écrite du script de la veille suffisent à installer le réflexe. Tu peux aussi conclure une séance sur ordinateur par un travail de rédaction: chaque binôme rend une fiche décrivant son programme en français, en listant les variables utilisées et leur rôle, et tu ramasses ces fiches comme preuves d'apprentissage exploitables en évaluation formative.

Les activités débranchées préparent aussi les élèves aux exercices du Brevet qui demandent de compléter un script manquant ou de repérer l'erreur dans un programme proposé. Ce type de question tombe régulièrement et fait la différence entre un candidat moyen et un candidat qui décroche la mention.

Au Brevet, le correcteur cherche une rédaction, pas une démonstration parlée: entraîne tes élèves à écrire ce qu'ils font.

Anticiper les blocages: erreurs récurrentes et gestion du stylo

Tes élèves vont tous faire les mêmes erreurs. Ce n'est pas un constat décourageant: c'est un avantage stratégique. En connaissant les pièges classiques avant qu'ils ne se produisent, tu peux les nommer en début de séance, et tes élèves gagnent un temps précieux au lieu de chercher pendant vingt minutes ce qui ne va pas.

Le stylo: un module à activer explicitement

Depuis Scratch 3.0, les blocs Stylo ne sont plus visibles par défaut dans l'interface. Si tu veux que tes élèves tracent des figures géométriques, tu dois leur demander d'ajouter l'extension via le bouton en bas à gauche de l'éditeur, puis de la laisser sélectionnée. Cette manipulation simple rate une proportion étonnante d'élèves en début d'année, qui cherchent en vain le bloc « stylo en position d'écriture » dans la catégorie Stylo.

Au-delà de l'activation, l'initialisation du stylo est un point de friction récurrent. Au clic sur le drapeau vert, ton élève doit systématiquement effacer tout pour repartir d'une zone propre, relever le stylo pour éviter les traits parasites pendant le positionnement, positionner le lutin aux coordonnées de départ, orienter le lutin dans la direction initiale, puis seulement abaisser le stylo et commencer le tracé. Oublie l'une de ces étapes et tu obtiens des figures illisibles où le lutin a tracé une ligne invisible entre son point de départ et le point d'origine.

Ce réflexe d'initialisation se construit en l'écrivant noir sur blanc au tableau dès la première séance, et en exigeant qu'il apparaisse dans chaque rendu. Tu transformes une procédure en rituel de classe.

Les blocs orphelins: le piège des événements

L'erreur la plus coûteuse en points sur une copie consiste à placer un bloc conditionnel ou un test d'événement en dehors d'une boucle « répéter indéfiniment ». Le test ne s'exécute alors qu'une seule fois au lancement du programme, puis plus jamais. Ton élève ne comprend pas pourquoi son lutin ne réagit plus à la touche pressée après le premier mouvement, et il passe de longs moments à douter de son clavier.

Apprends-leur à systématiquement encapsuler les tests dans une boucle infinie. C'est un réflexe architectural, pas une ligne de code: la structure du programme doit montrer que la condition est vérifiée en continu, pas une seule fois. Sur une copie, la présence de cette boucle vaut des points de méthode que le correcteur identifie immédiatement.

Les variables oubliées

L'oubli classique en classe ne concerne pas la création d'une variable, qui produit une erreur rapidement repérable par l'élève: il concerne la réinitialisation. Quand un élève utilise une variable sans la remettre à zéro au début du script, son programme fonctionne au premier lancement mais conserve la valeur de la séance précédente. L'élève croit son script cassé, alors qu'il a simplement gardé la mémoire du test précédent. Le réflexe à installer: un bloc « mettre [variable] à 0 » placé immédiatement après le drapeau vert, avant toute autre instruction.

Maîtriser les variables et l'initialisation des scripts

Les variables sont le point où la pensée algorithmique bascule vraiment. Les élèves comprennent ce qu'est une variable, mais ils butent sur deux usages voisins qui semblent interchangeables au premier abord: l'affectation et l'incrémentation. Les confondre produit des scripts qui semblent fonctionner mais donnent des résultats incohérents.

Deux blocs à ne pas confondre

« Mettre [variable] à [valeur] » écrase le contenu de la variable avec une nouvelle valeur. « Ajouter à [variable] [valeur] » ajoute à la valeur existante. Pour beaucoup d'élèves, ces deux blocs semblent interchangeables: ils cliquent sur le premier par défaut, même quand il leur faut le second. Le résultat: un compteur de pas qui reste bloqué à 1, parce que « mettre à 1 » écrase la valeur précédente au lieu de l'incrémenter.

Une technique simple pour distinguer les deux: tu écris au tableau un petit tableau de suivi d'une variable. Si la valeur doit redémarrer à chaque lancement, c'est « mettre à ». Si la valeur doit s'accumuler au fil des itérations, c'est « ajouter à ». Cette distinction reportée en marge de leur script leur évite de chercher pendant vingt minutes pourquoi leur compteur ne dépasse pas la valeur de départ.

Réinitialiser systématiquement

L'oubli classique revient dans chaque classe: ne pas remettre la variable à zéro au début du script. Le programme fonctionne au premier lancement, mais conserve la valeur de la séance précédente. Cette erreur enseigne une leçon précieuse sur le cycle de vie d'un programme, à condition que tu la pointes explicitement quand tu la rencontres. Le réflexe: un bloc « mettre [variable] à 0 » immédiatement après le drapeau vert, avant toute autre instruction. Cette ligne change profondément la lecture du script: elle prouve que tu penses ton programme comme un tout cohérent et que tu maîtrises l'initialisation de tes variables, un réflexe essentiel pour comprendre comment un script se construit, s'exécute et se relit.

Tableau récapitulatif des erreurs les plus fréquentes

Ta séance démarre maintenant: la séquence de validation

Pour transformer cette checklist en réflexe quotidien, voici la séquence que tu peux appliquer dès ta prochaine séance, en quatre temps. Chaque étape prend peu de temps, mais chacune élimine une catégorie précise de problèmes que tu rencontres habituellement à la troisième ou quatrième séance d'un projet.

Le premier temps est technique: tu vérifies l'environnement choisi la veille, depuis un poste élève. Scratch Desktop est installé et lance sans message d'erreur, Capytale répond depuis l'ENT, le réseau tient la charge. Cette vérification de cinq minutes t'évitera la séance blanche du vendredi matin où la moitié du laboratoire refuse de se connecter.

Le deuxième temps est matériel: tu répartis les binômes selon la consigne que tu t'es fixée, tu distribues la fiche de préparation si tu en utilises une, tu inscris au tableau la séquence d'initialisation du lutin et des variables pour qu'elle serve de modèle commun. Tu ne fais pas encore lancer Scratch: tu donnes d'abord le cadre méthodologique, et tes élèves savent exactement ce qui est attendu d'eux avant même d'ouvrir l'éditeur.

Le troisième temps est méthodologique: tu nommes explicitement les deux ou trois erreurs récurrentes que tu attends sur la séance. Tes élèves savent que « mettre à 0 » vient après le drapeau vert, que le stylo se relève avant le positionnement, que les tests vont dans une boucle infinie. Ce rappel prend trois minutes et te fait gagner vingt en temps de dépannage collectif.

Le quatrième temps est le lancement: tu donnes le signal, tu laisses tourner, et tu n'interviens que sur les groupes qui butent sur une difficulté conceptuelle. Le reste de la classe est en auto-régulation grâce aux binômes, et tu redeviens un enseignant qui accompagne plutôt qu'un technicien qui court d'un poste à l'autre.

Une séance bien préparée ne se voit pas. C'est quand rien ne tombe en panne que tu sais que ton cadrage a tenu.

Avec ces quatre temps enchaînés, ta séance Scratch démarre sur des bases solides et tes élèves entrent dans le projet sans avoir à te solliciter pour des questions de méthode qu'ils auraient pu anticiper. La checklist n'est plus un document que tu consultes la veille en soupirant: elle devient un schéma mental que tu appliques sans y penser, et c'est exactement ce que tu visais depuis le début de l'année.