Simulation Scratch pour réserver à l'Art Institute of Chicago

Simulation Scratch pour réserver à l'Art Institute de Chicago

Le véritable blocage se situe en amont, dans l'architecture mentale: par où commencer, quoi tester en premier, comment organiser les variables pour que le code ne devienne pas, en une heure, un labyrinthe où même son auteur se perd. C'est précisément à ce moment qu'intervient la pédagogie — non pour livrer la solution, mais pour aider l'élève à percevoir la structure cachée derrière ce qui ressemble, au premier abord, à une simple grille administrative.

Chicago

Billets et tarifs

Art Institute of Chicago

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

Visite guidée coupe-file — Jusqu'à 12 personnes

2,5 h·★5,0·57 avis

dès89.38 USD

Réserver des billets

Billet coupe-file — Accès rapide

★4,8·956 avis

dès39.46 USD

Réserver des billets

Billet officiel — Entrée générale adulte

dès32 USD

Réserver des billets

Billetterie officielle et achat en ligne

Plein tarif7 USD

Enfantgratuit

Site officiel — artic.edu

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

Le scénario que nous proposons est particulièrement fécond, car il conjugue plusieurs notions algorithmiques classiques — variables, conditions, fonctions modulaires — autour d'un objet à la fois tangible et presque ludique: préparer la visite d'un grand musée. Que l'élève rêve de se retrouver face à Un dimanche après-midi à l'Île de la Grande Jatte de Seurat, face au American Gothic de Wood ou face aux Nighthawks de Hopper, il doit d'abord comprendre à quel prix, quel jour et à quelle heure la visite est possible — et c'est exactement la question algorithmique que nous allons bâtir ensemble.

Poser le décor: ce que le musée nous demande de modéliser

Avant tout bloc, nous nous asseyons avec l'élève et nous énumérons, en français courant, ce que le musée exige réellement pour délivrer un billet. Cette étape n'est pas une perte de temps — c'est la fondation sur laquelle l'algorithme reposera, et la brûler conduit presque toujours à un programme fragile qui s'effondre au premier cas particulier.

L'Art Institute of Chicago, situé au 111 South Michigan Avenue, distingue au minimum quatre catégories d'information que tout système de réservation doit capturer:

• L'âge du visiteur, car les enfants de moins de 14 ans entrent gratuitement, quel que soit leur lieu de résidence.
• Le lieu de résidence, car les habitants de Chicago bénéficient de tarifs distincts de ceux des autres résidents de l'Illinois, eux-mêmes différents des tarifs pour les visiteurs hors de l'État.
• Le jour souhaité, car le musée est fermé le mardi ainsi que trois jours spécifiques par an (Thanksgiving, le 25 décembre et le 1er janvier).
• Le créneau horaire, car la tranche de 10h à 11h est réservée aux membres, et parce que les jeudis soirs prolongent l'ouverture jusqu'à 20h avec des conditions particulières pour les résidents de l'Illinois.

Une fois cet inventaire établi, la transition vers les variables Scratch devient presque mécanique. Chaque item devient une variable, chaque question devient un bloc « demander et attendre », et l'élève perçoit immédiatement que programmer est, d'abord, un exercice de clarification.

Programmer, ce n'est pas d'abord manipuler des blocs: c'est regarder une situation réelle et la décomposer jusqu'à ce qu'elle devienne traitable par une machine.

Deux approches pédagogiques à comparer

À ce stade de la progression, nous présentons délibérément deux démarches à l'élève, parce que c'est leur comparaison qui produit la compréhension en profondeur.

La première, que l'on peut appeler monolithique, consiste à écrire une longue séquence unique de conditions imbriquées: « si âge < 14 alors prix = 0, sinon si résidence = Chicago et âge < 18 alors prix = 0, sinon si résidence = Illinois et jour = jeudi et heure ≥ 17h... ». Cela fonctionne, techniquement. Mais dès qu'une exception surgit — une nouvelle fermeture, un nouveau créneau gratuit — toute la pile doit être relue et modifiée. La charge cognitive croît linéairement avec le nombre de cas, ce qui devient vite intenable pour un collégien.

La seconde, que nous recommandons et que la suite de l'article développe, consiste à fragmenter le programme en plusieurs petits blocs personnalisés (custom blocks), chacun responsable d'une seule préoccupation. Un bloc vérifie si le musée est ouvert le jour choisi. Un autre détermine si le visiteur bénéficie de la gratuité. Un troisième renvoie le tarif de base. Un quatrième combine le tout pour produire la réponse finale. Chaque bloc se teste indépendamment, en isolation, avec des entrées simplifiées. Quand toutes les briques fonctionnent individuellement, l'assemblage devient une simple affaire d'empilement.

L'élève résiste souvent, au départ, à l'approche modulaire — il veut voir tourner le programme complet le plus vite possible. Nous lui expliquons patiemment qu'un bâtiment ne tient pas parce que nous avons dressé les murs vite; il tient parce que les fondations ont été posées avec soin. Ce vocabulaire de la construction n'est pas ornemental: il nomme une vérité pédagogique réelle, que l'élève retrouvera tout au long de son parcours algorithmique.

Modéliser le calendrier: un état à trois valeurs, pas un booléen

La première routine que nous construisons ensemble concerne le calendrier. C'est aussi celle où l'élève découvre le plus souvent que la réalité est plus complexe qu'imaginée.

L'Art Institute de Chicago est fermé le mardi — une régularité facile à encoder avec un test simple sur le jour de la semaine. Mais il est également fermé trois jours spécifiques par an: Thanksgiving, le 25 décembre et le 1er janvier. Ces exceptions peuvent être codées soit comme trois tests indépendants, soit, plus élégamment, comme une petite liste que le programme consulte. Dans Scratch, l'élève peut créer une liste nommée « jours_feries » et demander au programme de vérifier si la date choisie s'y trouve. C'est l'occasion d'introduire, de manière très concrète, la notion de structure de données — notion qui l'accompagnera tout au long de son parcours algorithmique.

Nous abordons ensuite les horaires d'ouverture, qui ne sont pas uniformes selon le jour. Lundi, mercredi, vendredi, samedi et dimanche suivent un créneau de 11h à 17h. Le jeudi s'étend jusqu'à 20h. La tranche 10h–11h est réservée aux membres — ni vraiment ouverte au public, ni totalement fermée. Le bloc personnalisé doit donc renvoyer non pas un simple oui/non, mais un état à trois valeurs possibles: ouvert à tous, réservé aux membres, ou fermé. C'est une petite révolution dans l'esprit de l'élève: une condition ne renvoie pas toujours vrai ou faux. Parfois elle renvoie une valeur plus riche, que le reste du programme saura interpréter.

Modéliser le tarif: la gratuité d'abord, le prix ensuite

Une fois le calendrier établi, nous attaquons la question du prix. Ici encore, l'ordre dans lequel nous organisons les tests compte — à la fois pour la lisibilité du code et pour l'efficacité réelle du programme.

Nous commençons par le cas le plus simple: les enfants de moins de 14 ans entrent gratuitement, quel que soit leur lieu de vie. Ce cas élimine une part significative des visiteurs du reste du calcul. Le bloc personnalisé commence donc par tester l'âge: s'il est inférieur à 14, il renvoie immédiatement zéro et s'arrête.

Nous testons ensuite le cas des adolescents: entre 14 et 17 ans, un résident de Chicago entre gratuitement, tandis qu'un non-résident paie le tarif adulte. C'est le moment idéal pour introduire l'opérateur logique ET: la condition combine un test d'âge et un test de résidence. Dans Scratch, cela se traduit par des conditions imbriquées, que l'élève manipule plus facilement qu'une condition composée dans un seul bloc.

Enfin, nous abordons le cas adulte, où s'applique le tarif à trois niveaux: résident de Chicago, autre résident de l'Illinois, visiteur hors de l'État. Nous demandons à l'élève d'ajouter un petit tableau de données en commentaire du projet, afin que les tarifs soient clairement visibles et modifiables sans toucher à la logique. C'est également ici qu'intervient le Chicago CityPASS comme alternative: un billet combiné qui inclut plusieurs attractions. L'élève peut ajouter une quatrième branche proposant cette option, ce qui introduit l'idée que l'algorithme ne calcule pas une seule réponse — il présente à l'utilisateur un ensemble de choix possibles.

Tester la gratuité avant le tarif n'est pas qu'une question de propreté: c'est économiser du calcul, mais surtout rendre le code lisible à celui qui le relira demain.

Les pièges classiques: ce que nous observons en classe

Après plusieurs années à accompagner des élèves sur cet exercice, nous avons identifié un petit nombre d'erreurs qui reviennent avec une régularité confinant à l'obstination. Les énumérer n'est pas un moyen de juger l'élève; c'est un moyen de consolider sa vigilance sur les points où la réalité échappe au modèle.

La première erreur consiste à oublier que le créneau des membres n'est pas un créneau public. Certains élèves programment le musée comme ouvert dès 10h, ce qui conduit un non-membre à réserver un créneau qu'il ne pourra pas utiliser. Nous les encourageons à ajouter un message d'erreur explicite: « Ce créneau est réservé aux membres du musée. Veuillez choisir un autre horaire. » Transformer un bug silencieux en information utile est une habitude fondamentale en programmation.

La deuxième erreur concerne les jeudis soirs. De 17h à 20h le jeudi, les résidents de l'Illinois bénéficient d'une fenêtre de gratuité spécifique — une courtoisie du musée que l'élève doit décider d'inclure ou d'exclure. Chaque choix est défendable, mais il doit être conscient. Nous suggérons que l'élève ajoute un commentaire dans le code pour expliquer ce choix. Commenter est, dans notre expérience, l'une des compétences les plus sous-estimées de l'apprentissage algorithmique.

La troisième erreur est la confusion entre l'entrée générale et les expositions temporaires. L'Art Institute de Chicago accueille régulièrement des expositions temporaires qui nécessitent un billet séparé, souvent plus coûteux. Si l'élève souhaite modéliser cet aspect, il doit ajouter une nouvelle variable — « type d'accès » — et une nouvelle branche dans le calcul. Cela ouvre la porte à une discussion sur la différence entre la collection permanente (où l'on trouve les chefs-d'œuvre impressionnistes, les Salles miniatures Thorne, l'Aile moderne ou Modern Wing) et les expositions temporaires, qui s'ajoutent et restent optionnelles.

Assembler le projet: quatre routines, pas un monolithe

Une fois chaque bloc testé indépendamment — et nous insistons sur ce point: chaque bloc testé séparément avant tout assemblage — la construction du programme final devient presque méditative. Nous organisons le projet en quatre routines distinctes, chacune avec une responsabilité claire:

1. Saisie — recueille l'âge du visiteur, sa résidence, le jour et l'horaire souhaités.

2. Vérification du calendrier — renvoie si le musée est ouvert, et si oui, sous quel mode.

3. Calcul du tarif — applique la logique de prix en fonction de l'âge, de la résidence, du jour et de l'horaire.

4. Affichage du résultat — présente un récapitulatif clair à l'utilisateur, sous forme d'une phrase énoncée par un lutin ou affichée à l'écran.

Le choix du lutin n'est pas neutre. Nous suggérons d'utiliser un lutin qui évoque le musée — par exemple l'un des célèbres Lions de bronze qui encadrent l'entrée sur Michigan Avenue, ou une représentation stylisée d'une œuvre de la collection impressionniste. Ce n'est pas un gadget: cela rend le programme tangible, cela engage la sensibilité esthétique de l'élève, et cela lui rappelle qu'un algorithme sert toujours un dessein humain.

Pour l'affichage, nous recommandons une formule qui ressemble à du langage naturel: « Visiteur âgé de [X], résidant à [Y], souhaitant visiter le [Z] à [T]: le prix est de [P] dollars. » Cette formule est elle-même un petit exercice algorithmique — elle nécessite une concaténation de chaînes, que Scratch gère avec le bloc « regrouper ». L'élève rencontre ainsi, presque sans s'en rendre compte, la manipulation de données textuelles — notion qui lui servira bien au-delà de ce seul projet.

Ce que nous bâtissons vraiment

Si nous prenons du recul par rapport aux blocs Scratch et à la question des tarifs, nous constatons que cet exercice construit quelque chose de plus profond qu'un simple programme de réservation. Il bâtit la capacité à regarder une situation réelle complexe — ici, la politique tarifaire et d'accès d'un grand musée — et à y voir une structure: des variables à identifier, des conditions à ordonner, des exceptions à traiter explicitement, des décisions à prendre consciemment quand le modèle pourrait aller dans plusieurs directions.

Ces compétences se transfèrent naturellement. La même décomposition qui permet de calculer un billet de musée permet aussi de planifier une sortie scolaire, d'équilibrer un budget familial ou de concevoir un quiz pour un petit frère. L'Art Institute de Chicago est, dans cet exercice, un prétexte — un prétexte riche, certes, ancré dans la culture et la géographie, mais un prétexte nonetheless. Ce que nous rapportons véritablement à la maison, c'est une manière de penser.

Pour l'enseignant ou le parent qui accompagne l'élève, la recommandation tangible est simple: imprimer la grille tarifaire officielle du musée — celle publiée sur leur site — et la placer à côté de l'écran. Ce double support matériel, papier d'un côté, ordinateur de l'autre, permet à l'élève de vérifier chaque étape de son algorithme contre une référence concrète. Cela ouvre aussi une conversation sur la raison pour laquelle les musées pratiquent tels ou tels tarifs, sur le financement des politiques de gratuité, et sur le rôle des institutions culturelles dans une ville comme Chicago. L'algorithme devient alors le seuil d'une réflexion plus large — et c'est là, dans notre expérience, que l'apprentissage s'ancre véritablement.

Photo: ajay_suresh / CC BY 2.0 — Wikimedia Commons