Christ Rédempteur : checklist Scratch pour simuler l'achat

Christ Rédempteur: checklist Scratch pour simuler l'achat

Il valorise surtout la construction du raisonnement: une variable correctement nommée, une condition complète, un calcul lisible et une réponse justifiée. Une simulation d’achat de billets pour le Christ Rédempteur est donc un excellent support: le contexte est concret, mais la réussite dépend entièrement de la méthode.

Tu ne dois pas chercher à reproduire une véritable plateforme de réservation. Ton objectif est de modéliser une situation: un visiteur choisit une saison, un moyen de transport, un point de départ et un nombre de billets; le programme calcule alors le montant correspondant. Le décor est celui de Rio de Janeiro, mais la compétence évaluée est bien algorithmique.

Le train du Corcovado part de la gare de Cosme Velho et monte vers le monument en environ 20 minutes. Les vans officielles Paineiras Corcovado proposent notamment des départs depuis Copacabana, au niveau de la Praça do Lido, depuis Largo do Machado et depuis le centre des visiteurs de Paineiras. Les tarifs ne sont pas fixes: ils peuvent dépendre de la saison, de l’âge et du transport sélectionné.

La première règle est donc simple: ne grave pas un prix unique dans ton script. Fais-le varier à partir de données saisies par l’utilisateur.

Dans une simulation Scratch, le décor raconte l’histoire; les variables et les conditions portent la démonstration.

Modéliser les variables: saison, âge, transport et quantité

Avant de placer le moindre bloc, écris sur ton brouillon les informations dont le programme a besoin. Si tu commences directement dans Scratch, tu risques de créer des variables inutiles ou d’oublier une donnée qui sera pourtant nécessaire au calcul final.

Pour une simulation d’achat de billets du Christ Rédempteur, tu peux prévoir les variables suivantes:

• nombre_billets: nombre de billets payants demandés;
• age: âge du visiteur, si le programme traite une gratuité ou un tarif particulier;
• saison: basse saison ou haute saison;
• type_transport: train du Corcovado ou van officielle;
• point_depart: Cosme Velho, Copacabana, Largo do Machado ou Paineiras;
• prix_unitaire: tarif appliqué à un billet;
• montant_total: coût final de la commande.

Le nom d’une variable doit décrire son contenu. x peut fonctionner dans un calcul très court, mais il ne t’aide ni à relire ton programme ni à corriger une erreur. Si le correcteur cherche à comprendre ton algorithme, prix_unitaire lui montre immédiatement ton intention. C’est un point de rédaction et de lisibilité qui peut faire la différence lorsque le script comporte plusieurs conditions.

Distinguer une donnée saisie d’une donnée calculée

Toutes les variables ne sont pas remplies de la même manière.

Certaines correspondent à un choix du visiteur. Le programme peut demander:

1. le nombre de billets souhaités;

2. la saison de la visite;

3. le moyen de transport;

4. l’âge du visiteur;

5. le point de départ, lorsque le choix du transport le permet.

D’autres variables sont calculées par le programme. prix_unitaire ne doit pas être demandé au visiteur si le tarif dépend des réponses précédentes. Le script doit le déterminer à l’aide de conditions. Ensuite, montant_total est obtenu par une opération.

Dans Scratch, la logique générale est la suivante: poser une question, attendre la réponse, puis placer cette réponse dans la variable correspondante. Utilise des réponses compréhensibles, par exemple haute et basse, plutôt que des valeurs difficiles à interpréter comme 1 et 2.

Cette précaution évite une erreur fréquente: écrire une condition qui compare une réponse textuelle avec un nombre. Si tu demandes à l’utilisateur de saisir haute, la condition doit rechercher haute. Si tu veux travailler avec des nombres, annonce-le clairement dans la question et traite toutes les réponses de la même manière.

Choisir les prix de la simulation

La fiche d’exercice peut fournir un tableau de tarifs. Dans ce cas, reporte précisément ces données dans ton programme ou dans les variables de départ. Si aucun montant n’est imposé, choisis des valeurs d’entraînement et indique qu’il s’agit de tarifs fictifs utilisés pour la simulation.

Cette précision est indispensable. Les prix réels du Christ Rédempteur varient selon la saison, le moyen de transport et les conditions tarifaires. Une simulation scolaire ne doit pas être présentée comme un outil permettant réellement d’acheter un billet. Elle sert à travailler les variables, les tests et les calculs.

Tu peux organiser les tarifs sous cette forme sur ton brouillon:

Ne mélange pas dans une même variable plusieurs informations. transport_saison_age serait illisible et difficile à tester. Une variable, une information: cette règle rend ton algorithme plus solide.

Construire la structure conditionnelle du tarif

Le cœur de l’exercice se trouve dans les conditions. Le programme doit observer les choix enregistrés, puis sélectionner le tarif correspondant. Tu dois donc tracer l’ordre des décisions avant de les traduire avec les blocs Scratch.

Une organisation efficace consiste à traiter d’abord les cas particuliers, puis les cas généraux:

1. vérifier si le visiteur bénéficie de la gratuité;

2. déterminer le type de transport;

3. distinguer la haute saison de la basse saison;

4. calculer le montant total.

Pourquoi commencer par la gratuité? Parce qu’un enfant de moins de 4 ans voyage gratuitement dans le train du Corcovado s’il est installé sur les genoux de ses parents. Si tu calcules d’abord un prix standard, puis que tu oublies de l’annuler, le résultat sera faux.

Traiter la gratuité avant le tarif standard

La condition peut être formulée ainsi dans ton raisonnement:

• si l’âge est inférieur à 4 ans et que le transport choisi est le train, alors le prix appliqué à ce voyageur est nul;
• sinon, le programme poursuit la recherche du tarif normal.

Les deux informations sont nécessaires. Tester seulement l’âge ne suffit pas, car la règle de gratuité donnée dans l’exercice concerne le transport en train. Tester seulement le transport ne suffit pas non plus.

Dans Scratch, tu peux utiliser une condition composée avec le bloc logique et. Le raisonnement devient alors:

« Si age < 4 et type_transport = train, alors appliquer la gratuité. »

Attention à ne pas écrire une condition trop large du type « si l’âge est inférieur à 4 ans, alors gratuit ». Tu supprimerais la vérification du transport. Le correcteur verra immédiatement que la règle n’est pas entièrement traduite.

Ne pas confondre prix unitaire et montant total

Une autre erreur classique consiste à mettre directement le montant total dans prix_unitaire. Ces deux valeurs n’ont pas le même rôle.

prix_unitaire correspond au prix d’un billet dans une situation donnée. montant_total correspond au coût de tous les billets concernés. La formule de base est:

montant_total = nombre_billets × prix_unitaire

Si la simulation ne gère qu’un seul âge pour l’ensemble du groupe, précise cette hypothèse dans ton texte ou dans le message d’accueil. Sinon, le programme devra traiter chaque voyageur séparément, ce qui demande une structure plus avancée avec une répétition.

Pour un exercice de collège, le modèle le plus simple peut demander le nombre de billets payants et l’âge du bénéficiaire d’un billet particulier. Mais il ne faut pas faire semblant de calculer une famille entière si le programme ne distingue pas les âges de chaque personne.

Une condition n’est correcte que si elle traduit toute la règle: l’âge, le transport et l’action à effectuer doivent apparaître dans le raisonnement.

Relier le moyen de transport au point de départ

Le choix du transport ne doit pas rester une information décorative. Il doit modifier le parcours logique du programme.

Le train du Corcovado part de la gare de Cosme Velho, située Rua Cosme Velho 513. Les vans officielles Paineiras Corcovado peuvent accueillir les visiteurs depuis plusieurs points majeurs, notamment Copacabana, Largo do Machado et le centre des visiteurs de Paineiras.

Tu peux donc construire une condition qui vérifie la cohérence entre le moyen de transport et le point de départ:

• si le transport est le train, le point de départ attendu est Cosme Velho;
• si le transport est une van officielle, le programme peut proposer Copacabana, Largo do Machado ou Paineiras.

Cette partie permet de travailler une idée importante en algorithmique: une réponse peut être syntaxiquement valide mais logiquement incohérente. Un utilisateur peut écrire Copacabana alors qu’il a sélectionné le train. Le programme doit le détecter ou limiter les choix proposés.

Deux méthodes pour gérer les départs

Tu peux traiter les points de départ de deux manières.

Méthode 1: demander le point de départ après le transport

Le programme demande d’abord:

• « Choisis ton moyen de transport: train ou van. »

Puis il adapte la question suivante:

• pour le train, il indique Cosme Velho;
• pour la van, il propose les trois points de départ concernés.

Cette méthode est claire et proche du fonctionnement d’un formulaire. Elle évite de présenter à l’utilisateur des choix impossibles.

Méthode 2: vérifier la réponse après la saisie

Le programme demande le transport puis le point de départ, quelle que soit la réponse. Il contrôle ensuite la cohérence avec une condition.

Par exemple, si type_transport = train et que point_depart n’est pas Cosme Velho, le personnage Scratch peut afficher un message d’erreur et redemander la saisie.

Cette seconde méthode est intéressante pour travailler les conditions imbriquées, mais elle demande davantage de rigueur. Si tu annonces une erreur, ton script doit réellement permettre de corriger la réponse. Un simple message « choix incorrect » suivi du calcul serait contradictoire.

Utiliser la durée du trajet sans fausser le calcul

Le trajet en train dure environ 20 minutes. Cette donnée peut être affichée comme information dans la simulation:

« Le trajet choisi en train dure environ 20 minutes. »

Elle ne doit pas automatiquement entrer dans le prix si l’énoncé ne demande pas de calcul lié à la durée. C’est une distinction essentielle entre une donnée informative et une donnée utile au calcul.

Tu peux aussi intégrer l’horaire comme extension: les départs du train sont indiqués toutes les 30 minutes, de 8 h à 19 h. Dans ce cas, il faut vérifier que l’heure saisie respecte l’intervalle et le pas de 30 minutes. Mais n’ajoute pas cette fonctionnalité uniquement pour rendre le script plus impressionnant. Chaque nouvelle donnée crée de nouveaux cas à tester.

Organiser l’algorithme d’achat de billets

Une fois les variables et les règles définies, rédige l’ordre des actions sur ton brouillon. Écris des phrases courtes, avec un verbe d’action au début. Cette technique t’oblige à distinguer les étapes et facilite ensuite la traduction en blocs.

Voici une organisation robuste:

1. Initialiser la simulation.

Affiche le titre du projet et précise qu’il s’agit d’un exercice de calcul, pas d’une réservation réelle.

2. Demander le nombre de billets.

Stocke la réponse dans nombre_billets. Vérifie que la quantité est positive.

3. Demander la saison.

Enregistre haute ou basse dans saison. Évite d’accepter plusieurs orthographes si tu ne les traites pas ensuite.

4. Demander le moyen de transport.

Stocke train ou van dans type_transport.

5. Déterminer le point de départ.

Pour le train, utilise Cosme Velho. Pour la van, demande Copacabana, Largo do Machado ou Paineiras.

6. Demander l’âge lorsque la gratuité est étudiée.

Cette donnée permet de tester la condition concernant les moins de 4 ans.

7. Sélectionner le prix unitaire.

Utilise des blocs si... alors... sinon pour croiser le transport et la saison.

8. Appliquer la gratuité si elle est prévue.

Cette vérification doit être compatible avec le transport choisi.

9. Calculer le montant total.

Multiplie le nombre de billets par le prix retenu.

10. Afficher un récapitulatif.

Fais apparaître la saison, le transport, le départ et le montant final.

11. Signaler les incohérences.

Si une réponse ne correspond à aucun choix prévu, demande une nouvelle saisie au lieu de poursuivre silencieusement.

Cet ordre évite de calculer trop tôt. Tant que le programme ne connaît pas la saison et le transport, il ne peut pas déterminer le prix unitaire.

Prévoir une valeur par défaut

Dans Scratch, une variable peut conserver une ancienne valeur si le script est relancé sans être remise à zéro. C’est un piège discret: le premier essai fonctionne, puis le second utilise un prix ou un montant provenant de la simulation précédente.

Au début du script, remets donc les variables calculées à zéro ou attribue-leur une valeur clairement identifiable. montant_total = 0 est une base logique. Pour prix_unitaire, tu peux aussi utiliser une valeur provisoire, puis la remplacer dès que les conditions sont vérifiées.

Si aucune combinaison valide n’a été reconnue, le programme ne doit pas afficher un montant crédible par accident. Un message doit signaler que le choix n’a pas été compris.

Tester avec des jeux de données variés

Un algorithme n’est pas terminé lorsque Scratch exécute les blocs sans afficher d’erreur. Il faut encore vérifier les résultats. Pour cela, prépare plusieurs jeux de données sur ton brouillon et observe visuellement le chemin suivi par les conditions.

Ne teste pas uniquement le cas le plus simple. Une simulation fiable doit réussir au moins les situations suivantes:

Pour chaque test, écris le résultat attendu avant de lancer le programme. Sinon, tu risques de considérer comme correct un montant simplement parce qu’il paraît plausible.

Vérifier les limites

Les valeurs limites sont particulièrement utiles:

• nombre de billets égal à 1;
• nombre de billets supérieur à 1;
• âge égal à 4 ans;
• âge inférieur à 4 ans;
• âge négatif;
• nombre de billets égal à 0;
• saison saisie avec une majuscule ou une faute;
• point de départ incompatible avec le transport.

La condition age < 4 ne donne pas le même résultat que age <= 4. Si la gratuité concerne les enfants de moins de 4 ans, l’âge de 4 ans ne doit pas être traité comme gratuit. Observe bien le vocabulaire de l’énoncé: « moins de 4 ans » et « jusqu’à 4 ans » ne signifient pas la même chose.

Pour le nombre de billets, une valeur nulle doit être refusée si l’objectif est de simuler un achat. Il n’est pas logique d’afficher un billet total de zéro sans expliquer qu’aucune commande n’a été enregistrée.

Contrôler visuellement le résultat

La vérification visuelle ne remplace pas le calcul, mais elle aide à repérer une incohérence. Le récapitulatif final doit reprendre les choix effectués. Si l’utilisateur sélectionne le train et que le programme affiche une van, l’erreur vient probablement d’une variable mal réutilisée ou d’une condition mal ordonnée.

Fais afficher des messages suffisamment précis:

• moyen de transport choisi;
• point de départ reconnu;
• saison sélectionnée;
• âge pris en compte;
• prix unitaire retenu;
• montant total calculé.

Tu peux masquer certains détails dans la version finale, mais pendant la mise au point, ils sont précieux. Ils permettent de suivre le programme étape par étape, comme on suit une figure en géométrie pour vérifier qu’une construction respecte bien les données.

Corriger les erreurs qui font perdre des points

Les erreurs les plus fréquentes ne viennent pas de Scratch lui-même. Elles apparaissent lorsque le raisonnement n’a pas été posé clairement avant la programmation.

Une variable porte plusieurs rôles

Si prix sert d’abord à stocker le tarif de la saison, puis le total de la commande, tu ne peux plus relire correctement le calcul. Crée deux variables: prix_unitaire et montant_total.

Une condition oublie une partie de la règle

Écrire « si l’âge est inférieur à 4 ans » sans vérifier le transport applique une gratuité trop large. La condition doit reprendre toutes les restrictions fournies par l’énoncé.

Le programme calcule avant d’avoir toutes les réponses

Si montant_total est calculé avant que type_transport ou saison soient connus, le résultat repose sur une valeur par défaut ou sur une ancienne exécution. Trace l’ordre des questions, puis place le calcul à la fin.

Les textes saisis ne correspondent pas aux tests

Le programme demande haute saison, mais la condition recherche haute. Pour Scratch, ces deux réponses sont différentes. Choisis un format unique et répète-le exactement dans les questions, les conditions et les messages.

Les tarifs réels sont présentés comme immuables

Les conditions d’accès au Christ Rédempteur et les tarifs des billets peuvent évoluer. Dans un travail scolaire, indique clairement que les montants utilisés servent à l’exercice. Tu peux écrire dans le premier message du programme: « Simulation pédagogique: les tarifs sont des données d’entraînement. »

Cette phrase protège la qualité du projet: elle montre que tu distingues un modèle mathématique d’un service réel.

Ajouter une amélioration sans désorganiser le script

Une fois la version de base fonctionnelle, tu peux enrichir la simulation. Mais chaque amélioration doit rester reliée à une compétence précise.

Tu peux par exemple:

• afficher une information sur le trajet en train, d’environ 20 minutes;
• rappeler que le sommet du Corcovado se situe à environ 700–710 mètres d’altitude;
• proposer un message différent pour Cosme Velho et pour les points de départ des vans;
• vérifier que l’heure choisie se situe entre 8 h et 19 h;
• contrôler les départs espacés de 30 minutes;
• demander si l’utilisateur souhaite effectuer une nouvelle simulation;
• compter le nombre d’erreurs de saisie;
• afficher séparément les billets gratuits et les billets payants.

Si tu ajoutes une boucle, pense à remettre les variables de la nouvelle simulation à zéro. Sinon, les montants peuvent s’additionner alors que l’utilisateur pense recommencer une commande indépendante.

Tu peux aussi utiliser une liste Scratch pour enregistrer plusieurs visiteurs. Cette extension est plus ambitieuse: elle exige de parcourir les âges un par un, de calculer le tarif correspondant à chaque personne, puis d’additionner les résultats. Ne la choisis que si l’exercice porte sur les répétitions et les listes. Pour un premier travail, une simulation d’un groupe homogène est plus facile à justifier.

La rédaction qui rapporte les derniers points

Le programme peut être juste et la copie pourtant incomplète si tu ne rédiges pas ton raisonnement. Le correcteur doit pouvoir comprendre pourquoi le résultat obtenu est celui que tu affiches.

Dans ton compte rendu, présente:

• les variables créées et leur signification;
• les choix possibles pour la saison et le transport;
• la règle utilisée pour déterminer le prix unitaire;
• la condition concernant les moins de 4 ans;
• la formule du montant total;
• un exemple de test avec les réponses saisies;
• le résultat attendu et le résultat obtenu.

Ne te contente pas d’écrire « le programme fonctionne ». Explique ce que tu as vérifié. Une phrase comme « lorsque le transport est le train et que l’âge est inférieur à 4 ans, la variable de tarif est mise à zéro dans la simulation » est beaucoup plus utile qu’une affirmation générale.

Si tu utilises des tarifs fournis par une fiche, recopie-les sans les modifier. Si tu les choisis toi-même, indique qu’ils sont fictifs. Si une règle n’est pas prise en charge par ton script, ne prétends pas qu’elle l’est. Une limite annoncée clairement vaut mieux qu’une fonctionnalité seulement apparente.

Au moment de relire, observe trois éléments:

1. les noms des variables correspondent-ils réellement à leur contenu?

2. chaque condition possède-t-elle un cas contraire ou un message d’erreur?

3. le récapitulatif final correspond-il exactement aux choix effectués?

La dernière ligne de ta démonstration doit relier le calcul à la situation. Tu ne dois pas terminer par un nombre isolé, mais par une phrase qui précise ce que représente ce nombre: le montant simulé pour le nombre de billets choisi, selon la saison et le transport sélectionnés.

La réussite de cet exercice ne dépend donc pas de ta capacité à copier un script compliqué. Elle repose sur une suite d’actions visibles: définir, demander, tester, calculer, vérifier et justifier. Si tu traces cette chaîne avant de programmer, Scratch devient un outil de raisonnement plutôt qu’un assemblage de blocs. Et c’est précisément cette rigueur, lisible jusque dans la dernière phrase, qui rapporte les points.

Photo: Andy Stuardo L. / CC BY-SA 2.0 — Wikimedia Commons