Les variables dans Scratch : définition et exemples simples
Le quiz interactif tourne, les questions défilent, le lutin réagit — mais quand l'enseignant ouvre ta grille d'évaluation, le score affiché en haut de la scène reste obstinément à zéro.
Les variables dans Scratch: définition et exemples simples
Ou pire: il garde la valeur de la partie précédente, comme si le programme avait une mémoire qui n'a pas été remise à zéro au démarrage. Cette panne, tu la rencontres presque à chaque fois qu'un compteur entre en jeu. Et elle ne vient pas de la logique du quiz: elle vient d'une variable mal déclarée, mal initialisée, ou lue par le mauvais lutin. Comprendre les deux gestes de base — créer la variable, puis l'initialiser au bon moment — suffit à la faire disparaître.
Une variable dans Scratch, c'est exactement ce que tu imagines: une boîte étiquetée posée sur l'étagère de ton programme, dont le contenu peut changer au fil de l'exécution. Elle ne calcule rien toute seule — elle stocke un nombre, un mot ou un état logique (vrai / faux) que d'autres blocs viendront lire, modifier ou afficher. Sans variable, impossible de compter des points, de mémoriser le prénom de l'utilisateur ou de savoir si un personnage a déjà franchi la ligne d'arrivée. La mécanique tient en peu de choses, à condition de la voir comme une étagère bien rangée plutôt que comme une formule abstraite.
Déclarer avant d'utiliser: le premier réflexe à prendre
Avant d'écrire la moindre ligne de script, ta variable doit apparaître dans la palette orange « Variables ». Tant qu'elle n'y figure pas, Scratch ne te propose aucun bloc portant son nom — la création de la variable et l'apparition des blocs qui la manipulent sont indissociables. Tu dois donc observer la palette Variables avant d'observer ton programme: c'est l'ordre logique.
Pour déclarer une variable, tu ouvres la catégorie Variables (le bloc orange dans la palette), tu cliques sur « Créer une variable », et tu donnes un nom parlant: score, vies, tentatives, reponse_utilisateur. Évite les noms génériques comme a ou variable1 — un nom explicite raconte immédiatement le rôle de la variable, à ton prof comme à toi-même dans deux semaines quand tu rouvriras le projet. Range ta variable au moment de la création: c'est comme étiqueter une boîte avant de la poser sur l'étagère, sinon tu ne sauras plus ce qu'elle contient trois jours plus tard.
Une variable, c'est une boîte étiquetée sur l'étagère de ton programme: son contenu change, pas son nom.
Au moment de la création, Scratch te pose une question qui change tout: « Pour tous les lutins » ou « Pour ce lutin uniquement ». C'est la portée, et tu vas y revenir en détail un peu plus loin. Pour l'instant, retiens ce réflexe: tu déclares toujours la variable avant de poser ton premier bloc qui l'utilise.
Initialiser et modifier: les deux blocs à maîtriser par cœur
Une fois la variable créée, elle existe — mais son contenu est vide ou égal à zéro selon les cas, et tu ne peux pas te permettre de laisser ce hasard décider du comportement de ton programme. L'initialisation consiste à lui donner une valeur de départ propre, en général dès que le drapeau vert est cliqué.
Le bloc à utiliser est sans ambiguïté:
« mettre [variable] à (valeur) »
Tu le places en tête de ton script « quand le drapeau vert est cliqué », avant n'importe quel autre bloc qui lirait la variable. Pourquoi? Parce que si tu lances ton programme une deuxième fois sans réinitialiser, ta variable garde la valeur de la partie précédente — et l'enseignant qui recharge ton projet pour le tester le verra immédiatement, lui qui n'a pas la même patience que toi pour deviner d'où vient le « 17 » qui s'affiche au lancement.
Pour modifier la valeur en cours de route, deux blocs font l'essentiel du travail:
| Bloc | Effet | Usage typique |
|---|---|---|
| mettre [variable] à (valeur) | Remplace entièrement le contenu | Réinitialiser un score, fixer une réponse |
| ajouter à [variable] (valeur) | Ajoute (ou soustrait) à la valeur existante | Incrémenter un score, décrémenter des vies |
L'erreur classique consiste à confondre les deux: si tu utilises « mettre à 1 » à la place de « ajouter 1 » à l'intérieur d'une boucle, ta variable ne progressera jamais — elle sera écrasée à chaque tour par la même valeur. Trace ton algorithme sur ton brouillon avant de coder: à chaque passage dans la boucle, est-ce que tu remplaces ou est-ce que tu ajoutes? Cette question mérite d'être écrite en toutes lettres.
Tu dois initialiser ta variable avant de t'en servir. Sinon ton score part de rien — et c'est ton correcteur qui le verra en premier.
Globale ou locale: la portée qui change tout
Tu te souviens de la question posée à la création de la variable? C'est la portée, et c'est le point qui distingue un projet proprement structuré d'un projet où les lutins se marchent sur les pieds. Voici ce qu'il faut retenir:
| Portée | Visibilité | Quand la choisir |
|---|---|---|
| Pour tous les lutins (globale) | Tous les sprites du projet peuvent lire et modifier la variable | Score, vies, temps écoulé — toute donnée partagée |
| Pour ce lutin uniquement (locale) | Seul le sprite qui l'a créée peut l'utiliser | État propre à un personnage (énergie d'un ennemi, état d'animation) |
La règle d'or est simple: si plusieurs lutins doivent accéder à la même information, prends globale. Si l'information n'a de sens que pour un seul lutin, choisis locale — c'est plus propre, et ça évite les conflits quand tu auras cinq sprites en jeu.
Un cas concret: tu codes un jeu de dodgeball entre deux lutins. Le score partagé (joueur 1 contre joueur 2) doit être global, parce que les deux personnages doivent pouvoir le modifier. En revanche, l'énergie du lutin « méchant » qui descend quand il se prend une balle n'a aucune raison d'être visible ailleurs — elle reste locale. Si tu déclares cette énergie en globale, tu ouvres la porte à des modifications accidentelles par les autres sprites, et ton projet deviendra rapidement impossible à déboguer.
Au-delà des nombres: texte et booléens
Scratch n'est pas limité aux compteurs entiers. Tes variables peuvent stocker trois grandes familles de valeurs:
- Des nombres: entiers (0, -3, 42) ou décimaux (3,14). C'est le cas par défaut, et celui que tu utiliseras le plus souvent.
- Du texte: n'importe quelle chaîne de caractères, posée entre guillemets dans le bloc. Très utile pour stocker le prénom d'un joueur, le titre d'un niveau ou un mot à deviner dans un jeu de pendu.
- Un booléen: une variable qui ne prend que deux valeurs, vrai ou faux. Parfait pour mémoriser un état: partie_finie, a_gagne, a_deja_parle.
Le booléen mérite une attention particulière. Beaucoup d'élèves débutants créent une variable score quand un simple booléen suffirait: pour savoir si le joueur a déjà franchi la ligne d'arrivée, un a_gagne mis à vrai au moment opportun est dix fois plus lisible qu'un compteur qu'on remettrait à 1. Tu observes ici un principe de méthode: choisir le type de variable le plus simple qui répond à ton besoin. C'est cette économie de moyen que ton prof repère comme une vraie rigueur algorithmique.
Ne confonds pas la variable (qui stocke) et le bloc opérateur (qui calcule). Ta variable score ne s'incrémente pas toute seule: c'est le bloc « ajouter (1) à score » qui fait le travail.
Pourquoi ma variable reste à 0? les cinq erreurs qui bloquent ton programme
Maintenant que tu maîtrises la théorie, voici les pièges qui reviennent le plus souvent dans les copies. Chacun suffit à faire basculer ton programme du côté du « ne marche pas ».
1. Variable non déclarée. Tu fais référence à un nom de variable dans ta tête, mais elle n'a jamais été créée dans la palette. Scratch ne te propose aucun bloc portant ce nom, et tu cherches pendant vingt minutes pourquoi ton script « ne fait rien ». Solution: ouvre la palette Variables, vérifie que ta variable existe et que son nom est orthographié de la même façon partout.
2. Initialisation oubliée. Tu lances ton programme, le score part de 0, mais après un test il reste figé sur une valeur. C'est que tu n'as pas placé le bloc « mettre à » dans le script du drapeau vert. Vérifie que ce bloc est bien avant les autres, jamais après.
3. Mauvais bloc utilisé. Tu utilises « mettre à 1 » au lieu de « ajouter 1 » dans une boucle. Ta variable ne s'incrémente jamais. Projette sur ton brouillon ce que doit devenir la valeur à chaque tour: 0 →? →? →?. Si la logique n'est pas écrite, elle ne tiendra pas dans le programme.
4. Portée mal choisie. Tu déclares une variable locale à un lutin, et un autre lutin essaie d'y accéder. Résultat: la variable reste invisible depuis l'autre lutin — elle n'apparaît tout simplement pas dans sa palette Variables, et aucun bloc ne te permet de la lire ou de la modifier. Si tu voulais la partager entre sprites, c'est une variable globale qu'il te fallait dès le départ.
5. Réinitialisation déclenchée trop tard. Tu places ton « mettre à 0 » au milieu du programme, après une boucle, donc il s'exécute après que le score a déjà été incrémenté. Place-le toujours au tout début, juste sous le bloc « quand le drapeau vert est cliqué ».
Un dernier réflexe qui sauve des situations: affiche la variable à l'écran pendant tes tests. Le petit rond à cocher à côté du nom de la variable dans la palette Variables te permet de voir la valeur en temps réel sur la scène. Si le compteur ne bouge pas quand tu penses qu'il devrait bouger, c'est que ton script de modification n'est pas atteint — pas que la variable est cassée. Observer la valeur affichée, c'est projeter l'état de ton programme sur la scène, et c'est la meilleure vérification visuelle que tu puisses faire avant de soumettre ton travail.
Méthode de rédaction pour l'évaluation
Ton correcteur ne note pas seulement un programme qui « marche »: il note un programme qui montre qu'il marche. Concrètement, sur ta copie ou dans ton commentaire, tu dois pouvoir justifier chaque bloc. Voici la trame qui rend ta copie lisible:
- Nomme tes variables de manière explicite (score_joueur1, pas s1). Un nom clair, c'est déjà une indication que tu as pensé ton projet avant de l'écrire.
- Place un commentaire au-dessus de chaque script qui initialise une variable: « Initialisation du score à 0 au démarrage ». Cette ligne mérite sa place: elle prouve que tu as pensé la remise à zéro, pas seulement cliqué sur les blocs au hasard.
- Commente la portée choisie: « Variable globale, accessible à tous les lutins » ou « Variable locale propre à ce lutin ». Cela prouve que tu as compris la distinction, pas seulement recopié un bloc.
- Trace les valeurs attendues sur ton brouillon pour 2 ou 3 cas: par exemple, si le joueur gagne, score = 5; s'il perd, score = 0. Ce type de tableau démontre que tu as pensé l'algorithme avant de le programmer.
En suivant cette structure, tu ne te contentes pas de programmer — tu rédiges une démonstration que ton programme fait ce qu'il prétend faire. C'est exactement ce que cherche ton correcteur quand il lit ta grille d'évaluation, et c'est ce qui distingue une copie qui se contente de fonctionner d'une copie qui montre qu'elle a été pensée. La variable, en définitive, n'est qu'un outil: ce qui rend ta copie convaincante, c'est la clarté avec laquelle tu l'as pensée, déclarée et justifiée.