Projet Scratch au collège : points de contrôle avant séance

Le programme de mathématiques du cycle 4 a été fixé par l'arrêté du 18 février 2026 et publié au Bulletin officiel le 5 mars 2026. Pour la rentrée 2026-2027, il s'applique uniquement à la classe de 5e; les niveaux 4e et 3e basculent à leur tour lors des deux rentrées suivantes. Si tu prépares un projet Scratch cette année, la première chose que ta hiérarchie pédagogique va regarder, c'est l'alignement entre ta séquence et le niveau réel de la classe — pas la sophistication de tes blocs. Avant d'ouvrir l'éditeur, tu as cinq points de contrôle à passer en revue. Voici l'ordre dans lequel les traiter pour ne rien laisser au hasard.

Aligner ton projet sur le programme de cycle 4

Le nouveau programme ancre la pensée informatique dans le cycle 4 en l'abordant sous l'angle de l'algorithmique et de la programmation impérative par blocs. Scratch n'est pas désigné nommément dans les textes: ce qui est prescrit, c'est la programmation par blocs, et Scratch reste l'outil le plus répandu pour la mettre en œuvre. Pour une séance de 5e en 2026-2027, les attendus couvrent le séquençage d'instructions simples, l'identification des entrées et sorties, l'analyse et la modification des paramètres d'un programme simple, ainsi qu'une boucle inconditionnelle qui répète une séquence linéaire un nombre précis de fois. Tu n'as pas besoin de variable ni de condition à ce stade; si ton projet de 5e utilise déjà une instruction « si… alors » pour orienter un lutin, tu dépasses le cadre et tu places l'élève face à une notion qu'il n'a pas encore les outils pour décoder.

En 4e, à partir de la rentrée 2027-2028, les élèves commencent à écrire des programmes simples en autonomie: conditions simples, instructions conditionnelles, manipulation d'une variable, modification d'un programme pour en changer le comportement. En 3e, à la rentrée 2028-2029, le programme ajoute les conditions composées, les boucles conditionnelles et la structuration des programmes. L'erreur la plus fréquente consiste à prendre un exercice de 3e — jeu de labyrinthe avec conditions imbriquées, par exemple — et à le proposer tel quel à une classe de 5e en se disant que « c'est plus stimulant ». C'est exactement l'inverse: tu sors du programme, et tu condamnes la séance à tourner au tour de toi pendant que tes élèves recopient.

Pour les projets à dimension géométrique — tracer un carré, reproduire une figure, dessiner une rosace — le repérage spatial entre en jeu. En 5e, l'élève doit comprendre qu'une rotation de 90° combinée à un déplacement fixe produit un carré; il n'a pas besoin de variable pour y arriver, une suite de blocs suffit. Si ton énoncé demande de paramétrer la longueur du côté, tu relèves déjà d'un objectif de 4e. Note-le sur ton brouillon avant d'écrire la première ligne de ton projet.

Avant de lancer ta séance, écrs sur ton brouillon la compétence exacte visée et le niveau de classe. Sans cette ligne, tu risques de mélanger deux progressions et de corriger un décalage que personne n'a vu venir.

Tester l'environnement Scratch avant la séance

Scratch exige que JavaScript soit activé dans le navigateur pour fonctionner. Sur les postes de ton établissement, cette condition n'est jamais acquise d'avance: certains navigateurs verrouillés par l'administrateur réseau désactivent JavaScript par défaut, d'autres filtrent certains domaines via un proxy, d'autres encore empilent des extensions qui bloquent le chargement des sprites. Le test préalable est non négociable. Ouvre l'éditeur sur deux ou trois postes répartis dans la salle — pas uniquement celui du fond, pas uniquement celui du professeur — avec le navigateur réellement utilisé par les élèves, et charge un projet existant. Si la scène reste vide ou si les blocs refusent de s'assembler, tu as un problème de configuration, pas un problème de pédagogie.

Pense aussi au cache et aux cookies. Une session Scratch précédente peut laisser des fichiers temporaires qui perturbent un nouveau chargement; un poste resté ouvert pendant une semaine peut refuser de se reconnecter proprement. Prévois dans ta séquence une minute de réinitialisation: fermeture complète du navigateur, réouverture, chargement de ton projet de départ. Cette minute te sauve souvent vingt minutes de dépannage en cours de séance, et elle évite que la moitié de la classe attende pendant que tu dépanne l'autre moitié.

Aucune source officielle ne fixe de seuil de mémoire vive, de processeur ou de bande passante minimal pour Scratch 3. Les inconnues techniques — nombre d'élèves par poste, durée d'une séance, débit Internet — relèvent de ton établissement. Ne te fie jamais à une fiche constructeur générique pour valider un parc: teste sur place, avec le réseau réel, pendant un créneau où d'autres classes ne saturent pas la bande passante. C'est la seule manière d'avoir une réponse fiable avant que trente élèves ne soient assis devant un écran noir.

Gérer les comptes élèves et la protection des données

Le guide officiel des comptes enseignants Scratch précise qu'un compte enseignant permet de créer des comptes élèves, d'organiser les projets dans des studios et de surveiller les commentaires. Il demande aussi que les identifiants ne contiennent ni nom réel, ni information personnelle (établissement, localisation, adresse électronique). En clair: pas de « Dupont.Jean.collegeVichy » comme login, même si ça te paraît anodin. Le pseudonyme doit être neutre, non réversible, et ne permettre à personne extérieure de remonter à l'identité réelle de l'élève.

La CNIL rappelle que les élèves ont droit au respect de leur vie privée et que l'inscription ainsi que le suivi doivent respecter des règles, en particulier pour les plus jeunes. Le choix du dispositif de comptes — individuel, collectif, sans compte — et la décision de publier ou non les projets en ligne doivent être validés avec ton établissement avant la séance. Tu n'as pas à trancher seul: ce point relève du projet d'établissement, du règlement intérieur et éventuellement du délégué à la protection des données. Si ton chef d'établissement ne s'est jamais positionné sur Scratch, ta séance attend.

Si tu hésites entre les options, commence par le mode sans compte pour une première séance: tu testes ta progression sans engager de données, et tu recules la décision RGPD au moment où tu en auras vraiment besoin.

Anticiper les trois paliers de complexité Éduscol

Les repères Éduscol décrivent trois paliers de complexité pour les activités d'algorithmique et de programmation. Le premier palier consiste à compléter ou ordonner des blocs Scratch fournis: l'élève remet de l'ordre dans un script existant, identifie l'instruction manquante, replace les blocs dans le bon ordre. Le deuxième palier introduit condition, boucle, événement et variable: l'élève écrit un script complet à partir d'un cahier des charges précis. Le troisième combine boucles et conditions, fait fonctionner plusieurs scripts en parallèle et vise la création de jeux, de simulations ou de figures paramétrées.

Pour ton brouillon, traduis chaque palier en action observable:

• Palier 1: l'élève déplace, assemble, complète. Il ne crée pas de bloc ex nihilo.
• Palier 2: il écrit, teste, corrige. Il produit un script complet mais guidé.
• Palier 3: il conçoit, débugue, combine. Il structure un projet en plusieurs scripts.

Si ton énoncé demande « écris un script qui trace un polygone régulier de n côtés » alors que tes élèves n'ont jamais manipulé une boucle, tu mélanges les paliers 1 et 3 et tu te condamnes à faire le travail à leur place. Mieux vaut décomposer: d'abord un énoncé palier 1 avec les blocs fournis dans l'ordre, puis un énoncé palier 2 où l'élève introduit la variable, puis un énoncé palier 3 où il généralise et fait varier le nombre de côtés.

Pour les figures géométriques, ce découpage est particulièrement net. Tracer un carré relève du palier 1 si tu fournis les blocs dans l'ordre. Paramétrer le nombre de côtés d'un polygone régulier relève du palier 3, parce qu'il faut imbriquer une boucle, une variable et un calcul d'angle. Si tu proposes directement le polygone paramétré à une classe qui découvre Scratch, tu n'observes rien: tu regardes des élèves qui recopient, et tu ne pourras pas évaluer leur compréhension réelle.

Préparer un déploiement qui ne dépend pas du tout en ligne

Le réflexe du coach: avoir un plan B avant que le réseau ne tombe. Prévois trois choses sur papier ou sur clé USB: une copie locale de l'éditeur Scratch (installable sur les postes de l'établissement si l'administrateur l'autorise, ou version portable à décompresser), un projet de départ exporté en.sb3 prêt à distribuer, et la progression écrite sous forme de liste de blocs à assembler. Si tu te retrouves sans réseau en pleine séance, tu peux continuer: les élèves ouvrent le fichier local, chargent le projet, et la progression suit son cours sans rupture.

Pense aussi au brouillon de l'élève. Un cahier où il note, avant chaque étape, ce que le lutin doit faire, puis la suite de blocs qu'il choisit, puis le test qu'il effectue, puis le résultat observé — cette habitude de rédaction n'est pas décorative. Elle structure la pensée algorithmique et te permet, en fin de séance, de repérer où le raisonnement a dérapé. C'est le même principe qu'une démonstration de géométrie: on ne rédige pas la conclusion avant d'avoir tracé la figure, et on ne valide pas un script avant d'avoir observé son exécution. Si l'élève n'a pas écrit ce qu'il voulait faire, il ne peut pas te dire pourquoi son script ne fait pas ce qu'il attend — et toi, tu ne peux pas le corriger.

Pour les projets à finalité géométrique, ajoute une dernière vérification: le tracé produit-il effectivement la figure annoncée? Un carré dont les côtés ne se ferment pas, un angle qui dépasse 90°, une rotation qui dérive — ces écarts se voient à l'œil. Tu gagnes du temps en demandant systématiquement à l'élève de superposer mentalement sa figure obtenue à la figure cible, comme on superpose un schéma à une donnée d'exercice.

Reprends tes cinq points dans l'ordre. Le programme et le niveau de classe: tu sais exactement quelle compétence tu vises, et tu sais dans quel cadre réglementaire elle s'inscrit. L'environnement technique: JavaScript activé, éditeur testé sur les postes réels à l'heure de ta séance, cache et cookies nettoyés, réseau vérifié sans saturation parasite. Les comptes et les données: mode choisi, identifiants pseudonymisés, validation établissement écrite ou tracée. Les paliers Éduscol: tu as réparti tes activités entre compléter, écrire et concevoir, sans mélanger, et tu as noté pour chaque activité l'action observable attendue. Le plan B: éditeur local prêt, projet.sb3 distribué, progression sur papier, brouillon élève imposé.

Si l'un de ces points te met en doute, ne lance pas la séance. Ce n'est pas de la frilosité: c'est la différence entre une heure d'algorithmique productive et une heure passée à dépanner des postes pendant que la moitié de la classe attend. Le jour J, tu veux pouvoir dire « ouvrez votre projet » et que tout le monde y arrive en trente secondes. Le reste de l'heure est pour tes élèves — et pour la trace que tu pourras valoriser ensuite.