Les Sciences - programme de cinquième
Physique-chimie, sciences de la vie et de la Terre, technologie
Leçon 18 - Programmer par blocs avec Scratch
Comment un objet technique reçoit ses ordres
Programmer par blocs avec Scratch
Comment un objet technique reçoit ses ordres
Technologie · classe de cinquièmeUn fil rouge traverse ces sept chapitres : un carrefour muni d’un feu tricolore et d’un bouton d’appel pour les piétons. À chaque chapitre, ce carrefour gagne ce qui lui manquait encore, jusqu’à devenir un système complet que vous pourrez faire tourner sur un écran.
Le chemin que nous allons suivre
- De l’algorithme au programme · pourquoi des blocs plutôt que du texte
- La scène, les lutins, les scripts · où le programme s’exécute
- Répéter · les boucles, et le premier cycle du feu
- L’événement · ce qui déclenche un programme
- Le parallélisme et les messages · deux feux qui s’entendent
- Variables, conditions, capteurs · le programme qui se souvient et qui choisit
- La chaîne d’information · du bouton pressé à la lampe allumée
Vous avez déjà rencontré des objets techniques qui décident tout seuls. Le portail qui s’ouvre quand une voiture approche, la machine à laver qui enchaîne ses cycles, le distributeur qui rend la monnaie : chacun contient un programme. Ce cours explique comment un tel programme s’écrit, et pourquoi il ressemble si peu à une recette de cuisine.
Nous emploierons Scratch, un environnement où les instructions ne s’écrivent pas au clavier mais s’assemblent comme des pièces. Ce choix n’est pas un jeu déguisé : il permet de voir directement des idées que le texte cache, notamment le fait qu’un programme puisse posséder plusieurs points de départ et plusieurs actions menées de front.
🧩 De l’algorithme au programme
Pourquoi assembler des pièces, plutôt qu’écrire des phrases ?
Demandez à un camarade de vous préparer un chocolat chaud. Il saura faire, parce qu’il complétera de lui-même ce que vous avez omis : prendre une casserole, ne pas verser le lait à côté, éteindre le feu à la fin. Une machine, elle, ne complète rien. Elle exécute ce qui lui est demandé, dans l’ordre où cela lui est demandé, et rien de plus. Toute la difficulté de la programmation tient dans cet écart.
Avant d’écrire le moindre programme, il faut donc énoncer la suite d’actions de façon si précise que toute interprétation devienne impossible. Cette suite porte un nom.
Un algorithme est une suite finie d’instructions non ambiguës qui, exécutées dans l’ordre indiqué, permettent de traiter un problème donné. Il ne dépend ni d’une machine ni d’une langue : le même algorithme peut se dire en français, se dessiner sous forme de schéma, puis se traduire en Scratch, en Python ou dans le langage d’un automate industriel.
Le mot lui-même vient de loin, et son histoire dit quelque chose de la discipline.
Au IXe siècle apr. J.-C., Bagdad abrite la Maison de la Sagesse, un lieu où des savants traduisent, comparent et prolongent les textes grecs, indiens et perses. Le calife al-Ma’moun, qui règne de 813 à 833 apr. J.-C., lui donne son élan décisif ; l’institution avait été fondée quelques années plus tôt par son père.
Parmi ces savants travaille Muhammad ibn Musa al-Khwârizmî, né dans les années 780 apr. J.-C. dans la région du Khwarezm, en Asie centrale, et mort vers 850 apr. J.-C. à Bagdad. Il ne se contente pas de traiter les problèmes un à un : il décrit des méthodes générales permettant de les résoudre tous, étape après étape, sans avoir à réfléchir de nouveau à chaque fois.
Lorsque ses ouvrages sont traduits en latin, à partir du XIIe siècle, son nom devient Algoritmi. De cette déformation naît le mot algorithme. Le titre d’un autre de ses livres a donné, par un chemin voisin, le mot algèbre. Un savant du Moyen Âge se cache ainsi dans deux mots que vous employez en classe.
Une même méthode, trois formes successives
Entre l’idée et la machine, le travail passe par trois états, et les confondre coûte cher. La première forme se rédige en français : elle sert à réfléchir. La deuxième se dessine : elle sert à vérifier que rien ne manque. La troisième s’écrit dans un langage : elle sert à faire marcher la machine.
| Forme | Ce qu’elle est | Ce qu’elle apporte |
|---|---|---|
| L’algorithme | La suite des actions, énoncée en langue courante | Il oblige à décider de tout, y compris de ce que la machine fera si rien ne se passe |
| L’algorigramme | Le même contenu, dessiné avec des symboles normalisés | Il rend les chemins visibles, notamment les retours en arrière et les cas oubliés |
| Le programme | La traduction dans un langage que la machine comprend | Il s’exécute, donc il se teste et se corrige |
Ce que la forme d’un bloc interdit
Un langage écrit au clavier possède une grammaire, et cette grammaire se venge. Une parenthèse manquante, un deux-points oublié, un mot mal orthographié : la machine refuse de démarrer et affiche un message que le débutant ne comprend pas encore. Le temps passé à traquer ces fautes n’apprend rien sur le raisonnement.
Scratch supprime cette catégorie d’erreurs par un moyen matériel plutôt que par un avertissement. Chaque instruction est une pièce dont la forme dit où elle a le droit d’aller. Une pièce au sommet bombé refuse tout voisin au-dessus d’elle. Une pièce pointue n’entre que dans un trou pointu. La règle n’est plus écrite dans un manuel : elle est dans la géométrie.
Observez la conséquence la plus importante : une pile de blocs, que l’on nomme un script, ne démarre que si elle commence par un bloc de tête. Cette contrainte, qui semble une gêne, énonce en réalité une vérité de tout programme. Une suite d’instructions ne s’exécute pas d’elle-même ; il faut quelque chose qui la déclenche. Le chapitre 4 y reviendra longuement.
Le nom Scratch vient du vocabulaire des disc-jockeys. Le scratching consiste à faire tourner un disque à la main pour réutiliser un morceau existant et en tirer autre chose. L’équipe du Massachusetts Institute of Technology a choisi ce mot parce qu’elle souhaitait une plateforme où chacun puisse reprendre le projet d’un autre, le modifier et le republier. En informatique, réemployer du code écrit ailleurs est une pratique ordinaire, et le nom du logiciel la revendique.
Une consigne peut être fausse sans être mal écrite
Prenez une feuille et écrivez la marche à suivre pour dessiner un carré, sans dire le mot « carré ». Confiez-la ensuite à quelqu’un qui applique vos phrases à la lettre, sans rien deviner.
Presque tous les élèves écrivent « tracer un trait, tourner, recommencer quatre fois ». Le lecteur strict demandera aussitôt : tourner de combien ? Dans quel sens ? Recommencer à partir d’où ? Le chapitre 3 donnera la réponse chiffrée. Retenez pour l’instant le mécanisme : une consigne peut être très lisible et rester inexécutable, parce qu’elle laisse une décision à la charge du lecteur.
L’erreur de syntaxe empêche le programme de démarrer. Elle vient d’une règle d’écriture violée. Les blocs de Scratch la rendent presque impossible, ce qui explique la réputation de facilité du logiciel.
L’erreur de logique laisse le programme démarrer, et le résultat obtenu diffère du résultat attendu. Elle vient d’un raisonnement fautif. Scratch ne protège de rien à cet égard, et c’est heureux : la programmation commence précisément là.
- Un algorithme est une suite finie d’instructions non ambiguës, indépendante de toute machine et de toute langue.
- Le mot vient du nom latinisé d’al-Khwârizmî, savant de la Maison de la Sagesse de Bagdad au IXe siècle apr. J.-C.
- Le travail passe par trois formes successives : l’algorithme rédigé, l’algorigramme dessiné, le programme exécutable.
- Scratch possède six formes de blocs, et la forme de chacun indique la place qu’il a le droit d’occuper.
- Un script ne s’exécute que s’il commence par un bloc de tête : un programme a besoin d’être déclenché.
- Les blocs suppriment les erreurs de syntaxe, non les erreurs de logique.
Notre carrefour n’existe pour l’instant que sous forme de phrases : le feu passe au vert, puis à l’orange, puis au rouge, et il recommence. Avant de programmer quoi que ce soit, il faut savoir où ce feu sera posé, et comment la machine désigne un objet placé sur un écran. C’est l’affaire du chapitre suivant.
🎬 La scène, les lutins, les scripts
Où le programme s’exécute-t-il, et sur quoi agit-il ?
Un programme ne flotte pas dans le vide. Il agit sur un monde, et ce monde doit être décrit avant que la première instruction ne soit écrite. Dans Scratch, ce monde tient en quatre notions dont il faut se saisir sans tarder, parce que tout le reste s’appuie sur elles.
- La scène est le rectangle où se déroule l’action. Elle possède un arrière-plan et des coordonnées.
- Un lutin est un objet posé sur la scène. Il possède une position, une direction, une taille, et il peut être visible ou caché.
- Un costume est l’une des apparences possibles d’un lutin. Changer de costume ne déplace pas le lutin : cela change seulement ce qui se voit.
- Un script est une pile de blocs attachée à un lutin. Un même lutin peut porter plusieurs scripts, et chaque lutin possède les siens.
Cette dernière phrase mérite un arrêt, car elle contient une idée que les langages écrits au clavier montrent beaucoup plus tard. Le programme n’est pas une liste unique posée quelque part : il est réparti entre les objets. Le feu véhicules porte ses propres instructions ; le bouton porte les siennes. Chacun sait ce qu’il a à faire, et chacun garde ses propres valeurs.
Se repérer sur la scène
Elle mesure 480 pas de large et 360 pas de haut. Ces nombres ne sont pas choisis au hasard : ils correspondent aux dimensions historiques de la fenêtre d’affichage du logiciel. L’origine du repère se trouve au centre, non dans un coin, ce qui distingue Scratch de la plupart des systèmes graphiques.
Deux conséquences pratiques découlent de ce repère. La première : un lutin placé en x égal à zéro et y égal à zéro se trouve au milieu de l’écran, et non en haut à gauche. La seconde : la direction de départ de tout nouveau lutin vaut 90, c’est-à-dire vers la droite. Un lutin à qui l’on demande d’avancer sans autre précision partira donc vers la droite.
Ouvrez un projet vide et placez un lutin en haut à gauche de la scène, à mi-hauteur entre le centre et le bord. Quelles coordonnées faut-il écrire ?
Le bord gauche vaut -240, le centre vaut 0 : la moitié donne -120. Le bord haut vaut 180 : la moitié donne 90. Le lutin doit donc recevoir x égal à -120 et y égal à 90. Vérifiez en déplaçant le lutin à la souris : les deux nombres affichés sous la scène changent en direct.
Ce que Scratch doit à un langage de 1967
En 1967, trois chercheurs de la société Bolt, Beranek and Newman, près de Boston, mettent au point un langage destiné aux enfants : Logo. Ils se nomment Wally Feurzeig, Seymour Papert et Cynthia Solomon. Le nom du langage ne forme pas un sigle ; il vient du grec logos, qui signifie le mot ou la pensée.
Au tournant des années 1970 apparaît l’idée qui rendra Logo célèbre : une tortue que l’enfant commande par des ordres simples, avancer et tourner, et qui laisse une trace derrière elle. Il existe une tortue affichée à l’écran, et aussi un petit robot qui roule sur le sol.
Papert défendait une raison précise à ce choix. Un enfant qui cherche comment faire tourner la tortue peut se lever et faire lui-même le tour de la figure : son propre corps lui donne la réponse. La géométrie cesse d’être une affaire de formules pour devenir une affaire de déplacements que l’élève a déjà éprouvés.
Trente ans plus tard, Papert dirige au Massachusetts Institute of Technology la thèse d’un étudiant nommé Mitchel Resnick. C’est ce même Resnick qui fondera le groupe Lifelong Kindergarten, d’où sortira Scratch, lancé publiquement le 14 mai 2007. La filiation est directe : le lutin de Scratch est l’héritier de la tortue de Logo.
Le mot employé pour désigner un objet de la scène a changé. Scratch 2 affichait « lutin », traduction du terme anglais sprite ; Scratch 3 affiche « sprite ». Les manuels français continuent d’employer « lutin », et ce cours fait de même. Si votre écran indique « sprite », il s’agit du même objet. Ce genre de flottement de vocabulaire est fréquent en informatique, et il vaut mieux le savoir que le découvrir en pleine séance.
Chaque lutin garde son propre état
Un lutin possède à tout instant une position, une direction, un costume affiché, une taille. L’ensemble de ces valeurs forme son état. Deux lutins identiques posés côte à côte peuvent avoir des états différents, et c’est ce qui permet à un feu d’être au rouge pendant que l’autre est au vert.
| Ce que le lutin possède | Exemple sur le carrefour | Bloc qui le modifie |
|---|---|---|
| Sa position | Le feu véhicules est au bord gauche de la chaussée | aller à x : ... y : ... |
| Sa direction | Le feu regarde vers la droite | s’orienter à ... degrés |
| Son costume | Vert, orange ou rouge | basculer sur le costume ... |
| Sa visibilité | Le bouton disparaît quand il devient inutile | montrer et cacher |
Quand un projet s’arrête, les lutins conservent la position, la direction et le costume qu’ils avaient au dernier instant. Au lancement suivant, ils repartent de là.
D’où une habitude à prendre dès maintenant : commencer chaque script par les blocs qui remettent le lutin dans son état de départ. Sans cette précaution, un projet fonctionne une fois, puis se comporte étrangement.
- La scène mesure 480 pas sur 360, et son origine se trouve au centre.
- L’abscisse va de -240 à 240, l’ordonnée de -180 à 180.
- La direction se compte en degrés dans le sens des aiguilles d’une montre ; 90 correspond à la droite et constitue la valeur de départ.
- Un lutin possède un état : position, direction, costume, taille, visibilité.
- Chaque lutin porte ses propres scripts ; le programme est réparti entre les objets.
- Changer de costume modifie l’apparence sans déplacer le lutin.
- L’état survit à l’arrêt du projet, d’où la nécessité de le réinitialiser au lancement.
Le feu est posé, ses trois costumes sont dessinés. Reste à les faire se succéder, puis recommencer sans fin. Cette répétition est le premier outil véritable du programmeur, et le chapitre suivant lui est consacré.
🔁 Répéter
Comment demander cent fois la même chose sans l’écrire cent fois ?
Un feu tricolore passe au vert, puis à l’orange, puis au rouge, et recommence. Si le programmeur devait écrire chaque passage, un feu qui fonctionne une journée entière demanderait plusieurs milliers de blocs. La solution tient en une idée que tous les langages possèdent, sous des noms voisins.
Une boucle est une structure qui fait exécuter plusieurs fois un même groupe d’instructions. Le groupe répété s’appelle le corps de la boucle. Ce qui distingue les boucles entre elles est la manière dont elles décident de s’arrêter : après un nombre annoncé de tours, à l’arrêt du projet, ou lorsqu’une condition devient vraie.
| Le bloc | Quand il s’arrête | Emploi typique |
|---|---|---|
| répéter ( ) fois | Après le nombre de tours indiqué | Tracer une figure à quatre côtés, faire clignoter trois fois une lampe |
| répéter indéfiniment | À l’arrêt du projet | Un système qui reste en service tant qu’il est alimenté : un feu, une horloge |
| répéter jusqu’à ce que < > | Lorsque la condition devient vraie | Avancer tant que le bord n’est pas atteint, attendre une réponse |
Le nombre qui commande toutes les figures régulières
Reprenons la question laissée en suspens au chapitre 1 : de combien faut-il tourner pour tracer un carré ? La réponse tient à une remarque simple. Un lutin qui parcourt le contour d’une figure et revient à son point de départ, orienté comme au début, a effectué un tour complet, soit 360 degrés. Si la figure possède n côtés égaux, ce tour se répartit en n rotations identiques.
La rotation à effectuer à chaque sommet vaut donc 360 divisé par n. Pour le carré, cela donne 90 degrés ; pour le triangle équilatéral, 120 degrés ; pour l’hexagone, 60 degrés. Ces valeurs se vérifient par le calcul comme par le tracé.
Une erreur fréquente consiste à écrire 60 degrés pour le triangle équilatéral, parce que ses angles mesurent 60 degrés. Le tracé obtenu est alors une étoile inattendue.
Le bloc tourner de ... degrés fait pivoter le lutin par rapport à sa direction courante. Il attend l’angle dont la direction change, non l’angle dessiné sur la feuille.
Levez-vous et marchez le long d’un carré imaginaire, en comptant vos pivots. À chaque coin, votre corps tourne d’un quart de tour, soit 90 degrés. Après quatre coins, vous regardez de nouveau dans la direction de départ : quatre fois 90 font bien 360.
Recommencez avec un triangle. Le pivot est plus large : un tiers de tour, soit 120 degrés. Votre corps donne la réponse avant tout calcul, et c’est précisément le raisonnement que Seymour Papert cherchait à provoquer chez ses élèves.
Le premier cycle du carrefour
Le feu véhicules possède trois costumes. Les faire se succéder demande une alternance entre deux blocs : celui qui change l’apparence, et celui qui laisse le temps s’écouler. Sans le second, les trois costumes défileraient si vite que l’œil ne verrait qu’une couleur trouble.
Une précision réglementaire mérite d’être donnée, car elle montre que ces nombres ne sont pas décoratifs. En France, l’ordre des couleurs est fixé : vert, puis jaune fixe, puis rouge, puis vert de nouveau. La durée du jaune vaut trois secondes en agglomération et cinq secondes hors agglomération, cette dernière valeur étant obligatoire là où les véhicules roulent plus vite. La durée du rouge, elle, dépend du carrefour et du trafic.
En 1843, la mathématicienne britannique Augusta Ada King, comtesse de Lovelace, traduit en anglais un mémoire de l’ingénieur Luigi Menabrea consacré à la machine analytique de Charles Babbage. Elle y ajoute sept notes, désignées par les lettres A à G, dont le volume représente près de trois fois celui de l’article traduit.
La dernière, la note G, décrit pas à pas une méthode permettant de calculer les nombres de Bernoulli avec la machine. Elle est souvent considérée comme le premier véritable programme informatique publié, parce que les méthodes décrites jusque-là ne l’étaient pas dans une forme destinée à être exécutée par une machine. Elle comporte une répétition d’instructions commandée par une condition, notion absente des enchaînements purement séquentiels de Babbage et des métiers à tisser de Jacquard.
Deux réserves doivent accompagner ce récit. La machine analytique n’a pas vu le jour, de sorte que ce programme n’a pu être exécuté du vivant de son autrice. Par ailleurs, la part respective de Lovelace et de Babbage dans la rédaction de la note reste discutée par les historiens, les deux ayant travaillé en échange constant. Ce qui est établi, c’est que le choix de l’exemple et sa mise en forme lui reviennent.
Regardez attentivement le bas du bloc répéter indéfiniment : il ne possède pas de bosse. Rien ne peut donc se fixer en dessous. Cette absence n’est pas un oubli des concepteurs, mais une information : puisque cette boucle ne se termine pas d’elle-même, tout bloc placé à sa suite resterait hors d’atteinte. La forme du bloc empêche d’écrire une instruction inutile.
- Une boucle répète un groupe d’instructions appelé le corps de la boucle.
- Scratch propose trois boucles : un nombre annoncé de tours, une répétition sans fin, une répétition qui s’arrête sur condition.
- Pour un polygone régulier à n côtés, la rotation à programmer vaut 360 divisé par n.
- Cet angle est l’angle extérieur, celui dont pivote le lutin, non l’angle intérieur de la figure.
- Un changement de costume sans temps d’attente reste invisible : la durée fait partie du programme.
- La réglementation française fixe le jaune à trois secondes en agglomération et à cinq secondes hors agglomération.
- La note G d’Ada Lovelace, publiée en 1843, est tenue pour le premier programme publié comportant une répétition commandée par une condition.
Le feu tourne désormais tout seul. Mais qui a lancé le programme ? Et surtout : que se passerait-il si un piéton voulait intervenir ? Un programme qui ne fait qu’attendre son propre tour reste sourd au monde extérieur. Le chapitre suivant lui donne des oreilles.
🖱️ L’événement
Qu’est-ce qui décide du moment où un programme démarre ?
Les premiers ordinateurs ne se laissaient pas interrompre. Le travail se préparait sur des cartes perforées, se déposait auprès d’un opérateur, puis se traitait dans l’ordre d’arrivée. Le résultat revenait quelques heures plus tard, imprimé sur papier. L’utilisateur ne voyait la machine ni pendant le calcul, ni après. Poser une question en cours de route n’avait pas de sens.
La programmation que vous pratiquez repose sur le renversement de cette situation. Le programme ne se contente plus de dérouler sa liste : il attend qu’il se passe quelque chose et réagit.
Un événement est un fait extérieur au programme dont la survenue déclenche l’exécution d’un script. Un clic, l’appui sur une touche, la réception d’un message, le dépassement d’un seuil par un capteur : chacun est un événement. Programmer de cette manière s’appelle la programmation événementielle. Le programmeur n’y décrit plus quand les choses se produisent, mais ce qu’il convient de faire lorsqu’elles se produisent.
Un programme, plusieurs départs
Dans un langage écrit au clavier, un programme débute en général à un endroit unique et se termine à un autre. Scratch rend visible une organisation différente : un projet compte autant de départs qu’il porte de blocs de tête, et ces départs n’ont pas de rang entre eux.
Sur le carrefour, cela se traduit ainsi. Un script démarre au lancement du projet et fait tourner le feu. Un autre script, attaché au bouton, ne s’exécute que si quelqu’un clique dessus. Le second peut rester muet toute la journée ; il n’en reste pas moins présent, prêt à répondre. Un système technique passe d’ailleurs l’essentiel de son temps à attendre.
| Bloc de tête | Ce qui le déclenche | Sur le carrefour |
|---|---|---|
| quand le drapeau vert est cliqué | Le lancement du projet | Mise en service du carrefour |
| quand la touche ( ) est pressée | Une frappe au clavier | Une commande de secours pour les essais |
| quand ce sprite est cliqué | Un clic sur ce lutin | Le piéton appuie sur le bouton |
| quand je reçois ( ) | Un message diffusé par un script | Le feu piétons apprend que son tour arrive |
Le 9 décembre 1968, à San Francisco, l’ingénieur Douglas Engelbart monte sur scène devant environ mille professionnels réunis pour la Fall Joint Computer Conference. Il s’assied derrière une console et, pendant une heure et demie, se sert d’un ordinateur situé à une cinquantaine de kilomètres de là, dans les locaux du Stanford Research Institute.
L’assistance découvre en fonctionnement des dispositifs dont la plupart n’avaient été ni vus ni imaginés : la souris, le texte que l’on modifie à l’écran et qui se réorganise aussitôt, les liens qui mènent d’un passage à un autre, plusieurs personnes travaillant sur le même document, et même la visioconférence, le visage d’un collègue apparaissant dans un coin de l’image.
La démonstration a reçu bien plus tard le surnom de Mother of All Demos, que l’on peut traduire par « la mère de toutes les démonstrations ». Son intérêt pour nous tient à un point précis : Engelbart ne soumettait plus un travail à la machine, il agissait sur elle et elle répondait dans l’instant. Chaque geste devenait un événement, et le programme avait pour tâche d’y répondre. Le bloc de tête que vous posez au sommet d’un script descend en droite ligne de cette manière de concevoir la machine.
Le drapeau vert ne possède pas de pouvoir particulier. Il produit un événement comme les autres, et rien n’oblige un projet à en contenir un. Un projet dont tous les scripts commencent par quand ce sprite est cliqué fonctionne très bien : il attend simplement que le visiteur fasse le premier geste. Le drapeau est devenu une habitude, non une règle.
Ajoutez un lutin en forme de bouton et posez sur lui un unique script : quand ce sprite est cliqué, suivi de dire « appel enregistré » pendant 1 secondes.
Lancez le projet, puis cliquez sur le bouton. Recommencez sans cliquer sur le drapeau vert : le bouton répond quand même. Voilà qui montre que chaque bloc de tête vit sa propre vie, et que le projet ne se réduit pas à un script principal entouré d’accessoires.
Rien n’interdit de poser deux blocs de tête identiques sur un même lutin. Les deux scripts partiront ensemble à chaque survenue de l’événement.
Le résultat devient imprévisible lorsque ces scripts agissent sur la même chose, par exemple si l’un demande le costume vert pendant que l’autre demande le rouge. Un état, une seule autorité : c’est une règle d’hygiène à respecter dès les premiers projets.
- Un événement est un fait extérieur dont la survenue déclenche un script.
- La programmation événementielle décrit ce qu’il faut faire lorsqu’un fait se produit, plutôt que l’ordre dans lequel tout arrive.
- Un projet possède autant de points de départ que de blocs de tête, sans hiérarchie entre eux.
- Un script peut rester inactif toute une séance sans que cela constitue une anomalie.
- Le drapeau vert produit un événement ordinaire, et un projet peut s’en passer.
- La démonstration de Douglas Engelbart, le 9 décembre 1968, a montré publiquement une machine qui répond aux gestes de son utilisateur.
- Deux scripts déclenchés par le même événement et agissant sur la même valeur produisent un résultat imprévisible.
Le bouton réagit, le feu tourne. Ces deux comportements s’ignorent encore. Pour que le carrefour devienne cohérent, les lutins doivent agir ensemble et se prévenir mutuellement. Le chapitre suivant traite de ces deux capacités.
🔀 Le parallélisme et les messages
Comment plusieurs scripts peuvent-ils agir de front sans se contredire ?
Un carrefour comporte au minimum deux feux, et ces deux feux doivent fonctionner ensemble. Si le feu piétons attendait que le feu véhicules ait terminé son cycle pour commencer le sien, les piétons traverseraient au moment où les voitures démarrent. Il faut donc que les deux comportements se déroulent en même temps, et qu’ils s’accordent.
Deux scripts s’exécutent simultanément lorsque leurs instructions progressent ensemble, sans que l’un attende la fin de l’autre. Scratch lance en simultané tous les scripts dont le bloc de tête correspond à l’événement survenu.
Un message est un signal nommé qu’un script diffuse à l’ensemble du projet, et que capte au même instant tout bloc quand je reçois portant ce nom. Le message ne transporte pas de valeur : il annonce qu’un fait a eu lieu.
Une durée change au passage à cette deuxième version : le rouge des véhicules s’allonge de six à douze secondes, afin de couvrir les neuf secondes de traversée et de laisser une marge de sécurité de part et d’autre.
Pourquoi la diffusion vaut mieux que le comptage
Une solution paraît d’abord plus simple : donner à chaque feu son propre chronomètre et régler les durées pour que tout tombe juste. Cette méthode fonctionne quelques minutes, puis se dérègle. Les deux scripts ne partent pas au même millième de seconde, et le moindre ralentissement de la machine creuse un écart qui grandit à chaque tour.
La diffusion supprime le problème à la racine. Le feu piétons ne compte plus : il attend un signal. Quelle que soit la durée réelle du cycle véhicules, le passage au vert des piétons survient au bon moment, parce qu’il est commandé par un fait et non par une horloge. C’est le principe retenu dans les installations réelles, où un organe central commande l’ensemble des feux d’un carrefour.
envoyer à tous ( ) lance le message et poursuit aussitôt : le script émetteur continue sa route sans se soucier des destinataires.
envoyer à tous ( ) et attendre lance le message puis s’interrompt, et ne reprend que lorsque tous les scripts déclenchés se sont achevés. Le premier convient à un carrefour ; le second sert lorsqu’une étape doit être terminée avant la suivante.
Une simultanéité qui mérite d’être regardée de près
Le mot « simultané » demande une précision, de celles qui distinguent un élève qui comprend d’un élève qui récite. Scratch rafraîchit la scène trente fois par seconde. À chaque rafraîchissement, il fait progresser un peu chacun des scripts actifs, puis redessine l’image. Les scripts ne s’exécutent donc pas au même instant : ils avancent chacun leur tour, si vite que l’œil ne distingue pas l’alternance.
Cette manière de faire n’a rien d’un artifice de logiciel éducatif. Elle est au contraire l’une des inventions majeures de l’informatique.
À la fin des années 1950, un ordinateur traite une tâche à la fois. Les chercheurs déposent leur travail et attendent parfois une journée entière un résultat qui, souvent, révèle une erreur d’écriture. Le temps de la machine est précieux ; celui des humains l’est moins, semble-t-il.
En 1959, John McCarthy, professeur au Massachusetts Institute of Technology, adresse à un collègue un mémorandum proposant une idée renversante : puisque la machine passe l’essentiel de son temps à attendre qu’un utilisateur tape une ligne, elle pourrait servir plusieurs personnes en alternant très rapidement entre elles.
En novembre 1961, Fernando Corbató, alors directeur adjoint du centre de calcul, présente avec Marjorie Daggett et Robert Daley un système bâti sur cette idée, le Compatible Time-Sharing System. Quatre personnes travaillent en même temps sur un unique ordinateur IBM 709, et chacune a le sentiment de disposer de la machine entière. Le service régulier ouvre à l’été 1963.
Rien de tout cela n’est réellement simultané : la machine découpe son temps en tranches minuscules et les distribue. Cette illusion, appelée temps partagé, gouverne encore l’ordinateur sur lequel vous travaillez, qui affiche plusieurs fenêtres actives alors qu’il exécute les instructions les unes après les autres.
La vitesse de trente images par seconde explique un comportement déroutant. Une boucle qui déplace un lutin d’un pas à chaque tour le fait avancer de trente pas par seconde, quelle que soit la puissance de l’ordinateur. Scratch attend le rafraîchissement de l’écran avant de repartir. Il existe une exception : un bloc personnalisé créé avec l’option « exécuter sans rafraîchissement d’écran » déroule son contenu d’un seul trait, ce qui accélère considérablement les calculs répétitifs.
Créez deux scripts sur deux lutins différents, chacun commençant par quand le drapeau vert est cliqué et contenant une boucle sans fin qui ajoute 1 à une variable propre au lutin, c’est-à-dire à une valeur mémorisée sous un nom, notion détaillée au chapitre suivant. Lancez le projet, attendez cinq secondes, arrêtez.
Les deux compteurs affichent des valeurs voisines, aux alentours de cent cinquante. La proximité des deux nombres montre le partage équitable du temps ; leur valeur proche de trente par seconde révèle le rythme du rafraîchissement. Une expérience de cinq secondes rend visible un mécanisme inventé il y a plus de soixante ans.
- Scratch lance ensemble tous les scripts dont le bloc de tête correspond à l’événement survenu.
- Un message est un signal nommé, diffusé à tout le projet, qui annonce un fait sans transporter de valeur.
- La diffusion synchronise mieux que le comptage, car elle repose sur un fait et non sur une durée supposée.
- Le bloc de diffusion simple poursuit son chemin ; la variante « et attendre » suspend le script émetteur.
- Scratch rafraîchit la scène trente fois par seconde et fait progresser chaque script un peu à chaque rafraîchissement.
- Cette simultanéité apparente porte un nom : le temps partagé, démontré au Massachusetts Institute of Technology en novembre 1961.
Les deux feux s’accordent désormais. Le carrefour reste pourtant aveugle : il déroule son cycle que la rue soit déserte ou pleine. Pour qu’il tienne compte du monde, il lui faut retenir une information et prendre une décision. Ce sont les deux sujets du chapitre suivant.
🎚️ Variables, conditions, capteurs
Comment un programme retient-il quelque chose, et comment choisit-il ?
Le carrefour construit jusqu’ici déroule son cycle sans se soucier de rien. Pour qu’il devienne utile, deux capacités lui manquent : retenir qu’un piéton a demandé à traverser, et agir différemment selon que cette demande existe ou non. La première s’appelle une variable, la seconde une condition.
Une variable est un emplacement de la mémoire, désigné par un nom, dans lequel le programme range une valeur qu’il pourra relire ou remplacer. Le nom reste fixe, la valeur change : c’est de là que vient le terme. Une variable nommée appel peut valoir 0 tant que rien n’a été demandé, puis 1 dès qu’un piéton a pressé le bouton.
Le mot mérite une mise en garde, car il est trompeur pour qui sort du cours de mathématiques. Dans une équation, le x désigne une valeur inconnue que le calcul finira par révéler, et cette valeur ne change pas en cours de route. En informatique, la variable est une boîte dont le contenu est remplacé aussi souvent que le programme le décide. Écrire que appel reçoit la valeur appel augmentée de 1 n’a rien d’absurde : cela signifie que la boîte reçoit son ancien contenu augmenté de un.
Une notion rendue visible : la portée
Au moment de créer une variable, Scratch pose une question dont l’importance dépasse largement le logiciel : cette variable doit-elle valoir « pour tous les lutins » ou « pour ce lutin uniquement » ? Ce choix définit la portée de la variable, c’est-à-dire la partie du programme qui a le droit de la lire et de la modifier.
| Choix à la création | Ce que cela entraîne | Sur le carrefour |
|---|---|---|
| Pour tous les lutins | Une seule boîte, partagée. Tout script du projet peut la lire et la modifier. | La variable appel : le bouton l’écrit, le feu la lit. |
| Pour ce lutin uniquement | Une boîte par lutin. Chaque copie vit sa vie sans se mêler des autres. | Un compteur de cycles propre à chaque feu, utile pour les essais. |
Choisir : la condition
Une condition est une affirmation dont la valeur est vraie ou fausse, sans autre possibilité. Dans Scratch, ces affirmations prennent la forme de blocs hexagonaux, et le bloc si ... alors les accueille dans son trou pointu. Lorsque l’affirmation est vraie, les instructions du ventre s’exécutent ; lorsqu’elle est fausse, le programme les saute et poursuit après le bloc.
Les affirmations disponibles proviennent de deux familles. Les opérateurs, de couleur verte, comparent des valeurs : plus grand que, plus petit que, égal à, ainsi que les combinaisons « et », « ou » et « non ». Les capteurs, de couleur bleue, interrogent l’état du monde.
| Capteur de Scratch | Ce qu’il détecte | Son équivalent réel |
|---|---|---|
| touche ( ) pressée ? | L’appui sur une touche | Un bouton-poussoir |
| ( ) touché ? | Le contact avec un lutin ou un bord | Un capteur de fin de course |
| couleur ( ) touchée ? | La présence d’une couleur sous le lutin | Un capteur optique de ligne |
| volume sonore | Le niveau capté par le microphone | Un sonomètre |
| chronomètre | Le temps écoulé depuis la remise à zéro | Une horloge interne |
Créez une variable nommée appel, valable pour tous les lutins. Sur le bouton, posez quand ce sprite est cliqué suivi de mettre appel à 1. Sur le feu véhicules, insérez au début du cycle un bloc attendre jusqu’à ce que appel = 1, et remettez appel à 0 juste après.
Cochez la case située à gauche du nom de la variable pour la faire apparaître sur la scène. Vous verrez la valeur basculer de 0 à 1 au moment du clic, puis revenir à 0 lorsque le feu en tient compte. Cet affichage vaut mieux qu’une longue explication : il rend la mémoire du programme visible.
À l’université Harvard fonctionne en 1947 un calculateur électromécanique, le Mark II, composé de milliers de relais dont les contacts se ferment et s’ouvrent au rythme des calculs. Le 9 septembre, la machine produit des résultats incohérents.
L’équipe entreprend une inspection matérielle, seule méthode disponible à l’époque. Elle finit par trouver la cause : un papillon de nuit coincé entre les contacts du relais numéro 70 du panneau F. L’insecte est retiré, fixé au ruban adhésif dans le journal de bord, avec cette mention manuscrite restée célèbre : premier cas avéré de bug découvert.
Deux précisions s’imposent, car cette anecdote circule souvent déformée. La formule elle-même indique que le mot bug était déjà employé par les ingénieurs pour désigner une panne : l’auteur souligne qu’il s’agit cette fois d’un véritable insecte. Par ailleurs, le musée qui conserve le carnet estime qu’il appartenait à un autre membre de l’équipe que Grace Hopper, laquelle était présente et a rendu l’épisode célèbre par ses conférences ultérieures.
Ce que l’histoire enseigne vaut au-delà du sourire qu’elle provoque : chercher une panne consiste à formuler une hypothèse, puis à l’éprouver, et à recommencer. Cette démarche porte encore le nom qu’elle a reçu ce jour-là, le débogage.
mettre appel à 1 range la valeur 1 dans la boîte. C’est un ordre, et il modifie la mémoire.
appel = 1 demande si la boîte contient 1. C’est une question, et la réponse vaut vrai ou faux. Les blocs ont des formes distinctes, ce qui interdit de les confondre ; en Python, ces deux opérations s’écrivent respectivement avec un signe égal et deux signes égaux, et leur confusion compte parmi les erreurs les plus fréquentes des débutants.
Scratch possède aussi des listes, c’est-à-dire des variables capables de contenir plusieurs valeurs rangées dans un ordre. Une liste peut recevoir jusqu’à deux cent mille éléments. Sur un carrefour, une liste permettrait par exemple d’enregistrer l’heure de chaque appel piéton, puis de calculer combien de demandes sont survenues dans la journée.
- Une variable est un emplacement nommé de la mémoire dont le contenu peut être remplacé.
- La variable informatique diffère de l’inconnue mathématique : sa valeur change en cours d’exécution.
- La portée détermine qui peut lire et modifier la variable : tous les lutins, ou un seul.
- Une condition est une affirmation dont la valeur vaut vrai ou faux, et rien d’autre.
- Les blocs booléens hexagonaux proviennent des opérateurs, qui comparent, et des capteurs, qui observent.
- Ranger une valeur et comparer deux valeurs sont deux opérations distinctes, que la forme des blocs sépare.
- Le débogage tient son nom d’un papillon retiré d’un relais du Harvard Mark II le 9 septembre 1947.
Le carrefour sait désormais attendre, retenir et choisir. Reste à comprendre ce que ces blocs représentent dans un objet réel : un bouton n’est pas un lutin cliquable, et une lampe de carrefour n’est pas un costume. Le dernier chapitre établit cette correspondance et assemble le système complet.
🚦 La chaîne d’information
Que devient un programme lorsqu’il commande un objet réel ?
Sur l’écran, un clic sur le bouton range la valeur 1 dans une variable, et le feu change de costume. Sur le trottoir, un doigt enfonce un contact, un courant parcourt un câble, un calculateur enfermé dans une armoire décide, et une lampe s’allume. Le raisonnement est identique ; les organes diffèrent. La technologie donne un nom à cette suite d’organes.
La chaîne d’information d’un objet technique désigne la succession des organes qui recueillent une information, la traitent, puis commandent une action. Elle comprend le capteur, qui transforme un fait physique en signal ; le traitement, assuré par un programme ; l’actionneur, qui produit un effet dans le monde réel ; et les interfaces, qui adaptent les signaux entre ces organes.
Sur un carrefour véritable, le bouton d’appel constitue le capteur, l’armoire de commande installée au bord du trottoir assure le traitement, et les lampes forment l’actionneur. Scratch remplace chacun de ces organes par un équivalent affiché : le clic tient lieu de capteur, les blocs tiennent lieu de calculateur, le costume tient lieu de lampe. Ce remplacement est une simulation, et il vaut mieux le savoir : un programme qui fonctionne à l’écran n’a pas encore prouvé qu’il fonctionnera sur la route.
Dessiner le raisonnement avant de le coder
Le cours consacré à la représentation des objets a montré que chaque schéma renonce à quelque chose pour mieux répondre à une question donnée, et qu’il se juge à celle-ci. Il existe une famille de schémas destinée aux programmes.
Un algorigramme, également appelé organigramme de programmation ou logigramme, est une représentation graphique normalisée de l’enchaînement des opérations et des décisions d’un programme. Les symboles employés sont définis par la norme internationale ISO 5807 et par la norme française NF Z 67-010.
Trois règles gouvernent ce dessin. Un algorigramme comporte un seul symbole de début. Le sens principal de lecture va du haut vers le bas. Les deux sorties d’un losange portent obligatoirement leurs étiquettes, « oui » et « non », faute de quoi le lecteur doit deviner, ce qui ruine l’intérêt du schéma.
Une remarque honnête s’impose au sujet de notre exemple. Un feu de carrefour ne s’arrête pas : le symbole de fin marque ici l’achèvement d’une traversée, non l’arrêt du système, lequel recommence aussitôt. Un algorigramme décrivant fidèlement le carrefour entier n’aurait pas de fin, ce que la norme n’encourage guère. Le dessin représente donc un fragment, et il faut le dire plutôt que le laisser croire.
Le carrefour complet
L’assemblage réunit ce que les chapitres précédents ont introduit. Le feu véhicules déroule son cycle dans une boucle sans fin, attend l’appel avant de passer à l’orange, puis diffuse un message au moment de virer au rouge. Le feu piétons, réveillé par ce message, affiche le vert pendant la durée de traversée, puis revient au rouge. Le bouton, déclenché par un clic, range la valeur 1 dans la variable partagée. Quatre mécanismes différents, un seul comportement d’ensemble.
En 1866, les rues de Londres tuent 1 102 personnes et en blessent 1 334, alors que l’automobile n’existe pas encore : les attelages, les chevaux et les piétons se disputent une chaussée saturée. John Peake Knight, ingénieur de la signalisation ferroviaire, propose d’appliquer à la rue ce qui protège déjà les trains.
Son appareil est installé le 9 décembre 1868 devant le palais de Westminster. Le jour, des bras articulés indiquent l’ordre à suivre ; la nuit, une lanterne au gaz éclaire en rouge ou en vert. Un agent de police manœuvre le tout depuis le pied du mât. Le 2 janvier 1869, une fuite de gaz provoque une explosion qui blesse grièvement le policier de service. L’expérience est abandonnée, et le Royaume-Uni attend 1929 pour revoir des feux dans ses rues.
Le relais vient des États-Unis. En 1912, un policier de Salt Lake City nommé Lester Wire imagine un feu électrique à deux couleurs. En août 1914, un carrefour de Cleveland reçoit une installation portant les mots stop et move, commandée depuis une cabine et accompagnée d’une sonnerie. En 1920, à Detroit, l’agent William Potts intercale une troisième couleur entre le vert et le rouge, afin d’éviter les changements brutaux : le feu tricolore est né.
La France installe son premier feu le 5 mai 1923, au croisement des boulevards Saint-Denis et de Sébastopol, à Paris, réputé si dangereux qu’il portait le surnom de carrefour des écrasés. Ce feu ne comportait qu’une seule couleur, le rouge, doublée d’une sonnerie ; les trois couleurs ne s’imposeront que dans les années 1930.
Retenez la logique de cette succession. La couleur orange n’a pas été ajoutée pour faire joli : elle répond à un défaut constaté, le freinage brutal au passage du vert au rouge. Chaque perfectionnement technique répond à une difficulté observée, et le programme que vous écrivez obéit à la même règle.
Un feu destiné aux piétons ne comporte que deux couleurs, le rouge et le vert, et souvent une silhouette. La raison tient au comportement attendu : un conducteur qui voit l’orange doit décider s’il peut s’arrêter en sécurité, alors qu’un piéton engagé doit seulement achever sa traversée. Cette différence de besoin produit une différence d’objet, principe que vous avez rencontré en étudiant les fonctions des objets techniques.
Assemblez le projet complet, puis soumettez-le aux quatre situations suivantes. Personne n’appuie pendant deux minutes : le feu véhicules doit rester au vert. Quelqu’un appuie une fois : la traversée doit se dérouler entièrement. Quelqu’un appuie dix fois de suite : le système doit réagir comme pour un seul appui. Quelqu’un appuie pendant que le feu piétons est déjà vert : la demande doit rester sans effet.
Les deux dernières situations font apparaître les défauts les plus intéressants. Un système technique se juge à son comportement dans les cas imprévus, non dans le cas idéal que le concepteur avait en tête.
À l’écran, le clic est instantané et fiable. Sur le trottoir, un bouton peut rester enfoncé, se bloquer par le gel, ou se déclencher tout seul par vibration.
Les installations réelles prévoient ces cas : durée minimale entre deux demandes, vérification que la lampe s’est bien allumée, retour à un mode dégradé en cas de panne. La simulation vaut pour la logique, non pour la fiabilité.
- La chaîne d’information comprend un capteur, un traitement, un actionneur et des interfaces.
- Sur le carrefour, le bouton est le capteur, le programme le traitement, les lampes l’actionneur.
- Scratch simule ces organes ; une simulation valide une logique, non une fiabilité.
- L’algorigramme représente l’enchaînement des opérations et des décisions selon les normes ISO 5807 et NF Z 67-010.
- Un algorigramme comporte un seul début, se lit du haut vers le bas, et les deux sorties d’un losange sont étiquetées.
- Le premier feu, dû à John Peake Knight, est installé à Londres le 9 décembre 1868 et détruit par une explosion de gaz le 2 janvier 1869.
- La troisième couleur est ajoutée par William Potts à Detroit en 1920 ; la France reçoit son premier feu le 5 mai 1923.
- Un système technique se juge à son comportement dans les cas imprévus.
Le carrefour fonctionne. Il a fallu sept étapes pour l’obtenir : nommer les actions, poser les objets, répéter, réagir, se coordonner, retenir et décider, enfin relier le tout à la matière. Ce chemin est celui de tout système automatisé, du portail de garage au métro sans conducteur. Les blocs disparaîtront de votre écran le jour où vous écrirez du texte ; la démarche, elle, restera la même.
🐍 Après les blocs : le même programme en texte
Ce qui change lorsque les pièces deviennent des lignes
Les blocs ne constituent pas un langage à part, réservé aux débutants. Ils rendent visible une organisation que les langages écrits au clavier expriment autrement. Voici le tracé du carré, d’abord tel que vous l’assemblez, puis tel qu’il s’écrit en Python.
| En blocs | En Python |
|---|---|
| quand le drapeau vert est cliqué répéter 4 fois avancer de 100 pas tourner de 90 degrés |
import turtle for i in range(4): turtle.forward(100) turtle.right(90) |
Observez ce qui remplace quoi. Dans Scratch, le ventre du bloc en C entoure les instructions répétées, et la pièce elle-même montre où la boucle commence et où elle finit. En Python, cette information est portée par le décalage des lignes vers la droite, appelé l’indentation. Une ligne mal décalée sort de la boucle sans que rien ne l’annonce.
| Bloc de Scratch | Écriture en Python | Notion |
|---|---|---|
| répéter ( ) fois | for i in range(n): | Boucle bornée |
| répéter indéfiniment | while True: | Boucle sans fin |
| répéter jusqu’à ce que < > | while not condition: | Boucle conditionnelle |
| si < > alors | if condition: | Choix |
| mettre appel à 1 | appel = 1 | Rangement d’une valeur |
| appel = 1 (bloc pointu) | appel == 1 | Comparaison |
| attendre ( ) secondes | time.sleep(n) | Temporisation |
| Le ventre du bloc en C | L’indentation des lignes | Portée d’un bloc |
Le coût est immédiat : les fautes d’écriture réapparaissent, et la structure devient invisible sauf à respecter scrupuleusement les décalages.
Le gain apparaît plus tard : un programme écrit se lit d’un coup d’œil, se compare à une version antérieure, se cherche par un mot, et se transmet dans un simple fichier de texte. Ces avantages pèsent lourd dès que le projet dépasse quelques dizaines d’instructions.
❓ Vingt questions pour se relire
Répondez sans revenir au cours, puis vérifiez
1. Qu’est-ce qu’un algorithme ?
Une suite finie d’instructions non ambiguës qui traitent un problème donné, indépendamment de toute machine et de toute langue.
2. D’où vient le mot « algorithme » ?
Du nom latinisé d’al-Khwârizmî, savant de la Maison de la Sagesse de Bagdad au IXe siècle apr. J.-C.
3. Combien Scratch possède-t-il de formes de blocs, et pourquoi la forme importe-t-elle ?
Six. La forme indique la place que le bloc a le droit d’occuper, ce qui supprime les erreurs d’écriture.
4. Pourquoi un bloc de tête a-t-il le sommet bombé ?
Pour empêcher qu’une pièce se place au-dessus : un script commence obligatoirement par lui.
5. Quelles sont les dimensions de la scène, et où se trouve son origine ?
480 pas sur 360 pas, origine au centre. L’abscisse va de -240 à 240 et l’ordonnée de -180 à 180.
6. Quelle est la direction de départ d’un nouveau lutin ?
90 degrés, c’est-à-dire vers la droite.
7. Changer de costume déplace-t-il le lutin ?
Non. Le costume porte l’apparence, la position porte le lieu.
8. Pourquoi faut-il réinitialiser un lutin au début d’un script ?
Parce que son état survit à l’arrêt du projet : il repart de la position et du costume qu’il avait en dernier.
9. Quelles sont les trois boucles de Scratch ?
Répéter un nombre annoncé de fois, répéter indéfiniment, répéter jusqu’à ce qu’une condition devienne vraie.
10. De combien tourne un lutin qui trace un pentagone régulier ?
De 360 divisé par 5, soit 72 degrés à chaque sommet.
11. Pourquoi le bloc « répéter indéfiniment » n’a-t-il pas de bosse en bas ?
Parce que la boucle ne se termine pas : une instruction placée à sa suite ne serait pas atteinte.
12. Combien de temps dure le feu jaune en agglomération, en France ?
Trois secondes. Hors agglomération, la durée obligatoire est de cinq secondes.
13. Qu’est-ce qu’un événement ?
Un fait extérieur au programme dont la survenue déclenche l’exécution d’un script.
14. Combien de points de départ un projet peut-il posséder ?
Autant qu’il contient de blocs de tête, sans hiérarchie entre eux.
15. Qu’est-ce qu’un message, et que transporte-t-il ?
Un signal nommé diffusé à tout le projet. Il annonce un fait et ne transporte pas de valeur.
16. Pourquoi la diffusion synchronise-t-elle mieux que le comptage des durées ?
Parce qu’elle repose sur un fait constaté, alors que deux horloges séparées finissent par se décaler.
17. Les scripts de Scratch s’exécutent-ils vraiment au même instant ?
Non. Scratch les fait progresser chacun à leur tour, trente fois par seconde, ce qui donne l’apparence de la simultanéité.
18. Que signifie la portée d’une variable ?
La partie du programme autorisée à la lire et à la modifier : tous les lutins, ou un seul.
19. Quels sont les trois organes de la chaîne d’information ?
Le capteur, le traitement et l’actionneur, reliés par des interfaces.
20. Que représentent l’ovale, le rectangle et le losange d’un algorigramme ?
Le début ou la fin, une action, et un test à deux issues étiquetées « oui » et « non ».
✏️ Huit exercices de réflexion
Ces questions demandent un raisonnement, non une récitation
Exercice 1 · L’étoile involontaire
Un élève écrit : répéter 5 fois, avancer de 100 pas, tourner de 144 degrés. Il attendait un pentagone. Que va-t-il obtenir, et pourquoi ?
Piste : comparez 144 à 360 divisé par 5. Le lutin parcourt 5 fois 144 degrés, soit 720 degrés, c’est-à-dire deux tours complets. La figure se referme, mais après avoir traversé le plan deux fois : elle donne une étoile à cinq branches.
Exercice 2 · Le feu qui accélère
Un projet fonctionne bien sur l’ordinateur du collège et beaucoup plus vite sur celui de la maison. Le programmeur a réglé les durées en comptant les tours d’une boucle plutôt qu’en employant le bloc « attendre ». Expliquez la panne, puis proposez une correction.
Piste : un tour de boucle ne dure pas le même temps partout. Le bloc « attendre » mesure une durée réelle, ce qui rend le comportement indépendant de la machine.
Exercice 3 · Deux maîtres pour un feu
Deux scripts commencent par « quand le drapeau vert est cliqué » sur le même lutin. Le premier place le costume au vert, le second au rouge. Quelle couleur s’affiche ? Que faut-il en conclure sur la manière d’organiser un projet ?
Piste : la réponse dépend de l’ordre d’exécution, que le programmeur ne contrôle pas. Une valeur doit être modifiée par un seul script.
Exercice 4 · L’appel enregistré trop tôt
Un piéton appuie sur le bouton pendant que le feu piétons est déjà vert. Décrivez ce que fait le programme du chapitre 7, puis modifiez l’algorithme pour que cette demande reste sans effet.
Piste : ajoutez une seconde variable indiquant l’état du système, et n’enregistrez l’appel que si la traversée n’est pas en cours.
Exercice 5 · Le carrefour impatient
Une municipalité souhaite que les piétons attendent au minimum trente secondes entre deux traversées, afin de ne pas bloquer la circulation. Où placer cette contrainte dans l’algorigramme, et quel bloc employer ?
Piste : après le retour au rouge des piétons, un bloc « attendre » précédant la réouverture des demandes. Interrogez-vous sur ce qui doit se passer si quelqu’un appuie pendant ces trente secondes.
Exercice 6 · Le capteur qui ment
Un bouton d’appel réel se met à se déclencher tout seul plusieurs fois par minute, à cause des vibrations des camions. Le programme est pourtant correct. Sur quel organe de la chaîne d’information porte la panne, et quelle correction logicielle pourrait en limiter les effets ?
Piste : la panne porte sur le capteur. Le programme peut exiger que le contact reste fermé un temps minimal avant de retenir la demande.
Exercice 7 · Du dessin au code
Dessinez l’algorigramme d’un portail automatique : un capteur détecte un véhicule, le portail s’ouvre, attend dix secondes, puis se referme, sauf si le capteur détecte encore un véhicule.
Piste : deux tests sont nécessaires, et l’un d’eux se trouve après l’attente. Vérifiez que chaque losange porte bien ses deux étiquettes.
Exercice 8 · La question de fond
Le chapitre 7 affirme qu’une simulation valide une logique mais non une fiabilité. Trouvez, dans un objet technique de votre quotidien, un cas où le programme est correct et où l’objet tombe pourtant en panne. Expliquez lequel des organes de la chaîne d’information est en cause.
Piste : pensez à un portail dont la cellule est encrassée, à une porte de train bloquée par un objet, à une lampe grillée dont le calculateur ignore l’état. Interrogez-vous sur ce qui manque : un retour d’information vers le traitement.
🗃️ Lexique
Les termes à connaître, rangés par ordre alphabétique
Crédits et mentions. Les blocs reproduits dans ce document ont été redessinés d’après les formes et les couleurs de l’éditeur Scratch, à des fins pédagogiques. Scratch est développé par le groupe Lifelong Kindergarten du MIT Media Lab et maintenu par la Scratch Foundation. Voir scratch.mit.edu. Le logo Scratch et les personnages de la bibliothèque officielle sont des marques déposées et ne figurent pas dans ce document.
Les durées de signalisation citées proviennent de la réglementation française relative aux signaux lumineux d’intersection. Les symboles d’algorigramme suivent les normes ISO 5807 et NF Z 67-010.
Document destiné à un usage familial ou pédagogique privé.