Aquarium de Nouvelle-Angleterre visite : bug Scratch à corriger

Aquarium de Nouvelle-Angleterre visite: bug Scratch à corriger

Les variables sont posées, les conditions semblent cohérentes, les lutins sont en place, et pourtant le scénario ne se déroule pas comme prévu. Le chronomètre cesse d’avancer, le tarif affiche une valeur inattendue, la tortue reste immobile au fond du bassin ou la dernière étape de la visite disparaît.

Ce n’est pas une question de paresse ni d’attention distraite. Il s’agit généralement d’une erreur de construction logique, typique des premières rencontres avec la gestion d’état dans un programme. L’élève doit comprendre quelle donnée entre dans le script, sous quelle forme elle est stockée, à quel moment elle est modifiée et dans quelle condition elle cesse de l’être. L’Aquarium de Nouvelle-Angleterre, à Boston, fournit un terrain particulièrement riche pour travailler ces notions sans réduire l’algorithmique à une suite de blocs abstraits.

Le contexte réel aide aussi à poser de bonnes questions. Une adresse est-elle une donnée numérique ou textuelle? Une durée exprimée en heures peut-elle être utilisée directement dans un chronomètre? Un âge saisi au clavier est-il déjà un nombre exploitable? Une donnée historique doit-elle continuer à changer pendant l’exécution du programme? Chaque réponse conduit à une notion de programmation précise.

Logistique et accès au 1 Central Wharf: stabiliser les données d’entrée

La première étape d’un programme Scratch qui modélise une sortie scolaire ou familiale consiste à stabiliser les données d’entrée. Pour l’Aquarium de Nouvelle-Angleterre, ces données sont suffisamment concrètes pour que l’élève puisse les manipuler sans les inventer: l’adresse, la durée indicative de la visite, le jour choisi, le nombre de visiteurs ou encore le type de billet.

L’établissement se trouve au 1 Central Wharf, à Boston, dans le Massachusetts, sur le front de mer du quartier historique de Downtown. Dans Scratch, cette adresse doit être traitée comme une chaîne de caractères. Elle peut être enregistrée dans une variable appelée ADRESSE_AQUARIUM, initialisée au début du programme. Le nom n’a pas besoin d’être spectaculaire: il doit surtout permettre de comprendre immédiatement ce que contient la variable.

Cette distinction entre texte et nombre est une première occasion de faire réfléchir la classe. On peut additionner un nombre de visiteurs, comparer un âge ou calculer un prix. En revanche, on ne « calcule » pas une adresse. Elle peut être affichée, comparée à une autre adresse ou transmise à un lutin, mais elle ne se manipule pas comme une quantité. Le fait que l’adresse contienne des chiffres ne la transforme pas pour autant en donnée numérique.

La durée indicative d’une visite est d’environ deux heures. Pour un parcours simple, il est préférable de convertir cette durée en minutes: 120. Si le programme doit animer une jauge ou un chronomètre plus fin, cette même durée peut être exprimée en secondes: 7 200. Le choix de l’unité doit être fait avant de construire la boucle. Sinon, l’élève risque de créer un programme dans lequel une variable est en heures, une autre en minutes et une troisième en secondes, avec des résultats difficiles à interpréter.

Cette conversion fournit un exercice algorithmique collège très efficace:

• demander la durée prévue en heures;
• la multiplier par 60 pour obtenir des minutes;
• afficher la durée convertie;
• utiliser cette valeur pour organiser les étapes de la visite;
• vérifier que le résultat reste cohérent lorsque l’utilisateur saisit une autre durée.

Le programme peut également introduire une variable JOUR_VISITE. Si l’utilisateur saisit samedi ou dimanche, le script peut afficher un message indiquant que les temps d’attente doivent être pris en compte dans la planification. Il ne s’agit pas de prétendre calculer une fréquentation exacte: l’objectif est de faire comprendre qu’une donnée de contexte peut modifier le parcours ou la durée disponible.

L’Aquarium de Nouvelle-Angleterre accueille plus de 1,3 million de visiteurs par an. Cette donnée documentaire peut servir d’ancrage, mais elle ne doit pas être transformée abusivement en prévision précise pour une journée donnée. L’élève peut l’utiliser pour comprendre pourquoi la variable TEMPS_ATTENTE existe dans le modèle, pas pour déduire automatiquement le nombre de personnes présentes un samedi précis.

Une donnée bien nommée et placée au début du programme n’a pas besoin d’être recopiée dans chaque branche: c’est toute l’architecture du script qui s’en trouve allégée.

Cette règle paraît élémentaire, mais elle prépare déjà la modularité. Si l’adresse ou la durée apparaît dans plusieurs dizaines de blocs, la moindre modification devient pénible. Si elle est centralisée dans une variable, le programme gagne en lisibilité et l’élève commence à distinguer la donnée de son utilisation.

Une vérification simple peut être ajoutée avant le lancement de la simulation. Le script affiche les valeurs retenues: adresse, durée, jour et nombre de visiteurs. Cette étape n’est pas décorative. Elle permet de repérer immédiatement une variable vide, une unité mal choisie ou une réponse qui n’a pas été enregistrée au bon endroit. Dans un programme plus long, cette petite phase d’initialisation évite de chercher une erreur dans les animations alors que le problème se trouve dans les données de départ.

Le Giant Ocean Tank: modéliser les flux marins en boucle

Le Giant Ocean Tank constitue le centre visuel de l’aquarium. Il s’agit d’un bassin cylindrique de 200 000 gallons, soit environ 760 000 litres d’eau de mer, qui recrée un environnement inspiré des récifs coralliens des Caraïbes. Dans un projet Scratch, ce bassin peut devenir un décor, une toile de fond ou le cadre d’une simulation de déplacement.

Le volume du bassin peut être enregistré dans une variable telle que VOLUME_BASSIN, mais il ne faut pas confondre la donnée documentaire et le mouvement des lutins. Le nombre de litres ne dit pas directement comment un poisson doit se déplacer à l’écran. Pour cela, il faut définir des coordonnées, une vitesse et une condition d’arrêt. C’est précisément à cet endroit que la notion de boucle devient concrète.

Imaginons qu’un élève souhaite simuler la remontée d’un plongeur. Il crée un lutin PLONGEUR, place sa coordonnée verticale à -200, puis construit une boucle qui doit s’arrêter lorsque le lutin atteint le haut de la zone de jeu. La condition peut s’appuyer sur la coordonnée y, mais elle ne suffit pas à elle seule. À chaque répétition, le programme doit modifier cette coordonnée.

La logique attendue est la suivante:

1. placer le lutin à sa position de départ;

2. vérifier s’il a atteint la limite prévue;

3. le déplacer de quelques unités vers le haut;

4. attendre éventuellement un court instant pour rendre le mouvement visible;

5. recommencer jusqu’à ce que la condition d’arrêt soit vraie.

Le bug le plus fréquent apparaît lorsque l’élève écrit une condition correcte, mais oublie l’instruction qui la rend progressivement vraie. Si la coordonnée y reste à -200, la boucle ne peut jamais atteindre la valeur recherchée. Scratch répète alors le même état indéfiniment. Le programme ne « réfléchit » pas à la manière de sortir de la boucle: il applique exactement les instructions reçues.

Pour aider l’élève à diagnostiquer ce problème, il est utile de lui faire observer la variable y pendant l’exécution. Si sa valeur ne change pas, le problème se trouve dans le corps de la boucle. Si elle augmente mais dépasse rapidement la zone de jeu, la vitesse ou la condition d’arrêt doivent être ajustées. Le débogage devient alors une lecture de l’état du programme, et non une recherche au hasard du bloc prétendument responsable.

La même logique peut servir à représenter un flux de visiteurs. Un lutin avance d’une zone à l’autre, tandis qu’une variable NOMBRE_PRESENTS est modifiée lorsque quelqu’un entre ou sort. Le programme doit alors distinguer le déplacement visuel de la mise à jour des données. Faire avancer un personnage à l’écran ne diminue pas automatiquement le nombre de visiteurs dans une zone: cette modification doit être écrite dans le script.

On peut ensuite comparer plusieurs modèles. Le premier utilise un seul lutin et une boucle de déplacement. Il convient à une simulation simple et rend la répétition très visible. Le second fait appel aux clones pour créer plusieurs poissons qui se déplacent selon des trajectoires différentes. Cette approche permet d’aborder la création d’agents, la répétition parallèle et la suppression des clones à la fin de l’animation.

Les trois modèles peuvent produire une animation satisfaisante, mais ils ne racontent pas la même histoire algorithmique. Une boucle unique met l’accent sur la progression d’un objet. Les clones font apparaître plusieurs comportements simultanés. Une liste permet de séparer les positions de la logique de déplacement. Faire comparer ces solutions vaut mieux que demander à l’élève de recopier un script présenté comme unique.

Une activité intéressante consiste à volontairement retirer la mise à jour d’une variable, puis à demander aux élèves de décrire ce qui reste stable. Le lutin, la coordonnée et la condition sont alors observés comme trois éléments liés. Le bug n’est plus seulement une faute à corriger: il devient la preuve qu’une boucle a besoin d’un état qui évolue.

Gestion des tarifs et réservations: variables et conditions dans Scratch

La gestion des billets est le point où les erreurs de données deviennent les plus visibles. Dans l’exercice, on peut utiliser comme valeurs de travail 39,95 dollars pour un adulte de 12 ans ou plus et 30,95 dollars pour un enfant de 3 à 11 ans. Comme les tarifs d’un établissement peuvent évoluer, il faut présenter ces montants comme les données de la version étudiée et rappeler qu’une activité fondée sur une réservation réelle doit être vérifiée avant utilisation.

Le programme doit d’abord recueillir l’âge, puis décider de la catégorie de billet. L’erreur fréquente consiste à croire que le bloc « demander et attendre » fournit directement une variable numérique. Dans Scratch, la réponse saisie par l’utilisateur est accessible dans le bloc rapporteur réponse et doit être considérée comme une entrée à contrôler. Une saisie composée de chiffres peut être interprétée comme une valeur numérique par les opérateurs de comparaison. Le problème n’est donc pas qu’une comparaison comme âge < 12 échouerait systématiquement et appliquerait silencieusement le tarif adulte à un enfant.

La difficulté réelle est double. D’une part, l’élève peut comparer directement réponse sans avoir stocké cette entrée dans une variable clairement nommée. D’autre part, il peut ne prévoir aucun traitement pour une saisie vide, un mot ou un nombre décimal inattendu. Pour rendre le comportement numérique explicite, on peut affecter à âge le résultat de réponse + 0. L’opération force Scratch à traiter une réponse numérique comme une quantité. Elle ne dispense pas de vérifier la saisie: une réponse non numérique doit être refusée ou signalée, plutôt que convertie sans explication en valeur inutilisable.

Une démarche robuste peut suivre cette progression:

1. poser la question sur l’âge;

2. enregistrer la réponse dans âge en la convertissant par une opération arithmétique;

3. vérifier que la valeur obtenue correspond à une saisie acceptable;

4. utiliser la condition si âge < 12 pour distinguer l’enfant de l’adulte;

5. traiter séparément la limite de 12 ans;

6. calculer ensuite le coût total à partir du nombre de billets de chaque catégorie.

La limite doit être formulée avec précision. Si la règle de l’exercice indique que le tarif adulte commence à 12 ans, la condition âge < 12 attribue le tarif enfant aux âges de 3 à 11 ans et le tarif adulte à partir de 12 ans. Un élève qui écrit âge <= 12 ne crée pas une erreur de syntaxe, mais modifie la règle commerciale. Le débogage consiste donc aussi à vérifier les bornes, pas seulement la forme des blocs.

Le contrôle d’une saisie peut être organisé autour d’une boucle. Tant que l’âge est inférieur à 3 ou que la réponse n’est pas exploitable, le programme redemande une valeur. Cette extension permet d’introduire les opérateurs logiques sans détour artificiel. Elle rappelle surtout qu’un utilisateur ne se comporte pas toujours comme l’auteur du script l’avait imaginé.

Deux présentations restent possibles en classe. La première centralise les données et les calculs dans des variables simples. La seconde confie les questions et les messages à un lutin-caissier. Elles peuvent être comparées sans être confondues.

Aucune approche n’est supérieure dans tous les cas. Le lutin-caissier peut aider une classe à comprendre le déroulement d’une interaction. Les variables centralisées rendent plus lisibles la conversion et le calcul. Le meilleur exercice consiste souvent à faire produire une première version dialoguée, puis à demander aux élèves de déplacer les données importantes dans des variables mieux organisées.

Le calcul du coût total doit lui aussi être décomposé. On peut distinguer NOMBRE_ADULTES, NOMBRE_ENFANTS, TARIF_ADULTE et TARIF_ENFANT, puis utiliser une formule qui additionne les deux sous-totaux. Cette organisation évite de recopier plusieurs fois les montants dans les conditions et rend la modification des tarifs beaucoup plus simple.

Dans Scratch, une réponse saisie au clavier est une donnée à contrôler avant de devenir un âge, un prix ou une condition de programme.

Cette partie permet enfin de faire apparaître une erreur classique de variable Scratch: le même nom est utilisé successivement pour désigner une réponse, une catégorie de billet et un montant. Le programme peut alors rester exécutable tout en devenant difficile à comprendre. Séparer AGE_VISITEUR, TYPE_BILLET et PRIX_TOTAL ne rend pas le script plus compliqué; cela rend visibles les étapes du raisonnement.

Myrtle la tortue et les données historiques: intégrer des constantes dans vos scripts

L’Aquarium de Nouvelle-Angleterre a ouvert ses portes en 1969. Le Giant Ocean Tank a été inauguré en 1970 et Myrtle, une tortue verte devenue emblématique de l’établissement, y est présente depuis cette période. Ces informations historiques donnent une autre profondeur au projet: l’élève ne manipule plus seulement des données destinées à produire un résultat immédiat, il apprend à conserver une référence.

En Scratch, il n’existe pas de catégorie séparée appelée « constante » comme dans certains langages de programmation. On peut néanmoins adopter cette logique en créant une variable initialisée une seule fois et que les autres scripts ne doivent pas modifier. La convention de nommage devient alors particulièrement utile. Une variable comme ANNEE_OUVERTURE ou ANNEE_GIANT_OCEAN_TANK indique la nature de la donnée et son rôle dans le programme.

Le cas de Myrtle demande davantage de rigueur. Le fait qu’elle soit présente dans l’aquarium depuis juin 1970 ne permet pas de connaître son âge réel. Une durée de présence dans un établissement n’est pas une date de naissance et ne doit pas être transformée en âge biologique. C’est précisément le genre de glissement factuel qu’un exercice algorithmique peut rendre très visible: un calcul juste à partir d’une mauvaise donnée produit tout de même une conclusion fausse.

Pour une activité réalisée au 15 août 2026, le script peut calculer ou afficher 56 ans de présence depuis juin 1970. Cette valeur décrit une durée de présence dans l’aquarium, pas l’âge de Myrtle. Elle peut être stockée dans une variable appelée DUREE_PRESENCE_MYRTLE, afin que son sens reste explicite. Le nom AGE_MYRTLE serait trompeur, sauf si l’exercice indique clairement qu’il s’agit d’une valeur fictive choisie pour la simulation et non d’une information réelle sur l’animal.

Une formulation pédagogique peut donc distinguer trois éléments:

• ANNEE_DEBUT_PRESENCE = 1970, qui sert de référence historique;
• MOIS_DEBUT_PRESENCE = juin, qui précise le point de départ de la durée;
• DUREE_PRESENCE_MYRTLE = 56 pour une simulation arrêtée au 15 août 2026.

Le troisième élément n’est valable que pour cette date de référence. Si le programme est utilisé plus tard, la durée doit être recalculée ou présentée comme une valeur d’exercice datée. En revanche, aucun de ces éléments ne donne l’âge réel de la tortue. Pour éviter toute ambiguïté, le lutin peut afficher un message indiquant que le programme calcule une durée de présence dans l’aquarium.

On peut demander aux élèves de comparer deux versions du même script. Dans la première, une variable AGE_MYRTLE contient 56 et le lutin annonce l’âge de l’animal. Dans la seconde, la variable DUREE_PRESENCE_MYRTLE contient 56 et le lutin parle de sa présence depuis juin 1970. Les blocs peuvent être presque identiques, mais le sens des résultats est radicalement différent. L’exercice montre que le nom d’une variable et la formulation d’un résultat font partie de la correction algorithmique.

Cette situation permet aussi de différencier les constantes des variables qui évoluent:

• ANNEE_OUVERTURE ne change pas dans le cadre du projet historique;
• ANNEE_DEBUT_PRESENCE reste une référence fixe;
• DUREE_PRESENCE_MYRTLE dépend de la date à laquelle le programme est exécuté;
• TARIF_ADULTE peut changer selon la politique de billetterie et doit donc être isolé comme une donnée modifiable.

Le mot « variable » décrit le mécanisme de Scratch, mais pas nécessairement le comportement réel de la donnée. Une variable peut contenir une valeur que le programme ne modifie jamais. À l’inverse, une donnée historique peut devenir le point de départ d’un calcul qui évolue avec la date. Cette nuance donne une occasion concrète de parler de constantes, de paramètres et de valeurs calculées sans sortir du niveau collège.

Optimisation du parcours de visite: structurer une séquence pédagogique

Une visite simulée devient réellement intéressante lorsque les étapes ne sont plus une simple succession de décors. L’élève doit choisir ce qui doit être initialisé une fois, ce qui doit être calculé, ce qui doit être répété et ce qui doit déclencher la fin du programme.

Une séquence peut commencer par l’accueil, poursuivre avec la vérification des billets, organiser le déplacement vers le Giant Ocean Tank, puis proposer une étape consacrée à Myrtle. Chaque zone correspond à un état du programme. Une variable ETAPE_VISITE peut prendre des valeurs différentes, ou bien chaque lutin peut recevoir un message spécifique pour déclencher la séquence suivante.

La première erreur à éviter est de mélanger les événements. Si le script du billet lance directement l’animation du bassin, puis qu’un autre script modifie en même temps la durée de visite, le résultat devient difficile à prévoir. Il faut décider quel événement commande le passage à l’étape suivante. Un message diffusé dans Scratch peut jouer ce rôle: la validation du billet déclenche l’arrivée dans la zone suivante, et la fin de l’animation autorise le passage au commentaire historique.

Une structure simple peut reposer sur les variables suivantes:

Ce tableau n’a pas vocation à remplacer le script. Il sert à clarifier le rôle de chaque donnée avant de placer les blocs. Une variable qui change à plusieurs endroits sans raison claire est un bon indice de bug. De même, une valeur historique qui diminue à chaque boucle a probablement été confondue avec un compteur de temps.

Pour optimiser le parcours, il est possible de comparer deux stratégies. Dans la première, toutes les étapes sont jouées dans un ordre fixe, indépendamment de la durée disponible. Dans la seconde, le programme adapte la dernière étape si le temps restant devient insuffisant. La première solution est plus facile à construire. La seconde demande des conditions supplémentaires, mais elle permet de travailler la priorité, les seuils et les décisions.

Par exemple, si DUREE_RESTANTE devient inférieure à la durée prévue pour une animation, le programme peut afficher la zone suivante sans lancer l’animation complète. Il ne faut pas multiplier les règles au point de perdre le fil. Une seule condition bien choisie, testée avec plusieurs valeurs, enseigne davantage qu’un parcours rempli de branches impossibles à vérifier.

Le débogage peut alors suivre une méthode concrète:

1. exécuter le programme avec une durée très courte;

2. observer la valeur de ETAPE_VISITE après chaque événement;

3. tester séparément un adulte, un enfant et une saisie invalide;

4. vérifier que la durée de présence de Myrtle reste une donnée historique;

5. relancer la simulation avec plusieurs nombres de visiteurs;

6. noter la première valeur qui devient incohérente, plutôt que le dernier écran affiché.

Cette dernière étape est essentielle. Le dernier bug visible n’est pas toujours la cause du problème. Un tarif incorrect peut venir d’une mauvaise catégorie calculée au départ. Une animation manquante peut être la conséquence d’une condition devenue vraie trop tôt. Un lutin immobile peut dépendre d’une variable de position jamais mise à jour. Le travail consiste à remonter la chaîne des états, pas à ajouter des blocs jusqu’à ce que l’écran semble fonctionner.

Ce que l’exercice fait comprendre

L’intérêt d’un scénario autour de l’Aquarium de Nouvelle-Angleterre ne réside pas seulement dans le décor. L’adresse oblige à distinguer texte et nombre. La durée de visite introduit la conversion d’unités. Le tarif met en évidence la validation d’une saisie et les bornes d’une condition. Le Giant Ocean Tank donne un contexte visuel aux boucles et aux déplacements. Myrtle permet enfin de montrer qu’une donnée historique doit être nommée avec précision et qu’une durée de présence ne constitue pas l’âge réel d’un animal.

Un script peut donc être corrigé de plusieurs façons: en modifiant une condition, en déplaçant une initialisation, en séparant deux variables ou en changeant simplement le libellé d’un résultat. Cette dernière correction est parfois sous-estimée. Pourtant, afficher « 56 ans » quand le programme ne connaît que « 56 ans de présence depuis juin 1970 » n’est pas une petite maladresse de rédaction; c’est une erreur de modélisation.

Le bon exercice algorithmique collège ne cherche pas à reproduire toute la billetterie ni toute la circulation d’un aquarium. Il choisit quelques données, définit leur rôle, puis oblige l’élève à suivre leur évolution. Une donnée d’entrée est-elle transformée? Une constante est-elle modifiée par accident? Une boucle possède-t-elle une progression et une sortie? Une condition traduit-elle exactement la règle annoncée?

C’est à ce niveau que Scratch devient un outil de raisonnement. Les lutins attirent l’attention, mais les variables portent la logique. Dans une visite simulée, le bug n’est pas seulement ce qui empêche le personnage d’avancer. C’est aussi ce qui fait dire au programme plus que les données ne permettent réellement d’affirmer.

Photo: Robert Stern from USA / CC BY-SA 2.0 — Wikimedia Commons