IFT3225

Corrigé du formatif

Préparation de l'examen final

Ce corrigé accompagne le formatif de l’examen final.

Partie 1 : vrai ou faux

Quand l’énoncé est vrai, la justification devait dire ce qui supporte l’énoncé. Quand l’énoncé est faux, la justification devait dire ce qui le rend faux et formuler l’énoncé correct.

Énoncé 1 : FAUX

L’absence de réponse ne signifie pas que la requête n’a pas abouti : elle peut avoir été traitée et un problème rencontré ensuite a prévenu l’envoi de réponse. Comme POST n’est pas idempotente, la rejouer peut créer un doublon ou une incohérence au niveau des données.

Énoncé correct : un client peut reprendre automatiquement une requête idempotente (GET, PUT, DELETE), mais pas un POST sans précaution supplémentaire.

Énoncé 2 : VRAI

Le temps de résolution d’une requête dépend du code, mais également de l’infrastructure, le nombre d’utilisateurs, l’emplacement des serveurs intervenants dans la résolution et la quantité de données à traiter. Un changement au niveau de l’un de ces facteurs peut affecter significativement le temps de résolution d’une requête.

Énoncé 3 : FAUX

REST ne demande aucune correspondance entre les chemins et la structure de la base : l’URI identifie une ressource au sens conceptuel, pas une table. Un point d’accès sémantique, qui répond à une question du client sans refléter le stockage, est même une marque de bonne conception.

Énoncé correct : une API organise ces points d’accès et ressources selon les besoins de ses clients.

Énoncé 4 : FAUX

La signature permet de détecter une modification du jeton, elle n’en cache pas le contenu : un JWT est encodé, pas chiffré, et quiconque l’intercepte peut le lire.

Énoncé correct : la signature garantit l’intégrité du jeton ; c’est pourquoi on n’y place jamais d’information confidentielle.

Énoncé 5 : VRAI

C’est exactement ce qui amène à une réponse 403 Forbidden : le serveur sait qui fait la requête (l’authentification a réussi), mais cette identité n’a pas la permission demandée. C’est ce qui distingue l’authentification et l’autorisation.

Énoncé 6 : FAUX

Une valeur calculable à partir des props se calcule pendant le rendu et se met à jour automatiquement lorsque les props changent et donc accompagne le nouveau rendu du composant. Une valeur calculable à partir de l’état suit le même principe. Tout changement d’état va également susciter un nouveau rendu et donc une mise à jour de la valeur. Il n’est donc pas nécessaire de l’ajouter à l’état ou d’utiliser un useEffect.

Énoncé correct : Une valeur dérivée pure ne doit pas être mise dans l’état.

Énoncé 7 : FAUX

CORS est une autorisation que le serveur accorde, dans les en-têtes de ses réponses : rien de ce qu’on écrit dans le code du client ne peut l’accorder à sa place.

Énoncé correct : Pour qu’un client lise les réponses d’une autre origine, c’est le serveur de cette origine qui doit l’autoriser.

Énoncé 8 : VRAI

Les résolveurs conservent l’ancienne réponse en cache jusqu’à l’expiration du TTL et la servent en toute conformité pendant ce délai. Après un changement d’adresse, une partie du trafic atteint donc l’ancien serveur pendant des heures sans qu’aucune configuration soit fautive.

Partie 2 : questions à développement

Question 1 : stratégie d’optimisation

La réponse est propre à chaque équipe ; on évalue la structure du raisonnement. Elle doit nommer la stratégie générale (éliminer, réduire, différer, devancer, réutiliser, rapprocher), être contextuelle en décrivant brièvement un scénario et préciser comment le gain sera évalué et où il pourra être observé.

Exemple : différer la carte, qui ne sert pas au premier écran, pour accélérer la présentation d’un lieu consulté en étant sur un mauvais réseau ; mesurer le temps avant affichage utile de ce parcours en simulation de réseau lent, avant et après.

Question 2 : Architecture client-serveur et cycle d’une requête

Cette réponse s’illustre bien avec un schéma montrant:

Question 3 : authentification par JWT dans une application MERN

Cette réponse s’illustre bien avec un schéma montrant:

Partie 3 : interface réactive

Exercice 1 : cinq comportements

Chaque comportement vaut 2 % : la forme « quand, alors » avec une réaction observable (1 %), et la mention de ce qu’il garantit ou évite (1 %). Un comportement qui décrit une fonctionnalité (« l’utilisateur peut réserver un poste ») sans réaction observable ne rapporte rien.

Exemple de réponse complète, parmi bien d’autres possibles :

  1. Quand la liste des postes n’est pas encore arrivée, l’interface affiche un indicateur de chargement à la place de chaque salle. Évite l’écran vide, indiscernable d’une bibliothèque sans postes.
  2. Quand un poste affiché est réservé par quelqu’un d’autre, l’interface le marque occupé sans que l’utilisateur ait à recharger. Garantit que l’écran reflète l’état réel du système, pas celui d’il y a deux minutes. (Changement venu du système.)
  3. Quand la requête de réservation échoue ou que le réseau est coupé, l’interface le signale, propose de réessayer, et ne présente pas le poste comme réservé. Évite qu’un échec silencieux laisse croire à une réservation acquise. (Défaillance.)
  4. Quand l’utilisateur confirme une réservation, l’interface désactive le bouton pendant l’envoi, puis affiche le numéro du poste et l’heure de fin. Garantit un retour d’écriture et évite le double envoi. (Écriture et son retour.)
  5. Quand la réservation est refusée parce que le poste vient d’être pris, l’interface l’explique, retire le poste de la liste et suggère le plus proche encore libre. Évite l’attribution silencieuse d’un poste à deux personnes.

Exercice 2 : le composant à réparer

Comportement erroné à l’exécution

  1. La minuterie n’est jamais nettoyée. L’effet installe un setInterval sans retourner de fonction de nettoyage : à chaque disparition ou remontage du composant, une minuterie de plus continue de tourner, et les requêtes se cumulent.
  2. Le tableau de dépendances est vide alors que l’effet dépend de lieu. Quand la prop change, l’effet n’est pas relancé : la liste continue d’afficher, toutes les cinq secondes, les mesures de l’ancien lieu.
  3. nombre est un état dérivé, entretenu par un second effet. Il se calcule pendant le rendu ; le conserver ajoute un rendu et une seconde source de vérité. D’après le comportement attendu, il devait compter les mesures visibles : tel quel, il compte tout.
  4. ajouter modifie le tableau en place. mesures.push(...) puis setMesures(mesures) transmet la même référence : React ne voit aucun changement et ne redessine pas.
  5. onClick reçoit le résultat d’un appel, pas une fonction. onClick={ajouter({ valeur: 0 })} exécute ajouter à chaque rendu ; le clic, lui, ne fait rien.
  6. Le filtre n’est jamais appliqué. Le champ met bien filtre à jour, mais la liste affiche mesures sans filtrage, en écart direct avec le comportement attendu.

Problème de conception

  1. Couplage avec la couche donnée. Tout changement au niveau de l’appel pour récupérer les données nécessite de modifier le composant.
  2. Le composant s’occupe de la structure et présentation de multiples sous composants: filtre et mesure individuelle.

Partie 4 : problème de conception

Un scénario entièrement rédigé, à titre de modèle

a) Situation.

En heure de pointe (8h, à la station Berri), Camille attend la navette au milieu d’une foule dense ; la prochaine arrive dans deux minutes. Elle veut savoir vers quelle section marcher pour monter sans se battre.

b) Instruments.

  1. Les capteurs d’occupation de la navette en approche qui fournissent la répartition par section ;
  2. La position de la navette, pour rattacher la consultation à la bonne navette et estimer l’arrivée ;
  3. L’écran public du quai, réponse de repli qui ne dépend pas du téléphone de chacun, précieuse quand le réseau sature ;
  4. Le capteur de densité de quai, qui permet au système de savoir que l’information vaut la peine d’être affichée à cet arrêt.

c) Dialogue avec l’API.

GET /arrets/berri/prochaine-navette
    Paramètres : aucun (l'arrêt est dans le chemin)
    200 : navette en approche, minutes estimées,
          occupation par section (avant, milieu, arrière),
          instant du dernier relevé
    404 : arrêt inconnu
    503 : relevés indisponibles ; le client garde
          la dernière réponse reçue, datée

Une seule requête suffit : le point d’accès est sémantique, il répond pleinement à la question de Camille.

d) Interface et réponse attendue.

Sur le téléphone : trois blocs (avant, milieu, arrière) colorés par occupation, avec la mention « arrière presque vide » et l’âge du relevé (« il y a 20 s »). Si la requête échoue, la dernière réponse connue reste affichée, datée, plutôt qu’un écran d’erreur.

En parallèle, l’écran du quai affiche « Prochaine navette : montez à l’arrière », visible sans téléphone. Cette réponse sert à tous les utilisateurs sur place, y compris ceux qui n’ont pas l’application.

Deux autres directions recevables, esquissées