Boucle infinie dans Scratch : identifier et corriger l'erreur

Boucle infinie dans Scratch: identifier et corriger l'erreur

C’est le principe d’une boucle infinie. Le lutin continue alors à avancer, à parler, à changer de costume ou à modifier une variable, tandis que les blocs placés plus bas semblent ignorés.

Au collège, cette erreur apparaît fréquemment lorsque l’élève comprend bien l’idée de répétition, mais pas encore le lien entre la répétition et son évolution. Ajouter une condition d’arrêt ne suffit pas: encore faut-il que cette condition puisse devenir vraie pendant l’exécution du programme. C’est ce point précis qui permet de passer d’un simple bricolage de blocs à une véritable logique algorithmique dans Scratch.

Comprendre les trois structures de répétition dans Scratch

Dans la catégorie « Contrôle », Scratch propose trois grandes structures de boucle. Elles se ressemblent visuellement, mais elles ne répondent pas au même besoin. Avant de corriger une boucle infinie, nous devons donc identifier l’intention du programme: voulait-on répéter un nombre défini de fois, surveiller une situation en continu ou attendre qu’un événement se produise?

Cette comparaison est essentielle, car le bloc « répéter indéfiniment » n’est pas une erreur en lui-même. Dans un jeu, il est parfaitement pertinent pour surveiller en continu les commandes du joueur. Par exemple, un script peut vérifier sans interruption si la flèche droite est pressée, puis déplacer le personnage lorsque c’est le cas.

Le problème apparaît lorsque nous utilisons cette structure pour une tâche qui possède une fin naturelle. Si l’objectif est de faire avancer un lutin de dix pas, d’afficher une suite de cinq nombres ou de tracer quatre côtés, la répétition infinie ne correspond pas à la tâche. Le programme ne dispose d’aucune information lui indiquant qu’il a terminé.

Une boucle n’est pas infinie parce qu’elle répète beaucoup d’instructions; elle le devient lorsque le programme ne possède plus de chemin réel vers la fin.

La répétition avec compteur

Le bloc « répéter ( ) fois » est généralement le plus accessible pour débuter. Le nombre de répétitions est annoncé dès le départ et ne dépend pas d’un événement extérieur.

Pour tracer un carré, par exemple, nous savons que quatre côtés doivent être dessinés. La structure logique est donc stable:

1. avancer d’une certaine longueur;

2. tourner de 90 degrés;

3. recommencer quatre fois.

L’élève peut alors relier directement la forme géométrique à la structure du programme. La boucle ne sert pas seulement à économiser des blocs: elle met en évidence la régularité de la construction. Cette correspondance entre l’objet mathématique et le code constitue un ancrage particulièrement utile.

La répétition sans fin

Le bloc « répéter indéfiniment » est adapté lorsque le programme doit rester actif pendant toute la durée du projet. Un jeu doit souvent écouter les touches du clavier, détecter une rencontre entre deux lutins ou faire fonctionner une animation en arrière-plan.

Dans ce cas, l’absence de fin n’est pas un défaut. Elle traduit une consigne: « continue à surveiller cette situation ». Nous pouvons toutefois rencontrer deux difficultés:

• les blocs placés après la boucle ne seront pas exécutés tant que celle-ci continue;
• une action exécutée trop rapidement peut donner l’impression que le projet est bloqué, alors qu’il travaille sans pause.

Il est donc souvent nécessaire d’ajouter une courte attente à l’intérieur d’une boucle de surveillance. Cela ne transforme pas la boucle en répétition finie, mais cela laisse au projet le temps de traiter les événements et rend son comportement plus lisible.

La répétition conditionnelle

Le bloc « répéter jusqu’à ce que (condition) » introduit une idée plus élaborée: le nombre d’itérations n’est pas forcément connu au départ. Le programme poursuit son action jusqu’à ce qu’une situation soit atteinte.

Nous pouvons l’utiliser pour faire avancer un lutin jusqu’à une certaine position, attendre qu’une réponse soit correcte ou poursuivre un déplacement jusqu’à une collision. Dans Scratch, la condition est vérifiée au fil de l’exécution. La boucle s’arrête lorsque cette condition devient vraie.

L’ordre des mots compte ici. Si nous demandons de répéter jusqu’à ce que « réponse = 10 », le programme doit avoir une possibilité réelle d’obtenir la valeur 10. Si la réponse n’est jamais modifiée, si la variable observée n’est pas celle qui évolue ou si le test contient une erreur, la condition restera fausse.

Pourquoi une boucle devient-elle infinie?

Le cœur du problème se trouve rarement dans le mot « répéter ». Il se situe dans l’évolution de l’état du programme. Une boucle conditionnelle observe une information: une variable, une position, une réponse, un contact, une touche ou un événement. Pour pouvoir s’arrêter, cette information doit changer de manière compatible avec la condition.

Prenons un exemple simple. Nous créons une variable appelée « compteur » et demandons au programme de répéter jusqu’à ce que « compteur = 10 ». Si le compteur commence à 0 mais qu’aucun bloc ne l’augmente, la condition ne deviendra jamais vraie. Le programme continuera donc à répéter les instructions.

La présence d’une condition donne une apparence de contrôle, mais elle ne garantit pas la terminaison. Il faut examiner le mécanisme qui permet à la situation testée de progresser.

Le piège de la variable immobile

C’est l’une des erreurs les plus fréquentes dans les activités d’initiation à l’algorithmique. L’élève crée une condition pertinente, mais oublie de modifier la variable concernée.

La logique attendue est généralement la suivante:

1. donner une valeur de départ à la variable;

2. entrer dans la boucle;

3. effectuer une action;

4. modifier la variable;

5. vérifier si la condition d’arrêt est maintenant vraie.

Si la quatrième étape manque, le programme reste dans le même état. Il recommence les mêmes instructions sans se rapprocher de la fin.

Pour aider l’élève à repérer ce blocage, nous pouvons poser une question très concrète: « Qu’est-ce qui change à chaque tour? » Si la réponse est « rien », nous avons probablement identifié la source de la boucle infinie.

Une condition impossible à atteindre

Une boucle peut également devenir infinie lorsque la condition est mal choisie. Supposons qu’une variable augmente de 2 à chaque passage: 0, 2, 4, 6, 8, 10… Si nous demandons l’arrêt lorsque cette variable vaut 9, la valeur recherchée ne sera jamais obtenue.

Le programme avance bien, mais il ne peut pas atteindre l’état prévu. Cette distinction est pédagogiquement intéressante: l’erreur ne vient pas d’une absence d’évolution, mais d’une incompatibilité entre le mode d’évolution et la condition.

Dans ce cas, une condition comme « compteur ≥ 9 » peut être plus appropriée que « compteur = 9 », selon l’objectif de l’activité. Nous ne devons toutefois pas remplacer mécaniquement tous les tests d’égalité par des inégalités. Il faut d’abord comprendre ce que le programme est censé mesurer.

Une variable qui évolue dans le mauvais sens

Le même phénomène apparaît avec un compteur qui diminue alors que la condition attend une valeur supérieure. Une position peut aussi s’éloigner de la cible au lieu de s’en rapprocher. Dans un déplacement, le lutin peut avancer vers la droite tandis que la condition teste une position située à gauche.

Le programme poursuit alors une trajectoire cohérente du point de vue de ses blocs, mais incohérente du point de vue de l’objectif. C’est pourquoi le débogage ne consiste pas uniquement à chercher le bloc « fautif ». Nous devons reconstruire l’évolution du programme: valeur initiale, transformation appliquée, valeur attendue et direction du changement.

Une condition qui dépend d’un événement absent

Certaines boucles attendent une action extérieure: une touche pressée, une réponse donnée, un message reçu ou un contact entre deux objets. Si l’événement n’arrive jamais, le programme continue d’attendre.

Ici encore, cela ne signifie pas forcément qu’il existe une erreur. Un script chargé de surveiller l’appui sur une touche doit rester actif tant que l’utilisateur ne l’a pas pressée. En revanche, si l’élève pensait déclencher une étape automatiquement, il faut vérifier que le bloc qui produit l’événement est bien présent et qu’il s’exécute réellement.

Cette distinction entre « le programme attend volontairement » et « le programme attend une situation impossible » demande un accompagnement progressif. Nous pouvons aider l’élève à formuler la fin attendue en langage courant avant de toucher aux blocs: « Le personnage s’arrête quand… » La suite de la phrase révèle souvent la condition manquante ou mal reliée.

Déboguer un programme Scratch qui ne répond plus

Face à un blocage, la première réaction consiste parfois à retirer la boucle ou à fermer le projet. Cette réaction est compréhensible, mais elle prive l’élève d’une occasion de comprendre le mécanisme. Un débogage efficace commence par une observation limitée et organisée.

1. Identifier le script qui continue

Un projet Scratch peut contenir plusieurs scripts actifs en même temps, sur un même lutin ou sur des lutins différents. Si un personnage continue à bouger ou à parler, il faut d’abord repérer le script responsable.

Nous pouvons arrêter le projet, relancer l’exécution, puis observer quel script reproduit le comportement. Il est utile de tester les scripts séparément lorsque le projet est déjà complexe. Cette étape réduit la charge cognitive: au lieu de suivre tout le projet, l’élève travaille sur une seule chaîne d’instructions.

2. Lire la boucle comme une phrase

Une boucle doit pouvoir être reformulée oralement. Par exemple:

• « Répéter quatre fois: avancer puis tourner. »
• « Répéter jusqu’à ce que le compteur atteigne 10: augmenter le compteur. »
• « Répéter indéfiniment: si la touche droite est pressée, avancer. »

Si la phrase ne permet pas de dire ce qui provoque la fin, la structure mérite d’être examinée. Dans le cas d’une répétition conditionnelle, nous devons ensuite préciser la condition: quelle valeur est observée? Quand peut-elle changer? Qui la modifie?

3. Suivre une variable avec un affichage

Pour une activité de programmation au collège, afficher une variable à l’écran est souvent plus efficace qu’une longue explication. L’élève voit immédiatement si le compteur reste à 0, augmente trop vite ou s’éloigne de la valeur recherchée.

Nous pouvons utiliser quelques valeurs simples pour reconstruire les premières itérations:

Cette petite trace d’exécution rend visible le moment où la boucle doit s’arrêter. Elle permet aussi de comparer le comportement attendu avec le comportement observé. Si la valeur ne change pas, nous cherchons le bloc de modification. Si elle saute la valeur recherchée, nous réexaminons la condition.

4. Ralentir l’exécution

Une boucle très rapide peut masquer son fonctionnement. Le programme effectue alors des centaines d’itérations en un instant, et l’élève ne perçoit pas ce qui se passe. Ajouter temporairement une courte attente dans la boucle permet de rendre les étapes observables.

Cette modification n’est pas toujours la correction définitive. Elle sert d’outil de diagnostic. Nous pouvons aussi faire dire au lutin la valeur de la variable ou modifier momentanément son costume à chaque passage. L’objectif est de transformer un comportement opaque en suite d’indices interprétables.

5. Vérifier les blocs placés après la boucle

Lorsqu’une boucle infinie se trouve dans un script, les blocs placés ensuite ne sont pas exécutés tant que la boucle continue. Un élève peut donc croire que le bloc « dire “Bravo!” » ne fonctionne pas, alors que le programme ne l’atteint simplement jamais.

La question à poser est alors: « Le script a-t-il une sortie normale? » Avec « répéter ( ) fois », la suite du script est atteinte après le nombre prévu de passages. Avec « répéter jusqu’à ce que (condition) », elle est atteinte lorsque la condition devient vraie. Avec « répéter indéfiniment », aucune sortie normale n’est prévue.

Pour corriger une boucle infinie, nous ne cherchons pas seulement à faire cesser le mouvement: nous reconstruisons le chemin logique qui doit conduire le programme jusqu’à l’étape suivante.

Remplacer la boucle infinie par la bonne structure

La correction dépend de l’intention initiale. Il ne s’agit pas de supprimer systématiquement le bloc de répétition, mais de choisir une structure qui exprime correctement la règle du projet.

Utiliser « répéter ( ) fois » pour une quantité connue

Lorsque le nombre de répétitions est déterminé à l’avance, le bloc à privilégier est « répéter ( ) fois ». C’est le cas pour:

• tracer les côtés d’une figure géométrique;
• répéter une animation un nombre défini de fois;
• faire avancer un personnage par étapes comptées;
• produire une suite de valeurs dont la longueur est connue;
• exécuter une consigne exactement cinq ou dix fois.

Pour tracer un triangle équilatéral, nous répétons trois fois la même construction: avancer, puis tourner de 120 degrés. La boucle traduit directement la propriété de la figure. Cette approche est souvent plus claire que la création d’une variable compteur, car elle limite le nombre d’éléments à surveiller.

Elle convient moins bien lorsque la fin dépend d’un événement imprévisible. Si le personnage doit avancer jusqu’à rencontrer un obstacle, le nombre de pas n’est pas forcément connu au départ.

Utiliser « répéter jusqu’à ce que » pour une cible évolutive

Lorsque la fin dépend d’une situation à atteindre, la boucle conditionnelle est plus adaptée. Nous pouvons alors vérifier trois éléments:

1. la condition correspond-elle bien à l’objectif?

2. une valeur observée évolue-t-elle à chaque passage?

3. cette évolution rapproche-t-elle effectivement le programme de la condition vraie?

Pour un déplacement horizontal, le programme peut répéter « avancer de 5 » jusqu’à ce que la position du lutin soit supérieure à une certaine valeur. Pour un jeu de questions, il peut répéter une demande jusqu’à ce que la réponse soit correcte. Pour une construction géométrique, il peut poursuivre une série d’actions jusqu’à atteindre un nombre de points défini.

La boucle conditionnelle demande davantage d’anticipation. Elle est donc intéressante après une première manipulation des répétitions, lorsque l’élève peut déjà distinguer une quantité fixe d’une condition d’arrêt.

Conserver « répéter indéfiniment » pour une surveillance continue

Dans un programme interactif, nous devons parfois conserver la boucle infinie. Elle devient alors le cadre permanent du projet. Pour la rendre utile et éviter l’impression de blocage, nous pouvons y organiser des tests:

• si la touche gauche est pressée, déplacer le lutin vers la gauche;
• si la touche droite est pressée, le déplacer vers la droite;
• si le lutin touche un obstacle, modifier le score;
• si le temps est écoulé, envoyer un message de fin.

Dans une telle structure, le programme ne s’arrête pas parce qu’un compteur atteint une valeur, mais parce que l’utilisateur met fin au projet ou qu’un autre mécanisme d’arrêt est exécuté. Il faut donc distinguer la durée de vie du script et la durée d’une action particulière. Une action peut être limitée dans le temps à l’intérieur d’un script qui, lui, reste actif.

Comparer deux corrections fréquentes

Prenons un programme qui fait avancer un lutin jusqu’au bord de la scène. Deux solutions sont possibles, mais elles ne construisent pas exactement le même apprentissage.

La première approche est souvent plus rassurante pour un débutant. La seconde permet de consolider une pensée algorithmique plus générale, car elle apprend à décrire une fin par une propriété du système plutôt que par un nombre d’actions fixé à l’avance.

Nous pouvons donc commencer par une répétition comptée, puis proposer une variante conditionnelle. Ce passage progressif étaye la compréhension: l’élève ne découvre pas simultanément le déplacement, la variable, la condition et le débogage.

Le rôle et les limites du bloc « arrêter ce script »

Le bloc « arrêter [ce script] » peut être utile lorsque nous voulons interrompre explicitement une exécution. Il ne faut cependant pas lui attribuer un pouvoir qu’il n’a pas: il arrête uniquement le script auquel il est attaché. Les autres scripts du même lutin ou ceux des autres lutins peuvent continuer.

Cette limite devient importante dans les projets comportant plusieurs mécanismes parallèles. Un jeu peut avoir:

• un script qui déplace le personnage;
• un script qui surveille les collisions;
• un script qui actualise le score;
• un script qui joue une musique;
• un script qui affiche les messages.

Si nous arrêtons seulement le script du déplacement, le score ou la musique peuvent continuer. Le projet n’est donc pas entièrement arrêté, même si une partie de l’écran semble figée.

Quand utiliser un bloc d’arrêt?

Ce bloc peut convenir dans une situation où un script doit cesser dès qu’un événement précis survient. Par exemple, un script consacré à une animation peut s’arrêter lorsqu’un lutin touche la ligne d’arrivée. Mais si le projet doit revenir à un état final cohérent, il faut penser à l’ensemble des scripts concernés.

Nous pouvons envoyer un message de fin et prévoir, dans chaque script actif, une réaction à ce message. Cette organisation demande davantage de blocs, mais elle permet de distinguer deux notions:

• arrêter une tâche particulière;
• terminer le fonctionnement global du projet.

Cette différence est particulièrement formatrice. Elle aide l’élève à comprendre qu’un programme peut être constitué de plusieurs processus qui s’exécutent en parallèle.

Pourquoi l’arrêt forcé ne remplace pas une bonne condition

Employer un bloc d’arrêt pour masquer une boucle mal conçue ne résout pas toujours le problème. L’élève peut obtenir un projet qui « s’arrête », sans comprendre pourquoi la boucle ne se terminait pas. Nous risquons alors de consolider une stratégie de réparation superficielle: ajouter un arrêt dès que le comportement devient gênant.

Il est plus constructif de demander d’abord ce que la boucle devait accomplir. Si elle devait compter jusqu’à une valeur, il faut construire l’évolution du compteur. Si elle devait attendre un événement, il faut vérifier l’existence de cet événement. Si elle devait surveiller une touche pendant tout le jeu, la boucle infinie est probablement adaptée et ne doit pas être supprimée.

Construire une progression pour apprendre les boucles

La difficulté d’une boucle infinie ne vient pas uniquement de la syntaxe des blocs. Elle repose sur plusieurs idées qui doivent être coordonnées: répétition, état, condition, évolution et fin. Lorsque ces notions sont introduites en même temps, la charge cognitive peut devenir importante.

Nous pouvons bâtir une progression en plusieurs étapes.

Commencer par une répétition visible

Une première activité peut consister à tracer une figure régulière. L’élève observe immédiatement le résultat et peut compter les répétitions. La boucle « répéter ( ) fois » permet de consolider le lien entre une instruction répétée et une quantité précise.

Introduire ensuite le compteur

Nous pouvons remplacer progressivement le nombre inscrit dans la boucle par une variable visible. L’élève découvre alors que le programme possède un état qui se transforme. Cette manipulation prépare le travail sur les conditions d’arrêt.

Faire varier une seule chose à la fois

Pour comprendre une boucle conditionnelle, il est préférable de limiter les changements simultanés. Si nous modifions à la fois la position du lutin, la valeur du compteur, la condition et l’apparence, il devient difficile de savoir quel élément explique le résultat.

Une activité efficace peut demander de prédire les cinq premières valeurs d’une variable avant de lancer le programme. Le décalage entre la prédiction et l’observation devient alors un support de discussion, plutôt qu’un simple constat d’échec.

Utiliser un matériel tangible

Les cartes, les jetons ou les cases dessinées sur une feuille peuvent aider à représenter l’évolution d’une boucle. Un jeton avance d’une case à chaque tour; une carte indique la condition d’arrêt. Si le jeton ne bouge pas, nous voyons immédiatement pourquoi la condition ne peut pas changer.

Cette manipulation n’est pas une simplification destinée uniquement aux élèves en difficulté. Elle permet de construire un ancrage concret avant de revenir aux blocs abstraits. Nous pouvons ensuite demander à l’élève de traduire chaque étape manipulée dans Scratch.

Faire verbaliser la fin avant le code

Avant de choisir un bloc, formulons la consigne en langage courant:

• « Je répète exactement six fois. »
• « Je continue jusqu’à ce que le personnage touche le bord. »
• « Je surveille cette touche pendant tout le jeu. »

Ces trois phrases correspondent à trois structures différentes. La verbalisation aide à choisir le bloc en fonction du problème, plutôt qu’en fonction de sa forme ou de sa position dans la catégorie « Contrôle ».

Les erreurs typiques à observer dans un projet d’élève

Lors d’un débogage, certaines erreurs reviennent sous des formes variées. Elles méritent d’être distinguées, car elles n’appellent pas la même correction.

1. La variable n’est jamais initialisée.

Le programme utilise une ancienne valeur conservée dans le projet. Le résultat peut alors changer d’un lancement à l’autre. Réinitialiser la variable au début du script permet de rendre le comportement prévisible.

2. La variable est initialisée, mais jamais modifiée.

La condition observe toujours le même état. Il faut identifier l’instruction qui doit faire progresser le compteur, la position ou le score.

3. La variable est modifiée dans un autre script.

Cette organisation peut être volontaire, mais elle rend le raisonnement plus difficile. Si l’autre script ne se lance pas ou ne modifie pas la bonne variable, la boucle attend indéfiniment.

4. La condition teste la mauvaise variable.

Le programme fait évoluer « score », tandis que la boucle vérifie « points ». Les noms proches peuvent masquer cette confusion.

5. La valeur recherchée est sautée.

Une variable augmentée de 2 ne prendra pas toutes les valeurs entières. Une condition d’égalité peut donc rester fausse alors que la variable progresse.

6. La boucle infinie a été choisie pour une tâche finie.

Le programme devait dessiner une figure ou répéter une action cinq fois. Le remplacement par « répéter ( ) fois » rend la consigne explicite.

7. Les blocs suivants sont attendus alors qu’ils sont inaccessibles.

Ils sont placés après « répéter indéfiniment ». Il faut modifier la structure ou déplacer l’action dans un autre script.

8. Un seul script est arrêté alors que le projet en contient plusieurs.

Le bloc « arrêter ce script » ne suffit pas à interrompre les autres activités en cours.

Cette liste n’est pas destinée à transformer le débogage en procédure mécanique. Elle sert plutôt de support pour guider les questions. Nous aidons l’élève à reconstruire le fonctionnement du programme, au lieu de lui fournir immédiatement le bloc à remplacer.

Une méthode simple pour corriger une boucle infinie dans Scratch

Lorsque le projet ne répond plus, nous pouvons suivre cet ordre d’action:

1. Arrêter puis relancer le projet pour vérifier si le comportement se reproduit.

2. Repérer le lutin et le script concernés, sans modifier tout le projet à la fois.

3. Entourer mentalement la boucle et lire uniquement les blocs qu’elle contient.

4. Nommer la condition de fin: compteur, position, réponse, touche, collision ou message.

5. Observer ce qui change à chaque passage.

6. Vérifier que cette évolution peut rendre la condition vraie.

7. Choisir la structure adaptée: nombre de répétitions fixé, condition évolutive ou surveillance continue.

8. Tester avec des valeurs simples, puis relancer le projet.

9. Vérifier les blocs placés après la boucle.

10. Examiner les autres scripts si le projet semble encore fonctionner après l’arrêt d’un premier script.

Cette démarche donne une place centrale au raisonnement. Elle évite de présenter le débogage comme une chasse au bloc mal placé. Une erreur de boucle est souvent une erreur de modèle: le programme ne représente pas encore correctement la manière dont l’action doit progresser vers sa fin.

Ce que l’élève doit retenir

Une boucle infinie dans Scratch correspond à une répétition qui ne rencontre jamais de fin effective. Avec « répéter indéfiniment », cette absence de fin est intégrée à la structure et peut être parfaitement volontaire. Avec « répéter jusqu’à ce que », elle devient généralement un problème lorsque la condition reste toujours fausse.

Pour corriger l’erreur, nous devons donc poser trois questions:

• Qu’est-ce que la boucle doit répéter?
• Qu’est-ce qui doit changer à chaque passage?
• Quel événement ou quelle valeur indique que le travail est terminé?

Si le nombre d’actions est connu, « répéter ( ) fois » sera souvent le choix le plus lisible. Si la fin dépend d’un état qui évolue, « répéter jusqu’à ce que » permettra de décrire la cible. Si le programme doit surveiller une interaction pendant toute son exécution, « répéter indéfiniment » reste approprié.

La meilleure correction n’est pas toujours celle qui fait disparaître immédiatement le blocage. C’est celle qui rend le programme compréhensible pour celui qui l’a construit. En associant observation, verbalisation, trace des variables et manipulation concrète, nous aidons l’élève à bâtir une représentation solide de la répétition. Les blocs cessent alors d’être des pièces à assembler au hasard: ils deviennent les éléments d’une méthode que l’on peut expliquer, tester et consolider.