Mon espace Me contacter

NSI Première • Programme français, lycées de Montréal

Fiche de révision : les interactions homme-machine sur le Web

Le chapitre Web est celui où le programme ne plante presque jamais : une balise mal fermée s'affiche, un champ oublié part sans erreur, un bouton sans effet ne dit rien. C'est ce silence qui coûte les points, parce qu'il faut savoir dire ce qui s'est passé sans qu'aucun message ne l'indique.

Cette fiche liste les neuf erreurs qui reviennent dans les copies, avec la phrase exacte à écrire à la place et ce que chacune coûte au barème.

Le fil du chapitre

Tout ce qui vient du client est une PROPOSITION, jamais une garantie : le navigateur devine un document mal formé au lieu de le refuser, et le serveur reçoit ce qu'on veut bien lui envoyer.

Ce chapitre fait partie de NSI en Première

Avant ce chapitre

Cette fiche suppose ces notions acquises. Si une méthode ci-dessous reste opaque, c'est presque toujours l'une d'elles qui manque, pas la fiche.

L'essentiel

Un document est un ARBRE, pas une suite de balises

  • • Chaque balise ouverte crée un noeud ; tout ce qui est écrit avant sa fermeture en est un ENFANT.
  • • Deux balises qui se chevauchent n'ont aucun sens dans un arbre : le navigateur en devine un, souvent différent de celui voulu, et ne signale rien.
  • • Un sélecteur CSS et un script parcourent cet arbre, jamais le texte source : c'est pourquoi une balise mal fermée déplace un style ou casse un script sans message d'erreur.
  • • Le texte lui-même est un noeud : un élément qui contient du texte a un enfant.
<body> <div> <h1>Titre</h1> <p>Texte</p> </div></body>le source, ligne par lignel'arbre du documentbodydivh1p
Les mêmes six lignes vues deux fois : à gauche une suite ordonnée, à droite la seule structure qui compte, où h1 et p sont des enfants de div et non ses voisins.

Dans une question de lecture, dessiner l'arbre avant de répondre rapporte plus de temps qu'il n'en coûte : toutes les sous-questions se lisent ensuite dessus.

Le modèle de boîte et la cascade

  • • Une boîte a quatre couches, de l'intérieur vers l'extérieur : contenu, remplissage, bordure, marge.
  • • La largeur déclarée est celle du CONTENU seul : la place occupée vaut la largeur plus les deux remplissages plus les deux bordures.
  • • Spécificité croissante : balise, puis classe, puis identifiant. Un identifiant l'emporte sur n'importe quel nombre de classes.
  • • À spécificité ÉGALE seulement, la dernière règle lue l'emporte.

Une question de cascade se tranche en comptant : combien d'identifiants, combien de classes, combien de balises dans chaque sélecteur.

Ce qu'un formulaire envoie, et comment

  • • Un champ sans attribut name n'est PAS envoyé, même s'il est rempli et visible.
  • • Deux boutons radio sont exclusifs si et seulement s'ils portent le MÊME name, avec des value différentes.
  • • GET met les données dans l'URL, visibles et conservées dans l'historique. POST les met dans le corps de la requête.
  • • GET pour lire, POST pour modifier. Ni l'un ni l'autre ne chiffre quoi que ce soit : le chiffrement vient de HTTPS.

Quand le code s'exécute

  • • Un script placé dans l'en-tête s'exécute AVANT que le corps existe : toute recherche d'élément y renvoie null.
  • • Remèdes : placer le script à la fin du corps, ou utiliser l'attribut defer.
  • • addEventListener('click', f) enregistre la fonction f. addEventListener('click', f()) l'appelle immédiatement et enregistre son résultat, presque toujours undefined.
  • • textContent écrit du texte, innerHTML interprète du HTML : du contenu venu de l'utilisateur ne passe jamais par innerHTML.

Les pièges qui coûtent des points

Les erreurs ci-dessous sont celles que je corrige le plus souvent en séance. Chacune coûte des points sur une copie, même quand le raisonnement est juste.

1. Appeler la fonction au lieu de l'enregistrer

2 points, et le bouton reste sans effet pendant toute la suite du sujet

Ce qu'il ne faut pas écrire

« bouton.addEventListener('click', afficher()) : au clic, la fonction afficher s'exécute. »

Ce qu'il faut écrire

« Sans les parenthèses : bouton.addEventListener('click', afficher). Avec elles, afficher est appelée tout de suite au chargement, et c'est undefined qui est enregistré. »

Pourquoi : Une fonction est une valeur comme une autre : on passe son NOM pour la confier à quelqu'un, on ajoute les parenthèses pour l'exécuter. C'est la même distinction qu'entre une recette et un plat.

2. Placer le script dans l'en-tête

toute la question : le programme lève une erreur sur null dès la première ligne utile

Ce qu'il ne faut pas écrire

« Le script est dans head, donc il est chargé en premier et tout marche. »

Ce qu'il faut écrire

« Un script dans head s'exécute avant que le corps soit construit : document.getElementById renvoie null. Je place le script à la fin de body, ou j'ajoute defer. »

Pourquoi : Le navigateur construit l'arbre du document de haut en bas et exécute chaque script dès qu'il le rencontre. Un élément écrit plus bas n'existe pas encore.

3. Croire qu'un champ rempli est un champ envoyé

2 points sur la question « qu'est-ce que le serveur reçoit »

Ce qu'il ne faut pas écrire

« Le champ courriel est bien dans le formulaire, donc le serveur le reçoit. »

Ce qu'il faut écrire

« Sans attribut name, un champ n'est pas envoyé : le serveur ne reçoit rien pour lui. J'écris name="courriel", et c'est ce nom qui sera la clé côté serveur. »

Pourquoi : Le nom du champ est la clé du couple envoyé ; l'identifiant sert au style et au script, jamais à la transmission. Beaucoup de copies confondent id et name.

4. Donner un name différent à chaque bouton radio

1 point, et la question sur ce que reçoit le serveur devient fausse

Ce qu'il ne faut pas écrire

« J'ai mis name="choix1" et name="choix2" pour les distinguer, et l'utilisateur ne peut cocher qu'une case. »

Ce qu'il faut écrire

« Deux radios sont exclusifs seulement s'ils partagent le MÊME name : name="choix" pour les deux, avec value="a" et value="b". »

Pourquoi : C'est le name qui définit le groupe. Avec deux noms différents, on obtient deux groupes d'un seul bouton, donc deux cases cochables ensemble et deux couples envoyés.

5. Croire que la largeur déclarée est la place occupée

2 points sur la question de mise en page, la seule qui se calcule

Ce qu'il ne faut pas écrire

« width vaut 200 pixels, donc trois boîtes tiennent dans 600 pixels. »

Ce qu'il faut écrire

« La largeur déclarée est celle du contenu : avec 20 pixels de remplissage et 5 de bordure de chaque côté, chaque boîte occupe 200+40+10=250200 + 40 + 10 = 250 pixels, donc 750 pixels à trois. »

contenu 200 px+ remplissage 240 px+ bordure 250 pxdéclaré : width: 200px
La même déclaration width de 200 pixels, mesurée trois fois : le contenu fait bien 200 pixels, mais la place occupée dans la page en fait 250, et c'est elle qui décide si la mise en page déborde.

Pourquoi : Le modèle de boîte ajoute les couches vers l'extérieur. C'est aussi la raison pour laquelle une mise en page déborde alors que tous les calculs semblent justes.

6. Croire que la dernière règle CSS gagne toujours

1 point, et souvent toute la sous-question de justification

Ce qu'il ne faut pas écrire

« La règle sur .encadre est écrite après celle sur #titre, donc c'est elle qui s'applique. »

Ce qu'il faut écrire

« L'ordre ne départage qu'à spécificité ÉGALE. Un identifiant compte (1;0;0)(1;0;0) et une classe (0;1;0)(0;1;0) : c'est #titre qui l'emporte, où qu'il soit écrit. »

Pourquoi : La cascade compare d'abord les trois compteurs identifiants, classes, balises, dans cet ordre. L'ordre d'écriture n'intervient qu'en dernier recours.

7. Croire que POST protège les données

2 points sur la question de sécurité, très souvent posée au bac

Ce qu'il ne faut pas écrire

« On envoie le mot de passe en POST, donc il n'est pas visible et il est sécurisé. »

Ce qu'il faut écrire

« POST place les données dans le corps au lieu de l'URL : elles ne sont ni dans la barre d'adresse ni dans l'historique, mais elles circulent en clair. Seul HTTPS chiffre. »

Pourquoi : GET et POST décrivent l'INTENTION de la requête, lire ou modifier, et l'endroit où sont placées les données. La confidentialité est une propriété du transport, pas de la méthode.

8. Prendre un contrôle côté client pour une protection

toute la question de sécurité, qui vaut souvent 4 points

Ce qu'il ne faut pas écrire

« Le formulaire vérifie en JavaScript que l'âge est positif, donc le serveur ne peut pas recevoir un âge négatif. »

Ce qu'il faut écrire

« Le contrôle côté client est un confort pour l'utilisateur. N'importe qui peut envoyer la requête sans passer par la page : le serveur doit revérifier chaque donnée reçue. »

navigateurcontrôle JavaScriptserveurrequête forgéechemin normalle contrôle n'est jamais exécuté
Deux chemins arrivent au même serveur, et un seul traverse la page : le contrôle en JavaScript ne protège que le chemin du haut, celui que personne n'est obligé de prendre.

Pourquoi : Le client n'est pas de confiance : le code JavaScript est modifiable, désactivable, et la requête peut être fabriquée à la main. C'est la règle numéro un du chapitre.

9. Écrire du contenu utilisateur avec innerHTML

2 points, et c'est la faille que le sujet attend qu'on nomme

Ce qu'il ne faut pas écrire

« zone.innerHTML = message pour afficher ce que le visiteur vient de saisir. »

Ce qu'il faut écrire

« zone.textContent = message : le texte est affiché tel quel. innerHTML interpréterait les balises contenues dans le message, donc un script fourni par le visiteur. »

Pourquoi : innerHTML remplace un morceau d'arbre par du HTML analysé. Toute balise présente dans la chaîne devient un vrai élément, ce qui ouvre l'injection de contenu.

Quelle méthode choisir

GET ou POST

Ce que la requête FAIT, et non la taille des données.

  • Si la requête lit sans rien changer → GET

    Exemple : une recherche, un filtre, une page de résultats

    l'URL devient partageable et peut être mise en signet

  • Si la requête modifie l'état du serveur → POST

    Exemple : voter, s'inscrire, publier un message

  • Si les données sont longues ou binaires → POST

    Exemple : l'envoi d'un fichier

    la longueur d'une URL est limitée en pratique

  • Si les données ne doivent pas rester dans l'historique → POST, et HTTPS pour la confidentialité

    Exemple : un mot de passe

Aucune des deux ne chiffre : si la question parle de confidentialité, la réponse attendue est HTTPS.

Client ou serveur : où faire le travail

Le mot de l'énoncé : « vérifier », « afficher », « enregistrer », « calculer ».

  • Si il s'agit de réagir à un clic ou à une saisie → client, gestionnaire d'événement

    Exemple : afficher un message dès que le champ est vide

  • Si il s'agit de décider si une donnée est acceptable → serveur, obligatoirement

    Exemple : refuser un âge négatif

    le client peut le faire en plus, jamais à la place

  • Si il faut consulter ou modifier des données partagées → serveur

    Exemple : compter les votes d'un sondage

  • Si il s'agit de changer l'apparence sans nouvelle donnée → client

    Exemple : replier un menu, changer une couleur

Un contrôle peut être fait aux deux endroits : côté client pour le confort, côté serveur pour la sécurité. Le dire ainsi vaut le point complet.

La rédaction attendue

Le correcteur coche des étapes. Les voici dans l'ordre, avec la phrase de conclusion qu'il attend mot pour mot.

Dire exactement ce que le serveur reçoit

Quand l'utiliser : L'énoncé donne un formulaire et demande « qu'est-ce que le serveur reçoit lors de la soumission ».

  1. 1 Repérer la méthode et l'adresse : attribut method et attribut action de la balise form.
  2. 2 Ne garder que les champs qui portent un attribut name : les autres ne sont pas envoyés.
  3. 3 Pour chaque champ retenu, écrire le couple nom égale valeur, en prenant la value pour les boutons radio et les cases à cocher.
  4. 4 Placer ces couples dans l'URL si la méthode est GET, dans le corps de la requête si elle est POST.
  5. 5 Dire ce qui n'est PAS envoyé, et pourquoi : c'est la moitié du barème.

Phrase de conclusion

« Le navigateur envoie une requête POST vers /vote, dont le corps contient les couples choix=b et pseudo=Lina. Le champ commentaire, dépourvu d'attribut name, n'est pas transmis. »

Le piège : Oublier de dire quels champs ne partent pas : le correcteur cherche cette phrase autant que la liste des couples.

Barème : 1 point pour la méthode et l'adresse, 2 points pour les couples, 1 point pour les champs non transmis.

Justifier qu'un contrôle côté client ne protège rien

Quand l'utiliser : L'énoncé demande « ce contrôle suffit-il » ou « quelle faille reste ouverte ».

  1. 1 Nommer ce que le contrôle vérifie et sur quelle machine il s'exécute.
  2. 2 Rappeler que la page et son script sont fournis au client, donc modifiables par lui.
  3. 3 Donner le chemin qui contourne : envoyer la requête sans passer par la page, avec un outil quelconque.
  4. 4 Conclure par la règle et par le remède : revérifier côté serveur.

Phrase de conclusion

« Ce contrôle s'exécute sur la machine du visiteur, qui peut modifier ou désactiver le script, et rien ne l'oblige à passer par la page pour envoyer la requête. Le serveur doit donc revérifier lui-même que la valeur reçue est positive. »

Le piège : Répondre « ce n'est pas sécurisé » sans dire par où passe le contournement : la phrase ne vaut alors rien.

Barème : 1 point pour le lieu d'exécution, 2 points pour le contournement décrit, 1 point pour le remède.

Vérifier avant de rendre

Cinq minutes de vérification récupèrent plus de points qu'un exercice de plus commencé à la hâte.

L'exercice type décortiqué

Une page de sondage : ce qui part, ce qui ne part pas, et ce qui protège

Une page contient un formulaire de méthode POST vers /vote. Il porte deux boutons radio de même name égal à choix, de valeurs a et b, un champ texte de name égal à pseudo, et un champ texte pour un commentaire sans attribut name. Un script vérifie que le pseudo n'est pas vide avant l'envoi.

Décrire ce que reçoit le serveur quand un visiteur choisit b et saisit le pseudo Lina, puis dire si le contrôle du pseudo garantit qu'aucun pseudo vide n'arrive au serveur.

Étape 1

Méthode POST, adresse /vote : les données partent dans le corps de la requête, pas dans l'URL.

Pourquoi

C'est la première chose que le correcteur cherche, et elle décide de la forme de la réponse : une URL enrichie pour GET, un corps de requête pour POST.

Étape 2

Champs retenus : choix et pseudo. Le commentaire n'a pas de name, il est écarté.

Pourquoi

Le tri se fait sur l'attribut name et sur lui seul. Écarter explicitement le commentaire est une phrase notée, pas un détail.

Étape 3

Les deux radios partagent le name choix, donc un seul couple part : choix=b, la value du bouton coché.

Pourquoi

C'est ce qui prouve qu'on a compris que le groupe est défini par le name : la valeur envoyée est la value, jamais le texte affiché à côté du bouton.

Étape 4

Corps de la requête : choix=b et pseudo=Lina.

Pourquoi

La réponse attendue est cette liste exacte de couples, écrite comme telle. Une phrase vague sur « les données du formulaire » ne rapporte rien.

Étape 5

Le contrôle du pseudo s'exécute sur la machine du visiteur, dans un script qu'il peut modifier ou désactiver.

Pourquoi

Nommer le lieu d'exécution est ce qui transforme une intuition en argument. La suite en découle mécaniquement.

Étape 6

Rien n'oblige à passer par la page : une requête POST vers /vote peut être envoyée directement, avec un pseudo vide.

Pourquoi

C'est le chemin de contournement, la seule partie de la réponse qui prouve la faille. Sans lui, l'affirmation reste une opinion.

Conclusion rédigée

« Le serveur reçoit une requête POST vers /vote dont le corps contient choix=b et pseudo=Lina ; le commentaire n'est pas transmis faute d'attribut name. Le contrôle du pseudo, exécuté côté client, n'apporte aucune garantie : le serveur doit revérifier lui-même que le pseudo n'est pas vide. »

L'erreur classique sur cet exercice : Écrire que le commentaire part quand même « puisqu'il est dans le formulaire », et conclure que le contrôle JavaScript suffit parce qu'il empêche l'envoi depuis la page.

À savoir par cœur

  • • Un document est un ARBRE : dessiner l'arbre avant de répondre à toute question de structure.
  • • Pas de name, pas d'envoi. Le name est la clé côté serveur, l'id sert au style et au script.
  • • Deux radios exclusifs partagent le MÊME name, avec des value différentes.
  • • GET pour lire, POST pour modifier. Aucun des deux ne chiffre : le chiffrement, c'est HTTPS.
  • • addEventListener reçoit le NOM de la fonction, sans les parenthèses.
  • • Un script dans l'en-tête s'exécute avant que le corps existe : le placer en fin de corps, ou defer.
  • • La largeur déclarée est celle du CONTENU : ajouter deux remplissages et deux bordures pour la place occupée.
  • • Spécificité : identifiant, puis classe, puis balise. L'ordre d'écriture ne départage qu'à égalité.
  • • Tout contrôle côté client est un confort. Le serveur revérifie, toujours.

Questions fréquentes

Quelle est la différence entre GET et POST en NSI ?

GET place les données dans l'URL et sert à lire sans rien modifier : l'adresse reste partageable et visible dans l'historique. POST les place dans le corps de la requête et sert à modifier l'état du serveur, comme voter ou s'inscrire. Aucune des deux méthodes ne chiffre les données : la confidentialité vient de HTTPS.

Pourquoi mon bouton ne fait rien avec addEventListener ?

Deux causes reviennent toujours. Soit la fonction a été appelée au lieu d'être enregistrée, en écrivant les parenthèses après son nom, et c'est le résultat de l'appel qui a été enregistré. Soit le script est placé dans l'en-tête et s'exécute avant que le bouton existe, auquel cas la recherche de l'élément renvoie null.

Pourquoi un champ rempli n'arrive-t-il pas au serveur ?

Parce qu'un champ dépourvu d'attribut name n'est jamais envoyé, même s'il est visible et rempli. Le name est la clé du couple transmis ; l'attribut id, lui, ne sert qu'au style et aux scripts. Ajouter un name au champ suffit à le faire apparaître dans la requête, sous ce nom exactement.

Un contrôle en JavaScript suffit-il à sécuriser un formulaire ?

Non. Le script s'exécute sur la machine du visiteur, qui peut le modifier ou le désactiver, et rien n'oblige à passer par la page pour envoyer la requête. Un contrôle côté client améliore le confort en signalant l'erreur tout de suite ; seule une vérification refaite par le serveur protège réellement les données.

Comment savoir quelle règle CSS s'applique quand deux se contredisent ?

On compare la spécificité des sélecteurs, dans l'ordre : nombre d'identifiants, puis de classes, puis de balises. Un identifiant l'emporte sur n'importe quel nombre de classes, et une classe sur n'importe quel nombre de balises. L'ordre d'écriture ne départage que si les deux sélecteurs ont exactement la même spécificité.

Passer à la pratique

Exercices corrigés : Interactions homme-machine sur le Web

Une méthode se prouve sur une copie, pas sur une fiche. La série du même chapitre reprend chacun de ces pièges dans un exercice, avec le corrigé rédigé étape par étape.

  • 15 exercices corrigés
  • 150 points
  • 225 minutes
Faire les exercices
Fiche précédente Traitement de données en tables et types construits Fiche suivante Architectures matérielles, systèmes et réseaux

Voir aussi

Toutes les fiches Tous les exercices Tutorat NSINSI : les bases de PythonSNT : Internet et le WebPremière

Vous cherchez un tuteur en NSI à Montréal ?

Contactez-moi pour une première séance. On reprend les points de méthode qui font perdre des points en évaluation, puis on les met à l'épreuve sur des exercices du niveau réel de l'examen.

Me contacter WhatsApp
Site par Studio Squalli