Achat de billets à l'Aquarium de Kyoto avec Scratch

C'est précisément ce type de blocage que nous pouvons transformer en levier pédagogique: en demandant à l'élève de modéliser l'achat d'un billet pour un lieu réel — l'Aquarium de Kyoto, par exemple — la programmation cesse d'être un exercice abstrait pour devenir une simulation où chaque variable incarne une donnée tangible. Nous allons bâtir ce programme ensemble, en partant des informations vérifiables que nous connaissons sur ce site japonais, puis en construisant pas à pas une architecture Scratch capable de reproduire, avec ses contraintes, le parcours d'un visiteur qui souhaite entrer dans l'aquarium.

Les données réelles de l'Aquarium de Kyoto pour ancrer votre algorithme

Avant d'écrire la moindre ligne de code, nous devons effectuer un travail de fond que beaucoup d'élèves négligent: la collecte et la sélection des informations utiles à l'algorithme. Pour un projet de billetterie, cela revient à se mettre dans la peau d'un développeur qui doit comprendre le « métier » qu'il automatise. Sans cette étape préalable, le programme flotte dans le vide et l'élève, incapable de relier ses blocs à un contexte, finit par mémoriser des formules sans en saisir l'intention.

L'Aquarium de Kyoto se trouve dans le parc Umekoji, à environ quinze minutes à pied de la gare JR de Kyoto et cinq minutes de la gare JR Umekoji-Kyotonishi. Cet ancrage géographique n'est pas anecdotique: il introduit une notion souvent oubliée en algorithmique, celle de donnée contextuelle. Même si notre programme ne calcule pas un itinéraire, mentionner l'adresse dans un commentaire Scratch aide l'élève à comprendre qu'un algorithme s'inscrit toujours dans un écosystème de contraintes réelles — et que choisir ses sources fait partie du travail de programmeur.

Les autres données qui nourrissent directement notre simulation sont les suivantes:

• Le tarif d'entrée pour un adulte, consultable sur le site officiel et qui constitue une donnée de prix essentielle à modéliser.
• L'utilisation d'un billet électronique avec code QR ou code-barres 2D, présenté sur smartphone ou tablette à l'entrée.
• La règle de la dernière entrée, qui n'est plus autorisée passé un certain délai avant la fermeture (soixante minutes avant, selon les conditions publiées).
• La présence d'espèces remarquables comme la salamandre géante du Japon, monument naturel spécial, qui peut servir d'élément narratif pour agrémenter le programme.

Une variable bien nommée vaut mieux qu'un long commentaire: « prix_adulte » se lit comme une phrase, alors que « a1 » ressemble à une étiquette perdue.

Structurer les variables de prix et de temps dans Scratch

Une fois les données rassemblées, l'étape suivante consiste à bâtir le squelette informationnel du programme. C'est ici que se joue une grande partie de la qualité du projet: un élève qui crée ses variables au fur et à mesure finit par s'y perdre, alors qu'une structure réfléchie dès le départ rend l'ensemble beaucoup plus lisible et évolutif.

Dans Scratch, nous recommandons de créer des variables distinctes pour chaque catégorie de donnée plutôt que de tout empiler dans une seule. Voici une organisation possible, à adapter au niveau de la classe:

Pour un collégien en début d'apprentissage Scratch, on peut se limiter à trois ou quatre variables et compléter au fur et à mesure que le projet grandit. L'important est que l'élève perçoive l'utilité de chaque variable avant de la créer, plutôt que de suivre une recette mécanique.

Un point didactique que nous prenons toujours le temps de souligner: l'initialisation des variables. Beaucoup d'élèves oublient de donner une valeur de départ et se retrouvent avec un résultat vide ou égal à zéro, ce qui produit des bugs difficiles à diagnostiquer. L'astuce consiste à utiliser un bloc « mettre [...] à [...] » au tout début du programme, idéalement dans un bloc « quand le drapeau vert est cliqué ». Cela pose les fondations avant que la construction ne commence, exactement comme on prépare un terrain avant de couler une dalle.

Logique conditionnelle: gérer les horaires d'entrée et la fermeture

Le cœur pédagogique de cet exercice réside dans les structures conditionnelles. L'Aquarium de Kyoto applique une règle simple mais essentielle: la dernière entrée est autorisée jusqu'à une heure avant la fermeture. C'est exactement le type de règle métier qu'un algorithme doit savoir appliquer, et c'est une excellente entrée en matière pour comprendre l'instruction « si… alors… sinon ».

Décomposer la règle métier en français

Avant de traduire en blocs, nous demandons toujours aux élèves de formuler la règle dans leurs propres mots. Une formulation possible: « Si le visiteur arrive plus d'une heure avant la fermeture, on le laisse entrer; sinon, on lui refuse l'accès. » Cette étape, qui peut sembler superflue, est en réalité fondatrice: elle révèle les zones d'ombre que l'algorithme devra trancher. Par exemple, que se passe-t-il si le visiteur arrive pile à l'heure limite? Faut-il l'accepter ou le refuser?

Traduire en blocs Scratch

Pour modéliser cette règle, nous allons demander à l'utilisateur de saisir une heure d'arrivée, puis comparer cette heure avec l'heure de fermeture diminuée du délai de dernière entrée. Si l'arrivée est trop tardive, le programme refuse l'accès et affiche un message explicatif. Sinon, il poursuit le processus d'achat.

Voici, en pseudo-code, la logique que nous visons:

1. Demander à l'utilisateur l'heure à laquelle il souhaite se présenter à l'entrée.

2. Calculer l'heure limite d'entrée (heure de fermeture moins soixante minutes).

3. Si l'heure saisie est supérieure à l'heure limite, refuser l'accès et expliquer pourquoi.

4. Sinon, demander la catégorie de visiteur (adulte, enfant, etc.) et le nombre de billets.

5. Calculer le montant total et afficher le résultat.

Cette décomposition en étapes aide l'élève à percevoir qu'un programme, c'est d'abord une succession de décisions ordonnées. Nous remarquons souvent, en classe, que les collégiens qui n'ont jamais explicitement listé ces étapes se retrouvent bloqués dès qu'ils ouvrent Scratch: ils ne savent pas par où commencer, comme un maçon qui voudrait monter un mur sans avoir tracé le plan au sol.

Programmer, c'est d'abord écrire en français ce que l'ordinateur doit faire, et seulement ensuite traduire en blocs.

Simulation du processus de validation du billet électronique

Une fois les conditions d'accès validées, notre simulation entre dans une phase passionnante: celle de la reproduction du contrôle d'entrée. À l'Aquarium de Kyoto, le visiteur présente un billet électronique muni d'un code QR ou d'un code-barres 2D. Le personnel scanne ce code à l'entrée et autorise ou refuse l'accès.

Dans Scratch, nous ne disposons évidemment pas d'un véritable scanner. Mais nous pouvons très bien reproduire la logique de validation, et c'est même là que réside tout l'intérêt pédagogique. L'idée est de demander à l'utilisateur de saisir un identifiant de billet — par exemple, une combinaison de chiffres et de lettres générée aléatoirement — puis de vérifier que cet identifiant respecte un format prédéfini.

Plusieurs approches sont possibles, et le choix entre elles fait déjà partie de l'apprentissage:

• Vérification simple de la longueur: l'identifiant doit comporter exactement dix caractères, par exemple.
• Vérification du premier caractère: l'identifiant doit commencer par une lettre précise associée à l'aquarium.
• Vérification croisée avec une liste: l'identifiant saisi doit figurer dans une liste Scratch d'identifiants autorisés.

Cette dernière approche est particulièrement formatrice, car elle introduit la notion de liste et de parcours séquentiel. L'élève apprend que l'ordinateur peut comparer une donnée fournie par l'utilisateur à un ensemble de données préenregistrées, exactement comme un système de billetterie réel confronte un code à sa base de données. Pour les élèves plus avancés, on peut même introduire une boucle qui parcourt la liste jusqu'à trouver une correspondance.

Si l'identifiant est validé, le programme affiche un message de bienvenue — pourquoi pas accompagné d'une anecdote sur la salamandre géante du Japon, qui a le mérite de relier la programmation à la culture? Si l'identifiant est invalide, le programme refuse l'accès et propose de recommencer. Cette boucle de rétroaction est fondamentale pour ancrer chez l'élève l'idée qu'un programme peut — et doit — guider l'utilisateur en cas d'erreur, plutôt que de se contenter de planter silencieusement.

Débogage et tests de robustesse du programme de billetterie

Construire un programme qui fonctionne une fois est une chose; bâtir un programme qui fonctionne dans tous les cas de figure en est une autre. Cette distinction est au cœur de l'apprentissage de l'algorithmique, et c'est souvent à ce stade que les élèves prennent conscience de la rigueur nécessaire.

Nous proposons trois familles de tests à faire passer à votre projet:

1. Tests nominaux: un visiteur adulte, arrivant à une heure raisonnable, avec un identifiant valide. Le programme doit calculer le bon montant et afficher l'autorisation d'entrée.

2. Tests aux limites: un visiteur qui arrive exactement à l'heure limite d'entrée. Le programme doit accepter ou refuser selon la règle choisie (strictement inférieur, ou inférieur ou égal).

3. Tests d'erreur: un identifiant invalide, une heure d'arrivée saisie en lettres au lieu de chiffres, un nombre de billets négatif ou nul. Le programme doit gérer ces situations sans planter, idéalement avec un message clair.

Les erreurs les plus fréquentes que nous observons chez les collégiens:

• Oublier de convertir une saisie en nombre, Scratch traitant parfois les réponses comme du texte, ce qui produit des comparaisons imprévues.
• Mélanger les conditions dans un ordre qui empêche certaines branches d'être testées, notamment quand une condition englobante « avale » une condition plus spécifique.
• Utiliser une variable avant de l'avoir initialisée, ce qui produit des comportements étranges et difficiles à tracer.

Pour chacune de ces erreurs, l'attitude pédagogique que nous recommandons est de ne pas corriger à la place de l'élève, mais de l'accompagner dans la formulation d'hypothèses sur l'origine du problème. Cette posture de « chercheur de bugs » consolide la confiance technique et nourrit une vision apaisée de l'erreur. Un bug n'est pas une honte, c'est une information à exploiter.

Conseils pour consolider ce projet en classe ou à la maison

Si vous souhaitez aller plus loin, plusieurs prolongements sont possibles sans complexifier excessivement le programme:

• Ajouter une variable « budget du visiteur » et vérifier, avant l'achat, si le total reste dans la limite fixée.
• Introduire une notion de réduction (carte de fidélité, tarif groupe scolaire, gratuité jeune enfant) pour travailler les conditions imbriquées.
• Simuler plusieurs guichets avec des lutins différents, chacun responsable d'une étape du parcours d'achat.
• Documenter le projet avec un petit texte explicatif intégré comme commentaire, ce qui entraîne l'élève à formuler ses choix.

Chacune de ces extensions respecte la progression spiralaire que nous affectionnons en didactique: on consolide d'abord ce qui est acquis, puis on étaye avec une difficulté supplémentaire, exactement comme on ajoute une pierre à un édifice déjà stable. Aucun de ces prolongements ne dénature le projet initial; ils l'enrichissent en l'ouvrant sur de nouvelles questions.

Un projet Scratch réussi n'est pas un projet sans bugs: c'est un projet dont les bugs ont été compris, nommés et corrigés.

En définitive, simuler l'achat de billets pour l'Aquarium de Kyoto avec Scratch n'est pas qu'un exercice de programmation. C'est une manière concrète de relier les mathématiques, la logique algorithmique et la culture générale, tout en donnant du sens à chaque bloc posé par l'élève. Aidons-le à percevoir que derrière chaque instruction Scratch se cache une décision, et que derrière chaque décision se cache une intention — celle de modéliser un monde qu'il connaît déjà, pour mieux le comprendre.

Photo: Mti / CC BY-SA 3.0 — Wikimedia Commons