Lutin Scratch mal positionné : comment régler ce bug

Lutin Scratch mal positionné: comment régler ce bug

Une erreur de position de départ dans Scratch produit un effet très déroutant pour les élèves: le programme semble avoir fonctionné une première fois, puis le lutin recommence ailleurs, tourne dans une direction imprévue ou dessine une diagonale qui n’a rien à voir avec la figure demandée. L’enfant modifie alors les blocs de déplacement, change les nombres, ajoute des rotations… et éloigne souvent son programme de la solution.

Le blocage est compréhensible. Scratch conserve l’état du lutin à la fin d’une exécution: sa dernière coordonnée, son orientation, parfois même la trace laissée par le stylo. Or beaucoup d’élèves imaginent qu’un clic sur le drapeau vert remet spontanément tout à zéro. Ce décalage entre ce qu’ils attendent et ce que le logiciel exécute crée une charge cognitive inutile: ils cherchent une erreur dans l’algorithme de la figure, alors que le problème se situe avant son premier bloc.

Nous pouvons consolider cette base très tôt: un programme fiable ne commence pas par « avancer de 100 pas », mais par une situation de départ explicitement construite.

Un lutin ne repart pas de zéro parce que nous relançons le programme: il repart de l’état que nous lui avons donné.

Le vrai problème: Scratch se souvient de la dernière exécution

Prenons un programme très simple: le lutin avance, tourne, puis recommence plusieurs fois afin de tracer un carré. À la première exécution, le résultat peut sembler correct. Mais à la fin, le lutin n’est plus au centre de la scène et ne regarde plus forcément vers la droite.

Si nous cliquons une seconde fois sur le drapeau vert, Scratch ne replace pas automatiquement le lutin au point de départ. Il exécute de nouveau les instructions, mais à partir de la dernière position atteinte. Le carré peut donc se dessiner dans un coin, sortir partiellement de la scène ou se superposer à une ancienne figure.

Cette situation explique une grande partie des cas où un lutin Scratch est décalé. Ce n’est pas, à proprement parler, un dysfonctionnement du logiciel. C’est une information qui n’a pas été donnée au programme: où commencer, dans quelle direction regarder et dans quel état se trouve le stylo.

Pour aider un élève, nous gagnons à distinguer deux approches.

La première approche donne parfois l’impression d’aller plus vite. Mais elle ne permet pas à l’élève de comprendre ce qu’il programme. La seconde bâtit une habitude algorithmique précieuse: avant de décrire une action, nous définissons l’état initial du système.

Initialiser le lutin sous le drapeau vert

Pour réinitialiser un lutin Scratch, tous les blocs nécessaires doivent être placés sous l’événement:

quand le drapeau vert est cliqué

C’est ce script qui assure que chaque nouvelle exécution commence dans les mêmes conditions. Pour un projet de géométrie, nous pouvons partir de cette organisation:

1. Effacer les anciens tracés, si l’extension Stylo est utilisée.

2. Relever le stylo pour empêcher le lutin de dessiner pendant son déplacement initial.

3. Envoyer le lutin au point de départ choisi.

4. Lui donner une orientation explicite.

5. Abaisser le stylo seulement lorsque le programme est prêt à tracer.

6. Lancer la suite des instructions géométriques.

Dans Scratch, cela correspond généralement à l’enchaînement suivant, lu de haut en bas:

• quand le drapeau vert est cliqué
• effacer tout
• relever le stylo
• aller à x: 0 y: 0
• s’orienter à 90
• abaisser le stylo
• puis les blocs de déplacement, de rotation et de répétition.

Le choix de x: 0 et y: 0 est fréquent parce qu’il place le lutin au centre de la scène. Mais ce n’est pas une obligation. Pour tracer une frise, un triangle occupant la moitié gauche de l’écran ou un repère gradué, nous choisirons un autre point de départ. Ce qui compte n’est pas de toujours utiliser le centre: c’est de ne pas laisser ce point au hasard.

L’orientation mérite la même attention. Dans Scratch, s’orienter à 90 signifie que le lutin regarde vers la droite. Cette convention surprend parfois, car on pourrait spontanément associer le haut de l’écran à 90 degrés. Or Scratch utilise ici un repère d’orientation propre:

• 90: vers la droite;
• 0: vers le haut;
• -90: vers la gauche;
• 180 ou -180: vers le bas.

Si un élève veut tracer un carré en commençant par un côté vertical, il peut choisir s’orienter à 0. Le programme reste juste, à condition que cette direction corresponde au premier déplacement envisagé.

Pourquoi le déplacement initial doit se faire stylo relevé

C’est une erreur classique, et elle est très instructive. Le lutin termine un tracé dans le coin supérieur droit; au lancement suivant, le programme utilise aller à x: 0 y: 0. Si le stylo est resté abaissé, Scratch dessine une longue ligne entre le point d’arrivée précédent et le nouveau point de départ.

L’élève voit alors une diagonale « parasite » et peut croire qu’un bloc de rotation est mal placé. Pourtant, la figure géométrique elle-même n’est pas nécessairement en cause: le lutin a simplement dessiné son trajet de repositionnement.

Nous pouvons formuler la règle de manière concrète: le lutin se déplace d’abord pour préparer son travail; il ne dessine qu’à partir du moment où son point et sa direction sont stabilisés.

Pour tracer une figure propre, le stylo ne doit pas raconter le trajet de préparation du lutin.

Comprendre le plan cartésien de la scène Scratch

L’erreur de position de départ Scratch devient beaucoup plus facile à corriger lorsque l’élève comprend que la scène n’est pas seulement un décor. C’est un plan cartésien.

La scène mesure 480 unités de largeur et 360 unités de hauteur. Les coordonnées horizontales vont de -240 à 240, tandis que les coordonnées verticales vont de -180 à 180. Le point central correspond à:

• x: 0
• y: 0

L’axe des abscisses, noté x, se lit de gauche à droite. Quand x augmente, le lutin se déplace vers la droite; quand x diminue, il va vers la gauche. L’axe des ordonnées, noté y, se lit de bas en haut. Une valeur de y positive place donc le lutin au-dessus du centre.

Cette représentation offre un excellent ancrage entre les mathématiques et la programmation. Le bloc aller à x: … y: … ne sert pas seulement à déplacer un personnage dans un jeu: il permet de placer un point dans un repère. Nous passons ainsi du geste intuitif — faire glisser le lutin avec la souris — à une manipulation codée, précise et reproductible.

Pour un élève de collège, cette progression est particulièrement féconde. Il peut d’abord déplacer le lutin à la souris et observer les valeurs de x et de y affichées dans l’interface. Puis il anticipe les coordonnées avant de les saisir. Enfin, il utilise ces coordonnées comme des paramètres d’une construction géométrique.

Un décalage qui n’est pas toujours visible immédiatement

Un programme peut être juste dans sa logique tout en produisant une figure mal cadrée. C’est fréquent lorsqu’un élève programme une rosace ou une suite de polygones à partir de l’origine: la construction s’étend progressivement dans une direction et finit par sortir de l’écran.

Dans ce cas, il ne faut pas forcément modifier la longueur des segments ou les angles de rotation. Nous pouvons d’abord interroger le point de départ. Si la figure doit occuper une zone de largeur importante, un départ en x: -150 plutôt qu’en x: 0 peut suffire à la recentrer.

Cette distinction est utile:

• un lutin qui commence au mauvais endroit relève d’un problème d’initialisation;
• une figure qui sort de l’écran malgré une initialisation cohérente relève souvent d’un choix de cadrage;
• une figure dont les côtés ou les angles sont faux relève de l’algorithme de tracé;
• un lutin dont l’image semble glisser autour de ses coordonnées relève souvent du costume.

En séparant ces causes, nous évitons de demander à l’élève de tout corriger en même temps. Sa réflexion devient plus légère et plus solide.

Quand les coordonnées sont justes mais que le lutin paraît encore décalé

Il existe une situation plus discrète: le programme contient bien aller à x: 0 y: 0, mais l’image du lutin ne se trouve pas visuellement au centre. Lorsqu’il tourne, elle peut décrire un grand cercle ou pivoter autour d’un point extérieur à son corps. Le problème ne se situe alors pas dans les blocs de mouvement, mais dans le centrage du costume.

Chaque costume Scratch possède un centre, représenté dans l’éditeur graphique par une petite croix. C’est autour de ce point que le lutin tourne, et c’est ce point que Scratch place aux coordonnées indiquées dans le programme.

Si le dessin est décalé par rapport à cette croix, le lutin peut être mathématiquement à x: 0, y: 0 tout en paraissant à droite, à gauche, trop haut ou trop bas. Lors d’une rotation, l’effet devient très visible: au lieu de tourner sur lui-même, il semble faire une boucle.

Recentrer un costume dans Scratch 3.0

Pour corriger ce décalage, ouvrons l’onglet Costumes et observons le dessin plutôt que le script.

1. Sélectionnez le costume concerné.

2. Sélectionnez l’ensemble du dessin, et non une petite partie de son contour.

3. Repérez la croix qui indique le centre de rotation.

4. Déplacez ce centre vers la cible centrale du canevas.

5. Testez une rotation avec un bloc tel que tourner ↻ de 15 degrés.

6. Revenez ajuster le centre si le mouvement paraît encore désaxé.

Pour un personnage, le centre se place généralement vers le milieu du corps. Le choix peut varier selon l’animation: un danseur qui pivote sur un pied, par exemple, peut demander un point de rotation plus bas. L’essentiel est que ce choix soit volontaire.

Pour un lutin représentant un crayon, un compas ou un stylo, le principe est plus précis encore: le centre du costume doit être placé sur la pointe qui dessine. C’est cette pointe que l’élève s’attend à voir suivre les segments. Si le centre est au milieu du crayon, Scratch placera le milieu à la bonne coordonnée, mais la mine apparaîtra toujours décalée.

Cette correction donne un sens profond à la notion de point. En géométrie, nous traçons souvent un segment à partir d’une extrémité abstraite. Dans Scratch, le lutin rend cette abstraction visible: le point réellement programmé n’est pas forcément le centre apparent de l’image; c’est le centre défini dans son costume.

Distinguer le mouvement du lutin et le déplacement de son image

Cette nuance mérite d’être explicitée, car elle résout beaucoup de malentendus. Le lutin Scratch est constitué de deux réalités qui se superposent:

• une position numérique, définie par les coordonnées x et y;
• une image, définie par un costume et son point central.

Le script agit sur la première. L’éditeur de costumes ajuste la seconde. Si nous ne séparons pas ces deux niveaux, l’élève peut accumuler les tentatives sans comprendre pourquoi un changement de coordonnées ne règle pas un problème visuel.

Imaginons un crayon dont le centre est placé 30 unités derrière la mine. Lorsque le script ordonne aller à x: 50 y: 20, le point central du costume arrive bien en (50; 20). Mais la mine, elle, se trouve ailleurs. Si le programme trace une figure, celle-ci paraît commencer avant ou après la pointe. Modifier x et y peut masquer le problème pour une position donnée, mais le défaut réapparaîtra dès que le lutin tourne.

C’est pourquoi nous conseillons de corriger d’abord le centrage du costume, puis de régler le script. Une compensation numérique est fragile; un costume bien ancré rend tous les programmes plus fiables.

Une routine de départ pour les projets avec le Stylo

Dans les activités Scratch mathématiques, l’extension Stylo introduit une difficulté supplémentaire: le lutin conserve non seulement sa position et son orientation, mais aussi l’état du stylo. L’élève doit donc penser à la scène comme à une feuille déjà utilisée.

Une routine de départ complète peut être adaptée à presque toutes les constructions:

1. Effacer le dessin précédent. Le bloc effacer tout évite que les essais antérieurs se mélangent à la nouvelle exécution.

2. Relever le stylo. Le lutin peut rejoindre son point de départ sans laisser de trace.

3. Placer le lutin. Utilisez aller à x: … y: … avec des coordonnées choisies en fonction de la figure.

4. Fixer la direction. Le bloc s’orienter à … évite qu’une rotation héritée de l’essai précédent modifie tout le tracé.

5. Régler l’apparence du tracé si nécessaire. Couleur, taille ou nuance du stylo peuvent également être définies ici lorsque le projet les utilise.

6. Abaisser le stylo. Le programme entre alors dans sa phase de dessin.

7. Tracer la figure. Les boucles et les instructions de mouvement peuvent s’exécuter dans un environnement stable.

Cette succession a une valeur qui dépasse Scratch. Elle apprend à organiser un algorithme en deux temps: la préparation, puis l’action. Dans un projet de robotique éducative, nous retrouvons la même idée: avant de déplacer le robot, nous précisons sa position de départ, son orientation et les conditions de son environnement.

Le piège du bloc « avancer »

Le bloc avancer de 10 pas paraît simple, mais il dépend entièrement de l’orientation actuelle du lutin. Si cette orientation n’est pas initialisée, la même instruction peut envoyer le lutin dans quatre directions différentes selon l’essai précédent.

C’est précisément ce qui rend certaines erreurs si difficiles à interpréter. L’élève lit correctement son programme: « avancer de 100 », puis « tourner de 90 degrés ». Pourtant, la figure est inclinée ou inversée. Le raisonnement géométrique n’est pas forcément faux; l’état initial manque.

Pour un carré, par exemple, la logique de base reste stable:

• avancer d’une longueur donnée;
• tourner de 90 degrés;
• répéter quatre fois.

Mais cette logique ne produit un carré prévisible que si le lutin part d’un point et d’une orientation connus. Nous ne devons donc pas opposer l’algorithme et l’initialisation: l’initialisation en est la première instruction fonctionnelle.

Une méthode simple pour diagnostiquer le décalage

Lorsqu’un lutin Scratch mal positionné résiste à une correction rapide, avançons par observations courtes plutôt que par modifications simultanées. Cela permet à l’élève de conserver le fil de son raisonnement.

1. Lancer deux fois le même script

Si le premier lancement paraît correct et que le second produit un résultat différent, l’hypothèse principale est l’absence d’initialisation. Cherchons sous quand le drapeau vert est cliqué un bloc aller à x: … y: … et un bloc s’orienter à ….

2. Observer les valeurs de position

Affichez les variables ou les informations de position du lutin. Si le programme devait commencer au centre mais que les valeurs indiquent une autre coordonnée avant le tracé, le problème est identifié: le lutin n’est pas replacé.

3. Tester sans le Stylo

Si une ligne parasite apparaît, désactivez temporairement le dessin ou ajoutez relever le stylo avant le bloc aller à x: … y: …. Nous distinguons ainsi un défaut de déplacement d’un simple trait de repositionnement.

4. Faire tourner le lutin sans le déplacer

Si l’image décrit un cercle, oscille de façon étrange ou semble tourner autour d’un point vide, ouvrez l’éditeur de costumes. Les coordonnées ne sont probablement pas responsables: le centre du costume doit être corrigé.

5. Revenir à une instruction à la fois

Après chaque correction, relancez le programme et observez un seul effet: position, direction, trace ou rotation. Cette discipline peut sembler lente au départ, mais elle réduit la charge cognitive. Elle apprend à relier une cause à une conséquence, au lieu de modifier plusieurs blocs en espérant que l’écran « redevienne normal ».

Faire de l’erreur un appui pour apprendre le repère

La correction d’un aller à x y Scratch bug peut devenir une activité mathématique très riche. Au lieu de donner immédiatement les bonnes coordonnées, nous pouvons demander: « Où le lutin est-il maintenant? Où souhaitons-nous qu’il soit? Quels nombres traduisent ce déplacement? »

Pour déplacer un lutin de la gauche vers le centre, l’élève comprend que l’abscisse doit augmenter. Pour le faire descendre, il comprend que l’ordonnée doit diminuer. Il manipule le repère non comme un dessin figé dans un manuel, mais comme un espace où chaque nombre produit un effet observable.

Cette articulation entre écran et coordonnées aide à consolider plusieurs notions:

• le rôle de l’origine;
• le sens des valeurs positives et négatives;
• la différence entre abscisse et ordonnée;
• l’idée qu’un point est défini par un couple de nombres;
• la nécessité d’un point de départ dans une procédure.

Nous remarquons souvent qu’un élève capable de corriger seul la position de son lutin devient aussi plus à l’aise dans les exercices de repérage. Le code ne remplace pas la géométrie; il donne à ses objets une forme manipulable et immédiatement vérifiable.

Installer un réflexe durable plutôt qu’un correctif isolé

La solution au lutin décalé tient souvent en quelques blocs. Mais l’enjeu pédagogique est plus large: aider l’enfant à comprendre qu’un programme ne commence jamais dans le vide. Il a besoin d’un état initial explicite, comme une construction géométrique a besoin de points de départ et de consignes de tracé.

Avant de chercher des blocs plus complexes, consolidons cette routine: effacer, relever le stylo, placer le lutin, fixer sa direction, puis dessiner. Si l’image reste décalée malgré des coordonnées correctes, regardons le costume et son centre de rotation.

Pour les activités de tracé, un lutin très sobre — un petit point ou un crayon dont la pointe est parfaitement centrée — constitue souvent le meilleur matériel. Il rend le lien entre le point programmé et le trait obtenu immédiatement perceptible. C’est une aide modeste, mais elle étaye durablement la pensée algorithmique: chaque figure commence quelque part, et ce « quelque part » mérite d’être programmé.