Selwo Aventura visite : un algorithme Scratch pas à pas

Selwo Aventura visite: un algorithme Scratch pas à pas

Le programme donne alors un résultat plausible, mais faux.

Selwo Aventura

4,3· 123 avis

Réserver des billetsdès 19.90 €

• Billet d'entrée — 8-64 ansdès19.90 €

Au guichet19.90 €

En lignedès 19.90 €selon l'option

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

Site officiel — selwo.es

• Durée de visite: la journée
• Meilleur moment: le matin

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

Lien partenaire — billetterie GetYourGuide

La règle est simple: une donnée saisie doit être transformée par une suite de conditions exclusives. Si l’âge est inférieur à 3 ans, alors l’entrée est gratuite. Sinon, le programme poursuit l’analyse. Les tarifs affichés en ligne peuvent varier selon la date et les conditions de réservation. Il est donc préférable de stocker les montants dans des variables modifiables, et non de les inscrire définitivement dans les instructions.

L’objectif est de construire une simulation de visite avec Scratch. Le programme demandera le nombre de visiteurs, leur âge, les activités choisies et les éventuelles options. Il calculera ensuite le montant total du groupe. Le modèle peut être utilisé en classe de collège pour travailler les variables, les conditions, les boucles et les priorités opératoires.

1. Définir le problème avant d’ouvrir Scratch

Selwo Aventura est un parc animalier situé à Estepona, dans la province de Málaga. Il a été inauguré en 1999. Le domaine accueille plus de 2 000 animaux appartenant à plus de 200 espèces. Il est organisé autour de plusieurs zones et circuits, dont le Portique de la nature, le Village central et la Route des vallées.

Ces informations sont utiles pour construire le contexte de l’exercice. Elles ne sont pas toutes nécessaires au calcul du prix. Un algorithme ne doit conserver que les données qui interviennent dans le résultat.

Il faut donc distinguer trois catégories.

• Les données descriptives: localisation, zones du parc, nombre d’animaux, activités.
• Les données d’entrée: âge du visiteur, nombre de personnes, choix du safari, choix de la tyrolienne.
• Les données de calcul: tarif enfant, tarif adulte, tarif senior, prix des options, total.

Cette séparation évite une confusion courante: demander à Scratch de calculer avec une information qui n’a aucun rôle numérique.

Les règles d’âge

Pour l’exercice, on peut utiliser les catégories indiquées pour la réservation en ligne:

• moins de 3 ans: entrée gratuite;
• de 3 à 10 ans: tarif enfant;
• de 8 à 64 ans: tarif adulte;
• plus de 65 ans: tarif senior.

Cette liste contient un chevauchement entre 8 et 10 ans. C’est un problème logique. Un visiteur de 8, 9 ou 10 ans appartient à deux catégories. Le programme ne peut pas appliquer deux tarifs simultanément.

Il faut donc choisir une convention pédagogique avant l’écriture du script. La convention la plus simple consiste à utiliser des tranches sans chevauchement:

• moins de 3 ans;
• de 3 à 10 ans;
• de 11 à 64 ans;
• 65 ans ou plus.

Cette modification ne prétend pas reproduire une règle commerciale définitive. Elle sert à construire un algorithme cohérent. Pour une utilisation réelle, les conditions du billet sélectionné doivent être vérifiées au moment de la réservation.

Une condition mal ordonnée produit un résultat faux, même si toutes les variables et tous les opérateurs sont correctement écrits.

2. Créer les variables Scratch

Dans Scratch, une variable contient une valeur. Elle peut être modifiée pendant l’exécution du programme.

Pour un premier simulateur, les variables suivantes suffisent:

• nombre de visiteurs;
• âge;
• tarif courant;
• total billets;
• total options;
• total général;
• safari;
• tyrolienne.

Les variables safari et tyrolienne peuvent contenir une réponse textuelle, par exemple oui ou non. Une autre solution consiste à utiliser une valeur numérique:

• 0 signifie que l’option n’est pas choisie;
• 1 signifie que l’option est choisie.

La seconde solution est plus stricte. Elle réduit les erreurs de saisie. Scratch ne distingue pas toujours les variantes d’écriture d’une réponse textuelle. Oui, oui et OUI peuvent poser problème si le script teste une seule forme.

Pour les tarifs, utiliser des variables est préférable à une valeur fixe intégrée dans chaque condition. Le programme peut alors être mis à jour sans modifier toute la structure:

• tarif enfant;
• tarif adulte;
• tarif senior;
• prix safari;
• prix tyrolienne.

Les valeurs exactes ne sont pas données ici. Les tarifs en ligne sont susceptibles de changer selon la date, la période et le type de billet. L’exercice porte sur le mécanisme. L’élève peut saisir les valeurs correspondant à la réservation étudiée.

Initialiser les variables

Au début du programme, les variables de calcul doivent être remises à zéro:

• mettre total billets à 0;
• mettre total options à 0;
• mettre total général à 0;
• mettre safari à 0;
• mettre tyrolienne à 0.

Sans cette initialisation, une seconde exécution peut conserver le résultat de la première. Le total augmente alors artificiellement.

Le bloc quand le drapeau vert est cliqué doit donc commencer par l’initialisation. Ensuite seulement, le programme pose les questions.

3. Construire le calcul d’un billet

Le calcul d’un visiteur doit être isolé avant d’être répété pour tout le groupe. C’est une règle de méthode. Si le calcul individuel est faux, une boucle ne fera que répéter l’erreur.

Le script suit cette logique:

1. demander l’âge;

2. convertir la réponse en nombre;

3. déterminer la catégorie;

4. attribuer le tarif correspondant;

5. ajouter ce tarif au total des billets.

Scratch utilise la réponse au bloc demander... et attendre. Cette réponse doit être traitée comme une valeur numérique dans les comparaisons.

Ordre des conditions

L’ordre des tests doit aller du cas le plus spécifique au cas général.

La structure logique est la suivante:

• si âge < 3, alors mettre tarif courant à 0;
• sinon, si âge <= 10, alors mettre tarif courant à tarif enfant;
• sinon, si âge <= 64, alors mettre tarif courant à tarif adulte;
• sinon, mettre tarif courant à tarif senior.

Pourquoi ne pas tester directement âge <= 10 en premier? Parce qu’un âge négatif serait accepté comme un âge enfant. Le programme doit donc également contrôler la validité de la saisie.

Une version plus robuste ajoute une boucle de correction:

1. demander l’âge;

2. répéter jusqu’à ce que âge >= 0 et âge <= 120;

3. afficher un message si la valeur est impossible;

4. appliquer les conditions tarifaires.

La limite supérieure de 120 ans n’est pas une règle de billetterie. C’est une borne technique destinée à empêcher une saisie manifestement erronée, comme 250 ou -4.

Traduction en blocs Scratch

Les blocs peuvent être organisés ainsi:

• demander [Quel est l’âge du visiteur?] et attendre
• mettre [âge] à [réponse]
• si <(âge) < [3]> alors
• mettre [tarif courant] à [0]
• sinon
• si <(âge) <= [10]> alors
• mettre [tarif courant] à [tarif enfant]
• sinon
• si <(âge) <= [64]> alors
• mettre [tarif courant] à [tarif adulte]
• sinon
• mettre [tarif courant] à [tarif senior]

Enfin:

• ajouter (tarif courant) à [total billets]

Le bloc ajouter... à est adapté ici. Il accumule progressivement les montants. Il faut éviter de remplacer total billets par tarif courant à chaque tour, car le programme perdrait les visiteurs précédents.

4. Répéter le calcul pour un groupe

Une visite scolaire ou familiale concerne rarement une seule personne. Le programme doit donc utiliser une itération.

Une boucle répéter (nombre de visiteurs) suffit pour un groupe dont l’effectif est connu à l’avance. La structure devient:

1. demander le nombre de visiteurs;

2. initialiser les totaux;

3. répéter le calcul individuel pour chaque visiteur;

4. demander les options;

5. afficher le total.

Dans Scratch:

• demander [Combien de visiteurs?] et attendre
• mettre [nombre de visiteurs] à [réponse]
• répéter (nombre de visiteurs)
• demander l’âge;
• déterminer le tarif;
• ajouter le tarif au total.

La variable compteur n’est pas obligatoire si le bloc répéter est utilisé. Elle devient utile avec une boucle répéter jusqu’à, par exemple lorsque le programme demande les visiteurs un par un et s’arrête après un nombre saisi.

Boucle répéter ou boucle conditionnelle

Les deux structures ne répondent pas au même besoin.

Pour un exercice de collège, répéter (nombre de visiteurs) est le choix le plus lisible. Il met directement en évidence la relation entre l’effectif et le nombre d’itérations.

Erreur classique: modifier la mauvaise variable

Le total du groupe doit être conservé pendant toute la boucle. La variable tarif courant change à chaque visiteur. La variable total billets ne doit jamais être réinitialisée à l’intérieur de la boucle.

Structure correcte:

• initialiser total billets avant la boucle;
• calculer tarif courant dans la boucle;
• ajouter tarif courant à total billets dans la boucle.

Structure incorrecte:

• mettre total billets à 0 dans la boucle;
• calculer le tarif;
• afficher le total.

Dans la structure incorrecte, seul le dernier visiteur est réellement comptabilisé.

5. Ajouter les activités d’aventure

Selwo Aventura ne se réduit pas à un billet d’entrée. Le parc propose notamment une tyrolienne, des ponts suspendus, des safaris en véhicule 4x4 et du tir à l’arc. La tyrolienne Ziwa survole une distance de plus de 100 mètres.

Pour l’algorithme, chaque activité doit être modélisée par une variable et un montant. Il faut aussi préciser si le prix s’applique:

• à chaque visiteur;
• à un seul participant;
• à un groupe;
• à une réservation distincte.

Cette distinction modifie entièrement la formule.

Option individuelle

Supposons que le safari soit facturé par participant. Le programme peut utiliser:

• nombre de participants safari;
• prix safari;
• coût safari.

La formule est:

coût safari = nombre de participants safari × prix safari

Puis:

total options = total options + coût safari

Même principe pour la tyrolienne.

Option globale

Si une option est facturée une seule fois pour le groupe, la formule ne contient pas le nombre de visiteurs:

coût option = prix option

Le script doit alors demander simplement si l’option est choisie. Il ne faut pas multiplier automatiquement toutes les options par l’effectif. C’est une erreur de modélisation, pas une erreur de calcul.

Conditions d’activation

Une structure simple peut utiliser des réponses numériques:

1. demander si le safari est choisi;

2. si la réponse vaut 1, alors calculer le coût du safari;

3. sinon, ajouter 0;

4. répéter la même logique pour la tyrolienne.

Les blocs deviennent:

• demander [Safari: 1 pour oui, 0 pour non] et attendre
• si <(réponse) = [1]> alors
• calculer le montant;
• ajouter le montant à total options.

Le programme doit refuser les autres valeurs. Si l’utilisateur saisit 2, l’algorithme ne doit pas l’interpréter comme une réponse valide.

Une méthode plus robuste consiste à répéter la question jusqu’à obtenir 0 ou 1:

• répéter jusqu’à <(réponse = 0) ou (réponse = 1)>
• demander la réponse;
• poursuivre le calcul.

Cette structure introduit l’opérateur logique ou. Elle est utile pour montrer qu’une condition peut posséder plusieurs sorties acceptées.

Une option n’est pas un détail graphique. Elle modifie la formule du total. Donc elle doit être représentée par une variable ou par une branche conditionnelle.

6. Respecter les priorités opératoires

Le calcul final est:

total général = total billets + total options

Si les options sont individuelles, leur montant intermédiaire doit d’abord être calculé. Par exemple:

coût safari = participants safari × prix safari

La multiplication est prioritaire sur l’addition. Scratch applique les règles habituelles, mais les parenthèses rendent la structure visible et réduisent les erreurs.

Écrire:

total général = total billets + (participants safari × prix safari) + (participants tyrolienne × prix tyrolienne)

est plus sûr que de disperser les opérations dans plusieurs blocs sans variable intermédiaire.

L’utilisation de variables intermédiaires présente trois avantages:

• le calcul est lisible;
• chaque résultat peut être vérifié séparément;
• une erreur est localisable.

Le programme peut afficher successivement:

• le total des billets;
• le total des activités;
• le total général.

Il ne s’agit pas d’ajouter des messages décoratifs. Chaque affichage correspond à une étape du raisonnement.

7. Organiser le programme avec des blocs personnalisés

Lorsque le script devient long, le bloc définir permet de créer une procédure. Il est possible de créer un bloc personnalisé nommé calculer le tarif du visiteur.

Cette procédure utilise les variables âge et tarif courant. Elle ne demande pas le nombre de visiteurs. Elle ne calcule pas non plus les options. Chaque bloc doit avoir une responsabilité unique.

Organisation recommandée:

Bloc principal

• initialiser les tarifs;
• initialiser les totaux;
• demander le nombre de visiteurs;
• répéter le calcul du billet;
• demander les options;
• calculer le total général;
• afficher les résultats.

Bloc calculer le tarif

• contrôler l’âge;
• appliquer la condition correspondante;
• modifier tarif courant.

Bloc calculer le safari

• demander le nombre de participants;
• multiplier par le prix du safari;
• ajouter le résultat à total options.

Bloc calculer la tyrolienne

• demander le nombre de participants;
• vérifier que ce nombre ne dépasse pas l’effectif du groupe;
• multiplier par le prix de la tyrolienne;
• ajouter le résultat à total options.

Cette décomposition correspond à la logique algorithmique. Elle évite de placer toutes les instructions dans un seul empilement de blocs.

8. Vérifier les données avant le calcul

Un programme correct ne se contente pas de produire un nombre. Il contrôle les valeurs utilisées.

Contrôles nécessaires

• le nombre de visiteurs doit être un entier positif;
• l’âge doit être un entier ou une valeur numérique acceptable;
• le nombre de participants à une activité ne peut pas être négatif;
• le nombre de participants ne peut pas dépasser le nombre de visiteurs;
• une option doit être choisie selon une réponse définie;
• les tarifs doivent être initialisés avant le calcul.

Le contrôle du nombre de visiteurs peut suivre cette logique:

1. demander l’effectif;

2. répéter la demande tant que l’effectif est inférieur à 1;

3. poursuivre uniquement lorsque la valeur est valide.

Pour les participants, la condition est double:

participants >= 0 et participants <= nombre de visiteurs

L’opérateur et est indispensable. Tester seulement participants <= nombre de visiteurs accepterait une valeur négative.

Attention aux réponses textuelles

Si le programme utilise oui et non, il faut traiter les variantes possibles ou imposer une saisie unique. Une procédure simple consiste à ne poser qu’une question numérique:

• 1 pour sélectionner;
• 0 pour ne pas sélectionner.

Le programme est alors déterministe. Il ne dépend pas des majuscules, des espaces ou de l’orthographe.

9. Exemple complet de logique

Voici l’ordre d’exécution recommandé pour une simulation de visite Scratch:

1. Initialiser les tarifs des billets et des activités.

2. Mettre les totaux à zéro.

3. Demander le nombre de visiteurs.

4. Vérifier que ce nombre est valide.

5. Répéter, pour chaque visiteur:

• demander l’âge;
• vérifier l’âge;
• classer le visiteur;
• attribuer le tarif;
• ajouter le tarif au total.

6. Demander si le safari est choisi.

7. Si oui:

• demander le nombre de participants;
• vérifier ce nombre;
• calculer le coût;
• ajouter le coût aux options.

8. Demander si la tyrolienne est choisie.

9. Si oui:

• demander le nombre de participants;
• vérifier ce nombre;
• calculer le coût;
• ajouter le coût aux options.

10. Additionner total billets et total options.

11. Afficher le résultat détaillé.

12. Effectuer un test de cohérence.

Cette séquence respecte la dépendance entre les données. Le nombre de participants ne peut pas être contrôlé avant que le nombre de visiteurs soit connu. Le coût total ne peut pas être affiché avant le calcul des billets et des options.

10. Tester avec des cas limites

Un test unique ne suffit pas. Il faut choisir des valeurs qui provoquent les changements de branche.

Les valeurs limites sont prioritaires. Une condition âge <= 10 doit être testée avec 10, mais aussi avec 11. Le résultat permet de vérifier le passage entre deux branches.

Il faut également tester le chevauchement initial des catégories. Avec la formulation de 3 à 10 ans et de 8 à 64 ans, un âge de 8 ans déclenche potentiellement la première condition et empêche la seconde d’être exécutée. Le programme ne signale pas nécessairement l’erreur. Il applique simplement la première branche rencontrée.

C’est précisément pourquoi une condition sinon si est préférable à deux blocs si indépendants.

Deux blocs si indépendants

• si âge est compris entre 3 et 10, appliquer le tarif enfant;
• si âge est compris entre 8 et 64, appliquer le tarif adulte.

Pour un âge de 8 ans, les deux blocs s’exécutent. Le second écrase la valeur du premier. Le résultat dépend alors de l’ordre des blocs.

Structure si... alors... sinon

• si âge est inférieur à 3, gratuit;
• sinon si âge est inférieur ou égal à 10, enfant;
• sinon si âge est inférieur ou égal à 64, adulte;
• sinon, senior.

Une seule branche est exécutée. Le classement est donc stable.

11. Étendre la modélisation au parcours du parc

Le même projet peut intégrer les données spatiales de Selwo Aventura. Le parc est organisé en circuits thématiques. Il est donc possible de créer une variable zone actuelle et une variable durée estimée.

Le programme peut demander au visiteur de sélectionner:

• le Portique de la nature;
• le Village central;
• la Route des vallées.

Chaque zone peut recevoir une valeur pédagogique différente. Il ne faut pas inventer une durée réelle si elle n’est pas connue. Pour l’exercice, les valeurs peuvent être présentées comme des hypothèses de modélisation.

Le programme devient alors un simulateur plus général:

• coût de l’entrée;
• coût des activités;
• nombre de zones sélectionnées;
• durée estimée du parcours;
• heure de début;
• heure théorique de fin.

Le calcul de l’heure nécessite une conversion en minutes. Si une visite commence à 10 h 00 et dure d minutes, alors:

heure de fin en minutes = 10 × 60 + d

Ensuite, il faut convertir le résultat en heures et minutes:

• heure = partie entière de minutes / 60;
• minutes restantes = reste de la division par 60.

Cette extension permet de travailler la division entière et le reste. Elle reste distincte du tarif. Deux variables différentes doivent représenter deux grandeurs différentes. Ne pas stocker une durée dans total général.

Les heures habituelles d’ouverture sont indiquées autour de 10 h 00 à 18 h 00, avec une extension jusqu’à 21 h 00 pendant certaines périodes estivales. Le programme peut donc comparer l’heure de fin calculée à une heure de fermeture choisie. Il doit cependant présenter cette valeur comme une donnée de période, non comme une règle valable toute l’année.

12. Version améliorée: listes et fiche de groupe

Pour un exercice plus avancé, les âges peuvent être stockés dans une liste Scratch nommée âges du groupe.

Le fonctionnement est différent:

1. demander le nombre de visiteurs;

2. répéter la saisie des âges;

3. ajouter chaque âge à la liste;

4. parcourir la liste avec un index;

5. calculer le tarif de chaque position;

6. additionner les montants.

Variables nécessaires:

• index;
• âge courant;
• tarif courant;
• total billets.

La boucle lit alors l’élément numéro index de la liste. Après chaque calcul:

• ajouter le tarif courant au total;
• changer index de 1.

La condition d’arrêt est:

index > longueur de la liste

Cette version sépare la saisie et le traitement. Elle est plus proche d’un programme qui exploite un fichier de données. Elle permet aussi d’afficher ensuite le nombre de visiteurs dans chaque catégorie.

On peut ajouter les compteurs:

• nombre enfants;
• nombre adultes;
• nombre seniors.

Lorsqu’un âge est classé, le programme augmente le compteur correspondant. Le résultat contient alors à la fois le coût et la répartition du groupe.

13. Les erreurs à corriger avant de considérer le programme terminé

Certaines erreurs reviennent dans presque tous les algorithmes de simulation.

• Les tarifs sont écrits à plusieurs endroits.

Une modification devient difficile. Utiliser une variable par tarif.

• Le total est remis à zéro dans la boucle.

Le programme ne conserve que le dernier visiteur. Initialiser avant la boucle.

• Les catégories d’âge se chevauchent.

Définir des intervalles exclusifs.

• Les options sont toujours multipliées par le groupe.

Vérifier si l’activité est individuelle ou collective dans le modèle.

• Les participants ne sont pas contrôlés.

Une valeur supérieure à l’effectif rend le résultat incohérent.

• Les réponses oui et non sont comparées sans normalisation.

Préférer les valeurs 0 et 1.

• Les données réelles et les hypothèses pédagogiques sont mélangées.

Identifier clairement les valeurs fournies par le parc et celles choisies pour l’exercice.

• Le programme affiche uniquement le total final.

Afficher aussi les sous-totaux pour localiser une erreur.

La dernière erreur est la plus difficile à détecter. Un total peut être faux sans paraître absurde. Un affichage détaillé rend le calcul vérifiable.

Test de vérification rapide

Utiliser un petit groupe fictif contenant:

• un enfant de moins de 3 ans;
• un enfant situé à la limite supérieure de la catégorie enfant;
• un adulte;
• un senior;
• une activité choisie par une partie du groupe.

Vérifier ensuite quatre valeurs:

1. le nombre de billets comptabilisés;

2. le total des billets;

3. le nombre de participants à l’activité;

4. le total général.

Si une seule catégorie est incorrecte, contrôler les opérateurs <, <=, > et >=. Si le total augmente à chaque relance, contrôler l’initialisation. Si l’activité coûte trop cher, contrôler le nombre de participants et la formule de multiplication.

Le modèle scratch Selwo Aventura devient ainsi un exercice complet d’algorithmique. Le parc fournit un contexte concret. Scratch fournit les variables, les itérations et les conditions. Le résultat dépend uniquement de la structure logique: une donnée valide, une branche correctement ordonnée, puis une addition vérifiable.