Musée canadien de la guerre visite : étapes du projet Scratch

Musée canadien de la guerre visite: étapes du projet Scratch

Le jeudi, l’entrée est gratuite seulement entre 17 h et 19 h, mais le billet à heure déterminée reste obligatoire. Une visite guidée ajoute une condition de groupe.

Musée canadien de la guerre

4,7· 90 avis

Réserver des billetsdès 15 €

• Billet officiel — Adulteofficial ticketdès23 CAD

Au guichet23 CAD

En lignedès 15 €selon l'option

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

Site officiel — warmuseum.ca

• 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

Ces règles forment un problème d’algorithmique. Il faut donc les transformer en variables, en tests logiques et en résultats affichés. Le projet Scratch ne reproduit pas le musée. Il simule la planification d’une visite au Musée canadien de la guerre, situé au 1, place Vimy, à Ottawa.

L’objectif est précis: saisir les données d’une visite, vérifier les contraintes, calculer le montant correspondant et indiquer si le programme accepte ou refuse la demande.

Une règle réelle devient exploitable dans Scratch seulement après avoir été convertie en variable ou en condition.

1. Définir le modèle de la visite

Le programme doit travailler avec des données simples. Chaque donnée possède un rôle. Une variable stocke une valeur. Une condition compare cette valeur à une règle. Une sortie explique le résultat.

Pour une simulation Scratch au collège, les variables suivantes suffisent:

• jour: jour choisi pour la visite;
• heure: heure d’arrivée ou de créneau;
• nombreVisiteurs: nombre de personnes;
• billetReserve: indique si un billet à heure déterminée existe;
• visiteGuidee: indique si le groupe demande une visite guidée;
• tarifEntree: valeur de référence de l’entrée;
• tarifGuide: valeur de la visite guidée;
• gratuitJeudi: résultat du test de gratuité;
• montantTotal: résultat du calcul;
• accesAutorise: résultat final de la vérification.

Le musée exige un billet à heure déterminée pour chaque visiteur. La réservation peut être effectuée en ligne ou par téléphone. Dans le programme, cette règle se traduit par une variable booléenne. Elle ne contient pas un texte long. Elle contient une réponse logique:

• oui;
• non.

Une autre méthode consiste à utiliser 1 pour oui et 0 pour non. Cette méthode est utile dans les calculs, mais elle est moins lisible pour un premier projet. Il faut donc privilégier oui et non.

Données fixes et données saisies

Le programme ne doit pas confondre les informations permanentes avec les choix de l’utilisateur.

Les données liées au musée sont fixes dans le contexte du projet:

• adresse: 1, place Vimy, Ottawa;
• station de transport proche: Pimisi;
• durée indicative du trajet à pied depuis la station: environ sept minutes;
• capacité maximale d’une visite guidée: quinze personnes;
• période de gratuité: jeudi, de 17 h à 19 h;
• année d’ouverture du bâtiment actuel: 2005.

Les données de la simulation sont saisies à chaque exécution:

• le jour;
• l’heure;
• le nombre de visiteurs;
• la présence d’un billet;
• le choix d’une visite guidée;
• les valeurs tarifaires utilisées pour la simulation.

Les prix changent. Ils ne doivent donc pas être écrits définitivement dans les blocs si l’objectif est de construire un modèle réutilisable. Le programme demande les valeurs ou les place dans des variables modifiables.

2. Construire l’interface de saisie

Le programme commence par nettoyer l’écran et remettre les variables à zéro. Sinon, une ancienne exécution peut modifier le résultat de la suivante.

L’ordre recommandé est le suivant:

1. Ajouter le bloc quand drapeau vert cliqué.

2. Ajouter effacer tout.

3. Donner une valeur initiale à chaque variable.

4. Demander le jour.

5. Demander l’heure.

6. Demander le nombre de visiteurs.

7. Demander si un billet à heure déterminée a été réservé.

8. Demander si une visite guidée est souhaitée.

9. Exécuter les tests.

10. Afficher le résultat.

Le programme doit contrôler les réponses. Une saisie comme Jeudi et une saisie comme jeudi désignent la même information pour l’utilisateur, mais pas nécessairement pour le programme. Il faut donc normaliser la donnée.

Dans Scratch, la solution la plus simple consiste à donner une consigne stricte:

• écrire jeudi en minuscules;
• écrire une heure entière, par exemple 18;
• écrire un nombre entier pour les visiteurs;
• répondre oui ou non.

Une interface claire réduit les erreurs d’inattention. Elle ne remplace pas les tests. Elle les complète.

Exemple de séquence de questions

Le programme peut afficher les demandes suivantes:

1. Quel jour choisissez-vous?

2. À quelle heure arrivez-vous? Écrivez une heure entière.

3. Combien de personnes viennent?

4. Un billet à heure déterminée est-il réservé? oui/non

5. Souhaitez-vous une visite guidée? oui/non

La réponse donnée après chaque question est stockée dans la variable réponse, puis transférée dans la variable correspondante.

Exemple logique:

• demander Quel jour choisissez-vous? et attendre;
• mettre jour à réponse;
• demander À quelle heure arrivez-vous? et attendre;
• mettre heure à réponse.

La même structure est utilisée pour les autres variables.

3. Vérifier le billet et le créneau horaire

La première règle d’accès est indépendante du tarif. Une entrée gratuite ne signifie pas une entrée sans réservation. Le jeudi entre 17 h et 19 h, le billet à heure déterminée reste obligatoire.

Le programme doit donc effectuer deux opérations différentes:

• vérifier l’existence du billet;
• vérifier si les conditions de gratuité sont remplies.

Il ne faut pas écrire une condition qui associe automatiquement gratuité et accès. Ce serait une erreur logique.

Test du billet

La règle est:

Si aucun billet n’est réservé, alors l’accès est refusé.

Dans Scratch:

• si billetReserve = non alors;
• dire Accès impossible: un billet à heure déterminée est nécessaire.;
• mettre accesAutorise à non.

Le programme peut arrêter l’exécution après ce message. Dans un projet plus complet, il peut continuer pour afficher toutes les erreurs. Les deux méthodes sont possibles.

La méthode d’arrêt immédiat est plus simple:

1. tester le billet;

2. refuser si la condition est fausse;

3. poursuivre seulement si le billet existe.

La méthode de diagnostic complet est plus informative:

• créer une variable erreur;
• ajouter un message à erreur pour chaque contrainte non respectée;
• afficher toutes les erreurs à la fin.

Pour un projet de collège, la première méthode est suffisante. Elle rend l’ordre des tests visible.

Test de l’heure

L’heure doit être interprétée comme une valeur numérique. Le programme doit comparer heure à deux bornes:

• borne minimale: 17;
• borne maximale: 19.

La condition logique est:

jour = jeudi ET heure >= 17 ET heure <= 19

Dans Scratch, cette condition utilise deux blocs et imbriqués. Le programme ne doit pas tester seulement heure = 17 ou heure = 19. La gratuité concerne tout l’intervalle compris entre ces deux valeurs.

Il faut aussi décider si l’heure 19 est acceptée. La règle donnée utilise la période 17 h à 19 h. Pour la simulation, on peut considérer les bornes comme incluses. Cette convention doit être annoncée dans le projet. Sans convention, le programme peut produire un résultat ambigu.

4. Calculer le montant de la visite

Le calcul tarifaire vient après les contraintes d’accès. Sinon, le programme peut calculer un montant pour une visite qui doit être refusée.

Le modèle comprend deux composantes:

• le coût de l’entrée;
• le coût éventuel de la visite guidée.

On introduit deux variables de référence:

• tarifEntree;
• tarifGuide.

Le calcul de base est:

montantTotal = nombreVisiteurs × tarifEntree

Si une visite guidée est choisie, le calcul devient:

montantTotal = nombreVisiteurs × tarifEntree + nombreVisiteurs × tarifGuide

Cette écriture suppose que le tarif guidé est appliqué à chaque personne. Si les conditions tarifaires utilisées dans la simulation prévoient une autre règle, il faut modifier la formule. Le programme ne doit pas deviner.

Ordre des opérations

Scratch applique les priorités opératoires usuelles. Toutefois, les parenthèses rendent le calcul lisible.

Écrire mentalement:

nombreVisiteurs × (tarifEntree + tarifGuide)

est équivalent à:

nombreVisiteurs × tarifEntree + nombreVisiteurs × tarifGuide

si la visite guidée concerne chaque personne.

La première forme est plus courte. La seconde montre les deux postes. Pour l’apprentissage, la seconde est préférable. Elle permet de détecter une erreur dans l’un des tarifs.

Algorithme du tarif

1. Mettre montantTotal à nombreVisiteurs × tarifEntree.

2. Si visiteGuidee = oui, ajouter nombreVisiteurs × tarifGuide.

3. Si gratuitJeudi = oui, remplacer le coût d’entrée par zéro.

4. Conserver le coût de la visite guidée si le modèle prévoit qu’elle reste payante.

5. Afficher le résultat.

Le point 4 doit être explicite. La gratuité concerne l’entrée pendant la période prévue. Elle ne supprime pas automatiquement les autres prestations. Le programme doit donc distinguer tarifEntree et tarifGuide.

Tableau des cas tarifaires

Le tableau ne remplace pas les blocs Scratch. Il décrit les résultats attendus. Il sert donc de référence pour les tests.

Le tarif et l’accès sont deux variables différentes. Le premier se calcule. Le second se valide.

5. Programmer la gratuité du jeudi soir

La gratuité est le test le plus exposé à l’erreur. Trois informations doivent être vraies simultanément:

• le jour est jeudi;
• l’heure est au moins 17;
• l’heure est au plus 19.

La condition complète peut être écrite ainsi:

si (jour = jeudi) et ((heure >= 17) et (heure <= 19)) alors

Le programme met alors gratuitJeudi à oui.

Dans le cas contraire:

• mettre gratuitJeudi à non;
• conserver la valeur saisie dans tarifEntree.

Erreurs fréquentes

Tester seulement le jour

Condition incorrecte:

si jour = jeudi alors entrée gratuite

Cette condition accorde la gratuité toute la journée. Elle est fausse.

Tester seulement l’heure

Condition incorrecte:

si heure >= 17 alors entrée gratuite

Cette condition accorde la gratuité tous les jours à partir de 17 h. Elle est fausse.

Utiliser ou au lieu de et

Condition incorrecte:

si jour = jeudi ou heure >= 17 ou heure <= 19

Cette condition sera vraie dans un grand nombre de cas. Elle ne décrit pas la règle.

La règle exige une intersection. Il faut donc utiliser et.

Oublier le billet

Condition incomplète:

si gratuitJeudi = oui alors accès autorisé

La gratuité ne supprime pas l’obligation de disposer d’un billet à heure déterminée. Le billet est testé séparément.

Pseudo-structure Scratch

La structure logique peut être organisée ainsi:

1. Si le billet n’est pas réservé, refuser.

2. Sinon, tester le nombre de visiteurs.

3. Sinon, tester la demande de visite guidée.

4. Calculer la gratuité.

5. Calculer le montant.

6. Afficher la décision.

Les blocs si... alors... sinon doivent suivre cet ordre. Une condition générale ne doit pas masquer une condition plus précise.

6. Contrôler le nombre de visiteurs

Une visite guidée peut accueillir un groupe allant jusqu’à quinze personnes. Cette donnée doit être traduite par une comparaison:

nombreVisiteurs <= 15

Si le groupe dépasse cette limite et demande une visite guidée, le programme refuse cette option. Il ne doit pas nécessairement refuser toute la visite au musée.

Cette distinction est importante:

• l’accès au musée peut rester possible;
• la visite guidée peut être refusée ou nécessiter une autre organisation.

Un programme bien structuré ne mélange pas les deux décisions. Il utilise une variable spécifique:

• guideAutorise;
• ou visiteGuideePossible.

Traitement recommandé

1. Si nombreVisiteurs <= 0, refuser la saisie.

2. Si nombreVisiteurs > 15 et visiteGuidee = oui, afficher un avertissement.

3. Proposer de poursuivre sans visite guidée ou de modifier le nombre.

4. Si nombreVisiteurs <= 15, accepter la demande guidée.

5. Calculer ensuite le montant correspondant.

Le premier test élimine une valeur impossible. Un groupe de zéro personne ne constitue pas une visite. Une valeur négative est également invalide.

Dans Scratch, on peut répéter la question tant que la saisie n’est pas correcte:

• répéter jusqu’à nombreVisiteurs > 0;
• demander le nombre de visiteurs;
• mettre nombreVisiteurs à réponse;
• si la valeur est incorrecte, afficher un message.

Cette boucle est une itération. Elle exécute la même instruction jusqu’à ce qu’une condition soit satisfaite.

Deux stratégies pour un groupe trop important

La division automatique en sous-groupes demande une variable supplémentaire. Il faut calculer le nombre de groupes:

plafond(nombreVisiteurs / 15)

Scratch ne possède pas nécessairement un bloc nommé plafond dans la configuration de base. Il faut donc éviter cette extension dans un premier projet, ou construire une boucle qui compte les groupes. La solution simple consiste à refuser la visite guidée pour un groupe dépassant la limite.

7. Simuler l’arrivée depuis la station Pimisi

Le trajet depuis la station Pimisi peut être intégré comme une information logistique. La station se trouve à environ sept minutes de marche du musée. Cette donnée ne modifie ni le tarif ni la validité du billet.

Il faut donc la traiter comme une sortie informative, pas comme une condition d’accès.

Le programme peut afficher:

• Accès par OC Transpo: descendre à la station Pimisi.
• Temps de marche indicatif: environ sept minutes.
• Adresse: 1, place Vimy, Ottawa.

Ne pas écrire:

si trajet = sept minutes alors accès autorisé

Ce serait une erreur de modélisation. Le temps de marche décrit le déplacement. Il ne valide pas une réservation.

Ajouter une variable de transport

Pour enrichir le projet, créer une variable transport. Le programme demande:

Comment arrivez-vous? voiture ou transport en commun

Si la réponse est transport en commun, il affiche l’information sur Pimisi. Si la réponse est voiture, il affiche l’adresse et poursuit sans calcul de trajet.

Cette extension introduit une sélection:

• si le transport est transport en commun, alors afficher Pimisi;
• sinon, afficher l’adresse;
• dans les deux cas, poursuivre la vérification du billet.

La structure est simple. La contrainte de transport ne doit pas être confondue avec les contraintes tarifaires.

8. Organiser le programme en blocs personnalisés

Un seul script très long devient difficile à corriger. Scratch permet de créer des blocs personnalisés. Il est préférable de séparer les fonctions.

Créer les blocs suivants:

• saisir les données;
• vérifier le billet;
• calculer la gratuité;
• vérifier le groupe;
• calculer le montant;
• afficher le résultat.

Chaque bloc réalise une tâche unique. Cette séparation suit le principe de modularité.

Bloc « saisir les données »

Ce bloc:

1. demande le jour;

2. demande l’heure;

3. demande le nombre de visiteurs;

4. demande la réservation;

5. demande la visite guidée;

6. demande éventuellement le moyen de transport.

Il ne calcule rien. Il collecte seulement les valeurs.

Bloc « calculer la gratuité »

Ce bloc applique la condition:

jour = jeudi ET 17 <= heure ET heure <= 19

Il donne à gratuitJeudi la valeur oui ou non.

Bloc « calculer le montant »

Ce bloc utilise les variables déjà vérifiées. Il ne doit pas redemander les informations. Sinon, le programme possède plusieurs versions possibles de la même donnée.

Une variable doit avoir une source claire et un moment de modification identifiable.

Bloc « afficher le résultat »

Ce bloc présente:

• la décision d’accès;
• le statut de la gratuité;
• le montant simulé;
• la compatibilité de la visite guidée;
• l’information de transport.

L’affichage doit être séquentiel. Une seule bulle contenant toutes les informations devient difficile à lire.

9. Gérer les valeurs tarifaires sans figer le projet

Le montant affiché par le projet Scratch est un montant de simulation. Les conditions commerciales peuvent évoluer. Il ne faut donc pas inscrire un prix présenté comme permanent dans le code ou dans l’explication.

Deux méthodes sont correctes.

Méthode 1: saisir les tarifs au lancement

Le programme demande:

1. Quel tarif d’entrée utilisez-vous pour la simulation?

2. Quel tarif de visite guidée utilisez-vous?

Cette méthode rend le projet adaptable. Elle est adaptée à un exercice sur les variables et les entrées utilisateur.

Méthode 2: utiliser des variables modifiables

Le créateur du projet place les valeurs dans les variables tarifEntree et tarifGuide. Il peut les modifier avant chaque démonstration.

Cette méthode réduit le nombre de questions. Elle est adaptée à une présentation en classe.

Dans les deux cas, il faut conserver les opérations:

• multiplication par le nombre de visiteurs;
• ajout éventuel du tarif guidé;
• remplacement du tarif d’entrée par zéro pendant la période gratuite.

Le programme doit aussi empêcher les valeurs négatives. Un tarif négatif ne correspond pas au modèle étudié.

10. Tester le projet avec des cas limites

Un algorithme n’est pas terminé quand il s’exécute sans message d’erreur. Il doit produire le bon résultat dans plusieurs situations.

Tester au minimum les cas suivants:

1. Jeudi à 18 h, billet réservé, groupe de dix personnes, sans visite guidée.

2. Jeudi à 16 h, billet réservé, groupe de dix personnes.

3. Jeudi à 19 h, billet réservé, groupe de quinze personnes avec visite guidée.

4. Jeudi à 20 h, billet réservé, groupe de quinze personnes avec visite guidée.

5. Autre jour à 18 h, billet réservé.

6. Jeudi à 18 h, aucun billet réservé.

7. Groupe de seize personnes avec visite guidée.

8. Groupe de zéro personne.

9. Heure négative ou supérieure à 24.

10. Réponse différente de oui ou non.

Les cas 2 et 4 vérifient les bornes horaires. Le cas 3 vérifie la limite maximale. Le cas 6 vérifie que la gratuité ne supprime pas le billet. Le cas 7 vérifie la contrainte de groupe. Les cas 8 à 10 vérifient la robustesse de la saisie.

Tableau de tests

Un test doit comparer le résultat réel au résultat attendu. Dire que le programme fonctionne parce qu’il affiche un message ne suffit pas.

11. Vérification rapide du raisonnement

Avant de considérer le projet comme terminé, exécuter ce contrôle:

• Le billet est-il testé avant le calcul?
• Le jour et l’heure sont-ils vérifiés ensemble?
• La condition utilise-t-elle et, et non ou?
• Les bornes 17 et 19 sont-elles traitées de manière cohérente?
• Le tarif d’entrée est-il séparé du tarif de visite guidée?
• La limite de quinze personnes concerne-t-elle uniquement la visite guidée?
• Une donnée de transport modifie-t-elle par erreur l’accès ou le tarif?
• Les variables sont-elles réinitialisées au début?
• Une réponse invalide provoque-t-elle une nouvelle saisie?
• Les prix utilisés dans la simulation peuvent-ils être modifiés?

Si une réponse est négative, le programme n’est pas encore stable.

Conclusion

La visite du Musée canadien de la guerre fournit un contexte concret pour travailler les variables, les opérateurs logiques, les priorités opératoires, les boucles et les tests imbriqués. Le sujet n’est pas de créer une réservation réelle. Il s’agit de modéliser des contraintes vérifiables:

• un billet à heure déterminée est requis;
• la gratuité dépend simultanément du jour et de l’horaire;
• une visite guidée est limitée à quinze personnes;
• le coût dépend du nombre de visiteurs et des options choisies;
• le trajet depuis Pimisi reste une information séparée du calcul.

Le programme correct suit donc une séquence stricte: saisir, valider, calculer, afficher, tester. Il ne suffit pas d’obtenir un résultat. Il faut pouvoir expliquer chaque résultat par une condition précise.

Photo: Balcer~commonswiki / CC BY 2.5 — Wikimedia Commons