Programmation événementielle : cours de Terminale SI

Quand tu utilises une application sur ton téléphone, rien ne se passe tant que tu ne touches pas l'écran. Dès que tu appuies sur un bouton, l'application réagit : elle affiche une page, joue un son, envoie un message. Le programme ne suit pas un scénario écrit de la première à la dernière ligne : il attend que quelque chose arrive, puis il réagit.

C'est exactement l'idée de la programmation événementielle. Son principe est de recevoir des événements, de natures très variées : en particulier ce que fait un opérateur sur une interface graphique, comme bouger ou cliquer avec la souris, ou taper au clavier ⁵.

En sciences de l'ingénieur, cette façon de penser est partout. Un système automatisé reçoit des informations de capteurs, de boutons, de messages venant d'autres systèmes, et doit y répondre au bon moment. Dans le chapitre précédent, tu as vu comment un signal est échantillonné puis filtré : on obtient des valeurs numériques successives. La question suivante est naturelle : que fait le programme quand une de ces valeurs franchit un seuil, ou quand l'utilisateur agit ? La réponse se construit avec des événements.

Dans ce cours, tu vas apprendre à :

• définir ce qu'est un événement et un gestionnaire d'événement ;
• distinguer la programmation événementielle de la programmation séquentielle ;
• décrire la boucle principale qui détecte puis traite les événements ;
• écrire en pseudo-code un petit programme réactif et prévoir son comportement ;
• repérer les erreurs fréquentes : gestionnaire trop long, état mal mémorisé, événement oublié.

L'épreuve de spécialité de Terminale porte sur le programme de sciences de l'ingénieur et sur son complément de sciences physiques, et les notions de Première peuvent y être mobilisées ². Savoir raisonner sur un programme qui réagit à des entrées fait partie de cette culture numérique.

Cette définition a deux conséquences utiles.

Première conséquence : un événement vient de l'extérieur ou de l'intérieur du programme. Un clic vient de l'utilisateur. Une variable qui change de valeur vient du programme lui-même ⁵. Dans un système technique, on ajoute naturellement les informations d'un capteur : c'est la même idée, un fait nouveau auquel il faut réagir.

Seconde conséquence : un événement n'est pas une durée, c'est un instant. Le clic est l'instant où le bouton est enfoncé. Le programme n'est pas "en train de cliquer" : il reçoit l'information qu'un clic a eu lieu.

Pour comprendre l'intérêt de la programmation événementielle, comparons-la à ce que tu connais déjà. En programmation séquentielle, les instructions s'exécutent l'une après l'autre dans l'ordre où elles sont écrites : le programme décide de tout, l'utilisateur attend son tour. La programmation événementielle s'oppose à ce modèle, ainsi qu'à la programmation par processus légers (threads) ⁵.

Comment un programme peut-il réagir à des événements qu'il ne peut pas prévoir à l'avance ? Il s'appuie sur une architecture simple : une boucle principale qui comporte deux parties. L'une guette les événements, l'autre se charge de les traiter ⁵. On rencontre surtout cette organisation dans les interfaces graphiques ⁵.

Imagine un standard téléphonique. L'opératrice attend. Un appel arrive (détection). Elle le dirige vers le bon service (gestion). Puis elle revient à l'attente. Elle ne traite pas deux appels exactement au même instant : elle termine l'un avant de passer au suivant. La boucle principale fonctionne de la même manière.

Cette propriété a une conséquence pratique directe : tant qu'un gestionnaire n'est pas terminé, les événements suivants attendent. Si un gestionnaire met trois secondes à s'exécuter, l'interface semble figée pendant trois secondes, car la section qui détecte ne reprend la main qu'après la fin du traitement. C'est pourquoi on vise des gestionnaires courts.

À l'inverse, cette règle simplifie beaucoup le raisonnement : puisqu'un gestionnaire n'est pas coupé en plein milieu, tu peux le lire comme une petite séquence ordinaire, sans craindre qu'un autre gestionnaire modifie tes variables entre deux de ses lignes.

Un gestionnaire s'exécute puis se termine : il ne "se souvient" de rien par lui-même. Pour que le programme garde une mémoire d'un événement à l'autre, on utilise des variables d'état, déclarées en dehors des gestionnaires. Ce sont elles que les événements modifient, ce qui est cohérent avec l'idée qu'un programme événementiel se décrit par ses réactions aux changements qui surviennent ⁵.

Tu as étudié l'échantillonnage et le filtrage. Un capteur de température, une fois échantillonné, fournit une suite de valeurs : $T_0, T_1, T_2, \dots$ Le programme n'a pas besoin de réagir à chaque valeur. Il réagit quand quelque chose de significatif se produit. On peut donc fabriquer des événements à partir de mesures.

Remarque comment le filtrage entre en jeu : si le signal est bruité, il peut franchir le seuil plusieurs fois de suite par simple fluctuation, et produire une rafale d'événements parasites. Filtrer le signal avant de détecter le seuil, ou ajouter une marge entre le seuil de déclenchement et celui de retour à la normale, réduit ces événements inutiles. C'est une démarche d'ingénieur : on choisit la détection qui produit les événements utiles, ni trop, ni trop peu.

Cette approche est née avec les interfaces graphiques, et c'est surtout la programmation orientée objet qui l'a rendue courante ⁵. Une interface graphique est faite de nombreux éléments (boutons, menus, champs de saisie) qui réagissent chacun à des actions de l'opérateur ; associer à chaque élément ses réactions est une organisation très naturelle.

Les programmes événementiels s'intègrent dans la démarche plus générale du programme de sciences de l'ingénieur, qui s'appuie sur une démarche scientifique appliquée à des thématiques comme les territoires et les produits intelligents ². Un produit intelligent est justement un produit qui perçoit son environnement et réagit : c'est un terrain naturel pour des programmes pilotés par des événements.