Le choix entre les hooks React et Redux est une question de périmètre, pas de qualité. Utilisez les hooks React pour l'état local à un composant, ainsi que pour les petites valeurs partagées comme le thème ou la langue. Tournez-vous vers Redux lorsque plusieurs fonctionnalités indépendantes dépendent des mêmes données, lorsque plus de cinq développeurs travaillent sur la base de code, ou lorsque vous avez besoin d'un historique traçable de chaque modification. La plupart des applications en production finissent par utiliser les deux, à des niveaux différents.
Considérez l'état comme l'eau dans un bâtiment. Les hooks sont les robinets dans chaque pièce, au plus près de l'utilisation. Redux est le réseau principal, les vannes de pression et le compteur qui vous indique précisément qui a fait couler un bain à 3 heures du matin.
Même substance. Rôles très différents. Voilà tout l'argument, et tout ce qui suit n'est que la démonstration.
L'architecture de l'état est l'un des rares choix frontend dont les effets se cumulent. Si vous choisissez une structure trop légère, vous le paierez en temps d'intégration et en bugs impossibles à reproduire. Si vous en choisissez une trop lourde, vous le paierez en code répétitif inutile.
C'est l'asymétrie qui est intéressante. Le sur-ingénierie vous coûte quelques semaines perdues, et vous le ressentez immédiatement. La sous-ingénierie vous coûte des trimestres de baisse de vélocité silencieuse, et vous ne vous en rendez compte que lorsque votre équipe a grandi au point où une réécriture n'est plus une option simple.
Il s'agit donc d'une question de CTO déguisée en préférence de développeur. Nous avons structuré chaque section technique ci-dessous en fonction des risques de livraison associés, car c'est ce qui finit par impacter votre roadmap.
Les hooks React permettent de gérer l'état et le cycle de vie au sein des composants fonctionnels, sans avoir recours aux classes. Introduits avec React 16.8, ils ont été conçus pour réduire la complexité des composants en facilitant le partage de logique.
Le véritable avantage réside dans les hooks personnalisés. Extrayez les comportements que vous utilisez à plusieurs endroits et évitez de les réécrire.
// useDebouncedValue.js
import { useEffect, useState } from 'react';
export function useDebouncedValue(value, delay = 300) {
const [debounced, setDebounced] = useState(value);
useEffect(() => {
const timer = setTimeout(() => setDebounced(value), delay);
return () => clearTimeout(timer);
}, [value, delay]);
return debounced;
}
Le revers de la médaille : les hooks n'imposent aucune convention. L'emplacement de l'état partagé devient une décision arbitraire prise par chaque développeur, sans aucune formalisation dans les outils. C'est une liberté appréciable à deux développeurs, mais coûteuse à dix.
Redux est une bibliothèque permettant de gérer l'état global d'une application. Un seul store, une méthode rigoureuse pour le modifier et des outils qui surveillent chaque changement en temps réel.
La documentation officielle énonce trois principes :
Redux propose également ses propres hooks, useSelector et useDispatch, permettant aux composants fonctionnels de lire le store sans avoir recours à des classes. (Il s'agit de la liaison react-redux, et oui, elle est indispensable : plus d'informations à ce sujet dans la FAQ.)
Ce que la cérémonie vous apporte :
Le coût : le temps de configuration, le code répétitif et une courbe d'apprentissage pour les nouveaux utilisateurs. Redux Toolkit réduit considérablement ces trois aspects, et c'est aujourd'hui la méthode officiellement recommandée pour utiliser Redux.
Redux est une bibliothèque de gestion de l'état global d'une application. Elle propose divers outils qui nous aident, en tant que développeurs, à suivre l'état de l'application et à le transformer en permettant à l'utilisateur d'émettre des actions.
Redux, comme l'indique sa documentation, repose sur trois principes fondamentaux :
Redux a même mis à jour la bibliothèque avec ses hooks personnalisés. Ceux-ci peuvent être utilisés pour intégrer les composants qui utilisent le Hooks React fonctionnalités permettant d'accéder aux données du store et de déclencher des actions sans dépendre des classes de composants.
Maintenant que nous sommes un peu plus familiers avec Redux et Hooks React voyons la différence entre eux.
La plupart des articles sur ce sujet partent du principe que vous en maîtrisez déjà le langage. C'est précisément cette supposition qui entretient le flou ; voici donc le vocabulaire expliqué simplement.
L'état (State) désigne toute donnée qui évolue dans le temps et influence ce que voit l'utilisateur. Un champ de formulaire. Un utilisateur connecté. Un panier.
Un réducteur (reducer) est une fonction qui prend l'état actuel et une action, puis renvoie un nouvel état sans modifier l'original. Il rend chaque changement explicite et traçable.
Une fonction pure produit toujours le même résultat pour une même entrée et ne modifie rien en dehors d'elle-même. Pas d'appels réseau, pas d'écriture dans des variables externes. Les réducteurs doivent être purs, car c'est ce qui rend les changements d'état reproductibles et testables.
Émettre (ou dispatcher) une action consiste à décrire un changement sous forme d'objet simple plutôt que de l'effectuer directement. Vous ne modifiez pas le panier. Vous dispatchez { type: 'basket/itemAdded', payload: item } et laissez le réducteur déterminer le résultat.
Fournisseur (provider) et consommateur (consumer) sont les deux facettes de l'API Context de React. Le fournisseur détient une valeur et la met à disposition de tous les éléments situés en dessous dans l'arborescence. Le consommateur est tout composant qui la lit.
Un sélecteur est une petite fonction qui extrait une partie spécifique du store, comme state => state.basket.total. La souscription basée sur les sélecteurs signifie qu'un composant ne se re-rend que lorsque sa partie spécifique est modifiée.
Rayon d'impact (blast radius) désigne l'ensemble des composants qu'un changement d'état force à se re-rendre. Plus il est petit, mieux c'est.
Un thunk est une fonction que vous déclenchez à la place d'une action simple, ce qui vous permet d'exécuter des tâches asynchrones (généralement un appel API) avant de déclencher l'action réelle.
RTK Query est la couche de récupération et de mise en cache des données intégrée à Redux Toolkit. Elle gère les données serveur, évitant ainsi d'avoir à les stocker manuellement dans votre store.
Context a été conçu pour des valeurs qui changent rarement. Il ne dispose d'aucun mécanisme de sélection. Par conséquent, lorsqu'une valeur de fournisseur change, chaque consommateur situé en dessous est re-rendu, y compris les composants qui n'utilisent pas la partie modifiée.
Revenons à la plomberie. Context est un immense tuyau qui alimente tout l'immeuble. Ouvrez un robinet au troisième étage et toutes les pièces du bâtiment en subissent les secousses.
Pour un changement de thème, peu importe. Mais pour un contexte contenant l'utilisateur actuel, un panier, un flux de notifications en direct et un panneau de filtres, c'est une catastrophe. Une simple frappe dans le champ de filtre déclenche le re-rendu de la liste des notifications.
Les équipes s'en rendent généralement compte trois mois avant le lancement, une fois que les solutions de contournement se sont accumulées. Et ces solutions représentent le véritable coût : diviser un contexte en six, mémoriser les valeurs des fournisseurs, envelopper les consommateurs dans React.memo, restructurer l'arborescence pour limiter les dégâts.
Chacune de ces mesures se justifie individuellement. Mais ensemble, elles forment un gestionnaire d'état sur mesure et non documenté qu'un seul ingénieur comprend, et dont la maintenance coûte plus cher que la bibliothèque que l'on cherchait à éviter. C'est le chemin tout tracé vers la dette technique.
Redux évite cela par conception. Grâce aux sélecteurs, l'impact des mises à jour est limité à ce qu'un composant lit réellement.
useReducer est destiné aux composants dotés d'une logique interne complexe. Un formulaire en plusieurs étapes. Un assistant. Une grille de données gérant le tri, le filtrage et la pagination. Là où useState vous laisse avec cinq fonctions de mise à jour interdépendantes, un reducer vous offre une fonction de transition unique et cohérente.
const initialState = { status: 'idle', items: [], error: null };
function feedReducer(state, action) {
switch (action.type) {
case 'FETCH_STARTED':
return { ...state, status: 'loading', error: null };
case 'FETCH_SUCCEEDED':
return { status: 'ready', items: action.payload, error: null };
case 'FETCH_FAILED':
return { ...state, status: 'error', error: action.payload };
default:
return state;
}
}
const [state, dispatch] = useReducer(feedReducer, initialState);
Il prend en entrée le reducer et l'état initial, et renvoie l'état actuel ainsi qu'une fonction dispatch . Ne modifiez jamais l'état directement. Envoyez une action, toujours structurée sous forme d'objet avec un type (ce qui s'est passé) et un payload (les données nécessaires à la modification).
Alors, useReducer peut-il remplacer Redux ? Au niveau d'un composant, la question ne se pose jamais vraiment, car c'est tout simplement l'outil approprié.
Cependant, si vous l'utilisez pour gérer un état global via le contexte, vous obtenez la structure de Redux sans aucune de ses infrastructures. Vous finirez par reconstruire des abonnements basés sur des sélecteurs, des middlewares pour les tâches asynchrones et des outils de débogage. À partir de zéro. Un mardi, en plein milieu d'un sprint qui était censé se concentrer sur le produit.
Cette reconstruction a un coût, et ne figure sur la feuille de route de personne. La frontière se situe au niveau de la portée, pas de la complexité.
À vrai dire, pour la plupart des nouveaux projets, la comparaison ne se résume plus à un simple duel. Zustand est devenu le challenger par défaut, et faire semblant du contraire revient à vous offrir un faux choix.
Zustand est un store minimaliste. Vous créez un état, vous le consommez via un hook. Pas de provider, quasiment pas de code répétitif et, surtout, des abonnements basés sur des sélecteurs prêts à l'emploi, ce que le contexte natif ne peut pas vous offrir.
Selon l' enquête State of React 2025, Redux et Redux Toolkit restent les solutions de gestion d'état les plus répandues, mais Zustand gagne rapidement du terrain et arrive en tête de la catégorie en termes de satisfaction utilisateur, au point que les auteurs de l'enquête le considèrent comme le leader du secteur. La même étude note qu'une grande partie des répondants n'utilise aucune bibliothèque de gestion d'état, car useState et useContext suffisent amplement pour leurs besoins.
Une décision, pas une tendance :
Une mise en garde, et c'est la plus importante. La plupart des problèmes que les équipes cherchent à résoudre avec un store concernent l'état du serveur, c'est-à-dire les réponses API en cache. Cela doit être géré par TanStack Query ou SWR, et non dans un store client. Réglez ce point en priorité et, le plus souvent, la décision restante deviendra beaucoup plus simple.
La plupart des comparaisons éludent la question par un « ça dépend ». Voici ce que nous utilisons réellement lors de l'audit ou du lancement d'une base de code React. Deux axes : la complexité de l'application, c'est-à-dire le nombre de fonctionnalités partageant les mêmes données, et la taille de l'équipe, c'est-à-dire le nombre d'ingénieurs modifiant ces données.
Les quatre mêmes règles, en texte, car les images passent mal :
Et voici ce qui surprend les gens. La taille de l'équipe, et non la complexité de l'application, est le prédicteur le plus fiable. Une application réellement complexe maintenue par deux ingénieurs qui partagent le même modèle mental fonctionne parfaitement avec les hooks. Une application simplement fastidieuse maintenue par neuf ingénieurs répartis en trois équipes ne fonctionne pas, et ce n'est pas parce que le code ne peut pas l'exprimer. C'est parce que neuf personnes ne peuvent pas garder une convention non documentée en tête simultanément.
Imaginez un produit passant de deux à dix ingénieurs en quelques trimestres.
À deux, l'approche « hooks uniquement » est optimale. L'état partagé réside dans trois contextes, les conventions ne sont pas écrites car les deux ingénieurs les ont créées, et le déploiement est rapide. Redux serait un poids mort.
À dix, cette même architecture se retourne contre vous. L'intégration passe de quelques jours à plusieurs semaines, car il n'y a pas de réponse canonique à la question « où vivent ces données », seulement des précédents.
Deux ingénieurs résolvent le même problème de re-rendu indépendamment, de manières incompatibles.
Déboguer un incident en production revient à reconstruire l'état en lisant le code, faute de journal d'actions. La vélocité chute, sans qu'une décision unique n'en soit la cause.
Le compromis ne se situe donc pas entre code répétitif et élégance. Il s'agit d'un coût payé immédiatement contre un coût payé à grande échelle, avec des intérêts.
L'erreur est toutefois réciproque. Adopter Redux pour un MVP à deux ingénieurs représente un coût réel sans retour sur investissement. L'indicateur à surveiller n'est pas le nombre de lignes de code. C'est le jour où votre équipe ne parvient plus à expliquer « pourquoi ce re-rendu a eu lieu » sans ouvrir un débogueur.
La migration inverse est de plus en plus courante, généralement lorsque le store Redux s'avère n'être qu'un cache de données serveur déguisé.
useReducer, ou un seul store Zustand.
Les équipes constatent régulièrement que l'étape 2 suffit à clore le débat. Le problème n'a jamais été Redux. C'était l'utilisation d'un gestionnaire d'état client comme cache réseau.
Vous souhaitez approfondir le sujet ? Nos guides sur le choix d'une stack technique et les modèles JavaScript asynchrones couvrent l'architecture fondamentale liée à ce thème.
Redux est une bibliothèque open-source destinée à la gestion de l'état global dans les applications JavaScript, le plus souvent avec React. Elle centralise l'état partagé dans un objet unique appelé « store », et ne permet de le modifier qu'au travers d'actions envoyées à des fonctions pures appelées « reducers ». Le nom en dit long : les changements d'état sont réduits en un flux unique et prévisible.
Utilisez les hooks pour l'état local des composants et les petites valeurs partagées comme le thème ou la langue. Tournez-vous vers Redux lorsque plusieurs fonctionnalités dépendent des mêmes données, lorsque plus de cinq développeurs travaillent sur la base de code, ou lorsque vous avez besoin d'un historique des changements d'état. Dans la plupart des applications en production, la réponse est d'utiliser les deux, à des niveaux différents.
Commencez par les hooks. Passez à Zustand lorsque l'état partagé devient trop complexe pour le contexte et que vous commencez à lutter contre les re-rendus inutiles. Adoptez Redux Toolkit lorsque l'équipe dépasse environ cinq développeurs, ou que le domaine métier exige une traçabilité des changements d'état. Zustand est actuellement en tête en termes de satisfaction des développeurs, tandis que Redux reste la solution la plus largement déployée.
Oui. Mais ce n'est plus le choix par défaut automatique. L'enquête « State of React 2025 » montre que Redux et Redux Toolkit restent les solutions les plus répandues, et qu'ils demeurent l'option la plus robuste pour les grandes équipes et les secteurs réglementés. Pour un nouveau projet avec une petite équipe, Zustand, ou l'absence totale de bibliothèque, est désormais le point de départ le plus courant.
Utilisez useReducer lorsque l'état complexe est confiné à un seul composant ou à un groupe restreint : un formulaire multi-étapes, un assistant ou une grille de données. Utilisez Redux lorsque cet état est partagé entre des parties non liées de l'application. C'est la portée, et non la complexité, qui définit la limite.
Pour les applications de petite et moyenne taille, oui. useContext et useReducer reproduisent ensemble la majeure partie des fonctionnalités de Redux. Ce qu'ils ne peuvent pas remplacer sans un travail de personnalisation important, c'est le contrôle du re-rendu basé sur les sélecteurs, les middlewares pour la logique asynchrone et l'expérience de débogage offerte par les DevTools. C'est précisément sur ces points que s'appuient les grandes équipes.
Redux est indépendant de tout framework ; c'est un conteneur d'état qui fonctionne avec n'importe quelle couche d'interface utilisateur. react-redux est le binding officiel qui permet de l'intégrer à React, en vous fournissant useSelector et useDispatch hooks. Vous avez besoin des deux pour utiliser Redux dans une application React.
C'est possible. Context ne dispose pas de mécanisme de sélection ; ainsi, lorsque la valeur d'un fournisseur change, tous les consommateurs situés en dessous sont re-rendus, y compris ceux qui n'utilisent pas la partie modifiée. C'est acceptable pour des valeurs qui changent rarement, mais problématique pour tout ce qui évolue fréquemment ou qui est largement consommé.
Alors, Redux est-il fini ? Non, bien sûr que non. Les hooks React et Redux sont complémentaires, pas rivaux. Les hooks gèrent l'état des composants et la logique partageable, Redux gère l'état global, les actions distribuées et l'observabilité dont dépendent les grandes équipes, et Zustand se place désormais confortablement entre les deux.
Revenons une dernière fois à la construction. Vous ne choisissez pas entre le robinet et le réseau de distribution. Vous déterminez combien de pièces ont besoin d'eau, combien de personnes ouvrent les robinets, et vous installez la plomberie en conséquence.
Où se situe votre application sur l'axe de la complexité, où se situe votre équipe sur l'axe de la taille, et où seront-ils tous deux dans douze mois ? Concevez votre architecture pour cela. Pas pour aujourd'hui.
Si vous développez ou faites évoluer une application React et que vous souhaitez une réponse claire sur votre architecture d'état avant qu'elle ne soit figée, notre équipe réalise des audits techniques qui font exactement cela.
Développeur Javascript depuis 2016, j'ai créé des applications mobiles en utilisant Ionic et React Native. Guitariste et passionné de cuisine.
People who read this post, also found these interesting:
.webp)
