Après la séquence et la boucle, la condition est le troisième pilier fondamental de l'algorithmique, et sans doute celui qui demande le plus d'entraînement pour être véritablement assimilé par des élèves de 5e. Le principe du « si… alors » paraît simple en apparence, presque évident lorsqu'il est formulé en langage courant, mais sa traduction en blocs Scratch, puis sa combinaison avec d'autres notions comme les variables ou les capteurs, révèle rapidement des subtilités qu'il convient de travailler méthodiquement. Cet article propose une série de dix exercices progressifs, du plus simple au plus complexe, accompagnés de leur logique de correction, pour consolider durablement cette compétence essentielle.
Comprendre la logique du « si… alors » avant de coder
Avant de plonger dans les blocs eux-mêmes, il est utile de rappeler la structure logique d'une condition : elle repose sur un test, qui ne peut avoir que deux résultats possibles, vrai ou faux, et sur une ou plusieurs actions qui ne se déclenchent que si ce test est vrai. Dans Scratch, deux blocs principaux permettent de traduire cette logique : le bloc « si… alors », qui exécute une action uniquement si la condition est vraie et ne fait rien dans le cas contraire, et le bloc « si… alors… sinon », qui propose une seconde action alternative lorsque la condition est fausse. Cette distinction entre les deux blocs constitue elle-même un point de vigilance pédagogique, car de nombreux élèves utilisent systématiquement deux blocs « si… alors » séparés là où un seul bloc « si… alors… sinon » suffirait et serait plus rigoureux.
Exercice 1 : lire un script simple et prédire son résultat
Le premier exercice, de type observation, présente un script déjà construit contenant un bloc « si touche le bord, alors tourner de 180 degrés » à l'intérieur d'une boucle « répéter indéfiniment ». La consigne demande de décrire, sans exécuter le programme, ce qui va se passer lorsque le lutin atteint le bord droit de la scène. La correction attendue précise que le personnage va rebondir en repartant dans la direction opposée, un comportement classique de balle rebondissante, et insiste sur le fait que rien ne se passe tant que le lutin ne touche pas réellement le bord, illustrant bien la nature conditionnelle de l'instruction.
Exercice 2 : compléter un script avec la bonne condition
Le deuxième exercice fournit un script incomplet, où le bloc de condition est vide, et demande de choisir parmi plusieurs capteurs proposés (touche le bord, touche la couleur, touche le pointeur de la souris) celui qui correspond à la situation décrite : « le lutin doit dire Bonjour lorsque le joueur clique dessus avec la souris ». La correction guide l'élève vers le bloc « touche le pointeur de la souris », combiné à un test sur l'état du bouton de la souris, ce qui introduit la notion de combinaison de plusieurs capteurs au sein d'une même condition.
Exercice 3 : traduire une phrase en langage courant en condition Scratch
Le troisième exercice propose une phrase du quotidien à traduire directement en bloc Scratch : « S'il fait nuit, alors j'allume la lumière ». L'élève doit identifier la variable ou le capteur correspondant à « il fait nuit », par exemple une variable numérique nommée luminosité, et construire la condition « si luminosité < 10, alors changer de costume ». Cet exercice de traduction, du langage naturel vers le langage formel de la condition, constitue un exercice clé pour développer l'autonomie des élèves face à des consignes de projet plus ouvertes.
Exercice 4 : utiliser le bloc « si… alors… sinon »
Le quatrième exercice introduit spécifiquement le bloc à deux branches, en demandant de programmer un lutin qui dit « Gagné ! » si une variable score est supérieure ou égale à 10, et qui dit « Perdu » dans le cas contraire. La correction met en avant l'économie de blocs permise par le « si… alors… sinon » comparé à l'utilisation de deux blocs « si… alors » séparés avec des conditions inverses, un point de rigueur souvent négligé par les élèves débutants.
Exercice 5 : combiner une condition avec une variable
Le cinquième exercice fait le lien avec les notions de variable vues en parallèle, en demandant de programmer une jauge de vie simple : chaque fois que le lutin touche un ennemi, la variable vies diminue de 1, et si la variable vies atteint zéro, le message « Game Over » s'affiche et le programme s'arrête. Cet exercice mobilise à la fois une condition de détection de contact et une condition numérique sur la valeur d'une variable, illustrant la richesse des combinaisons possibles à partir de ce seul bloc de base.
Exercice 6 : les opérateurs de comparaison
Le sixième exercice se concentre spécifiquement sur les trois opérateurs de comparaison disponibles dans Scratch : supérieur à, inférieur à, et égal à. La consigne demande de choisir le bon opérateur pour trois situations différentes : afficher un message si l'âge est supérieur à 12 ans, si le score est exactement égal à 100, ou si la température est inférieure à 0 degré. La correction insiste sur les erreurs fréquentes de confusion entre « supérieur à » et « supérieur ou égal à », une nuance que Scratch ne propose pas directement mais que l'on peut construire en combinant deux opérateurs avec un bloc logique « ou ».
Exercice 7 : combiner deux conditions avec « et » / « ou »
Le septième exercice introduit les opérateurs logiques « et » et « ou », qui permettent de combiner plusieurs conditions au sein d'un même test. La consigne demande de programmer une alarme qui se déclenche si la température est supérieure à 30 degrés ET si l'humidité est inférieure à 20%, en utilisant le bloc logique « et » pour combiner les deux capteurs simulés par des variables. La correction souligne la différence fondamentale entre « et », qui exige que les deux conditions soient vraies simultanément, et « ou », qui suffit qu'une seule des deux conditions soit vraie pour déclencher l'action.
Exercice 8 : imbriquer une condition dans une autre
Le huitième exercice, plus avancé, propose d'imbriquer un bloc « si… alors » à l'intérieur d'un autre, pour gérer trois cas de figure distincts plutôt que deux : si le score est supérieur à 20, afficher « Excellent », sinon si le score est supérieur à 10, afficher « Bien », sinon afficher « Peut mieux faire ». Cet exercice prépare progressivement les élèves à la structure des conditions imbriquées, une notion qui sera approfondie en classe de 4e, tout en restant accessible en fin de cycle en 5e avec un accompagnement adapté.
Exercice 9 : détecter une erreur dans un script existant
Le neuvième exercice, de type débogage, présente un script contenant une erreur volontaire : une condition mal formulée qui empêche le comportement attendu de se produire, par exemple un test « si score = 10 » alors que le score augmente par paliers de 5 et ne passera donc jamais exactement par la valeur 10 dans certains scénarios. L'élève doit identifier l'erreur et proposer une correction, généralement en remplaçant l'égalité stricte par une comparaison « supérieur ou égal à ». Ce type d'exercice développe une compétence essentielle et transférable : la capacité à analyser un programme qui ne fonctionne pas comme prévu.
Exercice 10 : projet de synthèse libre
Le dixième et dernier exercice propose une consigne ouverte, sans script de départ : programmer un petit quiz de trois questions, où chaque bonne réponse augmente une variable score de 10 points, et où un message final différent s'affiche selon que le score final est parfait, moyen, ou faible. Cet exercice de synthèse mobilise l'ensemble des compétences travaillées dans les neuf exercices précédents et permet une évaluation globale de la maîtrise des conditions par l'élève, dans un contexte de projet complet et motivant.
Conclusion
La maîtrise des conditions « si… alors » ne s'acquiert pas en une seule séance, mais par un entraînement progressif et varié, alternant lecture de code, complétion, traduction depuis le langage courant, et création libre. Cette série de dix exercices, organisée du plus simple au plus complexe, permet à chaque élève de 5e de construire pas à pas une compréhension solide de cette notion centrale de l'algorithmique, tout en la reliant naturellement aux boucles et aux variables déjà travaillées. Cette base, une fois consolidée, facilitera grandement l'abord de notions plus avancées comme les conditions imbriquées ou les capteurs physiques en classe de 4e et de 3e.
FAQ : questions fréquentes sur les conditions en Scratch
1. Quelle est la différence entre « si… alors » et « si… alors… sinon » ?
Le bloc « si… alors » ne déclenche une action que lorsque la condition est vraie et ne fait rien sinon, tandis que « si… alors… sinon » propose systématiquement une seconde action alternative lorsque la condition est fausse, ce qui évite d'avoir à écrire deux blocs séparés avec des conditions opposées.
2. Comment savoir quel capteur utiliser dans une condition ?
Il faut identifier précisément ce que l'on souhaite tester : un contact physique entre deux éléments utilise « touche… », une valeur numérique utilise un opérateur de comparaison, et un événement clavier ou souris utilise les blocs capteurs correspondants dans la catégorie bleu clair.
3. Pourquoi ma condition sur l'égalité d'un score ne se déclenche jamais ?
C'est une erreur classique lorsque le score évolue par paliers qui peuvent sauter la valeur testée. Il est généralement plus sûr d'utiliser une comparaison « supérieur ou égal à » plutôt qu'une égalité stricte pour ce type de test.
4. À quel âge ou niveau peut-on aborder les conditions imbriquées ?
Une introduction en fin de 5e, avec un accompagnement guidé comme dans l'exercice 8, est tout à fait envisageable, mais une maîtrise complète et autonome de cette notion est généralement attendue plutôt en classe de 4e.
5. Quelle est la différence entre les opérateurs logiques « et » et « ou » ?
L'opérateur « et » exige que toutes les conditions combinées soient vraies simultanément pour que l'action se déclenche, tandis que l'opérateur « ou » suffit qu'une seule des conditions soit vraie, ce qui rend le déclenchement de l'action plus fréquent.
6. Comment vérifier que mon enfant maîtrise vraiment cette notion et ne se contente pas de recopier une solution ?
Le meilleur test est de lui proposer une situation nouvelle en langage courant, comme dans l'exercice 3, et de vérifier qu'il parvient à la traduire seul en condition Scratch, sans modèle préexistant à recopier.
0 commentaire