Achat de billets Train World : corriger un bug Scratch

Achat de billets Train World: corriger un bug Scratch

Les blocs sont connus, les variables sont créées, les questions apparaissent à l’écran… pourtant le prix calculé devient faux dès que l’âge du visiteur change ou qu’un cas particulier intervient.

Train World

4,7· 1 002 avis

Réserver des billetsdès 15 €

• Billet combiné — Rooftop et bièrebillet combinédès22 €
• Billet officiel — Adulte (18 ans et +)official ticketdès15 €

Au guichet15 €

En lignedès 15 €selon l'option

Tarifs vérifiés le 21 août 2026 · prix à jour sur la page du partenaire.

Site officiel — trainworld.be

• Durée de visite: 2–3 h
• Meilleur moment: le matin

Tarifs indicatifs, susceptibles de changer — prix et disponibilités confirmés sur la page du partenaire.

Lien partenaire — billetterie GetYourGuide

Ce type d’exercice est intéressant parce qu’il rend visible une difficulté centrale de l’algorithmique: traduire une règle en décisions successives sans perdre les frontières entre les catégories. Pour acheter des billets Train World, le programme doit notamment distinguer les enfants de 0 à 3 ans, ceux de 4 à 5 ans, les jeunes de 6 à 17 ans et les adultes à partir de 18 ans. Une seule condition mal placée peut alors modifier tout le résultat.

Nous allons partir de cette difficulté pour reconstruire un algorithme achat de billets Train World solide, comprendre les erreurs logiques les plus fréquentes et organiser une série de tests qui permet de vérifier le script sans le corriger au hasard.

Pourquoi la billetterie est un bon problème d’algorithmique

Une tarification par âge semble simple à lire dans un tableau. Elle devient plus délicate lorsque nous devons la transformer en programme.

La règle n’est pas seulement: « un âge donne un prix ». Le programme doit d’abord recueillir une donnée, la stocker dans une variable, puis la comparer à plusieurs bornes. Il doit aussi décider dans quel ordre effectuer ces comparaisons.

La structure tarifaire de Train World peut être modélisée de cette manière:

Les montants exacts ne sont pas nécessaires pour comprendre le mécanisme Scratch. Dans une activité pédagogique, nous pouvons attribuer à chaque catégorie une valeur connue dans l’exercice, ou utiliser les valeurs de la grille tarifaire fournie avec l’énoncé. Pour une réservation réelle, la grille affichée au moment de l’achat reste la référence, car les modalités peuvent évoluer.

Le premier objectif n’est donc pas de recopier des prix. Il consiste à faire comprendre à l’élève que les catégories doivent couvrir tous les âges possibles, sans se chevaucher et sans laisser d’intervalle vide.

Un bon algorithme ne se contente pas de donner un résultat pour un exemple: il sait expliquer implicitement pourquoi chaque cas appartient à une seule catégorie.

Le rôle de la variable d’âge

Dans Scratch, nous pouvons créer une variable nommée âge. Le programme demande ensuite l’âge du visiteur et affecte la réponse à cette variable.

La séquence logique est la suivante:

1. Le programme demande l’âge du visiteur.

2. La réponse est enregistrée dans la variable âge.

3. Le programme compare cette valeur aux limites des catégories.

4. Une variable prix ou catégorie reçoit le résultat.

5. Scratch affiche le billet correspondant.

Cette progression paraît élémentaire, mais elle étaye plusieurs apprentissages à la fois: la saisie d’une donnée, le stockage, la comparaison, la condition et l’affichage. Si nous introduisons toutes ces notions simultanément, la charge cognitive peut devenir importante. Il est souvent préférable de faire fonctionner d’abord une seule catégorie, puis d’ajouter les suivantes.

Construire les conditions dans le bon ordre

Le bug le plus courant apparaît lorsque l’élève empile des conditions sans analyser leurs frontières.

Un script peut par exemple commencer par demander si l’âge est inférieur à 18 ans. Cette condition regroupe alors les enfants et les jeunes. Elle n’est pas fausse, mais elle ne suffit pas à déterminer le tarif. Il faut encore distinguer les sous-catégories.

Nous pouvons choisir une approche allant des plus jeunes vers les plus âgés:

• si l’âge est inférieur ou égal à 3, sélectionner la catégorie gratuite;
• sinon, si l’âge est inférieur ou égal à 5, sélectionner la catégorie des 4–5 ans;
• sinon, si l’âge est inférieur ou égal à 17, sélectionner la catégorie des 6–17 ans;
• sinon, sélectionner la catégorie adulte.

Cette organisation possède une qualité didactique importante: chaque nouveau sinon élimine les cas déjà traités. Lorsque le programme arrive à la deuxième condition, il sait déjà que l’âge est supérieur à 3. Lorsqu’il arrive à la troisième, il sait que l’âge est supérieur à 5.

Nous pouvons aussi construire le raisonnement en partant des adultes:

• si l’âge est supérieur ou égal à 18, sélectionner la catégorie adulte;
• sinon, si l’âge est supérieur ou égal à 6, sélectionner la catégorie jeune;
• sinon, si l’âge est supérieur ou égal à 4, sélectionner la catégorie jeune enfant;
• sinon, sélectionner la catégorie gratuite.

Les deux approches peuvent fonctionner. Pour un premier exercice, la progression de 0 vers les âges supérieurs est souvent plus lisible, car elle suit directement le tableau de l’énoncé. La progression inverse peut être intéressante lorsque l’on veut travailler la notion de seuil minimal.

Deux manières de programmer une même règle

Comparons deux organisations possibles.

Avec des conditions séparées, un script pourrait contenir un premier test pour les enfants de moins de 4 ans, puis un autre pour les moins de 6 ans, puis un autre pour les moins de 18 ans. Si les blocs ne sont pas reliés correctement, un âge de 5 ans peut satisfaire plusieurs conditions. La variable prix sera alors modifiée plusieurs fois, et le dernier bloc exécuté risque d’écraser le résultat précédent.

Les conditions imbriquées réduisent ce danger, à condition de respecter l’ordre des tests. Elles rendent également visible la structure « un cas ou bien un autre », qui correspond à la logique de la tarification.

Dans une condition imbriquée bien construite, chaque branche réduit le nombre de situations encore possibles. Si le programme continue à hésiter entre plusieurs catégories, c’est souvent que les tests se chevauchent.

Les erreurs de frontières: là où le script se trompe vraiment

Les erreurs les plus instructives ne concernent pas les âges évidents. Un enfant de 2 ans et un adulte de 30 ans sont généralement bien classés. Le problème apparaît aux limites: 3, 4, 5, 6, 17 et 18 ans.

Confondre « inférieur à » et « inférieur ou égal à »

La catégorie gratuite concerne les enfants de 0 à 3 ans inclus. Le mot inclus impose une comparaison avec « inférieur ou égal à 3 ».

Si le programme utilise seulement « âge < 3 », l’enfant de 3 ans est exclu de la catégorie gratuite. Il risque alors d’être placé dans la tranche suivante. Le script semble fonctionner pour 0, 1 et 2, mais échoue précisément sur la frontière annoncée par l’énoncé.

La même vigilance s’applique à toutes les catégories:

• 4 et 5 doivent appartenir à la tranche des 4–5 ans;
• 6 doit entrer dans la tranche des 6–17 ans;
• 17 doit encore être considéré comme jeune;
• 18 doit être traité comme adulte.

Une bonne habitude consiste à écrire les intervalles sur papier avant de créer les blocs Scratch. Nous pouvons ensuite entourer les valeurs de frontière et les utiliser comme premiers tests.

Oublier le cas de l’âge nul ou négatif

Dans une activité scolaire, l’énoncé peut supposer que l’utilisateur saisit un âge valide. Il reste cependant utile de distinguer deux niveaux.

Le premier niveau est l’algorithme tarifaire: il classe les âges prévus par le problème.

Le second niveau est la robustesse du programme: il réagit à une valeur impossible, comme un âge négatif ou une réponse non numérique. Ces deux objectifs ne doivent pas être mélangés trop tôt. Si l’élève apprend simultanément les intervalles, les variables, les contrôles de saisie et les messages d’erreur, la construction devient plus lourde.

Nous pouvons d’abord obtenir une version correcte pour les âges valides, puis ajouter une vérification:

• si l’âge est inférieur à 0, afficher un message demandant une nouvelle saisie;
• sinon, appliquer la tarification;
• éventuellement, limiter l’âge à une valeur raisonnable si l’exercice le prévoit.

Cette étape d’étayage permet de consolider le raisonnement principal avant d’ajouter des exigences secondaires.

Créer une catégorie qui n’existe pas

Une autre erreur consiste à inventer une tranche intermédiaire, par exemple « de 3 à 6 ans », parce que le programmeur cherche à simplifier les conditions. Cette catégorie peut sembler pratique, mais elle ne correspond plus à la règle fournie.

L’algorithme ne doit pas arranger la réalité pour rendre les blocs plus faciles à placer. Il doit traduire fidèlement les catégories existantes. Si une simplification est souhaitable, elle doit être discutée comme une modification du modèle, pas glissée discrètement dans le programme.

Ajouter les cas particuliers sans fragiliser le programme

La tarification peut comporter des situations particulières, notamment pour les personnes en situation de handicap. La grille officielle indique un tarif réduit pour les personnes à mobilité réduite non accompagnées, avec une distinction entre les catégories enfant et adulte.

Dans Scratch, cela suppose d’ajouter une information. Nous pouvons créer une variable ou une réponse booléenne, par exemple PMR, qui prend la valeur « oui » ou « non ».

Le programme doit alors répondre à deux questions:

1. Quelle catégorie d’âge correspond au visiteur?

2. Cette personne bénéficie-t-elle d’un régime particulier prévu par l’exercice?

La difficulté vient de l’ordre des décisions. Si nous déterminons d’abord un prix standard, puis appliquons une réduction sans vérifier les conditions, le programme peut attribuer un tarif réduit à une personne qui ne remplit pas les critères retenus dans l’activité.

Une structure plus sûre consiste à séparer la reconnaissance de la catégorie et le calcul final:

• déterminer d’abord la catégorie d’âge;
• enregistrer cette catégorie dans une variable, par exemple catégorie;
• demander ensuite si la personne relève du cas PMR prévu par l’exercice;
• choisir enfin le tarif correspondant à la combinaison des deux informations.

Cette organisation est plus longue qu’un unique bloc de conditions, mais elle est beaucoup plus lisible. Elle évite de répéter la variable âge dans tous les embranchements et permet d’expliquer le raisonnement à un camarade.

Pourquoi une variable de catégorie aide à apprendre

Un élève peut être tenté de modifier directement prix dans chaque bloc. Cette méthode fonctionne pour un petit script, mais elle masque parfois l’idée principale: le programme ne calcule pas seulement une somme, il classe d’abord une situation.

La variable catégorie joue le rôle d’un ancrage intermédiaire. Elle rend explicite la réponse à la question: « Dans quel groupe se trouve ce visiteur? »

Nous pouvons ensuite associer chaque catégorie à une valeur:

• catégorie « gratuit »;
• catégorie « jeune enfant »;
• catégorie « jeune »;
• catégorie « adulte »;
• catégorie particulière prévue pour le cas PMR.

Ce découpage rend l’algorithme plus facile à modifier. Si les modalités tarifaires changent, nous pouvons revoir l’association entre catégorie et prix sans reconstruire toute la logique d’âge.

Il faut toutefois rester précis sur le périmètre de l’exercice. Un scénario Scratch ne doit pas être présenté comme une copie du système de billetterie réel de Train World. Il s’agit d’une modélisation pédagogique fondée sur les catégories communiquées dans l’énoncé. Pour acheter des billets Train World dans la réalité, l’utilisateur doit se reporter aux conditions et aux options actuellement proposées par le musée ou par le service de réservation utilisé.

Une progression Scratch qui limite la charge cognitive

Pour construire l’exercice, nous pouvons suivre une progression en cinq versions. Cette démarche est généralement plus efficace qu’un script complet fourni dès le début.

Première version: reconnaître une seule catégorie

Demandons l’âge et faisons afficher un message uniquement pour les enfants de 0 à 3 ans. L’objectif est de vérifier que la réponse est bien enregistrée et que la comparaison fonctionne.

À ce stade, l’élève observe déjà plusieurs éléments:

• la question posée par le lutin;
• la valeur conservée dans réponse ou dans âge;
• le fonctionnement du bloc si… alors;
• la différence entre une variable et un texte affiché.

Il ne s’agit pas encore de calculer tous les tarifs. Nous bâtissons la première pierre du programme.

Deuxième version: distinguer deux catégories

Ajoutons la tranche suivante, celle des 4–5 ans. Le bloc sinon devient utile: si l’âge n’appartient pas à la première catégorie, Scratch examine la seconde.

Nous pouvons demander à l’élève d’expliquer oralement pourquoi un âge de 5 ans arrive dans le deuxième cas. Cette verbalisation aide à faire passer la condition d’un geste de manipulation à une règle comprise.

Troisième version: compléter les jeunes et les adultes

Ajoutons ensuite les 6–17 ans, puis les adultes. Après chaque modification, nous testons les frontières au lieu de nous limiter à un âge représentatif.

Une série minimale comprend:

1. un âge situé au milieu de la première catégorie;

2. l’âge maximal de cette catégorie;

3. l’âge minimal de la suivante;

4. l’âge maximal de la tranche des jeunes;

5. l’âge minimal des adultes;

6. un âge adulte clairement supérieur à 18.

Cette série permet de repérer rapidement une erreur de comparaison.

Quatrième version: afficher une catégorie avant d’afficher un prix

Avant de demander au programme de calculer une somme, affichons le nom de la catégorie. Par exemple, Scratch peut annoncer que le visiteur relève de la catégorie « jeune » ou « adulte ».

Cette étape semble moins spectaculaire qu’un calcul automatique, mais elle facilite considérablement le débogage. Si le classement est faux, nous savons que le problème se trouve dans les conditions d’âge. Si le classement est juste mais que le montant affiché est faux, nous pouvons examiner séparément la partie tarifaire.

Cinquième version: intégrer les cas particuliers

Ce n’est qu’après avoir stabilisé les catégories d’âge que nous ajoutons la variable PMR ou toute autre situation prévue par l’exercice. L’élève dispose alors d’une structure déjà maîtrisée et peut se concentrer sur la combinaison des critères.

Cette progression est également utile pour les parents. Lorsqu’un enfant demande pourquoi son programme ne fonctionne pas, nous pouvons éviter de corriger immédiatement le bloc fautif. Il est souvent plus formateur de lui demander quelle question le programme devait résoudre à ce moment précis.

Tester l’algorithme comme un petit laboratoire

Un script Scratch ne devient pas fiable parce qu’il fonctionne une fois. Il doit être confronté à plusieurs situations choisies pour mettre les conditions à l’épreuve.

Nous pouvons préparer un tableau de tests avant de lancer le programme:

Le tableau sert de mémoire externe. Il diminue la charge cognitive, car nous n’avons plus besoin de retenir tous les essais ni de nous fier à une impression générale.

Lire un résultat faux sans tout réécrire

Lorsque le résultat est incorrect, nous pouvons localiser le problème avec trois questions:

1. La réponse a-t-elle été enregistrée dans la bonne variable?

2. La catégorie d’âge affichée est-elle correcte?

3. Le prix ou le statut associé à cette catégorie est-il correct?

Si l’âge de 18 ans est classé comme jeune, le problème se trouve dans la condition de frontière. Si la catégorie adulte est affichée mais que le montant ne correspond pas à l’énoncé, la logique de classement fonctionne et seule l’association tarifaire doit être vérifiée.

Cette manière de procéder évite le tâtonnement. Nous ne déplaçons pas les blocs au hasard: nous identifions d’abord l’étape qui produit l’erreur.

Les pièges classiques dans un exercice Scratch sur les billets

Utiliser directement la réponse partout

Scratch possède une variable système appelée réponse après une question. Il est possible de l’utiliser, mais la variable devient moins explicite lorsque le programme grandit.

Créer une variable âge permet de nommer la donnée selon son rôle. Cette pratique aide l’élève à distinguer la réponse temporaire d’une information réellement utilisée par l’algorithme.

Modifier le prix dans plusieurs branches

Si plusieurs conditions indépendantes écrivent dans prix, une même valeur peut être remplacée plusieurs fois. L’utilisation d’un ensemble si… sinon si… sinon limite ce risque, car une seule branche de la structure est retenue.

Quand plusieurs critères sont nécessaires, nous pouvons aussi séparer le classement et le calcul. Cette séparation rend le script plus long, mais elle facilite la lecture et la maintenance.

Mélanger âge et statut dans une seule condition illisible

Une condition qui combine immédiatement l’âge, le statut PMR et plusieurs exceptions devient rapidement difficile à expliquer. Les opérateurs et et ou sont utiles, mais leur multiplication sans étapes intermédiaires accroît la charge cognitive.

Nous pouvons étayer le raisonnement en conservant deux variables:

• catégorieAge pour le groupe déterminé par l’âge;
• statutParticulier pour le cas PMR prévu.

Le programme devient alors une suite de décisions explicites plutôt qu’un bloc compact impossible à relire.

Ne pas préciser les hypothèses

Un exercice doit dire ce qui se passe si l’utilisateur saisit une valeur décimale, un texte, un âge négatif ou une information PMR qui ne correspond pas aux options proposées. Toutes ces situations ne sont pas obligatoires dans une première version, mais elles doivent être distinguées des règles tarifaires elles-mêmes.

Une consigne claire peut préciser que l’âge est un nombre entier positif et que le statut particulier est choisi dans une liste de réponses. Cette limitation n’est pas une faiblesse: elle définit le modèle étudié.

Tester les bornes n’est pas une étape de finition. Pour un algorithme de tarification, les bornes sont le cœur du problème.

Une organisation plus lisible pour le script final

Une version aboutie peut suivre cette architecture:

1. Initialiser le programme avec le bouton vert.

2. Demander l’âge du visiteur.

3. Contrôler la validité de la saisie si cette notion est prévue.

4. Déterminer la catégorie d’âge à l’aide de conditions imbriquées.

5. Demander le statut particulier lorsque l’exercice le demande.

6. Associer la catégorie et le statut à un tarif ou à une mention adaptée.

7. Afficher le résultat de façon compréhensible.

8. Proposer un nouveau calcul si nous voulons traiter plusieurs visiteurs.

L’affichage final doit être suffisamment explicite. Un message qui indique seulement une valeur ne permet pas toujours de comprendre le raisonnement. Nous pouvons afficher la catégorie reconnue et le résultat dans une phrase complète, par exemple en combinant le prénom, l’âge, la catégorie et le tarif utilisé dans le cadre de l’exercice.

Cette précision a une fonction pédagogique. Elle permet à l’élève de comparer ce que le programme a compris avec ce qu’il voulait lui faire comprendre.

Faut-il utiliser une liste de tarifs?

Pour une activité plus avancée, nous pouvons stocker les valeurs dans une liste Scratch. Cette solution devient intéressante lorsque plusieurs catégories ou plusieurs visiteurs doivent être traités.

Cependant, une liste introduit de nouvelles notions: position, index, correspondance entre une catégorie et une valeur. Elle ne doit pas être ajoutée simplement pour rendre le script plus sophistiqué.

Pour un premier exercice, des variables et des conditions lisibles suffisent. Pour une classe qui maîtrise déjà ces éléments, une liste peut ouvrir une réflexion sur la séparation entre les données et les règles de calcul.

Le choix du matériel pédagogique compte ici. Des cartes représentant les catégories d’âge, les conditions et les résultats peuvent aider à manipuler l’algorithme avant de le programmer. L’élève déplace les cartes, vérifie les intervalles, puis traduit cette organisation en blocs Scratch. Cette manipulation concrète crée un ancrage avant le passage à l’écran.

Relier l’exercice à une visite réelle de Train World

Le contexte de Train World donne du sens au problème sans transformer l’exercice en copie du processus de réservation. Le musée se trouve au Prinses Elisabethplein 5, à Schaerbeek, dans la région de Bruxelles. Les visiteurs peuvent rencontrer plusieurs modalités de visite et de billetterie; le programme Scratch, lui, ne modélise qu’un extrait volontairement simplifié.

Cette distinction mérite d’être explicitée aux élèves. Un algorithme scolaire reproduit une règle choisie pour apprendre. Il ne remplace pas la consultation des informations actuelles du musée, des horaires, des conditions d’accès ou des options de réservation.

Pour acheter des billets Train World, nous pouvons donc utiliser le programme comme support de raisonnement, mais pas comme système de réservation. Les tarifs affichés par le script correspondent aux données de l’exercice et doivent être actualisés si l’énoncé change.

Cette nuance est aussi l’occasion de parler de la fiabilité des données. Un programme peut être logiquement parfait tout en produisant une information devenue obsolète. La qualité d’un outil dépend à la fois de son algorithme et des données qui l’alimentent.

Ce que cet exercice apprend réellement

Derrière la billetterie, l’élève rencontre plusieurs notions fondamentales:

• une variable représente une information;
• une condition permet de choisir une branche;
• des intervalles doivent être continus et non chevauchants;
• l’ordre des tests modifie la lecture du programme;
• un cas particulier peut nécessiter une nouvelle donnée;
• les tests doivent cibler les situations fragiles;
• un résultat peut être juste pour une mauvaise raison.

La difficulté n’est donc pas de mémoriser la syntaxe des blocs. Elle consiste à bâtir une représentation correcte du problème, puis à la consolider par des essais.

Nous remarquons souvent qu’un élève sait dire qu’un enfant de 5 ans relève d’une catégorie donnée, mais ne sait pas encore traduire cette phrase en comparaison. Il faut alors revenir au langage naturel: « Quel âge faut-il avoir au maximum? À partir de quel âge la catégorie suivante commence-t-elle? » Ces questions reconstruisent progressivement le pont entre la règle et le programme.

L’adulte qui accompagne peut jouer un rôle d’étayage sans prendre la souris. Plutôt que de montrer immédiatement le bloc correct, il peut demander à l’enfant de dessiner les catégories sur une ligne d’âges, puis de repérer les valeurs qui posent problème. Le script devient alors la traduction d’un raisonnement déjà construit.

En résumé pratique pour corriger le bug

Pour déboguer l’exercice achat de billets Train World dans Scratch, nous pouvons suivre cette démarche:

1. Relire les catégories d’âge et noter précisément les bornes incluses.

2. Créer une variable âge plutôt que de réutiliser indistinctement la réponse.

3. Choisir un seul ordre de classement, du plus jeune vers l’adulte ou l’inverse.

4. Relier les catégories avec une structure si… sinon si… sinon.

5. Vérifier séparément les âges 3, 4, 5, 6, 17 et 18.

6. Afficher d’abord la catégorie reconnue avant de calculer ou d’afficher le tarif.

7. Ajouter les cas PMR seulement lorsque la logique d’âge fonctionne.

8. Distinguer les règles de l’exercice des conditions réelles de réservation.

9. Conserver un tableau de tests pour éviter les corrections intuitives.

10. Réécrire les conditions si elles deviennent plus difficiles à expliquer que le problème lui-même.

La meilleure version du script n’est pas nécessairement la plus courte. Elle est celle qu’un autre élève peut relire, tester et modifier sans devoir deviner l’intention de son auteur.

Corriger un bug Scratch de billetterie, c’est donc apprendre à regarder les frontières, les exceptions et l’ordre des décisions. En manipulant d’abord les catégories avec des cartes ou une ligne d’âges, puis en les traduisant dans Scratch, nous aidons l’apprenant à bâtir une compréhension stable. Le programme cesse alors d’être un assemblage de blocs: il devient une méthode visible, que nous pouvons vérifier pas à pas et réutiliser dans d’autres problèmes d’algorithmique.

Photo: Wikimedia Commons / CC BY 2.5 — Wikimedia Commons