Aviodrome horaires : programmer un simulateur sur Scratch

Aviodrome horaires: programmer un simulateur sur Scratch

Elle porte sur les horaires. Et très vite, l'élève se heurte à une difficulté révélatrice: comment une donnée en apparence aussi simple qu'un créneau d'ouverture peut-elle devenir, en quelques lignes, un véritable labyrinthe? Du mardi au dimanche, oui, semble-t-il. Mais le lundi n'est ouvert qu'une partie de l'année. Les vacances scolaires néerlandaises viennent encore compliquer la lecture. Le 24, le 26 et le 31 décembre, les horaires raccourcissent. Le 25 décembre et le 1er janvier, le musée ferme. Voilà un terrain idéal pour comprendre ce qu'est réellement une condition en algorithmique: non pas une instruction isolée, mais un empilement de décisions qui doivent se consulter les unes les autres avant de répondre.

Aviodrome

4,5· 22 avis

Réserver des billetsdès 20 €

• Billet d'entrée — Enfants (0-2 ans)official ticketdès0 €

Au guichet17.50 €

En lignedès 20 €selon l'option

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

Site officiel — aviodrome.nl

• Durée de visite: 2–3 h
• Meilleur moment: le matin

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

Lien partenaire — billetterie GetYourGuide

C'est précisément cette complexité que nous allons transformer en script Scratch. Non pas pour « faire du Scratch autour de l'Aviodrome », mais pour aider l'élève à percevoir, derrière un objet culturel concret, la structure logique qui régit les horaires d'un lieu réel. Ce travail rejoint un mouvement plus large que nous expérimentons en classe: utiliser les centres d'intérêt des adolescents pour ancrer des notions abstraites, et réduire ainsi la charge cognitive qui pèse sur les chapitres d'algorithmique du programme de collège.

1. Structurer les données temporelles du musée

Avant d'écrire la moindre instruction, nous prenons le temps d'inventorier les informations dont l'algorithme aura besoin. Cette étape est trop souvent négligée par les élèves qui veulent « passer au code » dès la première minute. Or, c'est précisément là que se construit la robustesse d'un programme, et c'est aussi là que se joue la différence entre un script qui fonctionne par hasard et un script qui fonctionne parce qu'il a été pensé.

Pour l'Aviodrome, quatre catégories de données temporelles émergent naturellement:

• Le jour de la semaine (lundi, mardi, dimanche), qu'on distinguera du numéro de jour dans le mois.
• La plage horaire standard du musée, qui sert de référence par défaut.
• La période de l'année: été long, vacances scolaires officielles, reste de l'année.
• Les exceptions calendaires: 24, 26 et 31 décembre à horaires réduits; 25 décembre et 1er janvier en fermeture totale.

Chacune de ces catégories deviendra, dans Scratch, soit une variable, soit une réponse à une instruction demander. C'est un point que nous prenons soin d'expliciter avec les élèves: en programmation, une donnée n'existe vraiment que lorsqu'on lui donne un contenant. Tant qu'elle reste « dans la tête de l'utilisateur », elle n'est pas manipulable, et donc pas programmable.

Un algorithme solide commence par des données bien nommées, pas par des blocs empilés dans l'urgence.

Pour rendre cette étape tangible, nous proposons souvent de dessiner un tableau à deux colonnes sur une feuille de brouillon: à gauche, le nom de la variable (jour, mois, estLundi, estFete, etc.), à droite, sa signification en français. Cette manipulation préparatoire, menée collectivement en classe, ancre le vocabulaire et évite la confusion plus tard entre, par exemple, le numéro du jour dans le mois et le jour de la semaine — confusion extrêmement fréquente chez les élèves qui débutent.

2. Logique conditionnelle: comparer deux approches pédagogiques

Une fois les variables identifiées, le cœur du travail commence: l'enchaînement des conditions si / sinon. C'est ici que beaucoup d'élèves trébuchent, parce qu'ils cherchent à traiter tous les cas d'un coup dans un seul grand test. Aidons-les à percevoir qu'un algorithme n'est pas une addition de règles isolées, mais un arbre de décisions où chaque branche débouche soit sur une autre question, soit sur une réponse finale.

Nous leur présentons alors, volontairement, deux approches différentes, et nous les amenons à comparer leur efficacité.

Approche A — l'empilement plat. L'élève écrit une longue condition du type si (jour ≠ lundi ET jour ≠ 25 décembre ET jour ≠ 1er janvier ET …) alors. Au fil des règles, la condition devient illisible, et le moindre ajout d'exception oblige à tout réécrire. Cette approche fonctionne… jusqu'à ce qu'elle ne fonctionne plus.

Approche B — la cascade hiérarchique. L'élève organise les tests du plus restrictif au plus large: d'abord les fermetures annuelles, puis les horaires réduits, puis la condition saisonnière du lundi, et enfin la règle standard. Chaque test « passe » fait descendre d'un cran vers une décision plus fine. Cette approche reste lisible même lorsqu'on ajoute de nouvelles règles, et c'est celle que nous recommandons.

Pour rendre cette seconde approche concrète dans Scratch, chaque étape prend la forme d'un bloc si < > alors / sinon emboîté dans le précédent. L'élève voit alors physiquement la structure: un bloc à l'intérieur d'un autre bloc, comme des poupées russes. Cette visualisation spatiale est l'un des grands apports de Scratch par rapport à un langage textuel: la structure du programme se lit dans sa forme même. C'est un point que nous soulignons souvent, parce qu'il permet à l'élève de comprendre que la logique conditionnelle n'est pas une affaire de syntaxe, mais une affaire d'organisation de la pensée.

3. Gérer les exceptions: jours fériés et horaires réduits

Les exceptions sont le meilleur allié pédagogique du professeur d'algorithmique, à condition de ne pas les présenter comme des « cas particuliers qu'on verra plus tard ». Intégrons-les dès le départ dans le script, comme une manière de montrer à l'élève qu'un programme sérieux anticipe les irrégularités du monde réel — et que c'est précisément cette anticipation qui fait la qualité d'un logiciel.

Pour l'Aviodrome, le cas le plus formateur est celui du 25 décembre. La tentation, en classe, est de l'oublier parce qu'on est encore loin des fêtes lorsqu'on programme en octobre ou en novembre. Mais l'oublier révèle, en creux, le défaut d'un script qui ne couvre pas toutes les branches de son arbre de décisions. Voici comment nous traitons généralement cette exception: nous créons deux variables booléennes, est25decembre et est1erJanvier, calculées à partir du jour et du mois. Le test se place tout en haut de la cascade, avant même la question du jour de la semaine.

Pour aider l'élève à visualiser l'ensemble, nous leur proposons de résumer les règles dans un tableau de conception — un document de travail, pas un document à apprendre:

Ce tableau n'est pas un mémo à apprendre par cœur. C'est un outil de conception: l'élève y voit, d'un seul coup d'œil, les quatre sorties possibles de son programme. Nous leur demandons ensuite de numéroter ces sorties de la plus restrictive à la plus large, ce qui les oblige à hiérarchiser — autrement dit, à penser comme un algorithme. Cette gymnastique mentale, apparemment anodine, consolide une compétence que l'on retrouvera dans toutes les branches de l'informatique.

4. Intégrer la variable tarifaire Early Bird

Le tarif Early Bird mérite une section à part, parce qu'il introduit une dimension nouvelle: non plus seulement le temps du musée, mais la relation entre le moment de la réservation et le moment de la visite. Cette double temporalité est un excellent tremplin pour parler de variables dépendantes, notion que les manuels scolaires présentent souvent de façon trop abstraite.

L'Aviodrome propose une réduction aux visiteurs qui réservent leur billet au moins un jour avant leur visite. Dans Scratch, cela se traduit par une variable joursAvant qui prend une valeur entière, et par une comparaison logique simple. Mais le vrai intérêt pédagogique n'est pas dans l'instruction elle-même: il est dans la question que nous posons à l'élève avant d'écrire la moindre ligne. « Si je réserve le jour même, ai-je droit à la réduction? » Cette question, posée à voix haute, permet de formaliser ensuite une condition sans ambiguïté.

Voici les étapes que nous déroulons ensemble:

1. Demander à l'utilisateur la date de réservation, puis la date de visite souhaitée.

2. Calculer l'écart entre les deux dates et le stocker dans la variable joursAvant.

3. Tester si joursAvant ≥ 1: si oui, signaler l'éligibilité à la réduction.

4. Afficher un message adapté selon le résultat du test.

Un tarif n'est pas un nombre figé: c'est le résultat d'une condition temporelle. Programmer, c'est apprendre à rendre cette condition visible.

Cette section ouvre une porte vers la notion de variable calculée, qui sera utile bien au-delà de l'Aviodrome. L'élève comprend que certaines données ne sont pas entrées par l'utilisateur, mais produites par le programme lui-même — une idée fondamentale qu'on retrouve dans tous les langages, et qui change profondément le regard qu'on porte sur un logiciel.

5. Optimiser le script pour la simulation de visite

Une fois le script fonctionnel, le travail n'est pas terminé. C'est même là, souvent, qu'il devient vraiment intéressant: passer du « ça marche » au « c'est clair, c'est testable, c'est réutilisable ». Cette bascule, en algorithmique au collège, est aussi importante que la résolution du problème initial, parce qu'elle installe chez l'élève une posture de professionnel plutôt qu'une posture de bricoleur.

Nous proposons généralement trois axes d'optimisation, par ordre de difficulté croissant:

• Nommer les variables avec soin. Les noms courts comme a, b, c sont tentants pour aller vite, mais mois, jour, estLundi se comprennent sans effort six mois plus tard, ou par un camarade qui reprend le projet. C'est un geste de respect envers soi-même et envers les autres.
• Factoriser les constantes. La plage horaire standard revient à plusieurs endroits du programme. La stocker dans une variable unique OUVERTURE_STANDARD permet de la modifier en un seul endroit si les horaires du musée évoluent — ce qui, dans la vie réelle d'un logiciel, arrive bien plus souvent qu'on ne l'imagine.
• Tester les cas limites: faire tourner le programme avec des dates critiques — un 25 décembre, un lundi de février, un 31 décembre, un dimanche d'été, un jour de vacances scolaires. Cette étape révèle presque toujours un oubli, et c'est tant mieux: l'erreur est ici un matériau d'apprentissage, jamais un motif de sanction.

À ce stade, l'élève dispose d'un simulateur complet: il entre une date, le programme répond par un créneau d'ouverture — ou par une fermeture — et, éventuellement, par l'éligibilité à la réduction Early Bird. Ce simulateur peut d'ailleurs servir de point de départ à des projets transversaux: en géographie, pour comparer les rythmes d'ouverture des musées européens; en français, pour rédiger un petit guide de visite à destination d'une famille.

Ce que ce travail fait réellement progresser

Au-delà de la maîtrise technique de Scratch, ce projet d'Aviodrome horaires fait travailler plusieurs compétences que nous identifions comme essentielles en classe de collège.

D'abord, la lecture de contraintes: l'élève apprend à extraire d'un texte court — en l'occurrence les horaires officiels d'un musée — une série de règles sans en oublier aucune. C'est une compétence que l'on sous-estime souvent, et que ce type d'exercice révèle très vite. Ensuite, la hiérarchisation: les conditions ne se valent pas, certaines doivent être testées avant d'autres, et l'élève doit apprendre à décider lesquelles. Enfin, la manipulation: en entrant plusieurs fois des dates différentes dans le simulateur, l'élève voit immédiatement l'effet de chaque règle, ce qui consolide sa compréhension bien mieux qu'une lecture magistrale du cours.

Ce dernier point est celui sur lequel nous insistons le plus. La programmation, au collège, n'est pas une fin en soi; c'est un moyen de rendre visible ce qui, sans l'écran, resterait abstrait. L'Aviodrome, avec ses horaires en apparence capricieux, devient alors un excellent support pour bâtir — au sens propre — une première représentation mentale de la logique conditionnelle.

Pour prolonger le travail à la maison, nous recommandons une consigne simple: choisir un autre lieu que l'élève fréquente régulièrement — la piscine municipale, la médiathèque du quartier, le cinéma local — et reproduire la même démarche en autonomie. L'exercice est redoutablement efficace pour transférer la méthode, et il révèle, presque à chaque fois, des situations où la logique conçue pour l'Aviodrome est insuffisante — ce qui oblige l'élève à inventer de nouvelles branches. C'est exactement le mouvement que nous cherchons à provoquer en classe: passer d'un consommateur d'algorithmes à un bâtisseur d'algorithmes, capable d'étayer ses propres raisonnements et, à terme, de structurer sa pensée bien au-delà de l'écran.

Photo: Mw007 at Dutch Wikipedia / CC BY-SA 3.0 — Wikimedia Commons