Variable Scratch non réinitialisée : résoudre ce bug classique

Variable Scratch non réinitialisée: résoudre ce bug classique

Un score qui repart à 17 au lieu de 0, un compteur de vies déjà entamé au lancement, une réponse précédente qui influence l’exercice suivant: lorsqu’une variable Scratch ne se réinitialise pas, l’élève a souvent le sentiment que le programme « fait n’importe quoi ». Pourtant, le problème ne relève généralement ni du hasard ni d’un mystérieux défaut de Scratch. Il révèle une notion centrale de l’algorithmique: une donnée possède une valeur, et cette valeur doit être explicitement préparée avant que le programme commence son travail.

Nous remarquons que ce blocage est particulièrement fréquent au collège parce que l’élève associe naturellement le clic sur le drapeau vert à un redémarrage complet. Or, Scratch relance les scripts, mais ne remet pas automatiquement les variables créées par l’utilisateur à leur valeur de départ. Cette différence, discrète à l’écran, est décisive pour bâtir un projet fiable.

Pourquoi une variable conserve-t-elle son ancienne valeur?

Une variable est une petite mémoire nommée. Elle sert à conserver une information dont le programme a besoin: le score d’un jeu, le nombre de vies restantes, le numéro d’une question, la longueur d’un côté dans une figure tracée, la réponse saisie par un joueur.

Prenons un quiz très simple. À chaque bonne réponse, le programme exécute:

• « ajouter 1 à score »;
• puis affiche la valeur de score.

À la fin de la partie, le score vaut 8. Si l’on clique de nouveau sur le drapeau vert sans avoir prévu d’instruction de départ, la variable vaut toujours 8. La prochaine bonne réponse la fera passer à 9. Scratch n’a pas oublié de recommencer: il a simplement conservé l’information qu’on lui avait demandé de mémoriser.

C’est là que se situe le nœud cognitif. L’élève pense souvent: « Je relance le jeu, donc tout revient au début. » Le programme, lui, fonctionne selon une logique plus précise: « Je relance les scripts, et j’utilise les valeurs actuellement stockées. » Nous pouvons aider l’enfant à percevoir cette nuance en séparant deux idées:

Cette persistance n’est pas une anomalie: elle est même utile dans certains projets. Dans un programme qui mémorise un réglage, une étape ou un résultat intermédiaire, conserver une valeur peut avoir du sens. Mais pour une partie, un exercice ou un tracé que l’on souhaite reprendre dans les mêmes conditions, cette mémoire doit être remise en ordre au départ.

Le drapeau vert déclenche le programme; il ne décide pas à votre place de l’état initial des données.

La règle qui résout la plupart des bugs: initialiser sous le drapeau vert

Pour corriger une variable Scratch qui ne se réinitialise pas, nous plaçons le bloc d’affectation tout en haut du script de démarrage:

• « quand le drapeau vert est cliqué »;
• « mettre [variable] à [valeur de départ] ».

Pour un score, la valeur de départ est généralement 0. Pour un jeu disposant de trois essais, on écrira souvent « mettre vies à 3 ». Pour une activité de questions, numéro de question pourra commencer à 1. Il ne s’agit pas de choisir une valeur au hasard: nous formulons l’état dans lequel le projet doit se trouver avant la première action du joueur.

Dans un jeu de labyrinthe, par exemple, le script du lutin principal peut commencer ainsi, sous forme de raisonnement:

1. Le joueur lance le projet avec le drapeau vert.

2. Le score doit être nul, puisqu’aucune pièce n’a encore été ramassée.

3. Le nombre de vies doit être fixé à la réserve choisie pour la partie.

4. Le personnage doit revenir à sa position initiale.

5. Les objets collectables doivent réapparaître.

6. Seulement ensuite, le déplacement et les collisions peuvent avoir un sens.

L’initialisation ne concerne donc pas exclusivement les variables. Elle fait partie d’une mise en place générale: positions, costumes, affichage des messages, arrière-plans, chronomètre, listes, clones éventuels. En programmation, nous appelons cela définir l’état initial. Dans Scratch, cette étape est visible et manipulable, ce qui en fait un excellent point d’ancrage pour la pensée informatique.

Où placer le bloc « mettre à »?

Le bloc doit être placé immédiatement après « quand le drapeau vert est cliqué », avant les calculs, les questions, les tests ou les boucles qui utilisent la variable.

Supposons un script de quiz:

• quand le drapeau vert est cliqué;
• mettre score à 0;
• demander « Combien font 7 × 8? » et attendre;
• si la réponse est 56, alors ajouter 1 à score.

L’ordre est cohérent: nous préparons la variable, puis nous la consultons ou nous la modifions.

À l’inverse, si le programme commence par poser la question, puis ajoute éventuellement un point, et ne remet le score à 0 qu’après, l’élève ne verra jamais correctement la première bonne réponse comptabilisée. Le programme aura travaillé avec une valeur héritée de la partie précédente.

Dans un projet un peu riche, il est utile de constituer un petit script de démarrage lisible. Nous pouvons le nommer mentalement « le script qui prépare la partie » et y regrouper ce qui doit être prêt dès le lancement. Cette organisation réduit la charge cognitive: au lieu de chercher des blocs dispersés dans chaque lutin, l’élève sait où regarder lorsque le projet repart dans un état inattendu.

« Mettre à » et « ajouter à » ne font pas le même travail

L’erreur classique se produit lorsqu’un élève utilise « ajouter 0 à score » pour essayer de remettre le score à zéro. Cette instruction ne change rien: ajouter 0 à une valeur la conserve telle quelle. Si le score était 8, il reste 8.

La confusion est compréhensible. Les deux blocs se trouvent dans la catégorie des variables et parlent tous les deux d’un nombre. Mais ils correspondent à deux opérations algorithmiques profondément différentes.

Le premier bloc est une affectation: nous décidons de la valeur à stocker. Le second est une incrémentation — ou une décrémentation si le nombre ajouté est négatif: nous transformons la valeur déjà présente.

Cette distinction mérite d’être consolidée avant de multiplier les projets. Elle se retrouve dans tous les langages de programmation, même lorsque les mots et les symboles changent. Si l’élève comprend qu’un compteur doit être initialisé puis modifié, il possède déjà une structure de pensée solide:

• au début, nous fixons la valeur de référence;
• pendant le programme, nous faisons évoluer cette valeur;
• à chaque nouveau lancement, nous recréons les conditions de départ.

Pour rendre cette différence tangible, je conseille souvent de quitter quelques instants l’écran. Un jeton placé dans une boîte étiquetée « score » représente la valeur mémorisée. Mettre la boîte à 0, c’est vider tous les jetons puis repartir de zéro. Ajouter 1, c’est déposer un jeton supplémentaire. Avec cette manipulation très simple, l’opposition entre « remplacer » et « augmenter » cesse d’être une subtilité de vocabulaire: elle devient une action concrète.

Une initialisation remplace une ancienne valeur; une incrémentation s’appuie précisément sur elle.

Quand le bon bloc ne suffit pas: plusieurs scripts démarrent en même temps

Il arrive qu’un élève ait bien écrit « mettre score à 0 » sous un drapeau vert et que le résultat reste instable. À ce stade, nous devons regarder non seulement les blocs utilisés, mais aussi les scripts qui les utilisent.

Dans Scratch, plusieurs scripts « quand le drapeau vert est cliqué » peuvent démarrer au même moment, dans un même lutin ou dans des lutins différents. C’est pratique: le décor se prépare, le personnage se place, le chronomètre démarre et les obstacles apparaissent sans que nous ayons à tout écrire dans une longue suite unique. Mais cette simultanéité peut créer des conflits si plusieurs scripts modifient la même variable.

Voici une situation typique:

• le lutin Gestionnaire met score à 0 au drapeau vert;
• le lutin Pièce teste immédiatement une collision et ajoute un point;
• le joueur apparaît déjà sur la pièce, ou l’ordre d’exécution fait que le test arrive avant que l’initialisation soit stabilisée.

Le résultat peut sembler intermittent: parfois le score commence à 0, parfois à 1, parfois le comportement change après une petite modification du projet. Il serait imprudent d’affirmer un ordre universel et simple entre tous les scripts déclenchés simultanément: ce qui compte pédagogiquement est de ne pas bâtir un programme qui dépend d’un ordre implicite.

Centraliser les variables de partie

Une première approche, robuste pour un projet de collège, consiste à confier les variables communes à un lutin clairement identifié, souvent le lutin principal ou un lutin invisible nommé gestionnaire. Ce script prépare les données, puis envoie un message tel que « démarrer la partie ».

Les autres lutins ne commencent leur logique de jeu qu’à la réception de ce message. Ainsi, nous séparons deux temps:

1. préparer l’état initial: score, vies, niveau, position des objets;

2. lancer les actions qui lisent ou modifient ces données.

Cette progression n’a rien d’artificiel. Elle étaye le raisonnement de l’élève: d’abord mettre le système en place, ensuite le faire fonctionner. Dans un projet de géométrie, le même principe permet de fixer la longueur d’un côté ou le nombre de répétitions avant de demander au lutin de tracer la figure.

Repérer les doubles initialisations

Le problème inverse existe aussi: deux scripts réinitialisent la même variable. L’un met score à 0 au démarrage, l’autre le fait après une attente ou à la réception d’un message. Le score peut alors revenir brutalement à zéro en pleine partie.

Pour enquêter sans se perdre, nous pouvons suivre cette méthode:

1. Afficher la variable à l’écran pendant les essais, même si elle doit être cachée dans la version finale.

2. Rechercher tous les blocs qui contiennent le nom de cette variable, en particulier « mettre à », « ajouter à » et les conditions qui la testent.

3. Se demander quel lutin est responsable de sa valeur initiale.

4. Vérifier qu’un autre script ne la modifie pas dès le lancement.

5. Relancer plusieurs fois avec le drapeau vert et observer à quel moment la valeur devient inattendue.

Cette démarche transforme le débogage en lecture de programme. Au lieu d’essayer des blocs au hasard, l’élève formule une hypothèse: « Qui a écrit cette valeur dans ma boîte mémoire? » C’est une question très féconde, bien plus durable que la seule correction du bug du jour.

Variable globale ou variable locale: une portée qui change tout

Lorsqu’on crée une variable dans Scratch, deux choix sont possibles:

• « pour tous les sprites »;
• « pour ce sprite uniquement ».

Une variable créée « pour tous les sprites » est globale. Tous les lutins peuvent la lire et la modifier. C’est le bon choix pour un score commun, un niveau, un chronomètre partagé ou le nombre total de vies du joueur.

Une variable créée « pour ce sprite uniquement » est locale. Elle appartient à un seul lutin. Un obstacle peut ainsi posséder sa propre vitesse, un personnage son propre état, ou chaque élément cloné sa propre information.

Le bug devient fréquent lorsque le nom est identique mais que la portée ne l’est pas. Un élève peut croire réinitialiser score dans un lutin, alors que le score affiché ou utilisé par un autre script correspond à une variable différente. Les deux variables portent peut-être le même nom à ses yeux, mais elles ne désignent pas la même mémoire.

Pour consolider cette idée, nommons les variables selon leur fonction plutôt qu’avec des termes vagues. score, vies, question, côté, angle, vitesse obstacle sont plus parlants que variable, nombre ou compteur 2. Un nom précis diminue la charge cognitive au moment de relire le programme: il rappelle ce que la donnée représente et indique plus naturellement où elle doit être gérée.

Un exemple en activité mathématique

Imaginons une activité Scratch qui trace plusieurs polygones réguliers. Le programme utilise:

• nombre de côtés, commun à toute l’activité;
• longueur du côté, commune au tracé demandé;
• angle de rotation, calculé à partir du nombre de côtés;
• pas du lutin, éventuellement propre à un sprite qui se déplace.

Si l’élève relance le projet après avoir tracé un octogone et que nombre de côtés conserve 8 alors qu’il veut reprendre la configuration de base avec un carré, le tracé suivant ne correspondra plus à la consigne. Ici encore, l’initialisation ne sert pas seulement à éviter un bug visuel: elle garantit que l’activité mathématique commence dans des conditions comparables.

Nous pouvons donc écrire, dès le drapeau vert:

• mettre nombre de côtés à 4;
• mettre longueur du côté à la valeur choisie;
• effacer tout;
• placer le lutin au point de départ;
• orienter le lutin dans la direction attendue.

L’élève perçoit alors que le programme n’est pas une succession de blocs décoratifs. C’est une construction où les données, les calculs et les actions doivent s’appuyer les uns sur les autres dans le bon ordre.

Variables cloud et clones: deux cas à traiter avec davantage de prudence

Les variables cloud, reconnaissables au nuage devant leur nom, ne doivent pas être abordées comme de simples variables ordinaires. Elles servent notamment à partager des données sur la plateforme Scratch, par exemple dans des projets collectifs ou des tableaux de scores. Leur synchronisation peut produire des comportements spécifiques: une valeur peut dépendre de l’état enregistré du projet ou sembler revenir à une ancienne donnée.

Pour un travail d’initiation, il est généralement plus formateur de commencer par des variables classiques. Elles permettent de comprendre sereinement l’initialisation, l’affectation et l’évolution d’un compteur. Les variables cloud deviennent pertinentes quand le projet a réellement besoin de communication ou de persistance partagée; elles demandent alors des essais méthodiques et une conception plus rigoureuse.

Les clones constituent un autre point d’attention. Scratch peut gérer jusqu’à 300 clones actifs. Dans un jeu où des objets apparaissent en continu, une variable de suivi mal pensée peut donner l’impression de ne pas se réinitialiser alors que le véritable problème vient de clones anciens, de scripts qui continuent à agir, ou d’un compteur commun modifié par chaque copie.

Dans un projet avec clones, nous gagnons à distinguer clairement:

• les données globales de partie: score total, niveau, vies;
• les données propres à chaque clone: position, vitesse, type d’objet, durée de vie;
• le moment où les clones sont supprimés lors d’une nouvelle partie;
• le script qui remet les compteurs communs à leur valeur initiale.

Un compteur d’objets restants, par exemple, ne doit pas seulement être mis à 0: il doit être cohérent avec les clones effectivement créés ou supprimés. La bonne question n’est donc pas uniquement « quelle valeur mettre? », mais « à quel moment cette valeur représente-t-elle bien la situation du projet? ».

Faire de ce bug une habitude de programmation

Le bug de la variable Scratch qui ne se réinitialise pas est un excellent seuil d’apprentissage. Il oblige à comprendre que lancer un programme et préparer ses données sont deux opérations différentes. Une fois cette idée acquise, beaucoup d’autres difficultés deviennent plus lisibles: le chronomètre qui repart mal, le personnage qui apparaît au mauvais endroit, le niveau qui saute une étape, la figure géométrique qui se trace avec les paramètres précédents.

Nous n’avons pas besoin de multiplier les règles pour avancer. Une posture suffit: avant d’ajouter les actions d’un projet, demandons-nous dans quel état il doit se trouver au premier instant. Puis écrivons cet état, bloc après bloc, sous le drapeau vert ou dans un script de préparation explicitement déclenché.

Pour travailler cela avec un élève, je recommande un support tangible très sobre: une fiche de démarrage avec trois colonnes — « donnée », « valeur au départ », « bloc Scratch qui la fixe ». En remplissant score → 0 → mettre score à 0, puis vies → 3 → mettre vies à 3, l’enfant ne corrige pas seulement un programme qui dysfonctionne. Il apprend à bâtir une initialisation, c’est-à-dire les fondations invisibles de tout algorithme solide.