Du mobile au web : lire ce guide

Tu as construit une app mobile complète en React Native. Maintenant tu vises des stages frontend web — et le web, tu ne l'as jamais vraiment touché de l'intérieur. Ce module 0 fait trois choses : il mesure honnêtement ce que tu sais déjà (beaucoup plus que tu ne crois), il nomme précisément ce qui te manque (moins que tu ne crains), et il t'explique comment ce guide est construit pour combler l'écart — en lecture pure, sur ton téléphone, pendant tes shifts.

Tu pars de plus loin que tu le crois

Commençons par l'inventaire, parce que le syndrome de l'imposteur adore les inventaires flous. Quand on ne sait pas précisément ce qu'on sait, on suppose qu'on ne sait rien. Alors soyons précis. En construisant Halterofit, tu as appris — pas survolé, appris, avec les heures de débogage qui prouvent que c'est rentré — un ensemble de compétences qui sont exactement celles qu'un stage frontend web demande.

React et TypeScript, d'abord. Les hooks que tu écris tous les jours sont les mêmes fonctions, importées du même paquet react ; les types, les unions, le tsconfig.json sont le même compilateur. React Native et React web partagent le moteur ; seule la sortie diffère — des vues natives d'un côté, des éléments HTML de l'autre. On détaillera cette frontière dans le module sur les ponts entre React web et React Native ; retiens l'ordre de grandeur : ça se transfère à peu près à 100 %.

L'asynchrone. async/await, les promesses, les appels Supabase qui peuvent échouer, les états de chargement : c'est précisément le cœur du travail frontend web — appeler un serveur, attendre, gérer l'erreur, afficher le résultat. Le module sur JS asynchrone du premier guide de l'Atlas — celui sur Halterofit — (JavaScript moderne & l'asynchrone) reste ta référence : on ne le réenseignera pas ici, on le rappellera.

Et même le routing. C'est le transfert le plus sous-estimé de ta trousse. Expo Router t'a appris le routage par fichiers : un fichier dans app/ devient un écran, un dossier devient un segment d'URL, un _layout enveloppe ses enfants. Or Next.js — le framework web dominant, celui que ce guide enseigne — utilise exactement le même modèle. Ce n'est pas une coïncidence : Expo Router a été explicitement conçu en s'inspirant de l'App Router de Next.js. Tu as appris la version mobile d'un concept né sur le web ; il ne te reste qu'à faire le voyage retour.

Fais le total : React, TypeScript, l'asynchrone, le routage par fichiers, la gestion d'état, la lecture de code. C'est environ 80 % du métier de frontend web qui est déjà dans tes mains. Le reste — les 20 % qui manquent — n'est pas plus difficile que ce que tu as déjà appris. C'est juste nouveau. Et c'est l'objet exact de ce guide.

Ce que React Native te cachait

L'autre moitié de l'inventaire : les trous. React Native est une abstraction — elle t'a permis de construire une app sans jamais toucher aux couches qu'elle recouvre. Cadeau pour avancer vite, angle mort pour viser le web. Voici ce qu'elle te cachait, dans l'ordre où ce guide va le découvrir.

Le navigateur et le DOM. Sur mobile, tes composants devenaient des vues natives iOS/Android, et tu n'as jamais eu à savoir comment. Sur le web, tes composants deviennent des nœuds du DOM — l'arbre d'objets que le navigateur construit à partir du HTML et qu'il redessine à chaque changement. Le DOM, les événements qui s'y propagent, la façon dont le navigateur transforme du texte en pixels : c'est le socle de tout, et c'est l'objet du module Le navigateur : DOM, événements, rendu.

Le HTML. Tu écrivais <View> et <Text> — deux briques, presque neutres. Le web en a plus d'une centaine, et elles portent du sens : <nav>, <button>, <form>, <label> disent au navigateur, aux moteurs de recherche et aux lecteurs d'écran ce que c'est, pas seulement à quoi ça ressemble. Choisir la bonne balise est une compétence en soi — et un sujet d'entrevue adoré, parce qu'il sépare instantanément ceux qui ont appris le web de ceux qui l'ont contourné. C'est le module HTML sémantique & accessibilité.

Le CSS réel. Avec StyleSheet et NativeWind, tu utilisais un sous-ensemble de CSS, dans un environnement simplifié où tout est flexbox et où les styles ne s'héritent presque pas. Le vrai CSS est plus vaste et plus subtil : la cascade, la spécificité, le modèle de boîte, grid, les media queries, les variables. C'est probablement ton plus gros trou, et c'est pour ça qu'il a droit à deux modules complets : CSS 1 — modèle de boîte & flexbox et CSS 2 — grid, responsive, variables.

HTTP vu de près. Tu as utilisé HTTP des centaines de fois — chaque appel Supabase en est un — mais toujours à travers un client qui te masquait les détails. Le web te demande de les connaître : méthodes (GET, POST…), codes de statut (200, 404, 500…), en-têtes, corps de requête, et l'API fetch à nu. C'est le module HTTP & fetch : parler au réseau.

Le rendu côté serveur. Voilà le territoire le plus exotique vu du mobile. Ton app tournait entièrement sur le téléphone ; une app Next.js, elle, s'exécute en partie sur un serveur avant même d'arriver dans le navigateur. Des composants qui tournent côté serveur, du HTML généré avant l'affichage, des données chargées sans useEffect : c'est le cœur conceptuel de Next.js moderne, et tout le groupe de modules Next.js (à partir de La carte de Next.js) y est consacré.

Relis cette liste : navigateur et DOM, HTML, CSS, HTTP, rendu serveur. Maintenant regarde le sommaire de ce guide dans la barre latérale. C'est la même liste, dans le même ordre. Ce guide n'est pas un tour d'horizon généraliste du web : il est taillé sur l'écart exact entre ce que ton parcours mobile t'a appris et ce qu'un stage frontend web attend. Chaque module bouche un trou précis, et aucun module ne te fait réapprendre ce que tu sais déjà. Les groupes « Qualité » et « Synthèse » de la fin ne bouchent pas un trou : ils arment l'objectif — tester, critiquer du code, puis passer l'entrevue.

Deux détails de l'ordre méritent d'être justifiés, parce qu'ils ne se devinent pas. Le CSS vient avant React côté web : le CSS est indépendant de React (il stylise du HTML, peu importe qui l'a produit), et apprendre les deux en même temps est la recette classique de la confusion — on ne sait plus si le comportement bizarre vient du style ou du composant. Les deux modules de formulaires viennent avant Next.js : c'est la partie de React qui diffère le plus entre mobile et web (<form>, la soumission, les événements natifs n'existaient pas dans ton app), et Next.js les suppose acquis — un Server Component qui reçoit les données d'un formulaire n'a aucun sens si le formulaire lui-même est flou.

La méthode de lecture, et les rubriques du guide

Le premier guide s'ouvrait sur un module de méthode (« Méthode pour lire le code »), et tout ce qu'il disait reste vrai ici, mot pour mot. Rappel express, parce qu'on s'en sert dès la première page de code web : on ne lit pas du code comme un roman, on survole d'abord, on plonge ensuite, dans un ordre fixe — les imports (de quoi ça dépend), les exports (ce que ça offre), les signatures (la forme des données), le survol des noms (la carte du fichier), puis un seul chemin concret tracé ligne à ligne, et enfin un nom posé sur le pattern reconnu. Quand tu te noies, c'est que tu as plongé dans les détails avant d'avoir fait la carte : remonte.

Cette méthode s'applique telle quelle aux fichiers web, avec un bonus : elle s'applique aussi à des choses qui ne sont pas du code. Un fichier HTML se survole par ses balises de structure avant de se lire balise par balise. Une feuille CSS se survole par ses sélecteurs avant de se lire propriété par propriété. Une réponse HTTP se survole par son code de statut et ses en-têtes avant qu'on ouvre son corps. Le mouvement « forme d'abord, détails ensuite » est universel, et tu l'as déjà.

Un mot sur ce que « apprendre en lisant » veut dire, parce que ce guide est de la lecture pure : la lecture unique ne suffit pas, et la familiarité vient de la re-lecture. La première fois, tu comprends sur le moment puis ça s'estompe — c'est le fonctionnement documenté de la mémoire, pas un défaut de la tienne. La deuxième fois, quelque chose s'accroche. La troisième, tu reconnais avant même de relire, et c'est là que le savoir devient disponible en entrevue sans effort de rappel. Relire n'est pas un échec de la première lecture ; c'est la méthode elle-même.

Les encadrés du premier guide reviennent tous (concept, piège, quiz, exercices de lecture à corrigé repliable). Trois rubriques s'y ajoutent, et elles structurent chaque module :

• 📖 La formule (encadré doré, un par module) isole LE patron canonique du module en dix à quinze lignes, sous un nom court. Chaque fois qu'il réapparaît plus loin, on te le rappelle — on n'apprend pas une formule en la lisant une fois, on finit par la reconnaître à force de la recroiser, comme un visage. Ta seule responsabilité : à chaque rappel, trois secondes pour la revoir mentalement.
• 🔗 Pont (cyan) relie explicitement la notion à autre chose : le premier guide, un module précédent, ou le principe général dont elle n'est qu'un cas particulier. Tu en as croisé un plus haut, sur Expo Router et l'App Router. Quand tu vois un pont, traverse-le : c'est là que la compréhension isolée devient un réseau.
• 🎤 En entrevue (rose) pose une ou deux questions telles qu'on te les poserait, avec une réponse repliable formulée comme à l'oral — pas une définition de manuel, une vraie réponse de candidat, avec une structure réutilisable. Le guide prépare l'entrevue en filigrane pour que le module final soit une synthèse, pas une découverte.

RendezVous, l'app-exemple qui traverse le guide

Le premier guide avait un avantage énorme : le code étudié était ton code. Ce guide-ci ne peut pas s'appuyer sur Halterofit pour le web — la vitrine Next.js n'existe pas encore. Il lui faut donc un fil rouge, et ce fil s'appelle RendezVous : une page de prise de rendez-vous pour une clinique. Une liste de services (consultation, suivi, examen…), un formulaire qui s'adapte au service choisi, une validation des champs, et l'envoi de la demande au serveur. Module après module, on la construira par couches : son HTML nu d'abord, puis son CSS, puis ses appels réseau, puis sa version React, puis sa version Next.js complète.

Pourquoi ce choix ? Parce que « une liste + un formulaire + un envoi au serveur » est LE format classique du test technique de stage frontend : affiche ces données, laisse l'utilisateur saisir quelque chose, envoie-le, gère les erreurs. Le trio couvre tout le métier en miniature — affichage, interaction, réseau. En suivant RendezVous, tu ne liras pas un exemple académique : tu liras, morceau par morceau, la solution-type de l'épreuve qu'on te fera passer. Le module d'étude de cas fermera la boucle en disséquant un vrai énoncé, avec les critères qu'un évaluateur regarde vraiment.

RendezVous est volontairement petite : pas d'authentification, pas de base locale, pas de synchronisation — rien de la machinerie d'Halterofit. La complexité de ton app mobile venait de son architecture offline-first ; ta difficulté sur le web ne sera pas architecturale, elle sera dans les fondations (DOM, CSS, HTTP). Une app-exemple simple leur laisse toute la place.

rendezvous/
├── app/
│   ├── layout.tsx
│   ├── page.tsx
│   ├── rendez-vous/
│   │   └── page.tsx
│   └── api/
│       └── demandes/
│           └── route.ts
├── components/
│   └── AppointmentForm.tsx
└── package.json

Ta première formule : la page web minimale

Puisque ce guide promet des formules, autant tenir la promesse dès ce module. Voici la toute première, la plus fondamentale de toutes : le squelette d'une page web. Chaque site que tu as visité dans ta vie est, au fond, ce squelette avec du contenu dedans. Et — c'est le plus important pour la suite — même Next.js finit par générer exactement ce squelette : tout l'appareillage de Server Components, de routing et de rendu aboutit, dans le navigateur, à ce document-là. Le web moderne n'a pas remplacé cette structure ; il a industrialisé sa production.

<!DOCTYPE html>                <!-- "ceci est du HTML moderne" -->
<html lang="fr">               <!-- racine du document -->
  <head>                       <!-- métadonnées : RIEN d'affiché ici -->
    <meta charset="UTF-8">     <!-- encodage des caractères (accents !) -->
    <title>RendezVous</title>  <!-- le titre de l'onglet -->
  </head>
  <body>                       <!-- tout ce qui est VISIBLE vit ici -->
    <h1>Prendre rendez-vous</h1>
    <script src="app.js" defer></script> <!-- le JS, chargé sans bloquer -->
  </body>
</html>

Ne cherche pas à la mémoriser ce soir. Tu vas la recroiser dans les modules Le navigateur : DOM, événements, rendu et HTML sémantique & accessibilité, puis en filigrane dans tous les autres ; à la troisième rencontre, elle sera à toi. Note simplement, dès maintenant, le petit mot defer sur la balise <script> : il dit au navigateur « télécharge ce script, mais attends que la page soit construite pour l'exécuter ». Ce détail d'apparence anodine cache toute la mécanique de chargement d'une page — et il te tend un premier exercice.

<head>
  <title>RendezVous</title>
  <script src="app.js"></script>  <!-- déplacé ici, sans defer -->
</head>
<body>
  <h1>Prendre rendez-vous</h1>
  <button id="reserver">Réserver</button>
</body>

Comment étudier sur ton téléphone

Ce guide est conçu pour tes conditions réelles : le téléphone, des fenêtres de lecture irrégulières, pas d'ordinateur pour « essayer ». Le mode d'emploi tire parti de ces conditions plutôt que de les subir, parce que la lecture répétée et espacée est précisément ce que ton rythme de shifts permet le mieux.

• Un module par shift, pas plus. Deux modules avalés retiennent moins qu'un module lu posément : la densité de ce guide est dans la profondeur, pas dans la vitesse de défilement.
• Relis le module précédent avant d'ouvrir le suivant — en survol : les titres, les encadrés, la formule, le « À retenir ». Cinq minutes. Cette relecture tombe au moment où ta mémoire commence à lâcher la notion, là où elle a le plus d'effet. Elle te dit aussi ce qui est acquis : si un titre ne t'évoque rien, c'est la section à relire.
• Réponds AVANT de déplier. Corrigés, quiz, réponses d'entrevue sont repliables exprès. Formule ta réponse — mentalement, ou à voix basse entre deux machines — puis ouvre. L'effort de chercher, même dix secondes, même en se trompant, ancre la notion bien mieux que la lecture passive : les chercheurs appellent ça l'effet de test.
• Reviens piocher. Ce guide est aussi un ouvrage de référence : la veille d'une entrevue, relis les encadrés « En entrevue » ; bloqué sur du CSS dans six mois, reviens au module sur le modèle de boîte. Un module relu six semaines plus tard, c'est une passe de répétition espacée gratuite.

L'état d'esprit : expliquer, pas mémoriser

Qu'est-ce que « réussir » ce guide veut dire ? Pas tout retenir : les entrevues de stage ne testent pas la mémoire encyclopédique, les recruteurs savent que la documentation existe. Ce qu'ils testent, c'est si le candidat comprend ce dont il parle — et il n'existe qu'un seul détecteur fiable de la compréhension : la capacité à expliquer.

Un concept que tu sais expliquer à voix haute, avec tes mots, sans relire, est acquis. Un concept que tu « reconnais en le lisant » mais que tu ne saurais pas raconter à un collègue est encore en chantier — il lui faut juste une relecture de plus. Le critère s'applique n'importe où, sans matériel : à la fin d'un module, demande-toi « est-ce que je pourrais expliquer ça à quelqu'un qui n'a jamais codé ? ». Si oui, avance ; sinon, tu sais quoi relire. Expliquer simplement est d'ailleurs plus exigeant qu'expliquer avec du jargon : le jargon peut masquer un flou, les mots simples jamais.

C'est aussi, très concrètement, le format de l'entrevue. « Peux-tu m'expliquer la différence entre X et Y ? » n'est pas une question piège : c'est LA question, sous cent variantes. Les encadrés « En entrevue » de ce guide te font répéter exactement ce geste — transformer une compréhension en explication orale structurée. À force, le geste devient naturel, et le jour venu, l'entrevue ressemblera à un exercice que tu as déjà fait dix-sept fois.