Ce que Zustand change dans notre métier

Après cinq ans à manipuler Redux, MobX et Context API, j'ai découvert Zustand il y a dix-huit mois. Franchement, ça m'a dérangé. Pas parce que c'était mauvais, mais parce que je réalisais combien de complexité j'avais acceptée comme inévitable. Zustand remet en question notre approche collective de la gestion d'état en React, et ce n'est pas une évolution cosmétique : c'est un changement de paradigme qui force le métier à se poser des questions inconfortables.

La vraie révolution n'est pas technique—c'est philosophique. Zustand prouve qu'on n'a pas besoin de boilerplate massif, de providers enchâssés, ou de sélecteurs compliqués pour gérer l'état global efficacement. Pour ceux qui vivent quotidiennement les cauchemars de Redux, c'est libérateur. Pour l'industrie, c'est perturbant.

La fin du boilerplate comme norme

Redux s'est construit sur l'idée que la verbosité était une protection. Plus de code = plus de clarté = moins de bugs. C'était un mensonge confortable. J'ai passé des jours entiers à écrire des actions, des reducers, des dispatch, des selectors—du travail mécanique qui n'ajoutait aucune valeur métier. Zustand tue ça d'une phrase.

C'est tout. Pas d'actions, pas de constantes, pas de middleware complexe. Ça crée une rupture cognitive chez les développeurs habitués à Redux. On se demande : où est le reste? Et la réponse inconfortable est : il n'y a pas de reste, vous n'en aviez jamais besoin.

Le métier y gagne immédiatement : onboarding plus rapide, moins de défauts liés au boilerplate, et surtout, du temps libéré pour résoudre de vrais problèmes. Mais psychologiquement, c'est dur. On a investi des années dans Redux, et voilà qu'une librairie de 2KB le rend partiellement obsolète. Le secteur doit accepter cette accélération permanente.

L'autonomie du composant retrouvée

Avec Redux, on centralise tout. Le store devient une source de vérité unique, monolithe, rigide. Zustand encourage l'inverse : créer des stores spécialisés, petits, décentralisés. Un store pour l'authentification, un autre pour la pagination, un troisième pour le thème. Ça semble anarchique, c'est en réalité pragmatique.

Cette architecture micro-stores change la dynamique d'équipe. Chacun peut travailler sur son domaine sans créer des dépendances transversales monstrueuses. Les feature teams gagnent en autonomie. Les architectes perdent du contrôle centralisé, ce qui terrifie certains, mais libère énormément d'énergie ailleurs.

Pour un développeur junior, c'est transformateur. Il peut créer un petit store sans passer par un rituel initiatique. Pour un lead tech, c'est vertigineux—faut-il établir des conventions? Des garde-fous? La réponse dépend de la maturité de l'équipe, ce qui n'existait pas comme question auparavant.

DevTools et debugging : la transparence par défaut

Redux DevTools est une merveille, mais c'est une pièce rapportée. Avec Zustand, le débogage est primitif mais transparent. Vous pouvez logguer le store, tracer les mutations, voyager dans l'historique. Pas de magie noire, pas de middleware cabalistique à configurer.

Cette simplicité a un coût : moins de fonctionnalités sophistiquées. Mais honnêtement? La plupart des équipes n'en utilisent pas 30%. Zustand force la clarté plutôt que la puissance. C'est une philosophie qui change notre rapport au debugging : on accepte de perdre des outils pointus pour gagner de la compréhensibilité.

La question des re-rendus excessifs

Zustand force à penser aux sélecteurs. Si vous ne déclarez pas précisément ce que vous observez, vous risquez des re-rendus. Avec Context API ou Redux sans optimisation, c'était encore pire et souvent silencieux. Zustand le rend visible.

Chaque ligne force une décision consciente. C'est fatigant au début, puissant à la longue. Les développeurs apprennent que la performance n'est pas un problème à résoudre à la fin—c'est une décision architecturale dès le départ. Le métier devient plus mature dans sa conception.

Ce que ça change pour les équipes

Zustand ne révolutionne pas la stabilité ou la scalabilité. Il révolutionne l'expérience développeur et la maintenabilité. Les projets mid-size (5-10 devs) voient leur vélocité augmenter. Les très gros projets restent compliqués, mais moins par la structure que par leur domaine métier propre.

Cela crée une bifurcation : de nouvelles équipes prendront Zustand par défaut. Les équipes Redux establishment vont défendre leur choix, avec raison—le coût de migration sur un gros codebase justifie la stabilité. Mais les nouveaux projets? Zustand prend une part croissante du marché. C'est une mutation ordinaire du secteur.

Conclusion : accepter que moins c'est mieux

Zustand n'est pas la solution universelle. C'est une mise en question. Elle demande aux équipes d'arrêter de confondre complexité avec robustesse. Pendant dix ans, on s'est construit des châteaux de boilerplate, convaincus que c'était nécessaire. Zustand prouve le contraire, et cette transparence est inconfortable.

Si vous avez une équipe Redux stable et efficace, ne changez pas. Mais pour les nouveaux projets, pour les équipes qui cherchent de la vélocité, ou simplement pour explorer : testez Zustand. Vous découvrirez probablement qu'une grande part de votre infrastructure d'état était de la fiction. Le métier y gagnera en honnêteté technique.