Visite d'Aquacolors : simulation de parcours sur Scratch

Visite d'Aquacolors: simulation de parcours sur Scratch

Quand nous demandons à un élève de cinquième d’écrire un programme qui décide si un nombre est pair ou impair, nous testons sa capacité à manipuler une condition isolée. Mais quand nous lui demandons de planifier une journée dans un parc aquatique où il faut choisir entre plusieurs attractions, gérer son énergie et éviter les files d’attente, nous activons une autre forme de pensée: celle qui prévoit, qui anticipe, qui pèse le coût d’un choix contre son bénéfice.

Poréc

Billets et tarifs

Parc aquatique Aquacolors

★4,4/5 · 692 avisTarifs vérifiés le 27 août 2026Disponible à brève échéance

Excursion d'une journée — Accès d'une journée

★4,4·692 avis

dès35 €

Réserver des billets

Billet officiel — Plein tarif

dès36.95 €

Réserver des billets

Billetterie officielle et achat en ligne

Plein tarif25 €

Tarif réduit19.95 €

Site officiel — aquacolors.eu

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

Le parc aquatique Aquacolors, situé à Poreč en Istrie, constitue un terrain d’étude intéressant précisément parce qu’il ne se laisse pas réduire à une simple liste d’attractions. Avec sa rivière paresseuse de 500 mètres, ses 13 grands toboggans aux niveaux d’adrénaline variés et ses espaces organisés autour de plusieurs usages, il fournit une situation assez riche pour travailler les déplacements, les variables, les boucles et les conditions. Le but n’est pas de reproduire à l’identique une journée réelle dans le parc, mais de construire une représentation suffisamment cohérente pour que les choix du visiteur deviennent des objets de calcul.

Le parc Aquacolors comme terrain d’étude algorithmique

Avant d’ouvrir Scratch, aidons l’élève à percevoir ce que modéliser veut vraiment dire. Un parc aquatique n’est pas seulement un décor: c’est un système. Chaque attraction peut être décrite par un temps d’accès, une durée d’utilisation, un niveau d’intensité et une valeur subjective. Le plaisir procuré varie d’un visiteur à l’autre; l’attente peut sembler acceptable pour une attraction très recherchée et interminable pour une autre. Même le déplacement entre deux zones modifie la décision lorsque la journée avance.

Cette situation permet de distinguer trois éléments souvent confondus par les débutants:

• la réalité, avec ses visiteurs, ses files, ses espaces et ses règles;
• le modèle, qui ne retient qu’un nombre limité de caractéristiques;
• le programme, qui applique des règles à ce modèle pour produire un parcours.

La simulation de visite sur Scratch ne cherche donc pas à prédire exactement le comportement de chaque personne. Elle sert à rendre visibles les conséquences d’une stratégie. Un élève peut décider de commencer par les attractions les plus intenses, de privilégier celles qui sont proches les unes des autres ou de garder une partie de son temps pour la fin de journée. Ces décisions n’ont pas besoin d’être présentées comme les meilleures en toutes circonstances. Elles doivent surtout être formulées de manière assez précise pour être testées.

La question du paiement peut être intégrée au modèle, mais uniquement comme une hypothèse pédagogique lorsque les modalités concrètes du parc ne sont pas établies. Il est possible d’imaginer un système de crédits fictifs attribués au début de la simulation, puis consommés par certaines activités. Il est tout aussi pertinent de ne pas introduire cette dimension et de limiter l’exercice au temps, aux déplacements et à l’énergie. Dans les deux cas, l’enseignant doit annoncer clairement à l’élève ce qui relève de la réalité observée et ce qui relève d’une convention inventée pour les besoins de l’algorithme.

Modéliser, ce n’est pas représenter la réalité à l’identique: c’est choisir, dans cette réalité, les quelques éléments qui rendront la simulation instructive.

C’est ici que nous rencontrons le premier blocage typique chez les apprenants: ils confondent simulation et recette de cuisine. Ils veulent écrire un programme qui fait la visite, alors qu’un bon programme doit d’abord la décrire, puis éventuellement en proposer des variantes. Cette nuance est fondamentale: un algorithme ne décide pas à la place du visiteur; il l’aide à voir les conséquences de ses décisions avant qu’il ne les prenne.

L’exercice gagne en qualité lorsque l’élève commence par rédiger les règles avec des phrases ordinaires. Par exemple:

• une attraction demande un certain temps d’attente;
• le déplacement vers une autre zone consomme quelques unités de temps;
• une attraction intense diminue l’énergie disponible;
• lorsque le temps restant est faible, le programme privilégie une activité courte ou une pause;
• une activité déjà réalisée peut être écartée si l’on souhaite éviter les répétitions.

Ces phrases peuvent ensuite être transformées en variables et en conditions. Le passage du langage courant au langage algorithmique devient alors l’apprentissage principal.

Structurer les déplacements sur une carte de 100 000 m²

La question spatiale est la plus concrète, et c’est par elle que nous pouvons commencer. Sur Scratch, le lutin évolue dans un espace défini par deux coordonnées, x et y. Pour représenter les quelque 100 000 m² du parc Aquacolors, l’élève doit choisir une échelle. Il peut, par exemple, faire varier x de -240 à 240 et utiliser une convention graphique qui associe cette largeur de l’écran à la surface étudiée. Le calcul obtenu n’est pas une mesure officielle du parc: c’est une échelle de simulation. Elle sert à comparer les déplacements, pas à fournir un plan d’architecte.

Ce point mérite d’être explicité. Dans un modèle scolaire, la précision géographique n’est pas toujours la priorité. Une carte très détaillée peut même détourner l’élève de la question algorithmique. Si l’objectif est de comprendre les boucles et les conditions, un plan simplifié avec quelques secteurs bien identifiés sera souvent plus efficace qu’une reproduction minutieuse dont les coordonnées seraient difficiles à exploiter.

Nous bâtissons ensuite la carte sous forme de décor: un arrière-plan dessiné dans Scratch ou importé, avec des zones colorées représentant les différents secteurs du parc. On peut distinguer l’espace enfants, la zone des toboggans, la rivière paresseuse, la piscine à vagues et la zone de restauration. Chaque attraction devient un repère: un point de coordonnées x et y que le lutin peut atteindre.

Deux niveaux de représentation sont possibles:

L’approche du plan libre permet à l’élève de se concentrer sur les structures logiques sans être freiné par les calculs de distance. L’approche par quadrillage introduit une exigence supplémentaire: il faut estimer le nombre de déplacements, comparer deux itinéraires ou déterminer quelle attraction est la plus proche. On peut alors faire varier la durée du trajet en fonction de l’écart entre les coordonnées.

Même sans utiliser la distance euclidienne, le travail est déjà riche. L’élève peut décider qu’un déplacement horizontal ou vertical coûte une unité de temps par case, puis observer les effets de cette règle. Il comprend ainsi que la durée d’une activité ne se réduit pas à l’attraction elle-même. Une visite peut devenir moins efficace parce que le parcours entre deux zones est trop long.

Donner une fonction aux coordonnées

Une erreur fréquente consiste à attribuer des coordonnées aux attractions sans leur donner de rôle dans le programme. Pour éviter cela, chaque position doit intervenir dans une décision. Le lutin peut devoir rejoindre l’attraction sélectionnée, afficher son nom à l’arrivée, puis repartir vers un autre point. La carte n’est alors plus une illustration posée derrière le programme: elle devient une donnée utilisée par l’algorithme.

On peut également comparer deux stratégies:

1. visiter les attractions dans l’ordre où elles apparaissent sur la carte;

2. choisir à chaque étape l’attraction la plus proche parmi celles qui n’ont pas encore été visitées.

La seconde stratégie paraît plus efficace, mais elle ne garantit pas nécessairement la meilleure journée. Une attraction éloignée peut présenter un intérêt supérieur, une attente plus courte ou une intensité mieux adaptée à l’énergie restante. Cette tension entre proximité et intérêt donne lieu à une discussion mathématique simple, mais féconde: que cherche-t-on à optimiser exactement?

Gestion des variables: du temps d’attente à un budget de simulation

C’est ici que l’exercice devient vraiment intéressant. Un visiteur modélisé dispose de plusieurs ressources finies: le temps, l’énergie et, si l’on choisit de l’ajouter, un budget fictif. En Scratch, chacune de ces ressources devient une variable. On peut les nommer temps, energie et credits, afin d’éviter de présenter comme un fait établi un fonctionnement financier précis du parc.

La variable temps est la plus intuitive. Elle décroît à chaque action, selon un coût défini par la classe. Une attente, un déplacement, une descente ou une pause peuvent recevoir des durées différentes. Ces valeurs ne prétendent pas décrire les horaires réels ni les files observées sur place. Elles forment un jeu de données pédagogique que l’élève peut modifier pour voir comment le parcours évolue.

La variable energie est plus difficile à modéliser parce qu’elle dépend de facteurs physiologiques que la machine ne connaît pas. C’est pourtant une excellente occasion de parler des limites d’un modèle. L’élève peut décider qu’une attraction à sensations fait perdre davantage d’énergie qu’une activité calme, tandis qu’une pause en fait récupérer une partie. Il ne s’agit pas d’une mesure médicale: c’est une convention destinée à représenter une évolution dans le temps.

Le budget fictif suit la même logique. Si l’enseignant souhaite travailler les comparaisons numériques et les tests de seuil, il peut attribuer à chaque activité un coût choisi pour la simulation. Certaines attractions peuvent avoir un coût nul, d’autres un coût positif, mais cette répartition doit être présentée comme une hypothèse de scénario. Elle ne doit pas être formulée comme une description des tarifs ou des conditions réellement appliqués à Aquacolors lorsque ces informations n’ont pas été vérifiées.

La variable credits peut alors répondre à une question algorithmique claire: le budget prévu permet-il encore de sélectionner cette activité? Dans ce cadre, le programme réalise une vérification booléenne construite par l’élève. La condition ne porte pas sur un prétendu système financier réel; elle porte sur les règles du modèle.

Par exemple, le scénario peut commencer avec:

• temps égal à la durée fictive de la visite;
• energie égale à un niveau initial choisi par la classe;
• credits égal à un budget imaginaire;
• une liste vide pour les attractions déjà effectuées.

Chaque attraction reçoit ensuite des paramètres cohérents:

L’intérêt de cette organisation est de montrer que la variable n’est pas un simple compartiment où l’on range un nombre. Elle représente un aspect du système et doit être mise à jour au bon moment. Si l’on retire le temps avant le déplacement mais pas après l’attente, le programme donnera une image incohérente de la journée. Si l’on retire l’énergie avant de vérifier qu’elle est suffisante, le lutin pourra réaliser une activité que les règles du scénario lui interdisaient.

Tester une ressource sans confondre le réel et le modèle

Une condition peut prendre la forme suivante: l’activité est autorisée si le temps restant est suffisant, si l’énergie dépasse le seuil prévu et, lorsque le budget fictif est utilisé, si credits est supérieur ou égal au coût de l’activité.

Cette formulation a deux avantages. Elle rend le programme lisible et elle oblige l’élève à distinguer les données nécessaires des données décoratives. Le nom d’une attraction peut être affiché à l’écran, mais il ne suffit pas à décider si elle est accessible. La décision dépend des paramètres que l’élève a choisis pour son univers simulé.

Une variable bien nommée ne stocke pas seulement une valeur: elle raconte une partie de l’histoire que l’algorithme est en train de raconter.

On peut demander aux élèves de modifier une seule hypothèse à la fois: augmenter le temps d’attente, réduire l’énergie initiale, supprimer le budget fictif ou rendre certaines attractions plus coûteuses dans le scénario. Ils observent alors quelles décisions changent et quelles autres restent identiques. Cette méthode les rapproche d’une démarche expérimentale: on ne change pas toutes les règles en même temps, sinon il devient impossible d’expliquer le résultat.

Programmer des boucles pour optimiser l’enchaînement des attractions

Une fois les variables en place, l’élève est souvent tenté d’écrire une longue séquence linéaire: aller au premier toboggan, attendre, descendre, puis se rendre au suivant. Cette séquence peut fonctionner, mais elle ne traduit pas encore toute la logique d’une visite. Un programme plus intéressant doit pouvoir répéter une décision tant que certaines ressources sont disponibles.

C’est ici qu’intervient la boucle répéter jusqu’à ce que. Le scénario peut continuer tant que le temps restant est positif et que l’énergie n’est pas descendue sous le seuil minimal. À l’intérieur de la boucle, le programme choisit une attraction, vérifie les conditions, déplace le lutin, met à jour les variables et ajoute l’attraction à la liste des activités réalisées.

La boucle ne rend pas automatiquement le programme intelligent. Si elle répète toujours la même attraction, elle ne fait que reproduire une erreur plus vite. Il faut donc lui associer une règle de choix. Plusieurs options sont possibles:

• choisir l’attraction dont la valeur de plaisir est la plus élevée;
• choisir l’activité la plus proche;
• privilégier une activité dont le coût en énergie est inférieur au niveau restant;
• sélectionner une attraction non visitée;
• alterner activité intense et activité calme.

Chaque règle produit un parcours différent. C’est là que l’élève peut comparer des stratégies plutôt que chercher une unique solution correcte.

La liste attractions_visitees joue un rôle important. Elle permet de mémoriser les choix déjà effectués et d’éviter les répétitions si le scénario l’exige. Elle ouvre aussi la porte à une question plus subtile: faut-il vraiment interdire de refaire une attraction? Dans une simulation de visite, la répétition peut être parfaitement logique si elle procure beaucoup de plaisir et si son coût reste acceptable. L’algorithme doit donc appliquer une règle annoncée, et non une préférence implicite de son concepteur.

Une boucle doit avoir une sortie identifiable

Les débutants construisent parfois une boucle dont aucune condition ne peut devenir vraie. Le lutin continue alors de se déplacer ou de choisir des activités alors que le temps devrait être épuisé. Pour prévenir ce problème, chaque tour de boucle doit modifier au moins une variable qui participe à la condition de sortie.

Si la boucle s’arrête lorsque temps <= 0, une activité doit consommer du temps. Si elle s’arrête aussi lorsque energie <= 0, les activités et les pauses doivent modifier l’énergie. Si le programme exclut les attractions déjà visitées, la liste doit effectivement s’allonger. Cette vérification permet de relier la structure du programme à son comportement observable.

On peut aussi demander à l’élève d’afficher les variables après chaque étape. Le lutin annonce alors le temps restant, l’énergie disponible et le nombre d’attractions effectuées. L’objectif n’est pas de décorer la simulation, mais de rendre son fonctionnement vérifiable. Une journée qui s’arrête trop tôt devient immédiatement analysable: le temps de déplacement a peut-être été surestimé, l’énergie n’a peut-être jamais été restaurée ou la condition de sortie est peut-être mal formulée.

Conditions et logique: simuler les choix des visiteurs

La boucle sans condition serait un manège aléatoire, pas une visite. L’algorithmique prend tout son sens avec les instructions conditionnelles. C’est le moment d’aider l’élève à formuler des règles de décision explicites.

Une règle simple peut associer le niveau d’énergie à une catégorie d’activité: si l’énergie est élevée, le programme autorise une attraction intense; sinon, il propose une activité plus calme. Une autre règle peut tenir compte du temps restant: une attraction éloignée devient moins intéressante lorsque la fermeture approche, même si elle avait une forte valeur au début de la journée.

Les conditions peuvent être combinées:

• le temps restant doit être supérieur à la durée estimée du trajet et de l’activité;
• l’énergie doit être suffisante pour respecter la règle du scénario;
• l’attraction ne doit pas avoir déjà été sélectionnée, si les répétitions sont interdites;
• le nombre de crédits doit être suffisant, uniquement lorsque le budget fictif fait partie du modèle.

Le programme ne doit pas seulement répondre par oui ou par non. Il peut aussi expliquer la décision. Si une attraction est refusée, le lutin indique que le temps restant est trop court, que l’énergie est insuffisante ou que le budget imaginé ne permet pas ce choix. Cette sortie aide l’élève à vérifier que la condition correspond bien à la règle annoncée.

Une cascade de décisions

Nous pouvons proposer une cascade de décisions comme celle-ci, en laissant les valeurs numériques à la convention choisie par la classe:

1. Si le temps restant est largement supérieur à la durée du parcours, que l’énergie est élevée et que l’activité respecte le budget éventuel, le programme sélectionne une attraction de la zone des toboggans majeurs.

2. Sinon, si le temps restant permet encore une activité moyenne et que l’énergie demeure suffisante, il choisit une attraction moins exigeante.

3. Sinon, il se dirige vers une activité calme ou déclenche une pause.

4. Lorsque le temps restant ne permet plus de rejoindre une nouvelle attraction, la simulation se termine.

Cette cascade ne décrit pas la conduite obligatoire d’un visiteur réel. Elle formalise une stratégie parmi d’autres. Un élève peut préférer commencer par la rivière paresseuse, un autre réserver les attractions les plus intenses à une période où il estime que l’attente sera moindre. L’important est que chacun puisse expliquer les conditions de son programme et observer leurs conséquences.

Les conditions imbriquées permettent également de travailler les erreurs de priorité. Une activité peut être proche mais trop fatigante. Une autre peut être intéressante mais trop longue à rejoindre. Une troisième peut être accessible selon le temps et l’énergie, mais exclue par la règle du budget fictif. Le programme doit alors évaluer plusieurs informations au lieu de s’arrêter à la première caractéristique rencontrée.

Comparer plusieurs stratégies

L’élève peut enregistrer les résultats de différentes simulations dans un tableau. Il note, par exemple, le nombre d’activités réalisées, le temps restant, le niveau d’énergie final et la distance totale parcourue. Il ne s’agit pas de désigner un gagnant de manière artificielle. Une stratégie qui maximise le nombre d’attractions peut laisser très peu d’énergie à la fin; une stratégie plus prudente peut produire moins d’étapes, mais un parcours mieux réparti.

Cette comparaison introduit une question centrale en algorithmique: optimiser, oui, mais selon quel critère? Le meilleur parcours n’existe pas dans l’absolu. Il dépend de l’objectif retenu. Si l’on veut visiter le plus grand nombre d’attractions, on privilégiera certaines règles. Si l’on veut préserver l’énergie ou réduire les déplacements, le programme fera d’autres choix. La simulation rend cette discussion concrète sans prétendre transformer une journée de loisirs en problème parfaitement mesurable.

Recommandation pour ancrer l’apprentissage

En fin de compte, simuler une visite à Aquacolors sur Scratch n’est pas un exercice parmi d’autres dans le programme de mathématiques du cycle 4: c’est une manière de rendre visible une compétence que les élèves exercent sans toujours la nommer. Planifier, c’est déjà programmer. Choisir entre deux attractions en fonction de son énergie, c’est déjà formuler une condition. Comparer deux itinéraires, c’est travailler avec des coordonnées et des distances. Modifier une règle puis observer le résultat, c’est expérimenter sur un modèle.

Le parc, avec ses 13 toboggans, sa rivière paresseuse de 500 mètres et ses quelque 100 000 m² à représenter, offre un terrain suffisamment riche pour que chaque élève y projette sa propre stratégie. Mais cette richesse ne doit pas conduire à surcharger le programme dès le départ. Une première version peut se limiter à trois attractions, deux variables et une boucle. Une deuxième version ajoutera les déplacements. Une troisième introduira la liste des activités déjà réalisées ou un budget fictif. Cette progression est plus instructive qu’un projet qui chercherait à tout simuler en une seule fois.

Nous recommandons de prolonger l’exercice par un support tangible: un plan imprimé ou schématisé du parc, sur lequel l’élève trace son parcours avant de le programmer. Cette étape révèle souvent les incohérences qui restent invisibles à l’écran. Une attraction placée trop près d’une autre, un trajet qui ne consomme aucun temps ou une pause qui ne modifie jamais l’énergie peuvent être repérés avant même l’exécution du programme.

L’enseignant ou le parent peut alors poser des questions plutôt que corriger directement: quelle variable change après cette action? Que se passe-t-il si l’énergie est déjà faible? Pourquoi le programme choisit-il cette attraction plutôt qu’une autre? Le budget utilisé ici correspond-il à une règle vérifiée ou à une hypothèse de scénario? Ces questions ramènent l’élève au fonctionnement de son modèle et l’obligent à distinguer ce qu’il a observé, ce qu’il a supposé et ce qu’il a programmé.

La force de cette activité tient justement à cette distinction. Une simulation de visite sur Scratch n’est pas un plan officiel du parc, ni un calcul exact du temps d’attente, ni une description garantie des modalités de paiement. C’est un laboratoire miniature dans lequel on peut isoler des ressources, fixer des règles, tester des stratégies et discuter des limites d’une représentation. La file d’attente devient une durée, l’énergie devient une variable, le déplacement devient une suite de coordonnées et le choix d’une attraction devient une condition.

Le parc aquatique Aquacolors sert alors de support concret à une idée plus générale: un algorithme est une manière de rendre une décision explicite. Il ne supprime pas l’incertitude et ne remplace pas le jugement du visiteur. Il permet simplement de voir ce qui arrive lorsque l’on change une règle, que l’on oublie une ressource ou que l’on privilégie un objectif au détriment d’un autre. C’est exactement ce que l’on attend d’un exercice algorithmique au collège: non pas produire une animation impressionnante, mais apprendre à construire, vérifier et discuter une procédure.