Boucle répéter indéfiniment sur Scratch : principes et fonctionnement

Boucle « répéter indéfiniment » sur Scratch: principes et fonctionnement

Et c'est aussi, dans la plupart des évaluations, le bloc dont le manque de compréhension coûte le plus de points. Pourquoi? Parce qu'il ne s'arrête jamais tout seul. Si tu ne maîtrises pas ce principe, ton projet tournera en boucle sans que tu saches pourquoi, et ton correcteur le verra immédiatement.

Repérer le bloc dans la palette Contrôle

Le bloc « répéter indéfiniment » se trouve dans la catégorie Contrôle, identifiable à sa couleur orange. Visuellement, il se présente sous la forme d'un « C » allongé, ouvert vers le bas, sans chiffre ni losange à l'intérieur. Cette absence d'information est volontaire: tu n'as rien à paramétrer au départ. Tu prends le bloc, tu le places sous ton événement déclencheur (le drapeau vert, un message, un clic), puis tu glisses à l'intérieur toutes les instructions qui doivent se répéter sans interruption.

Pour bien le distinguer des autres boucles de la même catégorie, observe trois détails:

• Le bloc « répéter (10) fois » porte un champ numérique éditable. Tu connais le nombre de répétitions à l'avance.
• Le bloc « répéter jusqu'à ce que <...> » contient une condition en forme de losange. La boucle s'arrête dès que la condition devient vraie.
• Le bloc « répéter indéfiniment » ne contient ni nombre, ni condition. Sa forme seule te dit: « je ne m'arrête pas tout seul ».

Cette distinction est capitale à l'écrit. Si tu rédiges un compte-rendu de projet, la formulation « j'ai utilisé une boucle » est insuffisante — ton correcteur cherche la précision. La phrase qui rapporte les points est: « j'ai placé mes instructions dans le bloc 'répéter indéfiniment' de la catégorie Contrôle, sans condition d'arrêt interne ». Sur ton brouillon, note aussi la position du bloc par rapport à l'événement qui le déclenche: un bloc mal placé sous deux déclencheurs différents peut lancer deux exécutions parallèles, et c'est souvent la source des « mon lutin bouge deux fois trop vite ».

Une boucle « répéter indéfiniment » n'a pas de compteur: ce qui la stoppe doit venir de l'extérieur, jamais du bloc lui-même.

Comprendre pourquoi la boucle ne s'arrête jamais seule

Une fois lancée, la boucle exécute en continu la séquence d'instructions qu'elle contient. À chaque tour, le lutin parcourt ton programme de haut en bas, puis remonte au début, indéfiniment. Aucune variable interne ne vient compter les passages, aucun test ne vérifie si une limite est atteinte. Le bloc, par construction, ignore quand il doit s'arrêter.

La démonstration la plus parlante tient en une seule instruction: place « avancer de 10 » à l'intérieur de la boucle, sans rien d'autre. Ton lutin traversera la scène, sortira par la droite, et continuera son déplacement hors du cadre. La boucle ne sait pas qu'elle a « fini ». Elle continue tant que le programme n'est pas stoppé.

Trois leviers seulement permettent d'interrompre l'exécution:

1. Le bouton Arrêt rouge, situé près du drapeau vert — c'est une action externe, elle ne fait pas partie de ton script.

2. Un bloc « stop (tout) » ou « stop (ce script) » que tu as placé toi-même dans une condition — c'est une décision programmée.

3. Un événement déclencheur prévu dans le projet (touche pressée, message reçu, collision détectée) qui lance un autre script chargé d'arrêter le premier.

Ton correcteur portera une attention particulière au troisième point. Un projet qui ne propose aucune façon propre de quitter la boucle est un projet incomplet. Tu dois penser l'arrêt comme une partie intégrante du programme, pas comme un détail ajouté à la fin. Sur ta feuille de brouillon, trace l'organigramme de chaque lutin: qui lance la boucle, qui la quitte, et par quel moyen. Cette cartographie faite à la main révèle souvent, avant même le premier test, les boucles qui n'ont aucune sortie prévue.

Coupler la boucle à des conditions pour réagir en temps réel

Une boucle qui ne s'arrête pas ne sert pas qu'à dessiner ou à déplacer. Sa vraie puissance apparaît quand tu l'associes à des structures conditionnelles (« si... alors ») ou à des capteurs. C'est ce couplage qui transforme un programme figé en application interactive.

L'architecture classique tient en trois lignes mentales:

• La boucle vérifie en permanence une situation (touche pressée, contact avec un autre lutin, position du pointeur).
• La condition « si... alors » traduit cette vérification en action ciblée.
• L'instruction à l'intérieur du « alors » modifie l'état du lutin (déplacement, score, costume, message).

Prenons l'exemple d'un lutin qui doit suivre la souris. Sans boucle, ton lutin resterait immobile après la première vérification. Avec « répéter indéfiniment » contenant « aller à pointeur de souris », tu obtiens un déplacement fluide et permanent. Ajoute un « si <touche espace pressée?> alors » à l'intérieur, et tu gagnes une commande de saut. Tout ton script tient dans une boucle unique qui orchestre deux comportements distincts.

C'est ici que la rigueur de rédaction prend tout son sens. Lorsque tu présentes ton projet, tu dois pouvoir observer, sur ton brouillon, l'ordre d'exécution de chaque bloc. Quel test passe en premier? Quelle action en découle? Cette cartographie vaut autant que le code lui-même: elle prouve que tu as pensé le programme avant de l'écrire. Une vérification visuelle rapide consiste à suivre le liseré jaune de l'exécution: il doit balayer toute la boucle, du début à la fin, sans repasser inutilement. L'erreur classique que les correcteurs repèrent en deux secondes, c'est la condition « si » placée à l'extérieur de la boucle: elle n'est alors testée qu'une seule fois, et ton « jeu » ne réagit plus après le premier tour.

Trois cas d'usage typiques au collège

En classe, les projets autour de cette boucle tournent autour de trois familles d'exercices. Voici celles que tu rencontres le plus souvent, et ce que ton correcteur cherche à valider dans chacune.

1. Animer un lutin en continu — faire rebondir un lutin sur les bords, alterner deux costumes pour simuler la marche, créer un déplacement automatique. La notation porte sur la présence effective de la boucle et sur la variation visible du comportement. Un lutin figé malgré la boucle te coûte des points.

2. Attendre un événement déclencheur — un lutin qui attend qu'on appuie sur la touche espace pour sauter, un second qui se déclenche quand le score atteint 10. Ici, le correcteur vérifie que ta boucle contient bien la condition d'attente, et que tu n'as pas placé l'action en dehors de la boucle, ce qui la rendrait inactive après un seul tour.

3. Actualiser une variable en temps réel — un score qui s'incrémente quand on touche un obstacle, un chronomètre qui s'affiche en permanence, un compteur de vies. La boucle est obligatoire pour que la mise à jour soit continue; sans elle, ta variable resterait figée à sa valeur initiale.

Ce qui distingue un bon projet Scratch d'un projet moyen, ce n'est pas la complexité du code: c'est la présence systématique d'une boucle autour des actions qui doivent se répéter, et d'une condition de sortie autour de celles qui doivent s'arrêter.

Comparer les méthodes pour sortir proprement de la boucle

Un projet interactif n'est jamais une boucle lancée sans fin. Tu dois prévoir, dès le brouillon, comment l'utilisateur arrête le programme, et comment chaque lutin termine son rôle. Le tableau ci-dessous compare les cinq méthodes que tu peux mobiliser dans un projet de collège.

Le choix dépend de la structure de ton projet. Si tu codes un mini-jeu à un seul lutin, le bloc « stop (ce script) » suffit souvent. Si tu coordonnes trois lutins (un joueur, un obstacle, un compteur), mieux vaut une variable partagée: chaque lutin teste en boucle si la partie est terminée. Concrètement, tu crées une variable « partie_en_cours » initialisée à 1 dans chaque lutin, et un événement (collision finale, score atteint) qui la fait passer à 0. Tous les scripts en « répéter indéfiniment » commencent alors par « si <partie_en_cours = 0> alors stop (ce script) ». Cette seconde méthode est plus exigeante à écrire, mais c'est celle qui rapporte le plus de points dans un projet évalué, parce qu'elle prouve que tu sais orchestrer plusieurs scripts en parallèle.

Trois réflexes à adopter avant de rendre ton projet:

• Observe visuellement chaque boucle: elle doit contenir, directement ou via une condition, un chemin vers l'arrêt.
• Trace sur ton brouillon le diagramme de tes lutins: qui lance quoi, qui arrête quoi, par quel bloc.
• Teste toi-même en cliquant sur le bouton Arrêt rouge, situé près du drapeau vert, puis en relâchant: ton programme doit répondre instantanément, sans lutin figé ni variable bloquée.

Le détail de rédaction qui rapporte les points

Au moment de présenter ton projet, le correcteur ne lit pas seulement ton code: il lit la justification que tu en donnes. Trois formulations, à elles seules, différencient une copie moyenne d'une copie qui obtient tous les points. Première formulation: « j'ai choisi la boucle 'répéter indéfiniment' parce que mon lutin doit réagir en continu, sans nombre de tours fixé à l'avance ». Deuxième formulation: « j'ai ajouté une condition 'si <score = 10> alors stop (ce script)' pour que la partie se termine proprement ». Troisième formulation: « j'ai testé trois scénarios d'arrêt — victoire, défaite, sortie manuelle — pour vérifier que la boucle se ferme dans tous les cas ».

Ces trois phrases prouvent que tu comprends le bloc, que tu maîtrises son mécanisme, et que tu as pensé l'arrêt comme une partie du programme. Sur la grille de notation, ce sont elles qui font la différence entre un projet fonctionnel et un projet réellement maîtrisé. Trace-les sur ton brouillon avant la rédaction finale: tu gagneras du temps et tu éviteras les formulations floues que le correcteur sanctionne. Et garde en tête qu'un projet sans sortie propre n'est pas un projet « presque fini » — c'est un projet à moitié noté, quel que soit le soin apporté au reste.