React existe depuis 2013 et reste la bibliothèque frontend la plus demandée sur les offres d'emploi françaises. Les ressources pour l'apprendre se comptent par milliers : vidéos, cours payants, documentation officielle réécrite, réponses d'assistants IA.
Entre cette abondance et un composant qui affiche une liste de produits filtrée, il y a un chemin. Ce chemin n'est jamais décrit dans les ressources elles-mêmes, parce que chacune commence là où elle commence, sans dire ce qu'elle suppose déjà acquis.
Une roadmap React n'est donc pas une liste de mots à cocher. C'est un ordre de passage, avec des dépendances : certaines notions ne veulent rien dire tant qu'une autre n'est pas en place, et beaucoup d'abandons viennent d'une brique abordée trois étapes trop tôt.
Voici cinq paliers, ce qu'on installe à chacun, le code minimal qui prouve que le palier est franchi, et ce qu'on laisse volontairement de côté jusqu'au suivant.
Le problème : les roadmaps donnent une liste, pas un ordre
Ouvre une roadmap React trouvée en ligne. Elle contient une trentaine d'items : JSX, hooks, Context, Redux, React Query, Next.js, tests, Server Components, React Compiler, Zustand, Suspense. Tout est vrai, tout est utilisé quelque part en production, et rien n'indique lequel sert le premier mois.
Le résultat se voit en formation : quelqu'un connaît le nom de six bibliothèques de gestion d'état et bloque sur un événement onChange qui ne met pas à jour son champ de saisie. Le vocabulaire a été accumulé, le socle non.
Les assistants IA amplifient l'effet. Une question sur un formulaire React renvoie souvent une réponse qui embarque une bibliothèque de formulaires, un schéma de validation et un gestionnaire d'état global. Le code fonctionne, personne n'a rien appris, et la version suivante casse sans qu'on sache où regarder. Le même mécanisme est décrit dans notre article sur comment garder le contrôle de son code face à un assistant.
Une deuxième source de perte, plus discrète : les tutoriels périmés. React Router a publié sa version 8 le 17 juin 2026, et le paquet react-router-dom n'existe plus. Or à peu près tous les tutoriels en ligne commencent encore par l'installer. Le premier import échoue, sans message utile pour un débutant.
Le principe : chaque brique arrive quand elle devient nécessaire
React répond à une question précise : comment garder une interface synchronisée avec des données qui changent, sans manipuler le DOM à la main. Toutes les notions qui suivent existent parce qu'une version naïve de cette réponse finit par coincer quelque part.
D'où la règle d'ordre : on n'apprend un outil qu'après avoir rencontré le problème qu'il résout. Un routeur après avoir eu besoin de deux pages. Une bibliothèque de cache après avoir écrit trois fois le même appel réseau. Un gestionnaire d'état global après avoir fait descendre une même valeur sur quatre niveaux de composants.
Cet ordre a un effet secondaire agréable : chaque outil devient facile à comprendre, parce que le manque était déjà installé.
Palier 1 : le JavaScript qui manque le premier jour
La majorité des blocages étiquetés React sont des blocages JavaScript. Un composant qui n'affiche rien parce que la fonction fléchée renvoie undefined, une liste vide parce que map a été confondu avec forEach, un objet écrasé parce que la copie était superficielle.
La liste utile est courte, et volontairement plus courte qu'un cours complet de JavaScript :
- fonctions fléchées et retour implicite
map,filter,findet ce que chacune retourne- destructuration d'objets et de tableaux
- opérateur de décomposition pour copier sans modifier l'original
- modules ES :
importetexport - promesses et
async / await - gestion d'erreur avec
try / catch
Deux à trois semaines suffisent en général pour que ces notions cessent de surprendre, à condition de les écrire plutôt que de les lire. Si ce socle est encore fragile, la formation JavaScript fondamentaux couvre ce périmètre avant d'aborder un framework.
Palier 2 : le socle React, et rien d'autre
Cinq notions couvrent la quasi-totalité du code React écrit au quotidien : le JSX, les composants, les props, l'état local, le rendu de listes. Tout le reste s'ajoute par-dessus.
Le composant ci-dessous tient en dix lignes et contient déjà quatre de ces cinq notions.
import { useState } from "react";
export default function Panier() {
const [total, setTotal] = useState(0);
return (
<button onClick={() => setTotal(total + 1)}>
Articles ajoutés : {total}
</button>
);
}
Le point à retenir à ce stade tient en une phrase : on ne modifie jamais une variable d'état directement, on appelle la fonction de mise à jour, et React refait le rendu. Tant que ce réflexe n'est pas installé, la suite ne tient pas.
Vient ensuite la remontée d'état, qui pose plus de difficultés que les hooks eux-mêmes. Quand deux composants frères ont besoin de la même donnée, cette donnée remonte dans leur parent commun et redescend en props. Ce geste est le fondement de toute architecture React, et il s'apprend en le pratiquant sur une petite application, pas en lisant un schéma.
useEffect arrive en fin de palier, avec une consigne stricte : il sert à synchroniser avec quelque chose d'extérieur à React, pas à recalculer une valeur qui dérive déjà de l'état. Une valeur dérivée se calcule pendant le rendu, sans hook.
Ce que ce palier laisse volontairement de côté : Redux, Zustand, Context, Server Components, Suspense, React Compiler. Aucun de ces outils ne rendra un composant à état local plus lisible.
Palier 3 : l'outillage, et l'état réel des versions
Ce palier crée beaucoup de confusion, parce que la documentation lue en 2026 contredit la moitié des tutoriels indexés par Google. Voici l'état des lieux au moment où ces lignes sont écrites, en août 2026.
Create React App est déprécié depuis le 14 février 2025. L'équipe React recommande désormais soit un framework, soit un outil de build comme Vite. Vite 8 est stable depuis le 12 mars 2026 et remplace ses deux moteurs historiques par un bundler unique écrit en Rust, avec des builds nettement plus rapides.
React 19 est la version majeure courante. La série de correctifs a continué tout au long de 2026, avec la 19.2.8 publiée le 21 juillet 2026. Aucune version 20 n'a été annoncée.
TypeScript entre à ce palier, jamais avant. Ajouter des types à un moment où les composants eux-mêmes sont encore flous double la charge cognitive. Une fois le socle acquis, TypeScript devient un filet plutôt qu'une contrainte, et il est attendu sur la plupart des offres React. Notre article sur les erreurs de typage qui révèlent un mauvais design détaille les réflexes à prendre dès le début.
Palier 4 : le routage, avec le piège de version le plus coûteux
React ne gère pas les URL. Une application React sans routeur vit à une seule adresse, sans bouton retour utilisable ni lien partageable.
React Router reste le choix par défaut, avec la plus grande part de l'écosystème. Sa version 8 change une chose que tout tutoriel antérieur ignore : le paquet react-router-dom a été retiré. Les imports se font depuis react-router, et depuis react-router/dom pour les API spécifiques au navigateur.
// Tutoriels d'avant juin 2026
import { Link, useLocation } from "react-router-dom";
// React Router v8
import { Link, useLocation } from "react-router";
import { RouterProvider } from "react-router/dom";
La version 8 impose aussi des versions plancher, listées dans le guide de mise à jour officiel : Node 22.22 ou supérieur, React et React DOM en 19.2.7 ou supérieur, et Vite 7 ou supérieur pour le mode framework. Un projet lancé sur une vieille version de Node échouera à l'installation avec un message qui ne dit rien de tout ça.
TanStack Router existe comme alternative, orientée typage de bout en bout des routes et des paramètres d'URL. Elle mérite un regard une fois TypeScript maîtrisé, sur un projet où les erreurs viennent surtout de liens cassés et de paramètres invalides. Pour un premier parcours, un seul routeur suffit.
Palier 5 : les données distantes
Une application qui affiche des données réelles doit gérer quatre situations : le chargement, l'erreur, le succès, et le cas où la donnée est déjà connue. Écrire ça à la main dans chaque composant produit rapidement du code copié et des bugs de course entre deux requêtes.
La première fois, écris-le à la main avec fetch et useEffect, sur un seul écran. La deuxième fois, passe à une bibliothèque de cache. TanStack Query est le standard de fait sur ce terrain.
import { useQuery } from "@tanstack/react-query";
function Factures() {
const { data, isPending, error } = useQuery({
queryKey: ["factures"],
queryFn: () => fetch("/api/factures").then((r) => r.json()),
});
if (isPending) return <p>Chargement</p>;
if (error) return <p>Erreur de chargement</p>;
return (
<ul>
{data.map((facture) => (
<li key={facture.id}>{facture.numero}</li>
))}
</ul>
);
}
La distinction que ce palier installe pour de bon : l'état serveur, qui appartient à une base de données distante et qui peut devenir périmé, ne se gère pas comme l'état client, qui appartient à l'interface. Un panneau replié, un onglet actif, un champ en cours de saisie relèvent du second. Une liste de factures relève du premier.
Une fois cette séparation faite, la question du gestionnaire d'état global devient beaucoup plus petite. Beaucoup d'applications qui installaient Redux pour stocker des réponses d'API n'en ont plus besoin du tout.
Les pièges qui coûtent des semaines
Commencer par Next.js
Next.js ajoute le rendu serveur, le routage par fichiers et les Server Components par-dessus React. Quand une erreur survient, il faut savoir si elle vient de React, du framework ou de la frontière entre les deux, et ce tri est impossible sans le socle React. Le sujet mérite son propre parcours, décrit dans notre roadmap développeur Next.js.
Installer un gestionnaire d'état global au premier projet
Redux, Zustand ou Context résolvent un problème de distance entre composants. Sur une application de trois écrans, cette distance n'existe pas encore, et l'outil ajoute des fichiers sans rien simplifier.
Copier un tutoriel sans vérifier sa date
Le frontend bouge vite et les moteurs de recherche remontent volontiers des contenus de 2022. Avant de suivre un guide, regarde la date de publication et compare les numéros de version avec la documentation officielle du paquet concerné.
Optimiser avant d'avoir mesuré
Envelopper des composants dans des mémoïsations manuelles sans avoir observé un ralentissement produit du code plus difficile à lire, pour un gain souvent nul. Le React Compiler prend d'ailleurs ce travail en charge automatiquement depuis sa version stable.
Enchaîner les projets sans jamais en finir un
Un projet terminé, déployé et lisible pèse plus lourd qu'une série de clones abandonnés au troisième écran. C'est aussi ce qui remplit un portfolio, comme détaillé dans notre article sur le premier projet pour un CV de développeur junior.
Laisser l'assistant IA écrire le code d'apprentissage
Un assistant est excellent pour expliquer un message d'erreur ou relire une implémentation déjà écrite. Lui faire produire le composant à ta place pendant la phase d'apprentissage supprime exactement l'effort qui construit la compétence. La lecture de code reste utile, mais elle ne remplace pas l'écriture, ni la capacité à retrouver seul la cause d'un bug.
Un ordre, pas un calendrier
Les durées annoncées dans les roadmaps en ligne varient du simple au quintuple et dépendent surtout du temps réellement disponible chaque semaine. L'ordre, lui, tient : chaque palier suppose le précédent, et sauter une marche se paie plus tard, avec intérêts.
Le signal de passage d'un palier au suivant est simple à observer : quand une gêne apparaît et qu'elle porte un nom, l'outil qui la résout devient lisible en une lecture de documentation.
Pour un parcours encadré sur ces paliers, la formation React de LaPolaris couvre du socle jusqu'aux données distantes, et la formation fullstack React et Symfony prolonge côté serveur. Si le choix entre frontend, backend et fullstack n'est pas encore tranché, l'article sur quelle voie choisir quand on débute pose les critères.