Les Bibliothèques au Cœur des Applications React Modernes

Une application React moderne repose essentiellement sur React lui-même, complété par un ensemble restreint et prévisible de bibliothèques : une pour la récupération des données serveur, une pour l’état client, une pour le routage, une pour le style, une pour les composants UI primitifs, et une pour les formulaires. React en lui-même — actuellement la ligne 19.2 — gère les composants, les hooks et le rendu. Tout le reste relève d’un choix, et l’évolution rapide de l’écosystème rend ces choix plus difficiles qu’ils ne le sont réellement. En pratique, pour chaque besoin, il existe désormais une option par défaut clairement établie, accompagnée d’une ou deux alternatives selon le contexte.

Cet article cartographie cette stack par besoin fonctionnel : fondations, gestion d’état, récupération de données, routage, style, UI, formulaires et animation. Pour chaque catégorie, vous trouverez le choix par défaut en 2026, les cas où une alternative s’impose, et la manière dont ce choix interagit avec deux forces qui reconfigurent l’écosystème — les React Server Components (RSC) et le React Compiler.

Les Fondations d’un Projet React : Choisir son Framework

Avant tout choix de bibliothèque, vous devez choisir la fondation sur laquelle votre application repose — et en 2026, cette décision est largement conditionnée par la question de savoir si vous souhaitez utiliser les React Server Components. Le besoin fonctionnel ici est le scaffolding du projet, l’outillage de build, le routage et la stratégie de rendu, regroupés en un seul point de départ.

Pour la plupart des nouvelles applications, Next.js est le choix par défaut : c’est le framework React full-stack le plus complet, avec RSC stable, les server actions et le routage basé sur les fichiers. Optez pour Vite lorsque vous construisez une application monopage rendue côté client et que vous souhaitez un build rapide et sans opinion particulière, sans framework complet — vous assemblez vous-même le routage et la récupération de données. Optez pour Astro lorsque le projet est orienté contenu — pages marketing, documentation, blogs — et que vous souhaitez livrer principalement du HTML statique avec des îlots React uniquement là où l’interactivité est nécessaire. Optez pour TanStack Start lorsque le routage type-safe et les fonctions serveur sont la priorité et que vous pouvez adopter une solution encore en cours de stabilisation : il est en Release Candidate v1, proche de la stabilité, avec le support RSC encore en développement.

Les deux forces à prendre en compte pour tous ces choix sont les React Server Components, qui déplacent la récupération de données vers le serveur, et le React Compiler, qui mémoïse automatiquement vos composants quelle que soit la fondation choisie.

Ce que le React Compiler Change dans vos Choix de Bibliothèques

Le React Compiler est désormais stable et modifie les optimisations que vous écrivez manuellement. React Compiler 1.0 a été livré le 7 octobre 2025, annoncé lors de React Conf, et mémoïse automatiquement les composants et les valeurs de hooks à la compilation, supprimant la majorité des appels manuels à useMemo et useCallback. Pour la sélection des bibliothèques, cela importe car une catégorie de code répétitif qui encombraient autrefois le code d’intégration — encapsulation des sélecteurs, mémoïsation des callbacks passés aux champs de formulaire, stabilisation des valeurs dérivées — est désormais prise en charge par le compilateur.

L’effet pratique sur le choix des bibliothèques : cette mémoïsation automatique affaiblit l’argument de performance en faveur des bibliothèques d’état atomique et supprime une catégorie de code répétitif dans les intégrations de formulaires. Vous choisissez donc les bibliothèques selon leur modèle de données et leur ergonomie, et non selon la quantité d’ajustements manuels nécessaires pour éviter les cascades de re-rendus. Le compilateur est supporté par Vite, Next.js et Expo, conformément à la documentation d’installation du React Compiler.

Bibliothèques de Gestion d’État React : La Taxonomie en Quatre Catégories

Les applications React modernes comportent quatre catégories d’état distinctes — l’état serveur géré par TanStack Query, l’état UI client géré par useState ou Zustand, l’état URL géré par nuqs, et l’état global applicatif dans Zustand — et choisir le mauvais outil pour une catégorie donnée est la source la plus fréquente de complexité inutile. La plupart des difficultés liées à la gestion d’état proviennent du stockage de données serveur dans un store client, ou de la modélisation d’un état UI partagé qui devrait se trouver dans l’URL comme état global.

Entre TanStack Query pour l’état serveur, les hooks natifs pour l’état local, et l’URL pour l’état UI partagé, la surface nécessitant un store global dédié a considérablement réduit. Lorsque vous en avez besoin, Zustand est le choix par défaut — un store create() minimal avec des abonnements par sélecteur et sans provider :

import { create } from 'zustand'

const useCartStore = create((set) => ({
  items: [],
  addItem: (item) => set((state) => ({ items: [...state.items, item] })),
}))

Choisissez Redux Toolkit lorsque vous maintenez ou étendez une base de code Redux existante et que vous souhaitez bénéficier du voyage dans le temps avec DevTools et du suivi structuré des actions. Choisissez Jotai lorsque vous avez réellement besoin d’abonnements atomiques à grain fin — bien qu’avec la mémoïsation automatique du React Compiler, l’argument des re-rendus en faveur du modèle atomique soit moins convaincant qu’auparavant. Pour l’état URL spécifiquement, nuqs vous offre des paramètres de recherche typés afin que les filtres et la pagination survivent au rechargement et se partagent facilement via un lien.

État serveur et la valeur par défaut de staleTime

Le staleTime de TanStack Query est à 0 par défaut, ce qui signifie que chaque montage de composant marque les données comme périmées et déclenche un rechargement en arrière-plan ; pour les données stables comme les menus de navigation ou les profils utilisateurs, définir staleTime à une valeur non nulle est le changement de configuration à fort impact que la plupart des applications n’effectuent jamais. La documentation sur les valeurs par défaut importantes l’explique clairement :

import { useQuery } from '@tanstack/react-query'

// staleTime par défaut à 0 → recharge à chaque montage.
// Définissez une valeur non nulle pour les données qui ne changent pas par vue.
const { data } = useQuery({
  queryKey: ['profile'],
  queryFn: fetchProfile,
  staleTime: 5 * 60 * 1000, // 5 minutes
})

Un mode d’échec courant en production consiste à laisser cette valeur par défaut en place : les replays de session d’applications gourmandes en données font souvent apparaître des cascades de rechargements en arrière-plan se déclenchant à chaque changement de route — un schéma difficile à attribuer à une seule ligne de configuration jusqu’à ce que vous observiez la séquence réseau se rejouer lors d’une vraie session utilisateur.

Bibliothèques React de Récupération de Données et de Routage

Pour la récupération de données, le choix par défaut dépend de l’endroit où vous effectuez la récupération. Pour la récupération côté client — mise en cache REST ou GraphQL, mises à jour optimistes, synchronisation en arrière-plan — TanStack Query est le choix par défaut ; dans un framework RSC comme Next.js 16, vous récupérez les données côté serveur dans des Server Components et les transmettez en tant que props, évitant ainsi entièrement une bibliothèque de récupération côté client. Choisissez Apollo Client lorsque vous êtes en mode GraphQL-first et que vous souhaitez un cache normalisé ; choisissez tRPC lorsque vous contrôlez à la fois le client et le serveur en TypeScript et que vous souhaitez une inférence de types de bout en bout sans couche de schéma.

Le routage suit la même logique serveur/client. Si vous utilisez un meta-framework, il gère le routage. En dehors de cela, React Router est la bibliothèque la plus utilisée ; elle propose à la fois un mode bibliothèque classique côté client et un mode framework complet avec loaders, actions et rendu serveur. Choisissez TanStack Router lorsque l’inférence de routes type-safe est une priorité — il est stable en v1 avec une inférence TypeScript de premier ordre pour les paramètres et la recherche.

TanStack Start — qui offre un routage basé sur les fichiers type-safe, des fonctions serveur et du SSR — approche la stabilité en tant que Release Candidate v1 ; selon la documentation TanStack Start, le support RSC est encore en développement, ce qui fait de Next.js 16 le choix full-stack le plus complet pour les équipes ayant besoin de RSC aujourd’hui. Suivez-le comme le nouveau venu à surveiller plutôt que comme le choix par défaut actuel.

Bibliothèques de Style React et Compatibilité RSC

La compatibilité RSC est désormais un filtre de premier ordre dans les choix de style. Les bibliothèques CSS-in-JS à l’exécution comme styled-components et Emotion injectent les styles dans le navigateur, ce qui entre en conflit avec le modèle React Server Components qui effectue le rendu côté serveur — ainsi, dans une application Next.js 16 utilisant RSC, Tailwind CSS v4 ou les CSS Modules sont les choix par défaut compatibles, et non le CSS-in-JS à l’exécution.

Tailwind CSS est le choix par défaut utility-first. La ligne v4 a déplacé la configuration dans le CSS via la directive @theme et embarque un moteur plus rapide, selon l’annonce de Tailwind v4. Un seul className suffit pour le style :

<h1 className="text-blue-700">{title}</h1>

Choisissez les CSS Modules lorsque vous souhaitez un CSS colocalisé et scopé sans avoir à apprendre un vocabulaire de classes utilitaires — ils n’ont aucune fuite et fonctionnent parfaitement avec RSC. Choisissez une option CSS-in-JS à la compilation comme vanilla-extract lorsque vous souhaitez des styles type-safe rédigés en TypeScript sans coût à l’exécution.

styled-components est en mode maintenance depuis mars 2025 et n’est pas recommandé pour les nouveaux projets, mais ce n’est pas un projet abandonné — il fonctionne toujours avec RSC derrière une limite 'use client' et a introduit un thème basé sur les variables CSS compatible RSC via createTheme dans sa version v6.4.

Le constat général reste valable : l’injection de styles à l’exécution entre en conflit avec le modèle de rendu serveur, de sorte que les approches utility-first ou à la compilation sont le choix le plus sûr dans les nouvelles applications RSC.

Bibliothèques UI React : Modèle de Dépendance vs. Modèle de Possession

La décision la plus importante dans la couche UI est architecturale : installer une bibliothèque de composants versionnée, ou posséder le code des composants en propre. Les bibliothèques de composants stylisés — MUI, Mantine, Chakra UI, Ant Design — vous offrent un design system soigné et personnalisable en tant que dépendance que vous mettez à jour au fil du temps. Le modèle de possession, popularisé par shadcn/ui, copie le code source des composants directement dans votre projet.

Le modèle copier-coller de shadcn/ui signifie que vous possédez intégralement le code des composants — il n’y a pas de dépendance versionnée à mettre à jour, pas de migration avec rupture de compatibilité, et aucune décision de design de l’auteur de la bibliothèque que vous ne pouvez pas outrepasser — ce qui est architecturalement différent d’installer MUI ou Mantine, et explique pourquoi il est devenu le choix par défaut pour les équipes construisant des design systems personnalisés sur Tailwind. Il a dépassé les 110 000 étoiles GitHub.

// Modèle de possession : Button réside dans votre dépôt, vous le modifiez directement.
import { Button } from '@/components/ui/button'

// Modèle de dépendance : Button provient d'un package versionné.
import { Button } from '@mui/material'

shadcn/ui construit ses composants sur des primitives headless, et la primitive par défaut est Radix. Selon la documentation shadcn/ui, Base UI a été ajouté comme primitive alternative officielle début 2026, mais Radix reste la valeur par défaut recommandée.

Radix est maintenu par WorkOS depuis son acquisition de Modulz en 2022, et certains développeurs perçoivent son rythme de publication comme ayant ralenti — contexte qui explique pourquoi Base UI (de l’équipe MUI) est apparu comme alternative — bien que shadcn/ui utilise toujours Radix par défaut, qui reste activement maintenu et open source sous licence MIT. Choisissez Base UI lorsque vous souhaitez des primitives issues de la lignée MUI/Floating UI et une flexibilité dans le moteur de style ; choisissez une bibliothèque entièrement stylisée comme Ant Design lorsque vous construisez des interfaces d’entreprise riches en données et que vous souhaitez des tableaux, formulaires et sélecteurs de dates prêts à l’emploi plutôt que de les assembler vous-même.

Bibliothèques React pour les Formulaires

React Hook Form est le choix par défaut pour les formulaires dans React moderne. Sa conception est non contrôlée : les champs s’enregistrent via des refs plutôt que de stocker chaque frappe dans l’état React, ce qui minimise les re-rendus par construction. Avec la validation gérée via des résolveurs de schéma, le couplage typique est React Hook Form associé à Zod pour la validation à l’exécution et les types inférés.

import { useForm } from 'react-hook-form'

const { register, handleSubmit } = useForm()

Selon la documentation React Hook Form, register connecte un champ au formulaire sans le rendre contrôlé. Avec la mémoïsation automatique du React Compiler, la mémoïsation manuelle des callbacks autrefois nécessaire dans le code d’intégration autour des gestionnaires de champs est supprimée, simplifiant davantage le câblage. Choisissez TanStack Form lorsque vous souhaitez une gestion entièrement type-safe d’un état de formulaire complexe et profondément imbriqué ; choisissez Conform lorsque vous construisez des formulaires à amélioration progressive autour des server actions. Formik et React Final Form sont pratiquement sans maintenance — évitez-les pour les nouveaux projets.

Un mode d’échec courant en production dans les formulaires est le re-rendu excessif causé par des inputs contrôlés qui mettent à jour l’état à chaque frappe. Le modèle non contrôlé produit moins d’événements d’état intermédiaires, ce qui se traduit dans les replays de session par des traces d’interaction plus nettes — moins de rendus redondants entre la saisie de l’utilisateur et la soumission du formulaire.

Bibliothèques React d’Animation

Motion est la bibliothèque d’animation de facto pour React. Motion — la bibliothèque anciennement connue sous le nom de Framer Motion — utilise le nom de package motion et le chemin d’import motion/react, a atteint sa version majeure v12 avec un support complet de React 19, et enregistre environ 30 millions de téléchargements npm par mois.

L’API déclarative couvre la plupart des besoins des applications avec les props initial et animate :

import { motion } from 'motion/react'

<motion.div initial={{ opacity: 0 }} animate={{ opacity: 1 }} />

Selon la documentation Motion, elle couvre les gestes, les transitions de mise en page et AnimatePresence pour les animations de sortie. Une note sur l’accessibilité : respectez la media query prefers-reduced-motion, que MDN documente comme le signal standard indiquant qu’un utilisateur souhaite minimiser les animations — Motion vous permet de la lire et de conditionner les animations en conséquence. Choisissez react-spring lorsque vous souhaitez une animation à ressort basée sur la physique comme modèle central ; choisissez GSAP lorsque vous avez besoin d’une orchestration précise de timelines sur de nombreux éléments.

Compléments Essentiels : Auth, Tests, Graphiques et i18n

Au-delà de la stack principale, quelques catégories complètent la plupart des applications — avec un choix par défaut sensé pour chacune :

• Authentification : Auth.js
• Tests : Vitest pour les tests unitaires, Playwright pour les tests de bout en bout
• Graphiques : Recharts
• Internationalisation : i18next

Chacun est un sujet approfondi en soi ; considérez-les comme des points de départ et suivez la documentation à partir de là.

La Stack React 2026 en un Coup d’Œil

Pour une application Next.js 16 aujourd’hui, les choix par défaut compatibles s’alignent par besoin fonctionnel :

Conclusion

L’évolution rapide de l’écosystème est bien réelle, mais l’espace de décision est restreint : choisissez la bonne catégorie pour votre état, récupérez les données côté serveur lorsque votre framework le permet, adoptez Tailwind et shadcn/ui par défaut pour la couche UI, et utilisez Motion et React Hook Form pour l’animation et les formulaires. Les deux changements à intérioriser dès maintenant sont que le React Compiler supprime la majorité de la mémoïsation manuelle de votre code d’intégration, et que la compatibilité RSC est un filtre impératif — le CSS-in-JS à l’exécution et le support RSC encore instable limitent ce qui convient à une application Next.js 16. Partez de ces valeurs par défaut, puis adoptez une alternative uniquement lorsqu’une exigence spécifique — GraphQL à grande échelle, routage type-safe, animation physique — le justifie réellement.

FAQ

Puis-je utiliser styled-components avec les React Server Components ?

styled-components fonctionne avec les React Server Components uniquement derrière une limite 'use client', car il injecte les styles à l'exécution dans le navigateur, ce qui entre en conflit avec le modèle de rendu serveur des RSC. La bibliothèque est entrée en mode maintenance en mars 2025 et n'est pas recommandée pour les nouveaux projets, bien qu'elle publie encore des versions et ait ajouté un thème basé sur les variables CSS compatible RSC. Pour les nouvelles applications RSC, Tailwind CSS v4 ou les CSS Modules sont les choix par défaut compatibles, car les deux produisent des styles à la compilation plutôt qu'à l'exécution.

Quelle est la différence entre le modèle de possession de shadcn/ui et l'installation d'une bibliothèque comme MUI ?

shadcn/ui copie le code source des composants directement dans votre projet, de sorte que vous possédez et modifiez les fichiers en propre, sans dépendance versionnée à mettre à jour et sans migration avec rupture de compatibilité. MUI et Mantine s'installent en tant que packages versionnés que vous importez et mettez à jour au fil du temps, échangeant le contrôle de la personnalisation contre des mises à jour gérées. Le modèle de possession convient aux équipes construisant des design systems personnalisés qui souhaitent un contrôle total sur les modifications ; le modèle de dépendance convient aux équipes qui souhaitent un design system soigné et maintenu sans posséder le code.

Quand devrais-je utiliser Zustand plutôt que useState pour l'état client ?

Utilisez Zustand lorsque l'état doit être partagé entre des composants distants qui n'ont pas de relation parent-enfant directe, comme un panier d'achat, un thème ou des données de session accessibles depuis de nombreux endroits. Utilisez useState ou useReducer pour l'état local à un composant ou à un petit sous-arbre, comme les brouillons de formulaires et les bascules. Recourir à Zustand pour un état purement local ajoute de l'indirection sans bénéfice, tandis que maintenir un état véritablement global dans le prop drilling ou le contexte crée des problèmes inutiles de re-rendu et de couplage.

Le React Compiler remplace-t-il TanStack Query ou une bibliothèque de gestion d'état ?

Non. React Compiler 1.0, stable depuis le 7 octobre 2025, mémoïse automatiquement les composants et les valeurs de hooks à la compilation, supprimant la majorité des appels manuels à useMemo et useCallback, mais il ne gère pas la mise en cache de l'état serveur, le rechargement en arrière-plan, ni le partage d'état entre composants. Vous avez toujours besoin de TanStack Query pour l'état serveur et de Zustand ou useState pour l'état client. Le compilateur modifie la quantité d'ajustements manuels que ces intégrations requièrent, pas la nécessité des bibliothèques elles-mêmes.