La variable Scratch et les tarifs des billets Cedar Point

En 2026, le tarif d’entrée acheté directement au guichet atteint un niveau inédit pour le parc, tandis que les billets réservés en ligne commencent nettement plus bas. Pour un élève, cette situation réelle devient un excellent support pour construire un algorithme Scratch.

Sandusky

Billets et tarifs

Cedar Point

★4,0/5 · 19 avisTarifs vérifiés le 27 août 2026Places limitées

Billet d'entrée — 14 places restantes aujourd'hui

★4,0·19 avis

dès55.93 USD

Réserver des billets

Billet officiel — admission journalière

dès49 USD

Réserver des billets

Billetterie officielle et achat en ligne

Plein tarif49 USD

Site officiel — sixflags.com

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

L’objectif n’est pas de recopier un prix affiché sur une page de réservation. Ce prix peut évoluer. L’objectif est de traduire une règle de calcul: saisir un tarif, appliquer une réduction éventuelle, ajouter un coût complémentaire, puis afficher le résultat. C’est exactement le rôle d’une variable Scratch.

Dans un exercice Scratch au collège, tu dois donc raisonner en trois temps:

1. identifier les données qui peuvent changer;

2. stocker ces données dans des variables;

3. rédiger une formule lisible et vérifier le résultat.

Le programme ne doit pas seulement fonctionner. Il doit montrer au correcteur que tu as compris la situation et que chaque valeur utilisée a une fonction précise.

L’évolution tarifaire de Cedar Point: une donnée réelle pour l’algorithmique

Cedar Point, situé à Sandusky dans l’Ohio, propose plusieurs façons d’acheter une entrée. Le visiteur peut réserver à l’avance sur internet ou acheter son billet sur place. Ces deux choix ne correspondent pas au même tarif.

Les données disponibles montrent une évolution irrégulière du prix au guichet:

• le tarif a progressé au début des années 2020;
• une baisse temporaire a été observée en 2023;
• le prix est remonté l’année suivante;
• les nouvelles attractions et la politique commerciale du parc ont accompagné de nouvelles variations;
• en 2026, le tarif au guichet atteint un niveau particulièrement élevé.

Cette évolution suffit à montrer pourquoi un exercice Scratch ne doit pas enfermer une donnée dans une phrase ou dans un seul bloc de calcul. Si le tarif change, tu dois pouvoir modifier une variable sans reconstruire tout le programme.

Une bonne variable n’est pas seulement une boîte qui contient un nombre: c’est une information que ton programme doit pouvoir réutiliser et modifier.

Dans une situation d’achat de billets Cedar Point, les données possibles sont nombreuses. Le programme peut par exemple demander:

• le prix d’un billet acheté en ligne;
• le nombre de visiteurs;
• le tarif d’un billet au guichet;
• une réduction appliquée à certains visiteurs;
• le montant du stationnement;
• le choix entre une entrée simple et une formule plus large.

Tu ne dois pas toutes les utiliser automatiquement. Un exercice bien construit commence par une lecture attentive de l’énoncé. Si la consigne demande seulement de calculer le prix de trois entrées avec une réduction, ajouter une variable consacrée au parking ne rapporte aucun point. Cela rend même le programme plus difficile à suivre.

Distinguer les informations fixes et les informations variables

Une donnée fixe reste identique pendant toute l’exécution du programme. Une donnée variable dépend de la réponse de l’utilisateur ou du scénario choisi.

Prenons une situation simple: le programme doit calculer le coût d’une visite pour plusieurs personnes. Le nombre de billets est variable, car l’utilisateur peut saisir une valeur différente. Le prix unitaire peut être placé dans une variable s’il doit être réutilisé dans plusieurs calculs. Le nom du parc, lui, n’a pas besoin d’être stocké dans une variable si le programme porte uniquement sur Cedar Point.

Cette distinction est une étape de méthode. Si tu l’oublies, tu risques de mélanger les données saisies, les valeurs intermédiaires et le résultat final.

Créer les variables Scratch sans perdre la logique du calcul

Pour modéliser le prix ticket Cedar Point, commence par créer des variables dont le nom décrit réellement leur contenu. Évite les appellations vagues comme a, b ou nombre1, sauf si l’énoncé les impose.

Des noms plus efficaces sont:

• nombre de billets;
• prix unitaire;
• réduction;
• frais supplémentaires;
• total.

Scratch accepte les noms comportant plusieurs mots. Profite-en: un nom précis facilite la lecture du programme et la vérification finale.

1. Créer la variable

Dans la catégorie « Variables », sélectionne « Créer une variable ». Donne-lui un nom compréhensible, puis choisis si elle doit être accessible à tous les objets ou seulement au sprite concerné.

Pour un exercice simple, une variable utilisable par le programme entier suffit généralement. Si plusieurs sprites interviennent, la portée de la variable peut devenir un choix à justifier. Ne transforme toutefois pas une question de collège en problème d’architecture informatique: choisis la solution la plus lisible.

2. Donner une valeur de départ

Le bloc « mettre [variable] à » sert à attribuer une valeur. Tu peux l’utiliser pour enregistrer un tarif connu dans l’énoncé.

Par exemple, le programme peut commencer par:

• mettre prix unitaire à la valeur indiquée;
• mettre réduction à zéro si aucune réduction n’est prévue au départ;
• mettre frais supplémentaires à zéro si le stationnement n’est pas choisi.

Cette initialisation évite de laisser une ancienne valeur dans la mémoire du programme. Si tu relances le projet sans remettre les variables à zéro, le résultat peut dépendre d’une exécution précédente. C’est une erreur discrète, mais elle suffit à fausser une vérification.

3. Calculer dans le bon ordre

Le calcul dépend de la règle donnée. Pour plusieurs billets identiques, le prix brut s’écrit:

nombre de billets × prix unitaire

Si une réduction est ensuite soustraite, le total devient:

prix brut − réduction

Si des frais sont ajoutés à la fin:

prix brut − réduction + frais supplémentaires

Dans Scratch, tu construis cette formule avec les blocs opérateurs. Observe bien les emboîtements. Une multiplication placée au mauvais endroit peut modifier toute la logique.

Supposons que la réduction concerne l’ensemble de la commande. Tu dois d’abord calculer le prix de tous les billets, puis retirer la réduction. Si elle concerne chaque billet, la formule n’est pas la même: tu dois réduire le prix unitaire avant de multiplier par le nombre de billets.

Cette différence est fréquente dans les exercices. Le mot « réduction » ne suffit pas à déterminer la formule. Tu dois observer ce que la réduction porte sur: un billet, un groupe de billets ou le total de la commande.

La rédaction qui accompagne la formule

Même lorsque Scratch donne directement le résultat, écris la relation utilisée dans ton brouillon. Par exemple:

• prix brut = nombre de billets × prix unitaire;
• total = prix brut − réduction;
• montant final = total + frais supplémentaires.

Cette rédaction te permet de contrôler le programme avant de l’exécuter. Elle rapporte aussi des points de justification lorsque l’exercice demande d’expliquer la méthode.

Utiliser « demander et attendre » avec la variable « réponse »

Un programme devient réellement interactif lorsque l’utilisateur peut saisir les informations nécessaires. Pour cela, Scratch utilise le bloc « demander [question] et attendre ».

Après l’exécution de ce bloc, la valeur saisie est conservée dans la variable spéciale « réponse ». Tu peux alors utiliser cette valeur dans le bloc « mettre [variable] à ».

Pour une simulation d’achat de billets Cedar Point, l’ordre peut être le suivant:

1. demander le nombre de billets;

2. mettre nombre de billets à réponse;

3. demander le prix unitaire;

4. mettre prix unitaire à réponse;

5. calculer le prix brut;

6. demander le montant de la réduction si l’énoncé le prévoit;

7. calculer le total;

8. afficher le résultat.

Le bloc « réponse » ne doit pas être utilisé trop tard. Dès qu’une nouvelle question est posée, la réponse précédente est remplacée. Si tu demandes d’abord le nombre de billets, puis le tarif, mais que tu oublies de copier la première réponse dans nombre de billets, le programme ne conservera pas correctement les deux informations.

Une question claire produit une donnée exploitable

Écris des questions qui indiquent l’unité ou la nature de la valeur attendue:

• « Combien de billets veux-tu acheter? »
• « Quel est le tarif d’un billet? »
• « Quel montant de réduction dois-tu appliquer? »

Une question vague comme « Donne une valeur » oblige l’utilisateur à deviner ce qu’il doit saisir. Le programme peut alors fonctionner techniquement, mais la communication est insuffisante. Dans une évaluation, la clarté de l’algorithme compte.

Ne demande pas non plus une donnée que le programme peut calculer. Si l’énoncé fixe la réduction, l’utilisateur n’a pas à la saisir. La valeur doit être enregistrée directement dans la variable correspondante. Tu évites ainsi une saisie inutile et tu respectes la consigne.

Vérifier le type de donnée

Dans ce type d’exercice, les réponses saisies sont généralement numériques. Scratch peut ensuite les multiplier, les additionner ou les soustraire.

Une erreur classique consiste à demander une information sous forme de texte, puis à essayer de l’utiliser comme un nombre. Si le programme demande « en ligne ou au guichet? », la réponse est un choix textuel. Elle ne peut pas être multipliée directement par le nombre de visiteurs. Il faut d’abord utiliser une condition pour associer ce choix à un tarif.

La logique devient alors:

• si le choix est « en ligne », utiliser le tarif en ligne;
• sinon, utiliser le tarif au guichet;
• puis multiplier par le nombre de billets.

Tu ne dois pas confondre le choix d’une formule avec sa valeur numérique.

Afficher le résultat avec l’opérateur « regrouper »

Un calcul juste mais invisible ne permet pas à l’utilisateur de comprendre ce que le programme a produit. Pour afficher un message complet, utilise l’opérateur « regrouper ».

Cet opérateur permet de combiner un texte et la valeur d’une variable. Tu peux ainsi construire un message du type:

« Le coût total de ta visite à Cedar Point est de » + total

Dans Scratch, le bloc « regrouper » assemble les deux éléments. La première partie contient le texte; la seconde contient la variable total.

Tu peux également ajouter l’unité dans le message:

« Total à payer: » + total + « dollars »

Pour obtenir trois éléments, imbrique deux blocs « regrouper ». Le résultat doit rester lisible à l’écran. Une phrase complète est préférable à une suite de nombres sans explication.

Afficher les étapes intermédiaires

Dans un exercice d’apprentissage, afficher uniquement le total ne suffit pas toujours. Tu peux présenter successivement:

• le nombre de billets choisi;
• le prix brut;
• la réduction appliquée;
• le total final.

Cette présentation facilite la vérification visuelle. Si le prix brut est déjà faux, tu sais que l’erreur se trouve dans la multiplication. Si le prix brut est correct mais que le total ne l’est pas, observe la soustraction de la réduction.

Attention toutefois à ne pas multiplier les messages sans raison. Le programme doit accompagner le raisonnement, pas noyer l’utilisateur sous des informations répétées.

Arrondir seulement si la consigne le demande

Les tarifs peuvent comporter des décimales. Si une réduction produit un montant non entier, conserve la précision demandée par l’énoncé. N’arrondis pas spontanément.

Un arrondi effectué trop tôt peut modifier le résultat final. La méthode la plus sûre consiste à réaliser les opérations dans l’ordre, puis à arrondir à la fin si la consigne l’exige.

Dans Scratch, le résultat affiché doit être la dernière étape du raisonnement, pas un nombre sorti de nulle part.

Comparer l’achat en ligne et le guichet

Le thème Cedar Point billets permet de construire un exercice plus complet: comparer deux modes d’achat.

Le programme peut demander le nombre de billets, puis proposer deux tarifs:

• un tarif pour un achat anticipé en ligne;
• un tarif appliqué au guichet le jour de la visite.

Les données réelles du parc montrent que l’achat en ligne peut être nettement plus avantageux que l’achat sur place. Mais les tarifs évoluent. Dans un projet Scratch, place donc ces deux valeurs dans des variables plutôt que de les écrire à plusieurs endroits du programme.

Crée:

• prix en ligne;
• prix guichet;
• nombre de billets;
• total en ligne;
• total guichet;
• écart.

Les formules sont simples:

• total en ligne = prix en ligne × nombre de billets;
• total guichet = prix guichet × nombre de billets;
• écart = total guichet − total en ligne.

Le programme peut ensuite afficher les deux totaux et l’écart entre eux. Tu obtiens une comparaison claire, directement liée à une décision pratique.

Ajouter le stationnement sans compliquer le projet

Le parking peut être intégré comme un coût supplémentaire. Dans les données disponibles, le stationnement standard représente une dépense distincte du billet d’entrée. Il ne faut donc pas l’inclure dans le prix unitaire du billet.

Crée une variable parking, puis ajoute-la au total:

total de la visite = total des billets + parking

Si le parking est choisi uniquement dans certains cas, ajoute une question ou une condition:

• si l’utilisateur vient en voiture, ajouter le coût du parking;
• sinon, mettre parking à zéro.

Cette organisation est plus rigoureuse que l’ajout direct d’un nombre dans une formule. Elle montre la différence entre le prix de l’entrée et les frais liés à la visite.

Tester plusieurs scénarios

Un seul essai ne prouve pas que ton algorithme est correct. Prépare plusieurs cas de test:

1. une seule personne achète un billet en ligne;

2. plusieurs personnes achètent le même tarif;

3. le choix se porte sur le guichet;

4. aucune réduction n’est appliquée;

5. une réduction est appliquée;

6. le parking est ajouté;

7. le nombre de billets vaut une valeur minimale autorisée.

Pour chaque test, calcule le résultat à la main sur ton brouillon. Lance ensuite Scratch et compare les valeurs. Si le programme donne un résultat différent, ne modifie pas immédiatement les variables au hasard. Reprends la formule, puis observe chaque bloc.

Les erreurs qui coûtent des points dans un exercice Scratch

Les erreurs les plus fréquentes ne viennent pas d’un calcul difficile. Elles apparaissent lorsque l’élève ne suit pas le trajet des données.

Écraser la réponse précédente

Tu poses une question, puis une deuxième. Si tu n’enregistres pas la première réponse dans une variable, elle disparaît lorsque la seconde question est posée.

La correction est directe: après chaque bloc « demander et attendre », place immédiatement un bloc « mettre [variable] à réponse ».

Multiplier la réduction au mauvais endroit

Une réduction sur la commande entière ne se traite pas comme une réduction par billet. Relis l’énoncé et écris la formule avant de construire les blocs.

Mélanger les tarifs en ligne et au guichet

Les billets Cedar Point achetés en ligne et les billets pris sur place ne doivent pas être placés dans une seule variable si le programme doit comparer les deux options. Utilise deux variables distinctes et donne-leur des noms explicites.

Ajouter le parking au mauvais prix

Le parking n’est pas un billet. Si tu calcules un tarif moyen ou un prix par personne, ne répartis pas automatiquement le parking entre les visiteurs: cela dépend de la consigne.

Afficher seulement un nombre

Le message final doit préciser ce que représente le résultat. « 240 » ne signifie pas clairement qu’il s’agit du coût total. Préfère une phrase avec le contexte et l’unité.

Ne pas remettre les variables à zéro

Un programme relancé peut conserver certaines valeurs si elles ne sont pas réinitialisées. Place les blocs d’initialisation au début du script, avant les questions et les calculs.

Une méthode de brouillon pour construire ton programme

Avant d’ouvrir Scratch, trace un tableau de variables. Cette préparation prend peu de temps et évite les erreurs de structure.

Ensuite, rédige la suite des actions en phrases courtes:

1. demander le nombre de billets;

2. mémoriser la réponse;

3. demander ou sélectionner le tarif;

4. calculer le prix brut;

5. appliquer la réduction;

6. ajouter le parking si nécessaire;

7. afficher le total.

Cette liste joue le rôle d’un plan de construction. Elle te permet de repérer une donnée manquante avant même de créer le premier bloc.

Pour une vérification visuelle, suis la valeur de total avec ton doigt à l’écran. Observe le bloc qui lui attribue une valeur, puis chacun des nombres utilisés. Si un nombre apparaît directement dans une formule alors qu’il devrait être modifiable, remplace-le par la variable correspondante.

Ce que le correcteur doit pouvoir lire

Un exercice Scratch est évalué sur le fonctionnement, mais aussi sur la compréhension de l’algorithme. Le correcteur cherchera à lire une organisation cohérente:

• les variables portent des noms compréhensibles;
• les réponses sont mémorisées au bon moment;
• les calculs suivent l’ordre de l’énoncé;
• les choix entre achat en ligne et guichet sont séparés;
• le message final indique clairement le résultat;
• les tests permettent de vérifier plusieurs situations.

Ne cache pas ton raisonnement derrière un programme qui fonctionne par hasard. Si tu dois expliquer ton algorithme, indique quelle variable contient chaque donnée et pourquoi la formule est construite dans cet ordre.

Le vocabulaire de l’évaluation est simple: une variable correctement choisie peut rapporter les points liés à la modélisation; une formule bien traduite sécurise les points de calcul; une justification lisible évite de perdre les points de rédaction.

Pour terminer: la précision qui rapporte le dernier point

Pour réussir cet exercice, tu n’as pas besoin de mémoriser les tarifs de Cedar Point. Tu dois savoir transformer une situation concrète en données, variables et opérations. Les tarifs réels servent de contexte; la compétence évaluée concerne la construction de l’algorithme.

Commence par tracer les informations. Donne un nom à chaque valeur qui peut changer. Utilise « demander et attendre », copie immédiatement la valeur de « réponse », puis calcule dans l’ordre indiqué. Termine avec « regrouper » pour afficher une phrase compréhensible.

Et surtout, rédige la formule sur ton brouillon avant de déplacer les blocs. La dernière ligne de ton explication doit préciser ce que représente le résultat obtenu: le total des billets, le coût complet de la visite ou l’écart entre l’achat en ligne et le guichet. C’est ce détail de rédaction qui montre que tu ne t’es pas contenté de faire fonctionner Scratch: tu as réellement modélisé la situation.

Photo: Larry Pieniazek, User:Lar , en:User:Lar (primary) / CC BY 2.5 — Wikimedia Commons