Achat de billets au Dôme de Milan : check-list Scratch

Achat de billets au Dôme de Milan: check-list Scratch

Pour le Dôme de Milan, le programme doit gérer l’âge du visiteur, son éventuel statut étudiant, le jour de la visite, le type de billet choisi et la présence d’un accompagnateur pour les mineurs.

C’est exactement le genre de problème où un algorithme peut sembler correct au premier regard tout en oubliant un cas particulier. Avant d’ouvrir Scratch, prends donc le temps de transformer l’énoncé en données, puis les données en conditions. La qualité du programme dépend moins du nombre de blocs utilisés que de l’ordre dans lequel tu les fais agir.

La bonne méthode est simple: repérer les variables, classer les règles tarifaires, isoler les exceptions, puis tester le programme avec des situations différentes. Si tu passes directement au codage, tu risques de mélanger la tarification, les informations pratiques et les règles de sécurité dans une seule suite de conditions difficile à relire.

Définir les variables: la base de tout algorithme fiable

La première étape consiste à demander au programme les informations dont il a réellement besoin. Dans Scratch, cela revient à créer des variables explicites et à poser les questions dans un ordre logique.

Pour une simulation Scratch du Dôme de Milan, tu peux utiliser les variables suivantes:

• age_visiteur: âge saisi par l’utilisateur;
• est_etudiant: réponse indiquant si le visiteur possède ou non le statut étudiant;
• jour_visite: jour choisi pour la visite;
• type_billet: catégorie de billet sélectionnée;
• prix_base: prix associé au billet avant l’application d’une réduction éventuelle;
• prix_final: montant à afficher après les différentes conditions;
• accompagnateur_present: réponse utilisée pour la vérification concernant les mineurs;
• nombre_personnes: taille du groupe, si l’exercice prévoit plusieurs visiteurs;
• effort_total_marches: nombre de marches à prévoir selon le mode d’accès choisi.

Le nom des variables n’est pas un détail décoratif. Une variable appelée age_visiteur indique immédiatement ce qu’elle contient. À l’inverse, a, x ou variable1 obligent à revenir dans le programme pour comprendre leur rôle. Dans un exercice d’algorithmique, cette lisibilité permet de suivre le raisonnement et de repérer plus facilement une erreur.

Dans Scratch, les espaces et les accents peuvent compliquer la saisie ou la lecture des noms. Utilise donc des noms courts, réguliers et sans ambiguïté, par exemple age_visiteur, jour_visite ou type_billet. Le plus important est de garder la même convention du début à la fin du programme.

Tu peux initialiser les variables lorsque le drapeau vert est cliqué, puis poser les questions à l’utilisateur:

1. demander l’âge;

2. demander le statut étudiant;

3. demander le jour de visite;

4. demander le type de billet;

5. demander, si nécessaire, si un adulte accompagne le visiteur.

Cet ordre suit la logique de la situation. L’âge et le type de billet servent au calcul du prix, tandis que le jour de visite peut modifier le cas particulier du Musée du Dôme. La question sur l’accompagnateur intervient ensuite dans le contrôle de sécurité.

Une variable bien nommée ne remplace pas le raisonnement, mais elle le rend visible. Dans un programme à conditions multiples, c’est une vraie aide pour celui qui code comme pour celui qui corrige.

Choisir le bon type de réponse

Certaines informations sont numériques, d’autres sont textuelles ou binaires. Il faut éviter de tout traiter de la même manière.

L’âge est un nombre: le programme pourra comparer age_visiteur à 5, 6, 17 ou 18. Le jour de visite est plutôt une réponse textuelle: le programme cherchera par exemple si la réponse est « mercredi ». Le statut étudiant et la présence d’un accompagnateur peuvent être demandés sous la forme « oui » ou « non ».

Une réponse binaire doit cependant être utilisée avec cohérence. Si tu demandes « Es-tu étudiant? », prévois ensuite les tests oui et non, sans alterner avec vrai, faux ou des variantes d’orthographe. Une différence minime dans le texte peut empêcher une condition Scratch de fonctionner.

Pour éviter les erreurs, tu peux aussi présenter les choix de manière très explicite:

• « oui » ou « non » pour le statut étudiant;
• le nom complet du jour;
• le nom exact du billet;
• « oui » ou « non » pour la présence d’un accompagnateur.

Si le programme est destiné à être utilisé par quelqu’un d’autre, ajoute un message qui rappelle les réponses attendues. Un utilisateur qui saisit « mer » au lieu de « mercredi » ne doit pas provoquer un résultat incompréhensible sans explication.

Construire l’arbre des conditions: tarif plein, réduit ou gratuit

Le cœur de l’algorithme d’achat de billets repose sur les conditions tarifaires. Pour le rendre fiable, il faut les examiner du cas le plus particulier au cas le plus général.

Dans les données de l’exercice, l’ordre peut être organisé ainsi:

1. si l’âge est inférieur ou égal à 5 ans, le billet est gratuit;

2. sinon, si l’âge est compris entre 6 et 17 ans, le tarif réduit s’applique;

3. sinon, si le visiteur a moins de 26 ans et possède le statut étudiant, vérifier si le billet choisi ouvre droit à cette réduction;

4. sinon, appliquer le plein tarif.

La première condition concerne la gratuité. Elle doit être traitée avant les réductions, car un enfant de 5 ans ne doit pas être envoyé dans la branche générale des tarifs réduits. La deuxième condition couvre toute la tranche des 6-17 ans: elle ne dépend pas du statut étudiant. Enfin, la réduction étudiante demande une vérification supplémentaire concernant le type de billet.

Cette hiérarchie évite les chevauchements. Elle permet aussi de lire le programme comme une phrase: « si le visiteur est dans le premier cas, appliquer cette règle; sinon, examiner le cas suivant ».

Le tableau tarifaire comme outil de préparation

Avant de programmer, écris le tableau des prix sur ton brouillon. Il ne sert pas à remplacer l’algorithme, mais à repérer les valeurs qui changent selon l’âge, le billet ou le jour.

La colonne des 6-17 ans doit être parcourue pour tous les billets. Le tarif réduit ne disparaît pas pour le Culture Pass ou le Fast-Track Combo Lift: il existe bien pour cette tranche d’âge. Ce point est important, car une case vide ou un tiret peut être interprété comme « aucune réduction », alors que la logique de l’exercice indique le contraire.

La situation étudiante est différente. Dans le modèle retenu ici, la réduction liée au statut étudiant concerne certains billets seulement. Le programme doit donc croiser deux informations:

• le visiteur a-t-il moins de 26 ans et le statut étudiant?
• le type de billet choisi fait-il partie des billets concernés?

Un test sur l’âge seul serait insuffisant. De même, un test sur le statut étudiant seul pourrait appliquer par erreur le tarif réduit à un billet qui ne l’autorise pas.

Organiser le calcul du prix

Une organisation pratique consiste à attribuer d’abord à prix_base le prix correspondant au type de billet. Ensuite seulement, le programme examine l’âge et le statut du visiteur pour déterminer le tarif final.

Tu peux raisonner en trois étapes:

• identifier le billet;
• choisir le prix associé à la catégorie d’âge ou au statut;
• appliquer, si nécessaire, la règle du mercredi.

Cette séparation rend le programme plus facile à modifier. Si le prix d’un billet change dans l’énoncé, tu n’as pas besoin de rechercher la valeur dans une longue série de conditions mélangées.

Dans Scratch, les blocs « si… alors… sinon » permettent de construire cette logique. Pour chaque billet, tu peux sélectionner un prix de départ, puis utiliser une condition plus générale pour la catégorie de visiteur. Une autre solution consiste à regrouper les conditions par catégorie d’âge. Le choix dépend de la forme de l’énoncé, mais dans les deux cas il faut éviter les répétitions inutiles.

Le bloc « rejoindre » est utile pour afficher une phrase complète. Le programme peut ainsi combiner un message et la valeur de prix_final, par exemple: « Le prix de votre billet est de 13 euros. » Cette étape paraît simple, mais elle permet de distinguer le calcul du résultat et son affichage.

Gérer les exceptions: le mercredi et le Musée du Dôme

Les exceptions sont souvent la partie la plus délicate d’une simulation Scratch. Elles ne concernent pas forcément une nouvelle catégorie de visiteur: elles peuvent modifier le résultat après un premier calcul.

Le cas du Musée du Dôme est traité séparément dans l’exercice. Le billet « Duomo + Museum » n’est pas à considérer de la même manière le mercredi, puisque le musée est fermé ce jour-là et que le prix indiqué pour cette formule est différent.

La condition doit donc vérifier deux éléments en même temps:

• le jour choisi est mercredi;
• le type de billet est « Duomo + Museum ».

Si les deux réponses sont exactes, le programme utilise le tarif prévu pour le mercredi. Il ne faut pas appliquer cette règle à tous les billets du Dôme. Un visiteur qui choisit le Combo Stairs ou le Combo Lift un mercredi ne doit pas recevoir automatiquement le prix du billet Museum.

Une manière claire de construire le raisonnement est la suivante:

1. reconnaître le type de billet;

2. déterminer si le tarif correspond au plein tarif, au tarif réduit 6-17 ans ou au tarif étudiant;

3. vérifier si le billet est la formule avec le musée;

4. vérifier le jour;

5. afficher le prix final.

Cette organisation évite de créer une branche différente pour chaque combinaison possible. Il existe plusieurs types de billets, plusieurs profils de visiteurs et plusieurs jours de visite: si chaque combinaison est écrite séparément, le programme devient rapidement difficile à contrôler.

Le mercredi doit être traité comme une exception attachée au billet du musée, pas comme une réduction générale appliquée à toute la billetterie.

Tester les cas qui risquent de se croiser

Un seul test ne suffit pas pour vérifier un algorithme conditionnel. Choisis des situations qui obligent le programme à emprunter des branches différentes.

Tu peux notamment tester:

• un enfant de 5 ans avec un billet Combo Stairs: la gratuité doit être retenue;
• un enfant de 8 ans avec un billet Combo Stairs: le tarif réduit de 11 € doit être affiché;
• un enfant de 8 ans avec un Culture Pass: le programme doit bien appliquer le tarif réduit de 13 €;
• un étudiant de 22 ans avec un Culture Pass un dimanche: le tarif étudiant doit être utilisé;
• un étudiant de 22 ans avec un billet Combo Lift: le tarif plein correspondant à ce billet doit rester appliqué;
• un adulte de 35 ans avec un billet Duomo + Museum un mercredi: le tarif du mercredi doit apparaître;
• un adolescent de 16 ans avec un billet Duomo + Museum un mercredi: le programme doit combiner la tranche d’âge et le tarif particulier du mercredi.

Ces essais ne servent pas uniquement à trouver une erreur de frappe. Ils permettent de vérifier l’ordre des conditions. Le test d’un enfant de 8 ans avec un Culture Pass est particulièrement utile: il montre que la réduction 6-17 ans fonctionne bien sur les billets qui comportent aussi une règle étudiante.

Note les résultats attendus sur ton brouillon. Si le programme affiche une valeur différente, ne modifie pas immédiatement un bloc au hasard. Reviens à la règle concernée et demande-toi quelle condition a été déclenchée trop tôt ou laquelle n’a pas été testée.

Escaliers contre ascenseur: modéliser l’effort de montée

La simulation ne porte pas seulement sur le prix. Le choix du billet peut aussi modifier l’information pratique donnée au visiteur. Les formules d’accès aux terrasses ne correspondent pas au même effort physique.

• Combo Stairs: accès par les escaliers, avec 251 marches à parcourir;
• Combo Lift: accès en ascenseur jusqu’à un niveau intermédiaire, puis environ 50 marches à monter pour atteindre le Belvédère.

L’erreur classique consiste à interpréter « ascenseur » comme « accès direct au sommet ». Or l’ascenseur ne supprime pas toute la montée. Les dernières marches doivent être annoncées clairement dans le message final.

Dans Scratch, le choix du billet peut modifier effort_total_marches. Si l’utilisateur sélectionne le Combo Stairs, la variable prend la valeur 251. S’il sélectionne le Combo Lift, elle prend la valeur approximative de 50. Le programme peut ensuite afficher une phrase adaptée:

• « Le Combo Stairs prévoit une montée de 251 marches. »
• « Le Combo Lift vous conduit à un niveau intermédiaire; il reste environ 50 marches jusqu’au Belvédère. »

Cette variable est intéressante parce qu’elle transforme une information pratique en donnée exploitable. Le programme ne se contente plus de dire qu’une option est « plus fatigante » ou « plus facile »: il associe le choix à une quantité précise de marches.

Il faut toutefois conserver le mot « environ » lorsque l’information elle-même est approximative. Une variable numérique ne doit pas donner une impression de précision supérieure à celle de la donnée de départ.

Ne pas confondre prix et information pratique

Le nombre de marches ne doit pas être mélangé à prix_final. Ce sont deux résultats différents:

• le prix répond à la question « combien coûte le billet? »;
• l’effort répond à la question « que devra faire le visiteur? ».

Garder deux variables séparées rend le programme plus clair et permet d’afficher les deux informations sans créer de condition inutile. Le programme peut d’abord annoncer le prix, puis préciser le mode d’accès et le nombre de marches.

Tu peux aussi prévoir un message lorsque le visiteur choisit une formule avec ascenseur: « L’ascenseur réduit la partie de la montée effectuée à pied, mais ne supprime pas les escaliers restants. » Ce type de phrase est utile dans une simulation destinée à un utilisateur réel, car elle évite une interprétation trompeuse du nom du billet.

Sécurité et accompagnement: la condition souvent oubliée

Une billetterie correctement calculée n’est pas encore un programme complet. Il faut aussi vérifier les règles de sécurité prévues par l’énoncé.

Pour les visiteurs mineurs, le programme doit demander si un adulte accompagnateur est présent. La condition à contrôler est double:

• l’âge est inférieur à 18 ans;
• aucun accompagnateur n’est présent.

Si ces deux éléments sont vrais, l’accès doit être refusé ou le programme doit afficher un message indiquant qu’un adulte est nécessaire. Si le visiteur est majeur, la question de l’accompagnement ne bloque pas l’achat. Si le visiteur est mineur mais accompagné, le programme peut poursuivre le calcul du billet.

Dans Scratch, cette règle s’exprime avec l’opérateur logique « et ». Il ne faut pas écrire deux tests indépendants qui afficheraient des messages contradictoires. Le programme doit considérer l’ensemble de la situation:

« Si l’âge est inférieur à 18 ans et si aucun accompagnateur n’est présent, alors afficher le message de sécurité. »

Le contrôle doit intervenir avant de présenter l’achat comme finalisé. Il serait incohérent d’annoncer « paiement accepté » puis de signaler ensuite que l’entrée n’est pas possible. Tu peux calculer le prix en amont, mais le message final doit tenir compte du résultat de la vérification.

Une règle de sécurité n’est pas un supplément ajouté après le calcul: elle fait partie de la décision finale du programme.

Le cas d’un groupe

Si l’exercice porte sur plusieurs personnes, nombre_personnes ne suffit pas à vérifier la présence d’un adulte. Le programme doit savoir si le groupe comprend au moins une personne majeure ou si l’utilisateur déclare la présence d’un accompagnateur.

Pour une version simple, tu peux demander: « Un adulte accompagne-t-il le groupe? » La réponse sera ensuite utilisée pour tous les visiteurs mineurs du groupe.

Pour une version plus complète, le programme peut demander le nombre de mineurs et le nombre d’adultes. La logique devient alors:

• si le groupe comprend des mineurs et au moins un adulte, la condition de sécurité est respectée;
• si le groupe ne comprend que des mineurs, l’accès doit être signalé comme impossible dans le cadre de l’exercice;
• si le groupe ne comprend aucun mineur, la vérification d’accompagnement n’est pas nécessaire.

Cette extension est intéressante parce qu’elle montre qu’une variable doit correspondre à une question précise. accompagnateur_present indique l’existence d’un adulte, tandis que nombre_personnes indique seulement la taille du groupe. Une seule de ces informations ne permet pas de déduire l’autre.

Ne pas oublier la gratuité des plus jeunes

Pour les enfants de 0 à 5 ans, le programme doit afficher la gratuité prévue par l’exercice. Cette gratuité ne signifie pas nécessairement qu’aucune démarche n’est nécessaire: le billet gratuit doit être retiré à la billetterie physique.

Le message peut donc distinguer le prix et la démarche:

« Le billet est gratuit pour ce visiteur. Un billet doit toutefois être retiré sur place. »

Cette précision évite de présenter la gratuité comme une entrée automatique sans formalité. Elle constitue aussi un bon exemple de différence entre une information numérique — le prix égal à zéro — et une information pratique — la nécessité de retirer le billet.

Mettre au propre: séparer les responsabilités du programme

Quand toutes les conditions sont réunies, le programme doit rester lisible. Une bonne simulation peut être divisée en plusieurs moments:

1. recueillir les réponses de l’utilisateur;

2. vérifier que les réponses sont acceptables;

3. déterminer la catégorie tarifaire;

4. calculer le prix;

5. appliquer l’exception du mercredi si elle concerne le billet choisi;

6. déterminer l’information liée aux escaliers ou à l’ascenseur;

7. vérifier l’accompagnement des mineurs;

8. afficher le résultat.

Cette séparation n’impose pas de créer huit scripts différents dans Scratch. Elle sert surtout à organiser ta pensée. Dans un même programme, les blocs peuvent être regroupés avec des commentaires qui indiquent leur fonction.

Par exemple, tu peux ajouter des commentaires comme:

• « Saisie des informations »;
• « Détermination du tarif »;
• « Cas particulier du mercredi »;
• « Information sur les marches »;
• « Vérification de sécurité »;
• « Affichage du résultat ».

Les commentaires doivent expliquer la logique, pas répéter le texte du bloc. « Si âge inférieur à 18 » apporte peu d’information. « Refuser l’accès lorsqu’un mineur n’a pas d’adulte accompagnateur » explique au contraire la raison de la condition.

Vérifier les entrées

Un programme peut aussi réagir lorsque l’utilisateur saisit une réponse inattendue. Si l’âge est négatif, si le jour n’est pas reconnu ou si le type de billet ne correspond à aucune catégorie, le résultat ne doit pas être présenté comme fiable.

Tu peux prévoir une réponse du type: « Réponse non reconnue, veuillez recommencer. » Dans Scratch, cette vérification peut être placée juste après chaque question ou regroupée avant le calcul.

Pour les réponses textuelles, fais attention aux majuscules et aux accents. Si le programme attend exactement « mercredi », une saisie comme « Mercredi » peut ne pas être reconnue selon la manière dont les blocs ont été construits. Pour un exercice de collège, le plus simple est souvent d’annoncer clairement le format attendu dans la question.

Vérifier les résultats affichés

Le programme doit afficher un résultat compréhensible par une personne qui ne voit pas les blocs Scratch. Évite une succession de nombres sans explication. Le message final peut réunir:

• le type de billet;
• le prix;
• la mention de gratuité ou de tarif réduit;
• l’information sur les marches;
• le rappel de billetterie physique pour les 0-5 ans;
• le message de sécurité si un accompagnateur est nécessaire.

Il est préférable de ne pas masquer une information importante dans un message trop long. Tu peux faire parler le lutin plusieurs fois: une phrase pour le prix, une autre pour l’accès et une dernière pour les éventuelles contraintes.

Relis aussi les unités et les formulations. Écris « 1 euro » et « 11 euros », affiche le symbole € si cela rend le résultat plus clair, et vérifie que les messages restent compréhensibles lorsque les valeurs changent.

Une méthode de test qui suit les branches de l’algorithme

Pour terminer, relis ton programme non pas comme une suite de blocs, mais comme une collection de situations possibles. Chaque règle importante doit apparaître dans au moins un essai.

Tu peux construire une petite série de tests en faisant varier un seul élément à la fois. Commence avec un adulte et un billet simple, puis change l’âge, le jour ou le type de billet:

• adulte avec Combo Stairs;
• visiteur de 8 ans avec Combo Stairs;
• visiteur de 8 ans avec Culture Pass;
• enfant de 5 ans avec n’importe quel billet;
• étudiant de moins de 26 ans avec Culture Pass;
• étudiant de moins de 26 ans avec Combo Lift;
• adulte avec Duomo + Museum un mercredi;
• visiteur de 16 ans avec Duomo + Museum un mercredi;
• mineur sans accompagnateur;
• mineur avec accompagnateur.

Cette liste permet de contrôler les principales intersections entre les règles. Elle vérifie notamment que la réduction 6-17 ans est appliquée à toutes les catégories de billets, que la réduction étudiante ne se déclenche pas partout et que le mercredi ne modifie que le billet concerné.

Si une erreur apparaît, identifie d’abord la variable responsable. Un prix incorrect peut venir du type de billet, de la catégorie d’âge ou du jour. Un message de sécurité absent peut venir de la réponse sur l’accompagnateur ou de l’opérateur « et ». Cette manière de chercher est plus efficace que de déplacer plusieurs blocs sans savoir quelle règle est corrigée.

Le brouillon doit donc contenir à la fois les variables, les conditions et quelques exemples de résultats attendus. Tu n’as pas besoin de recopier tout le programme sous forme de texte: il suffit de rendre visible le chemin suivi par les données.

La billetterie du Dôme de Milan constitue un bon exercice parce qu’elle oblige à passer d’une situation concrète à une logique structurée. Acheter des billets pour le Dôme de Milan devient ici une simulation: l’âge sélectionne une catégorie, le billet détermine le prix, le mercredi ajoute une exception, le choix entre escaliers et ascenseur produit une information pratique, et la présence d’un adulte contrôle l’accès des mineurs.

La réussite ne repose donc pas sur une longue série de blocs. Elle repose sur des variables compréhensibles, des conditions placées dans le bon ordre et des tests qui couvrent réellement les cas limites. Une fois cette structure posée sur le brouillon, Scratch ne fait plus que traduire un raisonnement déjà maîtrisé.

Photo: Jakub Hałun / CC BY-SA 4.0 — Wikimedia Commons