Gatlinburg SkyPark visite : étapes de programmation Scratch

Gatlinburg SkyPark visite: étapes de programmation Scratch

Il apparaît au moment où il faut transformer une expérience réelle — acheter un billet, monter en télésiège, traverser un pont suspendu, tenir compte de la météo, puis revenir — en une suite d’actions que l’ordinateur peut exécuter dans l’ordre.

Nous remarquons souvent que l’élève connaît les blocs « avancer », « dire » ou « attendre », mais qu’il peine à choisir les informations à mémoriser et les décisions à faire prendre au programme. Le projet devient alors une occasion très concrète de consolider l’algorithmique: nous partons d’une visite du Gatlinburg SkyPark pour bâtir un scénario, organiser des variables, introduire une boucle et comprendre le rôle d’une condition.

Le Gatlinburg SkyPark se trouve à Gatlinburg, dans le Tennessee. Son attraction emblématique est le SkyBridge, un pont suspendu piétonnier long de 680 pieds, soit environ 207 mètres. Le pont atteint 140 pieds, environ 43 mètres, au-dessus du sol, et possède une section centrale de dalles transparentes longue de 30 pieds, un peu plus de 9 mètres. Ces données ne sont pas de simples décorations: elles fournissent une matière idéale pour travailler les conversions, les variables et la représentation à l’échelle.

Anatomie du projet: transformer une visite en algorithme

Avant d’ouvrir Scratch, nous aidons l’élève à raconter la visite dans un ordre suffisamment précis. Une personne peut dire: « On prend le télésiège, puis on traverse le pont. » Pour un programme, cette formulation reste trop vague. Il faut déterminer le point de départ, les étapes intermédiaires, les conditions et le retour.

Le parcours peut être organisé de la manière suivante:

1. Le visiteur arrive au guichet et choisit un type de billet.

2. Le programme calcule le prix total selon le nombre d’adultes et d’enfants retenus dans le scénario.

3. Le visiteur se place au départ du SkyLift.

4. Le télésiège monte progressivement vers le sommet de Crockett Mountain.

5. Le programme vérifie la météo simulée.

6. Si les conditions sont favorables, le visiteur commence la traversée du SkyBridge.

7. Une question permet de distinguer une traversée normale d’une traversée avec appréhension face aux dalles transparentes.

8. Le visiteur atteint l’autre extrémité, puis redescend ou revient au point de départ selon le scénario choisi.

Cette organisation fait apparaître trois familles de notions:

• les variables, qui conservent une information comme le prix, la météo ou la position;
• les boucles, qui répètent une action de montée, de déplacement ou d’affichage;
• les tests conditionnels, qui permettent au programme de choisir entre plusieurs suites d’actions.

L’intérêt pédagogique tient au fait que chaque notion répond à un besoin identifiable. Nous ne plaçons pas une boucle parce qu’elle figure dans le programme du collège: nous l’utilisons parce qu’un télésiège ne passe pas instantanément du bas au sommet. De même, nous introduisons le bloc « si… alors » parce qu’une traversée ne se déroule pas de la même manière selon la météo ou la réaction du visiteur.

Un bon projet Scratch ne commence pas par le choix des lutins: il commence par la question « quelles décisions le programme devra-t-il prendre? ».

Construire le décor sans perdre l’objectif mathématique

Le décor peut représenter une version simplifiée de Gatlinburg SkyPark: un guichet en bas, une ligne de montée, le sommet de Crockett Mountain, le SkyBridge et une zone de retour. Il n’est pas nécessaire de reproduire chaque rocher ni chaque arbre. Une représentation trop détaillée augmente la charge cognitive et détourne l’attention de l’algorithme.

Nous pouvons créer plusieurs arrière-plans:

• Guichet, pour le choix du billet et le calcul du coût;
• Montée, pour représenter le déplacement du SkyLift;
• Sommet, pour annoncer l’arrivée à environ 1 800 pieds au-dessus du niveau de la mer;
• Pont, pour distinguer la partie principale et les 30 pieds de dalles transparentes;
• Retour, pour conclure la simulation.

Les lutins jouent ensuite un rôle fonctionnel. Une nacelle représente le SkyLift, un personnage représente le visiteur, et un petit indicateur peut afficher la météo ou le montant payé. Cette séparation entre le décor et les objets mobiles aide l’élève à comprendre qu’un programme associe un état visuel à des données.

Gestion des variables: calculer le coût des billets

Le billet n’est pas une information isolée dans la simulation. Il peut devenir le point d’entrée vers les variables et les opérations. Pour l’exercice, nous pouvons retenir deux tarifs adultes indiqués aux guichets pour 2026: 39,95 dollars pour un billet adulte standard et 52,95 dollars pour un SkyPass adulte.

Ces montants doivent être présentés comme des données de l’exercice, et non comme une promesse tarifaire permanente. Les prix et les conditions d’accès peuvent évoluer; dans une situation réelle, l’élève apprend aussi à distinguer une donnée utilisée pour modéliser d’une information à vérifier avant une visite.

Nous pouvons créer les variables suivantes:

• nombre d’adultes;
• tarif adulte;
• type de billet;
• total;
• éventuellement nombre d’enfants, si l’on souhaite enrichir le scénario avec une autre catégorie tarifaire.

Pour une première version, le programme peut demander le nombre d’adultes, puis poser une question sur le choix du billet:

• si la réponse est « standard », le tarif adulte prend la valeur 39,95;
• si la réponse est « SkyPass », le tarif adulte prend la valeur 52,95;
• le total est ensuite obtenu en multipliant le nombre d’adultes par le tarif choisi.

Dans Scratch, les blocs de question et de réponse permettent de rendre le programme interactif. L’élève peut utiliser « demander… et attendre », puis affecter la réponse à une variable. L’opération « mettre total à… » devient alors une traduction directe du calcul mathématique.

Une difficulté fréquente: confondre donnée et action

Un élève peut vouloir créer une variable appelée acheter billet, alors qu’un achat n’est pas une valeur conservée de la même manière qu’un nombre. Nous pouvons l’amener à distinguer:

• une donnée, comme le prix ou le nombre de billets;
• une action, comme afficher un message ou déplacer un lutin;
• une décision, comme poursuivre la visite si la météo est favorable.

Cette distinction paraît simple, mais elle participe à l’ancrage de la pensée algorithmique. Une variable ne sert pas à « faire quelque chose » par elle-même: elle conserve une information que d’autres blocs vont utiliser.

Le calcul peut être enrichi progressivement. Par exemple, l’élève peut comparer le prix de deux adultes avec un billet standard et le prix de deux SkyPass. Il ne s’agit pas seulement d’obtenir un résultat numérique. Il s’agit de comprendre qu’un changement de valeur dans une variable entraîne des conséquences sur le reste du programme.

Nous pouvons aussi demander au programme d’afficher une phrase complète: « Le groupe paie 79,90 dollars » pour deux billets standards, ou « Le groupe paie 105,90 dollars » pour deux SkyPass. Les nombres sont alors replacés dans une situation compréhensible, ce qui facilite le passage entre le calcul formel et son interprétation.

Algorithme de montée: programmer le trajet du SkyLift

Le SkyLift est un support particulièrement efficace pour comprendre la différence entre une position de départ et une série de déplacements. L’accès au sommet de Crockett Mountain s’effectue par un télésiège historique, dont le trajet dure environ 9 à 10 minutes dans chaque sens. Dans Scratch, nous ne cherchons pas à reproduire cette durée réelle à la seconde près. Nous construisons une échelle de temps adaptée à l’activité.

Le lutin de la nacelle peut commencer aux coordonnées correspondant à la station inférieure. Pour le faire monter, deux approches sont possibles.

Première approche: un déplacement continu

Nous pouvons utiliser un bloc de type « glisser en X secondes à x: … y: … ». La nacelle se déplace alors directement vers la position du sommet. Cette méthode est rapide à programmer et permet de visualiser immédiatement la montée.

Elle présente toutefois une limite didactique: l’élève voit le mouvement, mais il ne perçoit pas nécessairement les étapes qui le composent. Le programme exprime un trajet global, pas une progression détaillée.

Cette approche convient lorsque l’objectif principal est de relier un événement à un changement de décor:

1. le visiteur appuie sur un bouton;

2. la nacelle glisse vers le sommet;

3. le décor change;

4. le programme annonce l’arrivée.

Deuxième approche: une boucle de déplacement

Pour travailler plus précisément la répétition, nous pouvons modifier progressivement la coordonnée verticale du lutin. Le principe est le suivant: tant que la nacelle n’a pas atteint le sommet, elle avance d’une petite distance, attend un court instant, puis recommence.

Dans Scratch, cette logique peut être construite avec une boucle « répéter jusqu’à » ou avec une boucle « répéter » contenant une modification de la position en y. La montée est alors décomposée en une succession de petits mouvements. L’élève observe que la boucle ne signifie pas « monter » en général: elle répète une instruction selon une règle donnée.

Un scénario simplifié pourrait suivre cette logique:

1. placer la nacelle au bas de l’écran;

2. fixer la position verticale du sommet;

3. répéter le déplacement d’une petite valeur;

4. attendre quelques dixièmes de seconde;

5. arrêter la boucle lorsque la nacelle atteint la zone supérieure;

6. envoyer un message annonçant l’arrivée.

Nous évitons de donner une valeur de coordonnées universelle, car elle dépend du décor choisi et de la taille de la scène. L’essentiel est que l’élève sache identifier la position cible et relier cette position à l’arrêt de la boucle.

Le lien avec les 9 à 10 minutes

La durée réelle du trajet peut être utilisée pour introduire une échelle. Par exemple, nous pouvons décider que 1 seconde dans Scratch représente 1 minute de trajet, puis programmer une montée de 9 secondes. Une autre simulation peut choisir 1 seconde pour 30 secondes réelles afin d’obtenir une animation plus longue.

Le point important est de faire déclarer cette convention par l’élève. Sans cette explicitation, le nombre de secondes affiché n’a pas de signification. Avec elle, il devient une donnée de modélisation: nous savons que le programme simplifie la réalité pour la rendre manipulable.

Cette étape permet également de discuter de la différence entre:

• la durée réelle, fournie par la description de la visite;
• la durée simulée, choisie pour des raisons pratiques;
• la vitesse d’animation, qui dépend du nombre de pixels parcourus à chaque répétition.

Ces trois notions sont souvent confondues. Les séparer aide à consolider les premières représentations de la modélisation.

La simulation n’a pas besoin d’être réaliste à chaque détail; elle doit être explicite dans les choix qui la rendent compréhensible.

Logique conditionnelle: météo, vertige et décisions du visiteur

Une visite virtuelle devient réellement algorithmique lorsque le programme ne suit plus toujours le même chemin. Le test conditionnel introduit cette bifurcation. Dans le cas du Gatlinburg SkyPark, la météo constitue un exemple naturel: les opérations du parc peuvent être suspendues en cas d’orage.

Nous pouvons simuler le climat avec une variable météo. Pour ne pas présenter un fonctionnement artificiel comme une information météorologique réelle, nous précisons que le programme produit simplement une situation aléatoire. Scratch peut choisir un nombre aléatoire entre 1 et 2:

• 1 correspond à une météo favorable;
• 2 correspond à un risque d’orage.

Le programme utilise ensuite une structure « si… alors… sinon »:

• si la météo est favorable, alors la visite continue vers le SkyBridge;
• sinon, le personnage affiche un message indiquant que la traversée est suspendue dans la simulation et revient vers la zone d’attente.

Cette activité permet d’observer qu’une condition comporte toujours trois éléments: une question, une action si la réponse est vraie et une autre possibilité lorsque la réponse est fausse. Nous pouvons demander à l’élève de reformuler le test en langage courant avant de le programmer: « Est-ce que la météo permet de poursuivre? »

Programmer la réaction face aux dalles transparentes

La partie centrale du SkyBridge comporte environ 30 pieds de dalles de verre transparent. Dans la simulation, ce passage peut devenir un second test conditionnel, cette fois lié au choix du visiteur.

Le programme demande par exemple: « Veux-tu traverser la section vitrée? » La réponse peut entraîner deux comportements:

• si le visiteur répond « oui », le lutin avance sur la zone transparente et affiche un message d’encouragement;
• s’il répond « non », le personnage s’arrête, décrit son hésitation, puis choisit une autre action prévue dans le scénario.

Nous veillons ici à ne pas transformer l’appréhension en échec. L’objectif n’est pas de punir une réponse ou de forcer un comportement, mais de montrer qu’un même parcours peut comporter plusieurs branches. Cette posture est importante dans un exercice d’apprentissage: l’erreur ou l’hésitation devient une information utilisée par le programme.

Le projet peut distinguer trois situations:

1. Météo favorable et traversée acceptée: le personnage franchit le pont jusqu’à l’autre extrémité.

2. Météo favorable mais appréhension: le personnage avance jusqu’à la section vitrée, puis choisit de s’arrêter.

3. Orage simulé: le programme ne lance pas la traversée et affiche une consigne de retour.

Nous obtenons ainsi un arbre de décisions sans avoir besoin d’un scénario compliqué. Chaque branche peut être testée séparément, ce qui facilite le débogage.

Utiliser les messages pour organiser les scènes

Les blocs « envoyer à tous le message… » et « quand je reçois… » sont particulièrement utiles pour coordonner les lutins et les décors. La montée peut envoyer le message arrivée au sommet. Le décor réagit alors en passant à la scène du pont, tandis que le personnage affiche une nouvelle consigne.

Une organisation possible est la suivante:

• départ visite lance le calcul du billet;
• billet validé déclenche la montée;
• arrivée au sommet lance le test météo;
• traversée autorisée active le lutin du visiteur;
• fin du pont déclenche le retour;
• visite suspendue affiche une conclusion alternative.

Ce découpage évite de placer toutes les instructions dans un seul script interminable. Il rend le projet plus lisible et aide l’élève à comprendre que plusieurs objets peuvent coopérer grâce à des événements.

Défis techniques: représenter le pont, la hauteur et les unités

Les dimensions du SkyBridge offrent une occasion de travailler la proportionnalité. Sa longueur réelle est de 680 pieds, soit environ 207 mètres. Le programme ne peut pas afficher 207 mètres dans une scène Scratch de manière littérale: il faut choisir une échelle.

Supposons que nous décidions que 1 unité de la scène représente 1 mètre. La largeur disponible à l’écran ne suffira pas pour représenter les 207 mètres en conservant une taille lisible. Nous pouvons donc choisir une échelle plus petite, par exemple 1 centimètre sur le dessin pour 10 mètres dans la réalité, ou une correspondance abstraite entre une certaine longueur de la scène et la longueur totale du pont.

L’élève peut alors répondre à plusieurs questions:

• quelle longueur de la scène représentera les 207 mètres?
• quelle longueur représentera les 9 mètres de la section vitrée?
• comment conserver la même échelle pour les deux parties?
• quelle proportion de l’ensemble du pont correspond à la zone transparente?

La section vitrée représente environ 9 mètres sur 207, soit un peu plus de 4 % de la longueur totale. Dans un dessin très réduit, cette zone risque de devenir presque invisible. Nous pouvons donc choisir de l’agrandir visuellement, à condition d’indiquer que le décor n’est plus strictement à l’échelle. Cette discussion est précieuse: elle montre qu’un modèle peut être fidèle sur certains aspects et simplifié sur d’autres.

Représenter la hauteur sans créer une fausse perspective

Le pont s’élève jusqu’à environ 43 mètres au-dessus du sol. Le sommet de Crockett Mountain est indiqué à environ 1 800 pieds au-dessus du niveau de la mer. Ces deux mesures ne décrivent pas la même chose:

• les 43 mètres correspondent à la hauteur du pont par rapport au sol;
• les 1 800 pieds correspondent à l’altitude du sommet.

Il faut éviter de les additionner ou de les placer sur un même axe sans explication. Dans Scratch, nous pouvons représenter la hauteur du pont par un déplacement vertical du décor, tandis que l’altitude du sommet apparaît dans un message ou dans une variable informative.

Cette distinction donne lieu à une erreur classique: l’élève associe automatiquement tous les nombres exprimés en pieds ou en mètres et les traite comme des longueurs comparables. Nous pouvons l’aider à identifier la référence de chaque mesure avant toute opération. Une grandeur n’est pas définie seulement par son unité; elle est aussi liée à ce qu’elle mesure.

Faire apparaître la section vitrée

Pour rendre les 30 pieds de dalles transparentes visibles, le décor du pont peut être divisé en trois parties:

• une portion d’approche;
• une portion centrale en verre;
• une portion de sortie.

Le lutin du visiteur envoie un message lorsqu’il atteint la zone centrale. Le programme peut alors changer le costume du personnage, afficher une question ou modifier l’arrière-plan. Cette technique aide à associer une position à un événement.

Une difficulté intéressante apparaît lorsque le lutin avance trop vite et traverse directement la zone vitrée sans déclencher le message. Nous pouvons ralentir le déplacement, réduire la distance parcourue à chaque répétition ou vérifier la position après chaque mouvement. L’élève découvre ainsi qu’un programme ne réagit pas seulement à ce que nous voyons à l’écran: il dépend de la fréquence à laquelle il vérifie les conditions.

Comparer deux approches pédagogiques pour construire le projet

Pour accompagner un collégien, deux méthodes sont particulièrement fréquentes.

Commencer par le décor et les animations

Cette approche est motivante. L’élève dessine le pont, choisit les couleurs, ajoute la nacelle, puis obtient rapidement une animation visible. Elle convient bien à une première prise en main de Scratch et permet de réduire l’appréhension devant l’écran.

Mais elle atteint vite ses limites. Le programme peut être joli sans être véritablement structuré. Les variables arrivent tard, les événements sont parfois empilés dans un seul script et les décisions du visiteur restent implicites. L’élève risque alors de confondre réussite visuelle et réussite algorithmique.

Commencer par le scénario et les données

Cette deuxième approche demande davantage de préparation. Nous écrivons d’abord les étapes, listons les variables, repérons les choix et décidons de l’échelle. Le décor n’est construit qu’après cette phase de conception.

L’avantage est une meilleure consolidation des notions. Chaque élément visuel correspond à une fonction du programme. La nacelle représente une boucle de déplacement, le billet met en jeu une opération, la météo introduit une condition et la section vitrée permet de créer une branche supplémentaire.

La seconde méthode est généralement plus efficace lorsque l’objectif porte sur l’algorithmique. Nous pouvons néanmoins conserver une part de manipulation graphique. Le décor n’est pas l’ennemi de la rigueur; il devient utile lorsqu’il rend une variable ou une décision visible.

Déboguer la simulation sans décourager l’apprenant

Un projet de visite virtuelle offre de nombreuses occasions d’erreur, et c’est précisément ce qui le rend formateur. La nacelle peut ne jamais atteindre le sommet, le prix peut rester à zéro, la météo peut empêcher systématiquement la traversée ou le personnage peut franchir le pont en sens inverse.

Pour aider l’élève, nous pouvons examiner les erreurs dans un ordre stable:

1. Le programme démarre-t-il au bon endroit?

Les variables doivent être réinitialisées au lancement. Sans cette remise à zéro, un ancien prix ou une ancienne position peut rester mémorisé.

2. Les valeurs sont-elles du bon type?

Une réponse saisie comme texte, telle que « standard », ne se compare pas de la même manière qu’un nombre. Le programme doit prévoir exactement les réponses attendues ou accepter plusieurs formulations.

3. La boucle possède-t-elle une condition d’arrêt?

Si la nacelle augmente sa position sans jamais atteindre la valeur cible, la répétition peut se poursuivre indéfiniment.

4. Les tests couvrent-ils les deux possibilités?

Un bloc « si… alors » sans alternative peut laisser le programme silencieux lorsque la condition est fausse. Dans une simulation, il est souvent préférable d’afficher une explication ou de prévoir un retour.

5. Les messages sont-ils envoyés au bon moment?

Le changement de décor ne doit pas se produire avant l’arrivée de la nacelle. Nous vérifions la relation entre la fin de la boucle et l’envoi du message.

6. Le modèle utilise-t-il une échelle cohérente?

Si les 9 mètres de verre occupent la moitié du dessin alors que les 207 mètres du pont tiennent dans la même largeur, le programme doit signaler qu’il s’agit d’une représentation volontairement agrandie.

Cette démarche de débogage contribue à une posture plus constructive. Au lieu de demander à l’élève de « corriger son programme » sans indication, nous l’aidons à localiser l’endroit où l’information cesse d’être correctement transmise.

Aller plus loin: rendre la visite interactive

Une première simulation peut rester courte. Une version plus ambitieuse peut intégrer plusieurs visiteurs, un choix de parcours ou une comparaison entre les billets.

Le programme peut par exemple proposer un menu:

• visiter uniquement le SkyBridge;
• effectuer l’aller-retour avec le SkyLift;
• choisir le SkyPass;
• quitter la simulation.

Chaque choix déclenche une partie différente du scénario. Nous pouvons aussi ajouter une variable temps de visite qui augmente à chaque étape, sans prétendre reproduire la durée réelle de l’expérience. Le but est d’observer comment plusieurs variables évoluent ensemble.

Une autre piste consiste à demander au programme d’afficher les conversions:

• 680 pieds correspondent à environ 207 mètres;
• 140 pieds correspondent à environ 43 mètres;
• 30 pieds correspondent à environ 9 mètres;
• 1 800 pieds correspondent à environ 549 mètres.

Ces valeurs arrondies doivent être traitées comme des conversions approximatives. L’élève peut comparer le résultat obtenu avec une conversion plus précise, puis décider du niveau de précision adapté à son décor. Cette étape permet de parler d’arrondi sans l’isoler dans une série de calculs abstraits.

Nous pouvons également proposer une version sans aléatoire, dans laquelle la météo est choisie par l’utilisateur. Cette variante est utile pour vérifier chaque branche du programme. Une fois les tests réalisés, le tirage aléatoire peut être réintroduit pour rendre la visite moins prévisible.

Ce que l’exercice permet réellement d’apprendre

L’activité n’a pas pour objectif de reproduire fidèlement toutes les fonctionnalités du parc ni de fournir un guide de réservation. Elle associe un contexte touristique concret à des compétences de programmation adaptées au collège.

L’élève apprend notamment à:

• décomposer une situation en étapes ordonnées;
• identifier les informations qui doivent être conservées;
• traduire un calcul en variables et en opérations;
• répéter une action avec une boucle;
• faire prendre une décision au programme;
• utiliser des messages pour coordonner plusieurs objets;
• représenter une grandeur réelle avec une échelle choisie;
• tester un scénario et analyser une erreur.

Nous pouvons aussi rattacher le projet à une recherche documentaire plus large sur les billets et les conditions de visite du Gatlinburg SkyPark. L’objectif est alors de distinguer les informations utiles à la préparation concrète d’un séjour des données retenues uniquement pour la modélisation Scratch.

La progression la plus solide reste graduelle:

1. créer le parcours avec deux ou trois scènes;

2. programmer le déplacement de la nacelle;

3. ajouter le calcul du billet;

4. introduire la météo;

5. intégrer la section vitrée;

6. vérifier séparément chaque branche;

7. améliorer l’apparence seulement après stabilisation de la logique.

Cette succession étaye l’apprentissage. Elle évite de demander simultanément à l’élève de gérer le dessin, les coordonnées, les variables et les conditions. En réduisant la charge cognitive à chaque étape, nous lui permettons de comprendre la fonction de chaque bloc avant de les combiner.

Une recommandation pour accompagner l’enfant

Pour ce type de projet, le matériel le plus utile n’est pas nécessairement une fiche remplie de consignes. Une feuille de préparation avec quatre colonnes suffit souvent:

Ce support tangible aide à externaliser une partie du raisonnement. L’enfant n’a plus besoin de retenir toute l’architecture du programme en même temps: il peut relier chaque ligne à une action, une donnée ou une décision. Nous pouvons ensuite passer de la feuille à Scratch, puis revenir à la feuille lorsque le programme se comporte de manière inattendue.

La simulation du Gatlinburg SkyPark fonctionne ainsi comme un petit laboratoire de pensée algorithmique. Le télésiège donne du sens à la boucle, le billet rend les variables nécessaires, la météo justifie la condition et le SkyBridge fournit une situation riche pour travailler l’échelle et les repères. En bâtissant le projet dans cet ordre, nous ne cherchons pas à produire une animation spectaculaire dès la première minute. Nous consolidons d’abord la logique, puis nous lui donnons une forme visible et manipulable.

C’est cette progression qui transforme une visite virtuelle en véritable exercice Scratch au collège: le décor attire l’attention, mais ce sont les décisions programmées, les données organisées et les erreurs analysées qui construisent la compréhension.