Billets du Palais Lobkowicz : l'algorithme de réservation

Billets du Palais Lobkowicz: l'algorithme de réservation

Le piège ne se trouve presque jamais dans l’addition finale: il se cache dans l’ordre des questions, dans les réductions qui ne se cumulent pas et dans les conditions mal traduites en blocs Scratch.

Le cas du Palais Lobkowicz, à Prague, est particulièrement intéressant. Le musée, installé dans le seul bâtiment privé du complexe du Château de Prague, applique des tarifs qui se modélisent avec des variables, des conditions et quelques vérifications précises. Pour comprendre comment acheter des billets Palais Lobkowicz, tu peux donc transformer une situation réelle de billetterie en un véritable exercice de programmation.

L’objectif n’est pas de reproduire un logiciel commercial complet. Il s’agit de construire un algorithme de réservation clair: l’utilisateur choisit un billet, indique son âge ou son statut, précise éventuellement la taille du groupe, puis obtient le montant total.

En algorithmique, le barème récompense moins la rapidité du calcul que la traduction exacte des règles.

Logique tarifaire et variables du Palais Lobkowicz

Avant d’ouvrir Scratch, tu dois isoler les informations utiles. Un programme ne peut pas « comprendre » une page de réservation comme le ferait un visiteur. Il faut lui donner des variables et des règles dans un ordre lisible.

Pour le Palais Lobkowicz, les données principales sont les suivantes:

Le musée est ouvert tous les jours de 9 h à 18 h. Le café et le restaurant attenants accueillent les visiteurs de 10 h à 18 h. Le concert quotidien commence à 13 h et dure une heure. Ces horaires ne servent pas directement au calcul du prix, mais ils peuvent intervenir dans une extension du programme: avertir l’utilisateur qu’une heure de visite est incompatible avec l’horaire choisi, ou lui rappeler que le concert commence à une heure fixe.

Les variables à créer

Pour une première version, tu peux prévoir:

• typeBillet: musée, concert ou combiné;
• statut: adulte, étudiant ou senior;
• age: utile pour vérifier le tarif réduit;
• nombrePersonnes: quantité de billets demandés;
• prixUnitaire: tarif avant multiplication;
• total: montant final;
• reductionGroupe: réduction appliquée au billet combiné;
• confirmation: réponse de l’utilisateur avant la validation.

Tu n’as pas besoin de créer une variable pour chaque détail du palais. Une variable doit avoir une fonction précise. Si tu crées heureOuverture, langueAudio, salleBaroque et ville sans les utiliser ensuite, ton programme devient plus difficile à lire sans gagner en efficacité.

L’audioguide du musée est disponible en neuf langues, dont le français. Cette information peut être intégrée à une question secondaire: « Choisis la langue de l’audioguide ». Elle ne modifie cependant pas le tarif indiqué. Il faut donc éviter de mélanger une information descriptive et une condition de calcul.

Attention à l’ordre des choix

Le type de billet doit être demandé avant le prix. C’est lui qui détermine les branches principales du programme.

Tu peux organiser le raisonnement ainsi:

1. Demander le type de billet.

2. Demander le nombre de personnes.

3. Pour chaque personne ou pour le groupe, déterminer le tarif applicable.

4. Appliquer la réduction de groupe si la règle est remplie.

5. Afficher le total.

6. Rappeler les contraintes pratiques de la réservation.

Cette organisation évite une erreur classique: demander d’abord « Es-tu étudiant? » alors que cette question ne sert pas de la même manière pour tous les billets. Dans un algorithme bien construit, chaque question arrive au moment où elle devient nécessaire.

Modéliser les réductions: étudiants, seniors et groupes

La difficulté principale de cette billetterie Palais Lobkowicz Prague ne vient pas des tarifs eux-mêmes. Elle vient de la formulation des conditions.

Le tarif réduit du musée est de 310 CZK pour les étudiants âgés de 7 à 26 ans et pour les seniors de 65 ans ou plus. Le billet combiné coûte 830 CZK pour un adulte et 730 CZK pour un étudiant ou un senior. Pour un groupe d’au moins 10 adultes, une réduction de 100 CZK par personne est appliquée sur le billet combiné.

Tu dois donc distinguer trois situations:

• une personne possède un tarif réduit grâce à son âge ou à son statut d’étudiant;
• un groupe atteint le seuil de 10 adultes;
• les deux conditions ne doivent pas être combinées automatiquement si la règle de la billetterie ne le prévoit pas.

Traduire une condition en langage simple

Prenons la réduction senior. La règle « senior à partir de 65 ans » devient:

• si age >= 65, alors le tarif senior peut être choisi;
• sinon, le tarif adulte reste applicable, sauf si le visiteur bénéficie d’une autre réduction prévue.

Pour un étudiant, le programme peut demander directement le statut, puis vérifier l’âge:

• si l’utilisateur répond « oui » à la question étudiant et indique un âge compris entre 7 et 26 ans, le tarif réduit est autorisé;
• si l’âge dépasse 26 ans, le programme ne doit pas appliquer automatiquement le tarif étudiant.

Cette vérification est pédagogique: dans une application réelle, le statut peut être contrôlé par un justificatif. Dans Scratch, tu simules cette règle avec des variables.

Le cas du groupe

La réduction de 100 CZK par personne ne concerne pas n’importe quelle réservation. Elle s’applique au billet combiné pour un groupe de 10 adultes ou plus.

La condition complète est donc:

typeBillet = combiné ET statut = adulte ET nombrePersonnes >= 10

Si l’un de ces éléments manque, la réduction ne doit pas être appliquée.

C’est ici que les opérateurs logiques deviennent indispensables. Dans Scratch, tu utiliseras un bloc « et » placé dans un bloc « si… alors ». Le programme doit vérifier simultanément plusieurs critères, et non les traiter comme trois réductions indépendantes.

Une réduction n’est pas une intention commerciale: dans Scratch, c’est une condition exacte, avec un seuil et un périmètre.

Réductions qui ne se cumulent pas

Imagine un groupe de 12 personnes comprenant 10 adultes et 2 étudiants. Si tu demandes seulement nombrePersonnes >= 10, tu risques d’accorder 100 CZK de réduction aux étudiants alors que la règle concerne les adultes. Si tu demandes seulement typeBillet = combiné, tu accordes la réduction aux groupes qui ne remplissent pas le seuil.

Pour éviter cette erreur, tu peux choisir l’un des deux modèles suivants.

Modèle collectif

Tu considères que la réservation porte sur un seul type de billet pour l’ensemble du groupe. L’utilisateur indique « adultes », « tarif réduit » ou « autre », puis le programme calcule le total.

Ce modèle est simple à programmer, mais il ne représente pas un groupe mixte.

Modèle détaillé

Tu demandes séparément:

• le nombre d’adultes;
• le nombre d’étudiants;
• le nombre de seniors.

Le programme calcule alors chaque sous-total. Pour le groupe d’adultes, il vérifie le seuil de 10. Pour les étudiants et les seniors, il applique le tarif réduit prévu.

Ce modèle demande davantage de variables, mais il est plus proche d’une réservation réelle. Il permet aussi de justifier chaque étape du calcul, ce qui est précieux dans une copie.

Construire l’algorithme de réservation

Un algorithme de réservation Scratch doit suivre le trajet naturel de l’utilisateur. Tu ne dois pas commencer par une grande série de blocs « si » placés au hasard. Trace d’abord l’ordre des décisions sur ton brouillon.

Étape 1: choisir le billet

Le programme peut afficher:

• 1: musée avec audioguide
• 2: concert de midi
• 3: billet combiné

La réponse est stockée dans typeBillet.

Ensuite, tu associes chaque choix à un prix de départ:

• si typeBillet = 1, alors prixAdulte = 380;
• si typeBillet = 2, alors prixAdulte = 600;
• si typeBillet = 3, alors prixAdulte = 830.

Pour le billet combiné, tu crées également prixReduit = 730. Pour le musée, prixReduit = 310.

Le concert seul mérite une remarque de méthode: la donnée fournie établit le tarif adulte de 600 CZK, mais ne donne pas de tarif réduit correspondant. Ton programme scolaire ne doit pas inventer un montant. Tu peux soit limiter cette option au tarif adulte, soit afficher un message indiquant que le tarif réduit doit être confirmé dans la billetterie au moment de la réservation.

Cette prudence rapporte des points dans une démonstration: tu distingues une information connue d’une hypothèse.

Étape 2: demander le profil du visiteur

Pour le musée et le billet combiné, le programme demande le statut du visiteur. Tu peux utiliser une réponse textuelle:

• adulte
• étudiant
• senior

Mais une réponse numérique est souvent plus fiable dans Scratch:

• 1 pour adulte;
• 2 pour étudiant;
• 3 pour senior.

Un nombre réduit les problèmes liés aux majuscules, aux accents ou aux fautes de frappe. Le programme peut ensuite associer la réponse à la condition correspondante.

Pour un étudiant, demande l’âge. Pour un senior, demande également l’âge afin de vérifier le seuil de 65 ans. Si la personne indique un statut incohérent avec son âge, le programme peut afficher un message d’erreur et demander une nouvelle réponse.

Par exemple:

• étudiant avec age < 7 ou age > 26: afficher « Le tarif étudiant indiqué ici s’applique de 7 à 26 ans »;
• senior avec age < 65: afficher « Le tarif senior commence à 65 ans ».

Tu ne dois pas laisser le programme poursuivre avec un prix réduit après une réponse invalide. Sinon, le résultat final paraît correct mais la logique est fausse.

Étape 3: calculer le prix unitaire

Une fois le type de billet et le statut connus, affecte le bon montant à prixUnitaire.

Pour le musée:

• adulte: 380 CZK;
• étudiant autorisé: 310 CZK;
• senior autorisé: 310 CZK.

Pour le billet combiné:

• adulte: 830 CZK;
• étudiant autorisé: 730 CZK;
• senior autorisé: 730 CZK.

Pour le concert seul:

• adulte: 600 CZK;
• tarif réduit: à confirmer, si tu veux laisser cette possibilité dans le programme.

Le mot « autorisé » est important. Le programme ne doit pas simplement croire une réponse; il doit vérifier la condition associée.

Étape 4: multiplier par le nombre de personnes

Demande ensuite nombrePersonnes. Le nombre doit être supérieur ou égal à 1. Si l’utilisateur saisit 0 ou un nombre négatif, le programme doit refuser la donnée.

Le calcul de base est:

total = prixUnitaire × nombrePersonnes

Dans Scratch, tu peux utiliser le bloc opérateur de multiplication. Affiche ensuite le total en précisant la devise:

« Le montant provisoire est de … CZK. »

Le mot « provisoire » est utile si la réduction de groupe n’a pas encore été examinée.

Étape 5: appliquer la réduction de groupe

La réduction de 100 CZK par personne s’applique seulement au billet combiné pour un groupe d’au moins 10 adultes.

Si tu utilises le modèle collectif, la condition peut être écrite ainsi dans ton brouillon:

si typeBillet = combiné et statut = adulte et nombrePersonnes >= 10

Alors:

prixUnitaire = 830 - 100

Puis:

total = prixUnitaire × nombrePersonnes

Pour 10 adultes, le calcul devient donc:

• tarif normal: 10 × 830 = 8 300 CZK;
• réduction: 10 × 100 = 1 000 CZK;
• total: 7 300 CZK.

Le programme peut aussi calculer le total normal, puis soustraire la réduction:

total = 830 × nombrePersonnes - 100 × nombrePersonnes

Les deux méthodes donnent le même résultat. La première est souvent plus lisible pour un élève, car elle transforme d’abord le prix unitaire. La seconde montre explicitement le montant de la réduction.

Une table de tests avant l’affichage final

Ne lance pas ton programme uniquement avec le cas qui fonctionne. Prépare plusieurs tests sur ton brouillon:

Le cinquième cas doit être défini clairement dans ton modèle. Si tu choisis de traiter les groupes mixtes, tu dois séparer les catégories. Si tu ne les traites pas, indique dans ton programme que la version étudiée concerne un groupe homogène. Une limite clairement annoncée vaut mieux qu’un calcul ambigu.

Implémenter l’algorithme sous Scratch

Scratch permet de représenter très visuellement les étapes du calcul. Tu peux construire ton programme autour des blocs « demander et attendre », « mettre variable à », « si… alors », « sinon » et des opérateurs de comparaison.

Une organisation en trois parties

Pour garder une structure lisible, sépare ton script en trois moments:

1. Saisie: le programme pose les questions et enregistre les réponses.

2. Traitement: il choisit le prix, vérifie les conditions et calcule le total.

3. Résultat: il affiche le montant et les informations pratiques.

Même si Scratch ne t’oblige pas à créer des fonctions, cette organisation joue le rôle d’un plan de démonstration. Le correcteur cherchera à lire une suite logique: donnée, décision, calcul, affichage.

Tu peux utiliser trois messages:

• lancer la réservation;
• calculer le tarif;
• afficher le résultat.

Cela évite de placer tous les blocs sous le drapeau vert dans une colonne interminable.

Les blocs de décision

Pour le choix du billet, utilise une structure emboîtée:

• si la réponse vaut 1, choisir le musée;
• sinon, si la réponse vaut 2, choisir le concert;
• sinon, si la réponse vaut 3, choisir le combiné;
• sinon, demander une nouvelle réponse.

Chaque branche doit affecter les variables nécessaires. Ne mélange pas la question du statut avec celle du nombre de personnes avant d’avoir identifié le type de billet.

Pour le statut, tu peux procéder de la même façon:

• si statut = 1, prix adulte;
• sinon, si statut = 2, vérifier l’âge étudiant;
• sinon, si statut = 3, vérifier l’âge senior;
• sinon, afficher une erreur.

Une erreur fréquente consiste à écrire trois blocs « si » indépendants qui modifient tous prixUnitaire. Si les conditions sont mal exclusives, le dernier bloc exécuté peut écraser le résultat du précédent. Utilise une structure « si… alors… sinon si… sinon » lorsque les choix s’excluent mutuellement.

Comparer correctement les nombres

Dans Scratch, les blocs de comparaison permettent de tester:

• age > 26;
• age < 7;
• age >= 65;
• nombrePersonnes >= 10.

Le signe doit correspondre exactement à la règle.

Par exemple, « à partir de 65 ans » signifie age >= 65, et non age > 65. Avec age > 65, une personne de 65 ans serait injustement exclue du tarif senior. C’est une petite différence visuelle, mais elle change le résultat et peut coûter le point de justification.

Même vigilance pour « au moins 10 adultes ». Il faut écrire nombreAdultes >= 10, pas nombreAdultes > 10. Le groupe de 10 doit bénéficier de la réduction.

Variables et réinitialisation

Lorsque tu relances le programme, les anciennes valeurs ne doivent pas rester actives. Au début de la réservation, remets à zéro:

• total;
• prixUnitaire;
• reductionGroupe;
• les compteurs éventuels.

Sinon, un premier test avec 10 personnes peut laisser une réduction dans la mémoire du programme, puis fausser un second test avec 2 personnes.

Cette erreur est très fréquente dans les projets Scratch. Le programme semble fonctionner au premier lancement, mais son comportement dépend de ce qui s’est passé avant. Pour la corriger, place les blocs de réinitialisation immédiatement après le démarrage.

Modèle détaillé pour un groupe mixte

Si tu veux produire une version plus solide, ne demande pas un statut unique. Demande:

• nombreAdultes;
• nombreEtudiants;
• nombreSeniors.

Le programme peut alors calculer:

• adultes musée: nombreAdultes × 380;
• étudiants musée: nombreEtudiants × 310;
• seniors musée: nombreSeniors × 310.

Pour le billet combiné:

• adultes: nombreAdultes × 830;
• étudiants: nombreEtudiants × 730;
• seniors: nombreSeniors × 730.

La réduction de groupe est ensuite liée uniquement au nombre d’adultes:

• si le billet est combiné et si nombreAdultes >= 10, alors soustraire 100 × nombreAdultes.

Le total devient la somme des trois sous-totaux, moins la réduction éventuelle.

Cette méthode demande plus de blocs, mais elle évite une confusion importante: le nombre total de visiteurs n’est pas toujours le nombre d’adultes. Un groupe de 10 personnes composé de 8 adultes et 2 étudiants ne remplit pas la condition « 10 adultes ou plus ».

Pour gagner le point de calcul, écris d’abord les sous-totaux. Pour gagner le point de méthode, montre ensuite pourquoi la réduction s’applique — ou ne s’applique pas.

Ajouter les contraintes réelles de la réservation

Un bon algorithme ne s’arrête pas au prix. Il doit aussi restituer les informations qui changent concrètement la visite.

Le billet en ligne n’est pas le billet physique

Une réservation en ligne génère un bon, ou voucher. Ce document doit être échangé contre un billet physique au guichet du Palais Lobkowicz. L’échange ne se fait pas aux guichets généraux du Château de Prague.

Cette distinction doit apparaître dans le résultat du programme, par exemple:

« Votre réservation est enregistrée. Présentez le voucher au guichet du Palais Lobkowicz pour obtenir les billets physiques. »

Évite une formulation comme « Accès direct au musée », qui serait fausse. Le programme doit transmettre une instruction opérationnelle, pas seulement confirmer le paiement.

Tu peux créer une variable voucher contenant la valeur « échange obligatoire au guichet du palais ». Cette variable n’intervient pas dans le calcul, mais elle complète le parcours utilisateur.

Le concert et le placement libre

Le concert de musique classique commence chaque jour à 13 h et dure une heure. La salle baroque date du XVIIe siècle. Les portes ouvrent 15 minutes avant le début de la représentation.

Les places ne sont pas numérotées. Le placement se fait selon le principe du premier arrivé, premier servi. Ton programme peut donc afficher:

« Pour le concert, arrive avant l’ouverture de la salle à 12 h 45. Les places sont libres et attribuées selon l’ordre d’arrivée. »

Ne crée pas de variable numeroDeSiege si aucun siège n’est réservé individuellement. Ce serait une représentation incorrecte de la situation.

En revanche, tu peux ajouter une alerte:

• si le billet contient le concert, afficher l’horaire de 13 h;
• rappeler l’ouverture de la salle 15 minutes avant;
• signaler l’absence de placement numéroté.

Vérifier les horaires dans une version avancée

Les horaires permettent d’ajouter une règle de cohérence. Si l’utilisateur indique une arrivée à 8 h 30, le programme peut signaler que le musée n’est pas encore ouvert. S’il indique une arrivée à 18 h 15, il doit également prévenir que la fermeture est dépassée.

Tu peux poser la question:

« À quelle heure prévois-tu d’arriver? »

Puis convertir la réponse en nombre de minutes depuis minuit, par exemple:

• 9 h = 540 minutes;
• 13 h = 780 minutes;
• 18 h = 1 080 minutes.

Cette conversion n’est pas indispensable pour l’exercice principal. Elle devient utile si tu veux comparer mathématiquement une heure avec une borne d’ouverture.

Pour le musée:

• arrivée valide si l’heure est comprise entre 9 h et 18 h;
• arrivée avant 9 h: afficher « Le musée n’est pas encore ouvert »;
• arrivée après 18 h: afficher « Le musée est fermé ».

Pour le concert:

• début fixe à 13 h;
• ouverture de la salle à 12 h 45;
• durée d’une heure.

Ne prétends pas que le programme réserve un créneau horaire pour le musée si la règle tarifaire étudiée ne le prévoit pas. Il vérifie une cohérence d’itinéraire; il ne remplace pas le système de réservation.

Vérifier le programme comme une démonstration

Tu dois tester ton algorithme comme tu vérifierais une figure géométrique: en observant les cas ordinaires, puis les cas limites.

Commence par un adulte seul qui choisit le musée. Le résultat attendu est simple: 380 CZK.

Teste ensuite les frontières:

• étudiant âgé de 7 ans;
• étudiant âgé de 26 ans;
• étudiant âgé de 27 ans;
• senior âgé de 64 ans;
• senior âgé de 65 ans;
• groupe de 9 adultes;
• groupe de 10 adultes.

Ces valeurs sont choisies parce qu’elles se trouvent juste autour des seuils. Elles révèlent immédiatement une erreur de signe ou une condition incomplète.

Les erreurs qui font perdre des points

Appliquer la réduction de groupe au musée

La réduction de 100 CZK par personne concerne le billet combiné pour les groupes d’au moins 10 adultes. Si tu la soustrais du tarif musée, tu modifies une règle qui n’existe pas.

Confondre étudiant et jeune visiteur

Le tarif réduit est indiqué pour les étudiants de 7 à 26 ans et les seniors de 65 ans et plus. Tu ne dois pas remplacer cette règle par « tous les moins de 26 ans » sans vérifier le statut étudiant.

Utiliser le nombre total au lieu du nombre d’adultes

Dans un groupe mixte, nombrePersonnes >= 10 ne suffit pas. La condition porte sur les adultes. Crée nombreAdultes si tu veux représenter correctement ce cas.

Oublier de recalculer le total

Si tu modifies prixUnitaire après avoir déjà calculé total, le résultat peut rester fondé sur l’ancien prix. Décide d’un ordre fixe: déterminer le prix, appliquer la réduction, puis multiplier.

Inventer un tarif absent

Le prix adulte du concert seul est de 600 CZK. Si tu ne disposes pas d’un tarif réduit confirmé pour cette option, ne fabrique pas une valeur pour compléter le tableau. Indique la limite du modèle ou réserve cette branche aux adultes.

Dire que le voucher suffit pour entrer

Le voucher doit être échangé contre un billet physique au guichet du Palais Lobkowicz. Cette étape doit rester visible dans l’algorithme et dans le message final.

Une vérification visuelle sur le brouillon

Avant de programmer, trace trois colonnes:

• Entrées: type de billet, âge, statut, nombre de personnes;
• Décisions: tarif réduit, seuil de groupe, billet combiné;
• Sorties: prix unitaire, réduction, total, consignes pratiques.

Puis relie chaque entrée à la décision qui l’utilise. Si une variable n’est reliée à aucune décision, elle est probablement inutile. Si une décision n’a aucune donnée d’entrée, elle est probablement mal définie.

Cette méthode est simple, mais elle t’empêche de construire un programme qui saute directement de la question au résultat sans justification.

Rédiger l’explication qui rapporte les points

Dans un exercice évalué, le programme seul ne suffit pas toujours. Tu dois expliquer les conditions en phrases complètes.

Écris par exemple:

« Le billet combiné coûte 830 CZK pour un adulte. Si la réservation concerne au moins 10 adultes, une réduction de 100 CZK est appliquée par personne. Le prix unitaire devient donc 730 CZK, puis le total est obtenu en multipliant ce prix par le nombre d’adultes. »

Cette rédaction montre trois éléments:

1. la règle utilisée;

2. la condition qui déclenche la réduction;

3. le calcul effectué après la décision.

Pour un groupe de 10 adultes:

« Comme 10 est supérieur ou égal à 10, la condition de groupe est vérifiée. Le tarif par personne est donc 830 − 100 = 730 CZK. Pour 10 personnes, le montant final est 10 × 730 = 7 300 CZK. »

Le signe >= doit apparaître dans ton raisonnement sous la forme « supérieur ou égal à ». Ne te contente pas d’écrire « réduction de groupe »: le correcteur doit pouvoir vérifier que tu as compris le seuil.

Pour finir, rappelle les contraintes essentielles: le concert commence à 13 h, les portes ouvrent 15 minutes avant, les places ne sont pas numérotées et le voucher doit être échangé au guichet du palais.

Le résultat attendu n’est pas un programme qui donne seulement un nombre. C’est une réservation modélisée avec des données fiables, des conditions lisibles et un message final utilisable. En procédant dans cet ordre — choisir, vérifier, calculer, contrôler, expliquer — tu transformes la billetterie du Palais Lobkowicz en un exercice complet d’algorithmique Scratch, sans laisser les détails pratiques fausser la logique.

Photo: VitVit / CC BY-SA 3.0 — Wikimedia Commons