Erreur Scratch : acheter des billets Archiginnasio de Bologne
Quand nous préparons une sortie scolaire à Bologne, le premier réflexe pédagogique qui surgit est presque toujours le même: transformer le déplacement en exercice de calcul.

Acheter des billets Archiginnasio de Bologne: simuler le coût d'un groupe en Scratch
Avec l'Archiginnasio, ce réflexe prend tout son sens, parce que la visite mêle une cour en libre accès et des salles historiques soumises à billetterie. C'est précisément là qu'apparaît le blocage cognitif le plus fréquent chez les élèves de collège: ils imaginent qu'un prix unique multiplié par le nombre de participants suffit, alors que la réalité tarifaire du monument exige une vraie modélisation algorithmique. Aidons l'enfant à percevoir cette distance entre l'intuition et la rigueur avant de lui demander de coder.

Archiginnasio de Bologne
- Visite guidée privéevisite guidéedès110 €
- Visite guidée — Portiques de l'UNESCOvisite guidéedès165 €
Tarifs vérifiés le 17 août 2026 · prix à jour sur la page du partenaire.
Site officiel — bolognawelcome.com
- Durée de visite: 2–3 h
- Meilleur moment: tôt le matin
Tarifs indicatifs, susceptibles de changer — prix et disponibilités confirmés sur la page du partenaire.
Lien partenaire — billetterie GetYourGuideNous remarquons que cette confusion entre la valeur saisie et la valeur calculée est l'une des plus tenaces en classe de cinquième ou de quatrième. L'élève confond la variable qui compte les participants avec celle qui stocke le coût, oublie d'initialiser un accumulateur, ou empile les conditions dans le mauvais ordre. C'est un détour précieux que nous proposons ici: la sortie à l'Archiginnasio n'est pas qu'un déplacement, elle devient une situation-problème où chaque euro dépensé correspond à une instruction précise du programme.
La gratuité de la cour ne signifie pas la gratuité de la visite — c'est la première distinction que l'algorithme doit savoir faire.
Ce qui est gratuit et ce qui demande un billet dans le palais
Avant d'écrire la moindre ligne de Scratch, la classe doit comprendre la structure tarifaire réelle du lieu. L'Archiginnasio de Bologne n'est pas un monument monolithique: c'est un ensemble d'espaces aux régimes d'accès distincts, et cette stratification est exactement le type de donnée qu'un algorithme doit savoir traiter.
L'accès à la cour intérieure du palais est libre. On peut s'y promener, observer les arcades, les portraits d'anciens élèves et la statuaire sans débourser un centime. C'est une donnée fondamentale pour l'algorithme: la variable accès_cour vaut zéro, et cette gratuité doit apparaître explicitement dans le programme pour que l'élève ne l'oublie pas.
En revanche, la visite du Théâtre Anatomique et de la Salle Stabat Mater — les deux espaces historiques les plus emblématiques — est payante et soumise à une réservation préalable obligatoire. Le Théâtre Anatomique, construit en bois en 1637 par Antonio Levante, est une véritable petite salle de spectacle médicale dont l'accès est limité à des créneaux très courts. La Salle Stabat Mater, qui servait de salle d'apparat pour les leçons des docteurs, complète ce parcours payant.
| Espace | Conditions d'accès | Billet | Réservation |
|---|---|---|---|
| Cour intérieure du palais | Libre, en accès direct | Non requise | Non |
| Théâtre Anatomique | Créneau de 10 min, capacité limitée | Payant | Obligatoire en ligne |
| Salle Stabat Mater | Visite accompagnée | Payant | Obligatoire en ligne |
| Bibliothèque Comunale | Réservée aux chercheurs | Sans objet | Interdite aux touristes |
Cette distinction est essentielle, et elle correspond exactement à la structure conditionnelle que nous retrouverons dans Scratch: si l'espace figure dans la liste des espaces gratuits, alors la variable coût reste inchangée; sinon, on interroge la variable catégorie_visiteur.
Le parcours de réservation en ligne via Bologna Welcome
Maintenant que la structure tarifaire est posée, abordons le circuit concret de réservation. C'est ici qu'intervient le partenaire officiel: Bologna Welcome, l'office de tourisme qui centralise la billetterie en ligne pour le Théâtre Anatomique. Cette centralisation n'est pas un détail administratif: elle signifie que l'élève ne peut pas improviser l'achat sur place. Le programme Scratch doit donc intégrer la notion de réservation préalable comme une condition logique, et non comme une option que l'on traite à la fin.
Les billets touristiques s'achètent sur le site officiel de Bologna Welcome ou via des revendeurs tiers habilités. La plateforme propose plusieurs formules selon le format de visite souhaité: visite simple, visite avec audioguide, ou formules combinées. Le tarif exact est affiché sur la plateforme au moment de l'achat et évolue; nous ne le reproduisons pas ici, mais l'enseignant peut le consulter en direct et le saisir comme valeur dans son exercice, ce qui ancrera la simulation dans une donnée réelle.
Pour une sortie scolaire, les créneaux sont volontairement courts — dix minutes par groupe — et la capacité est plafonnée à trente personnes simultanément. Cela change profondément la manière de penser l'algorithme: on ne raisonne plus sur un seul achat, mais sur la répartition d'un groupe dans le temps. Les créneaux audioguidés s'enchaînent toutes les dix minutes de 10h00 à 17h40. Pour une classe de trente élèves, cela signifie concrètement qu'il faut réserver un créneau unique et non plusieurs achats séparés. L'élève qui code la simulation doit comprendre que la capacité est une donnée d'entrée, pas un paramètre que l'on ajuste après coup.
Les contraintes pratiques qui pèsent sur la préparation
Une fois la logique de réservation posée, il reste trois contraintes que l'algorithme Scratch doit pouvoir absorber sans broncher. Ce sont ces contraintes qui, mal prises en compte, produisent les erreurs de calcul les plus fréquentes chez les élèves.
La capacité et la durée des créneaux
Le Théâtre Anatomique accueille au maximum trente personnes par créneau, et la durée de présence à l'intérieur est limitée à dix minutes. Cette double contrainte transforme un calcul simple en un calcul conditionnel: combien de groupes de trente devons-nous former, et à quels créneaux successifs? Si la classe dépasse trente élèves, il faut soit scinder le groupe, soit réserver deux créneaux. L'algorithme doit prévoir cette bifurcation, et c'est précisément l'occasion d'introduire une division entière suivie d'un si/alors/sinon.
L'accès pour les personnes en situation de handicap
L'entrée principale se fait au Piazza Galvani 1, 40124 Bologne. Pour les personnes à mobilité réduite, un accès spécifique est prévu via le Via de' Foscherari n° 2. Cette mention est importante dans un programme scolaire: si un élève ou un accompagnateur est concerné, la variable accès_PSH doit être positionnée à vrai, et le programme doit proposer un message d'orientation différent. C'est un exercice modeste mais utile, qui apprend à l'élève que les conditions ne sont pas que tarifaires: certaines sont d'accessibilité.
Les jours et horaires d'ouverture
Le palais est fermé aux visites touristiques le dimanche et les jours fériés. Cette donnée semble anodine, mais elle est la source d'erreurs de planification très classiques: un élève qui programme sa sortie un samedi ne verra pas le problème, alors qu'un dimanche change toute la disponibilité. Dans Scratch, cela se traduit par une variable jour_fermé à intégrer dans la condition principale, avec un message d'erreur explicite si la sortie est planifiée ce jour-là.
Les règles d'usage à intégrer dans la simulation
Deux règles d'usage méritent d'être modélisées explicitement dans l'exercice, parce qu'elles sont souvent oubliées et qu'elles produisent des situations cocasses en classe.
L'audioguide se prend avec son propre téléphone
Pour les créneaux audioguidés, les visiteurs doivent impérativement utiliser leur propre smartphone et leurs propres écouteurs. Le palais ne prête pas de matériel. Cela signifie que l'algorithme doit prévoir une variable écouteurs_personnels initialisée à faux par défaut, avec un message d'avertissement si elle n'est pas validée. C'est un excellent exercice pour apprendre à l'élève que toutes les conditions ne sont pas tarifaires: certaines sont logistiques, et leur oubli ruine toute la sortie.
La bibliothèque Comunale n'est pas une salle de visite
La section de la bibliothèque de l'Archiginnasio est strictement réservée à la recherche et à la conservation, et donc interdite aux visites touristiques. Un enseignant qui voudrait y accéder avec sa classe n'y parviendra pas. Dans la simulation Scratch, cela se traduit par un message du type « cet espace n'est pas réservable via la billetterie touristique », et c'est l'occasion de rappeler que toutes les institutions culturelles ne fonctionnent pas comme des lieux de visite: certaines sont des lieux de savoir, et leur accès obéit à d'autres règles.
Modéliser une sortie culturelle, c'est d'abord distinguer ce qui est libre de ce qui ne l'est pas — le reste de l'algorithme en découle.
Traduire la sortie en exercice Scratch: éviter les erreurs de calcul
Voici le cœur de notre propos: comment transformer cette préparation en un projet Scratch robuste, et surtout, quelles sont les erreurs de variables que nous voyons revenir systématiquement chez les élèves de collège. Nous comparons ici deux approches pédagogiques pour faire émerger la plus fiable.
Approche 1: le calcul à plat
L'approche intuitive consiste à demander à l'élève d'utiliser directement les blocs de saisie et les opérateurs arithmétiques sans créer de variables intermédiaires. Le programme demande le nombre de participants, multiplie par un prix fixe, et affiche le résultat. Cette approche fonctionne pour un cas unique, mais elle s'effondre dès qu'on introduit une condition: gratuité pour les accompagnateurs, tarif réduit à partir d'un certain seuil, etc. L'élève ne sait plus où insérer la condition, et il finit par multiplier des chaînes de caractères entre elles, ce qui produit des erreurs silencieuses difficiles à déboguer.
Approche 2: la modélisation par variables
L'approche structurée consiste à créer explicitement une variable pour chaque donnée du problème, puis à combiner ces variables dans des calculs et des conditions. Voici la cartographie que nous proposons:
| Variable | Rôle | Type de valeur |
|---|---|---|
nb_élèves | Nombre de participants | saisie utilisateur |
nb_accompagnateurs | Adultes accompagnateurs | saisie utilisateur |
tarif_unitaire | Coût d'un billet plein | valeur de référence |
seuil_groupe | Nombre à partir duquel un tarif réduit s'applique | valeur de référence |
coût_total | Sortie finale du programme | calcul |
Cette approche permet d'introduire une condition simple: si nb_élèves est supérieur ou égal à seuil_groupe, alors on applique une réduction sur le tarif unitaire. C'est cette brique logique qui fait toute la différence entre un programme qui calcule et un programme qui décide.
Trois erreurs classiques à anticiper
L'erreur la plus fréquente consiste à utiliser une variable dans un calcul sans lui avoir attribué de valeur initiale. Scratch signale alors zéro comme résultat par défaut, et l'élève ne comprend pas pourquoi son programme affiche un coût nul. La parade est simple: initialiser systématiquement chaque variable en début de script, même si la valeur sera remplacée plus tard par une saisie. Cette habitude évite aussi des bugs liés à l'ordre d'exécution des blocs.
Un autre piège classique consiste à écrire si (nb_élèves > 10) alors au lieu de si (nb_élèves ≥ 10) alors. Cette différence d'opérateur change tout: un groupe de dix personnes paie plein tarif au lieu du tarif réduit. Apprendre à l'élève à réfléchir aux bornes inclusives et exclusives est un apprentissage mathématique fondamental, et la situation de la sortie scolaire le rend immédiatement concret.
Enfin, l'élève confond souvent la valeur de la variable avec le texte affiché. Si l'utilisateur saisit « 25 », Scratch stocke bien la valeur numérique 25, mais l'élève veut parfois afficher « vingt-cinq » en toutes lettres. Cette nuance est l'occasion de parler de la différence entre saisie, stockage et présentation — trois étapes distinctes dans un programme, et trois blocs Scratch différents.
Recommandation: un projet tangible à construire en classe
Pour conclure, nous proposons une posture concrète à l'enseignant ou au parent qui souhaite transformer cette préparation en projet Scratch abouti. Plutôt que de distribuer un corrigé tout fait, faisons émerger les erreurs chez les élèves en leur confiant un canevas incomplet: la liste des variables sans les valeurs initiales, la structure conditionnelle sans les opérateurs, la sortie sans la concaténation. Aidons l'enfant à percevoir, par touches successives, ce qui manque à son programme pour qu'il devienne fonctionnel. C'est cet étayage progressif qui consolide l'apprentissage, bien plus qu'une démonstration magistrale.
Le matériel tangible recommandé est simple: une feuille de brouillon où l'élève note, en français, ce que doit faire son programme — par exemple « si le groupe dépasse tel seuil, alors on applique tel tarif » — avant de traduire cette phrase en blocs Scratch. Cette étape intermédiaire, souvent négligée, est celle qui fait basculer l'intuition en algorithmie. Une fois la feuille validée, le passage au code se fait avec une charge cognitive bien moindre, et l'élève peut se concentrer sur la syntaxe plutôt que sur la logique.
La sortie culturelle n'est donc pas un détour par rapport à l'apprentissage du code: elle en est, si nous l'acceptons comme telle, l'un des meilleurs terrains d'exercice. En confrontant l'élève à un cas réel — un monument qu'il visitera peut-être, une réservation qu'il devra un jour faire seul — nous ancrons l'algorithmique dans une utilité concrète. C'est cette articulation entre le concept abstrait et la situation vécue qui donne du sens à l'apprentissage, et qui donne envie d'aller au bout du programme.
Infos pratiques
Monnaie : EUR
Conduite : à droite
Numéro d'urgence : 112