Module 4 · L'oral

Pour aller plus loin

Tu arrives au bout du guide. Ce dernier module ne t'apprend pas une notion de plus : il déplie la carte des territoires voisins — ce que c'est, quel problème ça résout, à quoi tu le reconnais, quand ça vaut la peine d'y aller. Aucun tutoriel : une carte honnête, et un ordre pour la parcourir sans t'éparpiller.

🗺️ Comment lire cette page

Ne la lis pas comme une liste de choses à faire — le plus sûr moyen de te décourager. Lis-la comme une carte routière : tu veux savoir ce qui existe et dans quelle direction. Deux territoires — l'animation et la 3D — ont leur propre guide dans l'Atlas, parce qu'ils ont chacun un modèle mental qu'on n'installe pas en trois paragraphes. Les autres sont des repères que tu sauras nommer en entrevue, et où revenir le jour où un projet réel te les impose.

Où tu en es

On sous-estime toujours la distance parcourue quand on l'a franchie module par module. Ce guide t'a fait traverser six groupes, chacun comblant un manque précis que le mobile ne t'a jamais demandé de combler.

Le groupe	Ce qu'il t'a donné, en une phrase
Pour commencer	La méthode : partir de ce que tu sais déjà en React Native et nommer précisément ce qui change quand on passe au web.
Fondations du web	La plateforme elle-même : le DOM et le cycle de rendu du navigateur, le HTML qui porte du sens et l'accessibilité qui en découle, le CSS (boîtes, flexbox, grid, responsive, variables), et HTTP comme protocole de conversation.
React côté web	La traduction terme à terme du React que tu pratiques, puis les formulaires en profondeur — état contrôlé ou non, validation, erreurs accessibles.
Next.js	Le cœur : pourquoi un framework par-dessus React, l'App Router, la frontière serveur/client, les quatre façons de fabriquer une page, et le côté serveur de ton frontend.
Qualité	Lire une suite de tests comme une spécification vivante, et poser un regard critique argumenté sur du code frontend qui n'est pas le tien.
Synthèse	Un vrai test technique disséqué de bout en bout, puis la stratégie d'entrevue — et cette carte.

En capacités concrètes, voici ce que tu peux faire seul après ce guide :

Ouvrir un projet Next.js inconnu et t'y orienter en quelques minutes. L'arborescence de app/ est le plan du site, tu reconnais les fichiers spéciaux, tu lis un layout imbriqué et comprends pourquoi telle page hérite de tel cadre.
Dire où s'exécute un morceau de code — peut-être la compétence la plus rare chez un junior. Directive client ou non, provenance des données, présence d'un état ou d'un événement, et tu tranches : serveur, client, ou les deux. La moitié des bugs déroutants de Next.js viennent d'une confusion sur ce point.
Lire un formulaire. Repérer si l'état est contrôlé ou laissé au DOM, où se fait la validation, si une erreur est réellement annoncée à un lecteur d'écran et pas seulement peinte en rouge.
Lire une suite de tests et en tirer la spécification du composant : ce qu'il promet, ce qu'il refuse, quels cas limites l'auteur avait en tête.
Critiquer du code frontend avec des arguments. Nommer une duplication, un état mal placé, un div qui aurait dû être un button — et le formuler sans agressivité.

💡 Ce que ça vaut, factuellement

Ce n'est pas « être senior » : la mémoire musculaire de centaines d'heures de frappe viendra au travail, ce guide est un guide de lecture. Mais dans un entretien de stage, la différence entre un candidat qui a copié des tutoriels et un candidat qui sait expliquer où s'exécute son code et pourquoi est immédiatement audible. Le reste — vitesse, réflexes, cicatrices — s'achète en heures, pas en lectures.

📖 La formule

La question du niveau en dessous

Devant un outil, une bibliothèque, un framework :

  « Qu'est-ce que cet outil m'apporte
    que le niveau en dessous ne m'apportait pas ? »

  → Réponse en une phrase concrète  : l'outil est justifié.
  → « rien, mais c'est plus moderne » : le niveau en dessous suffisait.

La question qui gouverne toute cette carte, et tu la verras revenir à chaque territoire : on ne quitte le CSS pour Motion, Motion pour GSAP, le HTML pour la 3D, les props pour un magasin global que lorsqu'on peut nommer ce que l'étage supérieur apporte de plus. Elle sert autant en entrevue qu'en revue de code, et t'évite le piège numéro un du développeur enthousiaste : adopter un outil avant d'avoir le problème.

Les territoires voisins

Six directions, et pour chacune la même chose : le problème qu'elle résout, à quoi tu la reconnais, et si elle vaut un détour maintenant. Pas de tutoriel — un tutoriel se périme, une carte non. Applique-leur la formule ci-dessus et tu sauras laquelle t'appelle vraiment.

Deux d'entre elles t'attendent déjà dans l'Atlas comme guides à part entière, et c'est délibéré : elles ont chacune un modèle mental qu'on n'installe pas en trois paragraphes. Les quatre autres sont des sections, présentes ou à venir, dans les guides qui les concernent — parce qu'elles n'ont de sens qu'à l'intérieur d'un territoire déjà couvert.

L'animation web

Le territoire qui t'attire, et il se lit en trois niveaux : le navigateur anime seul (transitions et animations CSS, sans une ligne de JavaScript) ; la plateforme expose une API quand il faut piloter (Web Animations, animation liée au défilement) ; une bibliothèque comme GSAP arrive quand il faut orchestrer — enchaîner, synchroniser, reprendre au milieu. L'erreur la plus commune est de sauter directement au troisième niveau.

Le fil rouge technique, celui qui sépare une animation fluide d'une animation qui saccade : seules certaines propriétés (transform, opacity) sont confiées au compositeur et n'obligent pas le navigateur à recalculer la mise en page à chaque image. Un guide entier lui est réservé — nommé par le problème, pas par l'outil, pour qu'il survive à la bibliothèque du moment.

La 3D dans le navigateur

Deuxième territoire qui t'attire, et le plus coûteux de la liste — il faut le dire honnêtement. WebGL, et son successeur WebGPU, donnent à une page l'accès à la carte graphique : tampons de sommets, petits programmes appelés shaders, pipeline de rendu. Personne ne construit un site directement là-dedans, comme personne n'écrit un site en assembleur ; three.js est la couche qui rend tout ça praticable.

Le vrai contenu à installer, ce sont les objets qui reviennent partout : une scène, une caméra, des géométries, des matériaux, des lumières, et une boucle qui redessine soixante fois par seconde. Un guide entier lui est réservé aussi, à lire après celui de l'animation — la boucle de rendu s'y installe déjà, et on ne l'apprend pas deux fois.

L'état serveur côté client

Moins spectaculaire, mais tu le croiseras dans presque tous les projets React professionnels. Tu sais aller chercher une donnée et tu as vu la version naïve : un effet, un fetch, trois états — donnée, chargement, erreur. Puis les vraies questions arrivent : comment éviter de recharger ce que l'écran d'à côté vient de charger ? que montrer pendant qu'on rafraîchit ? Ce sont des questions de cache, et c'est ce que résolvent TanStack Query et ses cousins.

Tu en as déjà vu l'autre réponse : le cache de Next.js, dans le module Rendu & data fetching. Deux réponses au même problème, à deux endroits différents. C'est une section, pas un territoire.

L'état global côté client

Le message principal vaut mieux que n'importe quelle comparaison de bibliothèques : une fois l'état serveur mis de côté, il reste très peu d'état vraiment global dans une application. Le thème, la session, une préférence — et c'est à peu près tout. Tu connais déjà Zustand, puisque ton app mobile l'utilise ; c'est la même bibliothèque côté web, avec la même API, ce qui fait un excellent argument en entrevue.

Les systèmes de composants et le style à l'échelle

Écrire un bouton est facile. Écrire le trentième en gardant les mêmes espacements, les mêmes couleurs, le même comportement au clavier et les mêmes états de focus, c'est un problème différent. Trois réponses complémentaires : des composants sans style qui n'apportent que le comportement difficile (piéger le focus dans une modale, fermer avec Échap, annoncer le bon rôle) ; des jetons de design centralisés ; et une convention d'écriture des variantes. C'est une section du guide sur l'architecture React, pas un territoire.

La performance et la mesure

Sur le web, la performance est mesurée publiquement par des métriques standardisées, les Core Web Vitals, qui influencent le référencement. Sache les nommer et les expliquer en une phrase chacune : c'est une question d'entrevue très fréquente, et elle sépare instantanément ceux qui ont lu de ceux qui répètent.

Deux outils suffisent, déjà dans ton navigateur. Lighthouse produit un rapport chiffré et une liste d'améliorations classées — bon point de départ, mais il simule un appareil et un réseau. L'onglet Performance est l'instrument sérieux : il enregistre ce que fait réellement le navigateur, image par image.

🔗 Pont — la même question, six fois

Relis les six directions ci-dessus et tu verras qu'elles posent toutes la formule de ce module. Passer du CSS à une bibliothèque d'animation, des props à un magasin global, d'un fetch à un cache de requêtes, du HTML à la 3D : chaque fois, la question est « qu'est-ce que l'étage du dessus m'apporte que celui du dessous ne m'apportait pas ? ». Quand la réponse est une phrase concrète, monte. Quand c'est « c'est plus moderne », reste où tu es — tu viens d'économiser une semaine et une dépendance.

Le reste de la plateforme, en survol

Ces territoires ne méritent pas un détour maintenant, mais tu dois pouvoir les nommer et dire à quoi ils servent. C'est déjà énorme : la plupart des blocages d'un junior ne viennent pas de ne pas savoir faire, mais de ne pas savoir que la chose existe et porte un nom.

TypeScript avancé. Tu sais lire des types simples ; il existe une couche au-dessus : génériques, types conditionnels, types utilitaires (Pick, Omit, Partial), inférence à partir d'un schéma de validation. Ça vaut la peine quand tu écris des fonctions réutilisables plutôt que du code d'écran. Le module Lire les types TypeScript est ta base ; la suite s'apprend au besoin, jamais en avance.
Les monorepos et Turborepo. Un dépôt unique contenant plusieurs applications et des paquets partagés — tu vis déjà dedans, Halterofit en est un. Turborepo y ajoute l'intelligence qui compte : il connaît le graphe de dépendances et ne relance que ce qui a changé, en mettant le reste en cache. Sur un gros projet, c'est la différence entre une intégration continue de trois minutes et de vingt.
Le déploiement, et ce que « edge » veut dire. Vercel, Cloudflare Pages et Netlify font la même chose de base : tu pousses ton code, ils construisent et publient. Le mot edge mérite une explication : un serveur classique vit à un endroit précis, et un visiteur à l'autre bout de la planète paie le trajet en millisecondes. L'edge, c'est exécuter ton code sur un réseau de petits serveurs répartis dans des dizaines de villes, pour que la réponse parte du point le plus proche. Ça se paie : environnement d'exécution restreint, et la base de données reste souvent au même endroit.
La surveillance d'erreurs. Sentry capte les erreurs de tes vrais utilisateurs avec leur contexte : message, pile d'appels, navigateur, page. Sans ça tu ne sais rien — l'utilisateur qui plante ferme l'onglet et ne te le dira jamais.
L'internationalisation. Servir un site en plusieurs langues, ce n'est pas « traduire les chaînes » : c'est router par langue (le segment [locale]), formater dates, nombres et monnaies selon la région, gérer les pluriels — qui n'ont pas les mêmes règles d'une langue à l'autre — et parfois le sens de lecture. Au Québec, ça se monnaie : beaucoup de projets sont bilingues par obligation.
L'authentification. Sessions par cookie ou jetons, fournisseurs externes, protection des routes, et surtout : où se vérifie l'identité. La règle découle du module sur les Server et Client Components — une vérification faite uniquement côté client n'est pas une sécurité, c'est une décoration. Tout ce qui arrive dans le navigateur est modifiable par le visiteur.

🎤 En entrevue

« Qu'est-ce que tu as envie d'apprendre ensuite ? »

Question apparemment anodine, en réalité très révélatrice : elle teste ta curiosité et ta capacité à te situer. La mauvaise réponse est vague — « un peu de tout », « l'IA », « approfondir le frontend en général ». Elle donne l'image de quelqu'un qui suit le vent.

La bonne réponse est précise, motivée par un problème rencontré, et bornée. Par exemple : « GSAP, et plus précisément ScrollTrigger. J'ai remarqué en lisant des sites de studios que ce qui les distingue n'est pas les effets, c'est le rythme — la séquence, les chevauchements, ce que le défilement déclenche. Le CSS ne sait pas exprimer ça et je veux comprendre comment on pense une chorégraphie. Je compte y aller après avoir solidifié Next.js, parce que je préfère finir un territoire avant d'en ouvrir un autre. »

Trois choses passent dans cette réponse : tu sais ce que tu veux, tu sais pourquoi (un manque identifié, pas une mode), et tu montres de la discipline d'apprentissage. La dernière phrase vaut souvent autant que les deux premières.

« Comment fais-tu ta veille technique ? »

Ce qu'on cherche à savoir : est-ce que tu vas te périmer ? Encore une fois, la précision fait tout. « Je regarde des vidéos YouTube » est faible. Mieux : nommer des sources et surtout une méthode.

Par exemple : « Ma source principale, ce sont les documentations officielles et les notes de version — celles de Next.js et de React en particulier, parce que c'est là que les changements sont expliqués par ceux qui les ont faits. Je lis aussi les billets techniques des équipes qui publient sur leur propre stack. Et je me suis fixé une règle : quand je découvre quelque chose, j'essaie de l'expliquer par écrit avec mes mots — si je n'y arrive pas, c'est que je ne l'ai pas compris. J'ai d'ailleurs monté mes propres guides d'étude pour ça. »

Cette dernière partie est un atout réel dans ton cas : tu as ces guides. Les mentionner transforme une réponse générique en preuve concrète.

« Parle-moi d'une optimisation que tu as faite. »

« Un écran de liste ramait au défilement sur un appareil d'entrée de gamme. Avant de toucher au code, j'ai compté les rendus — chaque ligne se redessinait à chaque frappe dans le champ de recherche, parce que l'état de recherche était placé trop haut dans l'arbre. J'ai descendu cet état dans le composant qui en avait réellement besoin. Le nombre de rendus est passé de tout l'écran à une seule ligne, et la saccade a disparu. »

« Ce qui m'a fait gagner, ce n'est pas une bibliothèque : c'est d'avoir mesuré, et d'avoir trouvé que le problème était un état mal placé. »

Et si tu n'as pas encore d'exemple vécu : « Je n'ai pas encore eu à optimiser en production, mais voici comment je m'y prendrais : Lighthouse d'abord pour situer, puis l'onglet Performance pour trouver le vrai coût — et je ne change rien tant que je n'ai pas de chiffre. »

🧭 Pourquoi cette réponse marche

Elle suit quatre temps — symptôme observé, mesure avant, ce qui a changé et pourquoi, mesure après — et jamais elle ne commence par l'outil. « J'ai ajouté du memo » ou « j'ai mis du lazy loading » répond à une question qu'on ne t'a pas posée : on te demande un raisonnement, pas un nom de technique. L'honnêteté accompagnée d'une méthode passe toujours mieux qu'un exemple inventé, qui s'effondre à la question suivante.

Comment continuer à apprendre sans te disperser

Tu viens de lire une page pleine de noms. Le vrai danger, maintenant, n'est pas l'ignorance — c'est la dispersion. Voici quatre principes, dans l'ordre d'importance.

Un territoire à la fois. Le principe fondateur de l'Atlas, écrit noir sur blanc sur sa page d'accueil : une carte par territoire, couvert en entier. Trois semaines sur un sujet, jusqu'à pouvoir l'expliquer, valent mieux que trois jours sur six sujets. La raison est cognitive, pas morale : la compréhension profonde vient des liens entre les notions, et les liens ne se forment que si tu restes assez longtemps dans le même monde pour que les notions se rencontrent. Six survols produisent six collections de faits isolés, qui s'effacent en un mois.

Lis les documentations officielles, pas les tutoriels de troisième main. Le réflexe naturel est de chercher un article de blog, parce que c'est plus digeste. Le problème n'est pas la qualité, c'est la date. Exemple le plus parlant de ton stack : les comportements par défaut du cache de Next.js ont changé significativement d'une version majeure à l'autre — ce qui était mis en cache a cessé de l'être, des options ont été renommées, la façon d'invalider a évolué. Or Internet est un cimetière d'articles jamais corrigés : une bonne moitié des tutoriels enseignent, avec assurance, un modèle mental qui ne correspond plus au framework, et tu perdras des heures à déboguer un comportement que ton article décrivait comme normal.

La documentation officielle a trois avantages décisifs : mise à jour en même temps que le code, elle indique à partir de quelle version un comportement s'applique, et elle est écrite par ceux qui ont pris la décision — donc elle explique souvent le pourquoi. Les notes de version sont, dans le même esprit, une lecture étonnamment formatrice. Garde les tutoriels pour ce qu'ils font bien : donner une intuition initiale. Puis vérifie dans la doc.

Lis du code de vrais projets. Un projet réel montre ce qu'aucun tutoriel ne montre : les compromis. Le code de démonstration est propre parce qu'il n'a aucune contrainte ; le code réel porte les cicatrices de cas limites, d'urgences, de décisions prises avec un contexte incomplet. Y voir un contournement bizarre avec un commentaire qui l'explique t'apprend plus que dix exemples parfaits. Un fichier par semaine, lu à fond, avec la grille que tu connais : qu'est-ce qui entre, qu'est-ce qui sort, qui l'appelle, où s'exécute-t-il.

Et le signal qui dit que tu maîtrises vraiment : tu sais l'expliquer à quelqu'un d'autre. Pas le réciter — l'expliquer : choisir une analogie, anticiper la question qui vient, savoir dire où s'arrête ta certitude. Tant que tu ne peux qu'appliquer une recette, tu as un réflexe, pas une compréhension, et le réflexe casse dès que le contexte change. C'est exactement ce que teste une entrevue technique. Prends donc l'habitude d'expliquer — à un collègue, dans un carnet, à voix haute dans ta voiture. Le moment où tu bafouilles est l'endroit où tu ne sais pas encore.

⚠️ Piège fréquent

Empiler les bibliothèques par curiosité plutôt que pour résoudre un problème réel. Le piège classique du développeur enthousiaste, et cette page est une invitation à y tomber si tu la lis mal. Une bibliothèque d'état global « parce que c'est plus propre » alors que trois useState suffisaient, un moteur 3D pour un graphique en barres, une bibliothèque d'animation pour un fondu de 200 ms : chaque ajout coûte du poids téléchargé, une dépendance à maintenir, une mise à jour un jour douloureuse, et une notion de plus que le prochain lecteur devra connaître. La formule du module tranche à chaque fois : qu'est-ce que cet outil m'apporte que le niveau en dessous ne m'apportait pas ? Si tu ne peux pas répondre en une phrase, tu n'as pas le problème — seulement l'envie de l'outil.

Optimiser sans mesure est le même piège sous un autre costume : de la mémoïsation, du chargement différé, du découpage de bundle « parce que c'est mieux », sans avoir ouvert l'onglet Performance. On récolte du code plus complexe, parfois plus lent, et aucune preuve d'amélioration. Une optimisation sans un chiffre avant et un chiffre après n'est pas une optimisation : c'est une croyance, avec un coût de maintenance.

✅ À retenir

La question qui gouverne la carte : « qu'est-ce que cet outil m'apporte que le niveau en dessous ne m'apportait pas ? » Pas de réponse en une phrase = pas besoin de l'outil.
L'animation se lit en trois niveaux : le CSS seul (transitions, @keyframes), les bibliothèques d'interface (Motion, transitions de vue) pour l'entrée/sortie des composants, et GSAP pour la chorégraphie et le défilement. On ne monte que quand le précédent bute — et toute animation sérieuse honore prefers-reduced-motion et anime transform/opacity plutôt que la mise en page.
La 3D — WebGL/WebGPU, three.js, React Three Fiber — tient en cinq mots : scène, caméra, maillage, lumière, boucle de rendu. Investissement à part entière, avec un coût réel en apprentissage, poids, batterie et accessibilité.
GSAP et three.js auront chacun leur guide dans l'Atlas : le temps d'un côté, l'espace de l'autre.
Une donnée serveur n'est pas de l'état, c'est un cache (TanStack Query, SWR) — toujours utile après une interaction, même avec des Server Components.
Avant une bibliothèque d'état global : « est-ce vraiment global, ou juste mal placé ? » Zustand, que tu connais du mobile, s'utilise à l'identique côté web.
À l'échelle : comportement accessible sans style (Radix/shadcn), stratégie CSS assumée (Tailwind, CSS Modules), et surtout des tokens — les variables CSS, cousines des constantes de design de ton app mobile.
LCP, INP, CLS, mesurés avec Lighthouse et l'onglet Performance. Un chiffre avant, un chiffre après, sinon ce n'est pas une optimisation.
Pour continuer : un territoire à la fois, la doc officielle plutôt que les tutoriels périmés, du code de vrais projets — et le signal de maîtrise, savoir l'expliquer à quelqu'un d'autre.

Et ailleurs : ce que ces territoires ont en commun est ce que tu emportes vraiment. Le compositeur du navigateur et le fil natif de Reanimated : sortir le travail répétitif du chemin critique. Le cache par clé de TanStack Query et l'abonnement à la base locale de ton app mobile : ne jamais traiter comme un état une donnée dont on n'est pas propriétaire. Les variables CSS et les constantes de design : une décision, un endroit. « Mesurer avant d'optimiser » : ne change rien que tu ne puisses prouver. Quatre principes d'ingénierie, ni web ni mobile ni React. Les frameworks que tu apprendras dans dix ans n'existent probablement pas encore ; ceux-là, si.

Le mot de la fin

Tu as commencé ce guide en sachant lire du React côté mobile et pas grand-chose du web. Tu le termines en sachant ce qu'est le navigateur, ce que le HTML porte de sens, comment le CSS construit une page, comment on parle à un serveur, comment React se traduit d'un monde à l'autre, où s'exécute chaque ligne d'un projet Next.js, comment se lisent un formulaire et une suite de tests, et comment on critique du code sans se faire détester. Ce n'est pas de la culture générale : c'est le socle qu'on attend d'un stagiaire frontend.

Ce que cette dernière page ajoute, c'est de la perspective : il existe un pays de l'animation, un de la 3D, un du cache, un de la performance mesurée — et tu sais lequel t'attire. Deux d'entre eux t'attendent déjà dans l'Atlas, chacun avec sa carte, parce qu'un territoire se couvre en entier ou pas du tout.

En attendant, la meilleure chose à faire n'est pas de commencer un nouveau guide : c'est de reprendre celui-ci. La première lecture sert à découvrir, la seconde à relier — comment le HTML sémantique prépare l'accessibilité des formulaires, comment la frontière serveur/client explique la moitié des choix de Next.js, comment les tests décrivent ce que le code promet. Ce sont ces liens qui font un développeur, pas la liste des outils essayés.

Bonne route. On se retrouve dans le prochain territoire. 🗺️