Pourquoi votre app est lente (même avec la fibre) : Le State Management expliqué

Pourquoi votre app est lente (même avec la fibre) ? Le State Management expliqué

Votre serveur répond en 50 ms. Votre connexion est en fibre. Et pourtant, un clic sur "Ajouter au panier" prend 2 secondes. Le coupable n'est pas votre hébergeur — c'est votre state management.

Si vous cherchez pourquoi votre state management application lente est un problème si répandu, vous êtes au bon endroit. Le state management est l'architecture invisible qui détermine comment votre application gère, distribue et met à jour ses données. Bien conçu, il donne à vos utilisateurs une expérience fluide, quasiment instantanée. Mal conçu, il transforme chaque interaction en une cascade de re-renders inutiles qui épuisent le CPU, vident les batteries et font fuir les utilisateurs.

Cet article vous explique les mécanismes précis qui provoquent les lenteurs, les anti-patterns les plus courants dans les projets React, et les solutions concrètes — de Zustand aux React Server Components — avec des exemples de code commentés et des étapes de diagnostic reproductibles.

---

Comment le state management provoque des re-renders en cascade

Pour comprendre pourquoi une application React devient lente, il faut d'abord comprendre comment React décide de re-rendre un composant.

Le cycle de vie d'un composant React

React suit un modèle simple : quand un état change, le composant qui détient cet état se re-rend, ainsi que tous ses enfants, sauf si vous avez mis en place des optimisations explicites. Ce comportement est intentionnel et correct pour les petites applications. Il devient catastrophique dès que votre arbre de composants grossit ou que l'état change fréquemment.

Imaginons une application e-commerce avec une architecture naïve. Vous avez un composant App qui détient dans son état local le panier, l'utilisateur, le thème et les préférences de filtre. À chaque fois que l'utilisateur change de thème — une action qui ne concerne que l'apparence visuelle — React re-rende App, ce qui déclenche le re-render de tous ses enfants : la liste de produits (potentiellement des centaines d'éléments), le header, le footer, le composant de recherche, etc. Aucun de ces composants n'a besoin d'être recalculé, pourtant React les recalcule tous.

// exemple simplifié — ❌ État trop centralisé
function App() {
  const [cart, setCart] = useState<CartItem[]>([]);
  const [user, setUser] = useState<User | null>(null);
  const [theme, setTheme] = useState<'light' | 'dark'>('light');

  // Changer le thème re-rend TOUT l'arbre
  return (
    <ThemeContext.Provider value={theme}>
      <Header user={user} />
      <ProductList /> {/* Re-render inutile */}
      <Cart cart={cart} /> {/* Re-render inutile */}
    </ThemeContext.Provider>
  );
}

La question n'est pas "est-ce que React est lent ?" — React est extrêmement rapide pour le rendu virtuel. La question est "combien de travail inutile lui demandez-vous de faire ?"

Le problème du contexte trop large

React Context est magnifiquement simple à utiliser, mais il cache un piège de performance bien documenté. Chaque fois que la valeur d'un Context change, tous les composants qui consomment ce Context via useContext se re-rendent, sans exception, même si la partie de la valeur qu'ils utilisent n'a pas changé.

Ce problème devient critique lorsqu'on met tout dans un seul Context global : utilisateur, panier, notifications, thème, préférences. Une notification entrante force le re-render du composant qui affiche uniquement le nom de l'utilisateur. Un article ajouté au panier force le re-render du composant qui affiche uniquement le thème.

// exemple simplifié — ❌ Context monolithique
const AppContext = createContext<{
  user: User;
  cart: CartItem[];
  theme: string;
  notifications: Notification[];
}>({ user: null, cart: [], theme: 'light', notifications: [] });

// Tous les consommateurs re-rendent si QUOI QUE CE SOIT change
function UserAvatar() {
  const { user } = useContext(AppContext);
  // Se re-rend aussi quand cart ou theme change !
  return <img src={user.avatar} />;
}

Sans mémoïsation, un changement de thème re-rend Header, Cart et Products. Avec Zustand et des sélecteurs ciblés, seul Header est touché.

---

Les anti-patterns qui tuent les performances

Maintenant que vous comprenez le mécanisme, voici les anti-patterns les plus fréquents dans les projets React réels — ceux que l'on retrouve dans presque toutes les revues de code.

Anti-pattern 1 : Trop d'état dans le store global

L'erreur la plus répandue est de traiter le store global comme un fourre-tout. Dès qu'une donnée est utilisée à deux endroits différents, le réflexe naturel est de la mettre dans le store. Ce réflexe est dangereux.

Posez-vous toujours cette question : cette donnée est-elle vraiment partagée entre plusieurs composants qui ne peuvent pas se parler directement ? Si la réponse est non, gardez-la en état local. L'état local ne propage pas de re-renders au-delà du composant qui le détient.

L'état d'un modal ouvert/fermé, d'un champ de formulaire en cours de saisie, d'un accordéon déroulé — tout cela appartient à l'état local. Le mettre dans un store global revient à sonner l'alarme de tout l'immeuble parce que vous avez allumé votre lampe de chevet.

Anti-pattern 2 : État dénormalisé avec duplications

La dénormalisation consiste à stocker la même donnée à plusieurs endroits pour la commodité. Par exemple, stocker à la fois la liste des produits et un objet selectedProductDetails qui contient une copie du produit sélectionné.

Quand le produit est mis à jour (prix, stock), vous devez penser à mettre à jour les deux sources. Vous oubliez l'une d'elles — c'est inévitable — et votre interface affiche des données incohérentes. C'est l'état désynchronisé : le panier affiche "3 articles" en haut, "Vide" en bas. L'utilisateur ne comprend pas ce qui se passe et abandonne.

La solution est la normalisation : stocker les entités une seule fois, indexées par ID, et ne stocker que l'ID là où vous avez besoin de référencer une entité.

// exemple simplifié — ✅ État normalisé
interface StoreState {
  products: Record<string, Product>; // source de vérité unique
  selectedProductId: string | null;  // référence par ID
  cartItemIds: string[];             // liste d'IDs
}

// Lecture : toujours dériver depuis la source de vérité
const selectedProduct = store.products[store.selectedProductId];

Anti-pattern 3 : Sélecteurs non mémoïsés dans Zustand

Zustand permet d'éviter les re-renders inutiles grâce aux sélecteurs. Un sélecteur est une fonction passée à useStore qui extrait uniquement la partie du store dont le composant a besoin. Zustand compare la valeur retournée par le sélecteur avant et après chaque mise à jour du store : si la valeur n'a pas changé, le composant ne se re-rend pas.

Mais si votre sélecteur retourne un nouvel objet ou un nouveau tableau à chaque appel — même avec les mêmes données — Zustand considère que la valeur a changé et déclenche un re-render.

// exemple simplifié — ❌ Sélecteur qui crée un nouveau tableau à chaque fois
function CartSummary() {
  // Crée un nouveau tableau à chaque rendu du store
  const expensiveItems = useCartStore(
    (state) => state.items.filter((i) => i.price > 100)
  );
  return <div>{expensiveItems.length} articles premium</div>;
}

// exemple simplifié — ✅ Sélecteur mémoïsé avec createSelector (zustand + reselect)
const selectExpensiveItems = createSelector(
  [(state: CartState) => state.items],
  (items) => items.filter((i) => i.price > 100)
);

function CartSummary() {
  const expensiveItems = useCartStore(selectExpensiveItems);
  return <div>{expensiveItems.length} articles premium</div>;
}

Prop Drilling : les données traversent inutilement toute la hiérarchie. Zustand : chaque composant s'abonne directement au store sans intermédiaire.

Un state global mal géré déclenche 100% de re-renders. Avec Zustand et des sélecteurs ciblés, seuls les composants réellement concernés se re-rendent.

---

React Context vs Zustand vs Redux : quel outil choisir ?

La question n'est pas "quel est le meilleur outil ?" mais "quel outil est adapté à mon cas d'usage ?" Voici comment raisonner.

React Context est parfait pour les données qui changent rarement et qui doivent être accessibles partout : thème, langue, utilisateur connecté. Si la valeur change plus d'une fois par seconde, évitez Context — ses re-renders en cascade ne sont pas optimisables sans une complexité architecturale importante.

Zustand est la bibliothèque qui offre le meilleur équilibre entre simplicité et performance pour les états clients fréquemment mis à jour. Son API est minimaliste, son empreinte mémoire est faible, et ses sélecteurs permettent des abonnements chirurgicaux. Pour un panier e-commerce, des notifications en temps réel, ou une interface avec beaucoup d'états interactifs, Zustand est le choix naturel.

Redux Toolkit reste pertinent pour les très grandes applications qui bénéficient de la structure imposée, du time-travel debugging et de l'écosystème de middlewares. Pour la majorité des projets de taille moyenne, son rapport complexité/bénéfice est défavorable comparé à Zustand.

TanStack Query (React Query) mérite une mention spéciale : il ne gère pas l'état client, mais l'état serveur — les données récupérées depuis une API. Pour cet usage, il est imbattable : cache intelligent, déduplication des requêtes, revalidation automatique. Ne dupliquez pas dans Zustand ce que vous récupérez depuis votre API — laissez React Query s'en charger.

Quand utiliser un état local, lever l'état au parent commun, ou passer à un store global ? Ce diagramme guide vos décisions d'architecture.

---

useMemo, useCallback et les sélecteurs Zustand : mise en pratique

Ces trois outils servent le même objectif — éviter des calculs ou des re-renders inutiles — mais dans des contextes différents.

useMemo : mémoïser les calculs coûteux

useMemo est utile quand un composant doit calculer une valeur dérivée à partir de données qui changent peu souvent, mais que le calcul lui-même est coûteux. Le cas typique : filtrer ou trier une liste de plusieurs milliers d'éléments à chaque rendu.

// exemple simplifié
function ProductList({ products, searchQuery }: Props) {
  // Sans useMemo : recalcule à chaque re-render du composant parent
  const filteredProducts = useMemo(
    () =>
      products.filter(
        (p) =>
          p.name.toLowerCase().includes(searchQuery.toLowerCase()) &&
          p.stock > 0
      ),
    [products, searchQuery] // Ne recalcule que si ces deps changent
  );

  return filteredProducts.map((p) => <ProductCard key={p.id} product={p} />);
}

Attention : useMemo a un coût. Il alloue de la mémoire pour stocker le résultat mémoïsé et consomme du CPU pour comparer les dépendances. N'ajoutez pas useMemo partout — réservez-le aux calculs qui prennent réellement du temps ou qui sont appelés très fréquemment.

useCallback : stabiliser les références de fonctions

useCallback mémoïse une référence de fonction. Son utilité principale est d'éviter qu'un composant enfant enveloppé dans React.memo se re-rende à cause d'une nouvelle référence de fonction passée en prop.

// exemple simplifié
const handleAddToCart = useCallback(
  (productId: string) => {
    cartStore.addItem(productId);
  },
  [] // Référence stable — ne change jamais
);

// ProductCard est mémoïsé : ne se re-rend que si ses props changent
const ProductCard = React.memo(({ product, onAdd }: ProductCardProps) => {
  return <button onClick={() => onAdd(product.id)}>{product.name}</button>;
});

Sélecteurs Zustand : l'abonnement chirurgical

Avec Zustand, la règle d'or est de n'extraire que ce dont vous avez besoin. Un composant qui n'a besoin que du nombre d'articles dans le panier ne doit pas s'abonner à la liste complète des articles.

// exemple simplifié — ✅ Sélecteur granulaire
import { create } from 'zustand';

interface CartStore {
  items: CartItem[];
  addItem: (item: CartItem) => void;
  removeItem: (id: string) => void;
}

const useCartStore = create<CartStore>((set) => ({
  items: [],
  addItem: (item) =>
    set((state) => ({ items: [...state.items, item] })),
  removeItem: (id) =>
    set((state) => ({ items: state.items.filter((i) => i.id !== id) })),
}));

// Ne re-rend QUE si le nombre d'items change
function CartBadge() {
  const count = useCartStore((state) => state.items.length);
  return <span className="badge">{count}</span>;
}

// Ne re-rend QUE si les items eux-mêmes changent (shallow compare)
function CartDrawer() {
  const items = useCartStore((state) => state.items, shallow);
  return <ul>{items.map((i) => <CartItem key={i.id} item={i} />)}</ul>;
}

---

Profiling et diagnostic : comment détecter les lenteurs de state management

Avant d'optimiser quoi que ce soit, vous devez mesurer. Optimiser sans profiling revient à réparer une voiture sans regarder le moteur.

React DevTools Profiler

React DevTools est l'outil indispensable pour le diagnostic des re-renders. Il s'installe comme extension navigateur (Chrome, Firefox) et ajoute un onglet "Profiler" dans les DevTools.

Procédure :

1. Ouvrez l'onglet Profiler dans React DevTools.
2. Cliquez sur l'icône d'enregistrement (cercle rouge).
3. Reproduisez l'interaction que vous soupçonnez d'être lente.
4. Arrêtez l'enregistrement.

Le Profiler affiche une "flamegraph" des rendus. Chaque barre représente un composant. La couleur indique la durée du rendu (vert = rapide, rouge = lent). Activez le mode "Highlight updates" dans les paramètres DevTools : les composants qui se re-rendent sont entourés d'un flash coloré en temps réel — c'est souvent suffisant pour identifier immédiatement les composants qui re-rendent sans raison.

Recherchez en priorité les Wasted Renders : composants qui re-rendent avec les mêmes props et le même state. C'est toujours le signe d'une optimisation manquante.

Chrome DevTools Performance

Pour les problèmes plus profonds — Long Tasks qui bloquent le thread principal, calculs JavaScript coûteux, GC pressure — utilisez l'onglet Performance de Chrome DevTools.

Procédure :

1. Ouvrez Chrome DevTools → onglet Performance.
2. Activez "CPU: 4x slowdown" pour simuler un appareil mobile et amplifier les problèmes.
3. Cliquez sur Record, reproduisez l'interaction, arrêtez.
4. Cherchez les Long Tasks (barres rouges dans la piste "Main") : toute tâche dépassant 50 ms bloque le thread principal et provoque un "jank" perceptible.

Dans la vue détaillée, vous pouvez voir l'arbre d'appels JavaScript et identifier quelle fonction consomme du temps. Si vous voyez des noms de composants React dans la flamegraph, vous avez trouvé vos suspects.

Guide étape par étape : de l'identification du problème via React DevTools jusqu'à la solution adaptée (Zustand, useMemo, React Query, RSC).

Cas réel : l'application de livraison GPS

Voici un exemple concret d'un problème de state management que nous avons rencontré sur une application de livraison. Le livreur déplace sa position GPS sur la carte en temps réel — la position est mise à jour plusieurs fois par seconde via WebSocket.

L'architecture initiale stockait la position GPS dans le state global de l'application, au même niveau que le panier, les commandes en cours et les informations utilisateur. Résultat : à chaque mise à jour GPS, toute l'interface se re-rendait — la liste des commandes, le header, le panneau de détails. L'application devenait inutilisable après quelques minutes d'utilisation intensive.

La correction :

// exemple simplifié — ✅ Store isolé pour la position GPS
const useGPSStore = create<GPSStore>((set) => ({
  position: { lat: 0, lng: 0 },
  updatePosition: (pos) => set({ position: pos }),
}));

// Seul MapPin s'abonne au store GPS
function MapPin() {
  const position = useGPSStore((state) => state.position);
  return <Marker position={position} />;
}

// OrderList ne sait pas que la position existe — aucun re-render
function OrderList() {
  const orders = useOrderStore((state) => state.orders);
  return <ul>{orders.map((o) => <OrderCard key={o.id} order={o} />)}</ul>;
}

En isolant la position GPS dans son propre store Zustand, seul le composant MapPin reçoit les mises à jour. Le reste de l'application dort paisiblement à 60 FPS. Pour aller plus loin sur l'optimisation des performances web côté chargement, consultez notre guide sur comment diviser le temps de chargement par 10.

---

React Server Components : la solution radicale pour éliminer le problème à la source

Les React Server Components (RSC), disponibles dans Next.js depuis la version 13 et matures dans Next.js 15/16, représentent un changement de paradigme pour la gestion des lenteurs liées au state management.

L'idée est simple : si un composant n'a pas besoin d'interactivité (pas de useState, pas d'événements utilisateur), pourquoi l'envoyer au client ? Les RSC sont rendus entièrement sur le serveur, leur code JavaScript n'est jamais envoyé au navigateur, et ils ne participent pas à l'arbre de state management client.

Pour un article de blog, une page produit avec des informations statiques, une liste de catégories — tous ces éléments peuvent devenir des Server Components. Vous réduisez ainsi la taille de votre bundle JavaScript, la quantité d'état client à gérer, et mécaniquement le nombre de re-renders possibles.

// exemple simplifié — RSC : rendu serveur, zéro JS client
// app/products/page.tsx — Server Component par défaut dans Next.js App Router
async function ProductsPage() {
  // Fetch direct en server-side, pas de useEffect, pas d'état
  const products = await db.products.findMany({ where: { active: true } });

  return (
    <main>
      <h1>Nos produits</h1>
      {/* Server Component : zéro JS envoyé au client */}
      <ProductGrid products={products} />
      {/* Client Component : seulement le panier a besoin d'interactivité */}
      <CartButton /> {/* 'use client' uniquement ici */}
    </main>
  );
}

Dans Next.js 16.2, les améliorations apportées au Partial Pre-Rendering permettent une granularité encore plus fine : certaines parties de la page sont servies statiquement (cachées à la bordure), d'autres sont rendues dynamiquement, le tout dans le même composant. Notre article sur le Partial Pre-Rendering dans Next.js détaille cette approche. Si vous êtes déjà sur Next.js et voulez comprendre les dernières évolutions, lisez également ce que change concrètement Next.js 16.2 en 2026.

---

Guide step-by-step : corriger une application lente en 5 étapes

Voici la procédure concrète que nous appliquons lors de nos audits de performance.

Étape 1 — Profiler avant d'optimiser. Ouvrez React DevTools Profiler, activez "Highlight updates" et reproduisez l'interaction problématique. Notez les 3 composants qui re-rendent le plus souvent de manière inattendue.

Étape 2 — Identifier la source de l'état. Pour chaque composant problématique, remontez la chaîne : est-ce que ce composant consomme un Context ? Un store Zustand entier ? Reçoit-il des props qui changent trop souvent ? Cherchez le "point d'origine" du re-render.

Étape 3 — Isoler et partitionner l'état. Divisez vos stores en entités cohérentes et indépendantes. Un store cart, un store user, un store UI (modals, toasts, thème). Chaque store ne doit couvrir qu'un domaine fonctionnel. Les composants n'abonnent que ce dont ils ont besoin.

Étape 4 — Ajouter les sélecteurs. Remplacez les accès au store entier par des sélecteurs granulaires. Si vous utilisez useStore((state) => state) n'importe où dans votre code, c'est un bug de performance garanti — le composant se re-rend à chaque changement du store, quelle que soit la partie modifiée.

Étape 5 — Migrer les composants statiques vers les Server Components. Identifiez les composants qui n'ont pas d'interactivité et n'ont pas besoin de state client. Transformez-les en Server Components pour retirer leur JavaScript du bundle. Ce seul changement peut réduire significativement la surface d'état client à gérer.

Si votre application souffre de problèmes plus larges de dette technique qui compliquent ces refactorisations, notre article sur pourquoi une application coûte 5x plus cher à maintenir avec la dette technique vous donnera un cadre pour prioriser les refactorisations nécessaires.

---

La vérité sur l'IA et le state management

Les outils d'IA générative (GitHub Copilot, Cursor, Claude) accélèrent considérablement l'écriture de code React. Mais ils ont une tendance documentée à générer du Prop Drilling — c'est la solution la plus simple à déduire contextuellement, et les grands modèles de langage optimisent pour la simplicité locale, pas pour l'architecture globale.

Si vous relisez du code généré par IA sans comprendre les implications de performance du state management, vous accumulerez de la dette technique à haute vitesse. L'IA peut écrire du code correct et fonctionnel qui est architecturalement désastreux pour les performances.

La règle est simple : l'IA écrit le code, vous validez l'architecture. Si vous voyez du Prop Drilling à plus de deux niveaux, ou un état mis dans un Context global qui change fréquemment, c'est un signal d'alerte qui requiert votre jugement humain.

---

Conclusion : de l'app qui rame à l'app fluide

Un state management application lente n'est pas une fatalité. Les causes sont connues, les outils pour les corriger sont matures, et les gains de performance sont souvent spectaculaires — sans réécrire toute votre application.

Retenez ces priorités :

• Mesurez d'abord avec React DevTools Profiler avant d'optimiser quoi que ce soit.
• Isolez vos stores par domaine fonctionnel et utilisez des sélecteurs granulaires dans Zustand.
• Normalisez vos données pour éviter la désynchronisation et les duplications.
• Mémoïsez à bon escient avec useMemo et useCallback — pas partout, seulement là où c'est justifié.
• Déportez sur le serveur avec les React Server Components tout ce qui n'a pas besoin d'interactivité cliente.

Une application fluide comme Instagram ou Uber n'est pas le fruit d'un hardware surpuissant — c'est le résultat d'une architecture de state management rigoureuse, construite sur ces principes.

---

FAQ — State Management et performances React

Pourquoi mon application React se re-render-t-elle autant ?

Les re-renders excessifs proviennent le plus souvent d'un état global trop large (Context ou store non partitionné), de sélecteurs non mémoïsés, ou de props qui recréent des objets/fonctions à chaque rendu. Utilisez React DevTools Profiler pour identifier les composants qui "flashent" et ajoutez des sélecteurs Zustand ciblés ou React.memo pour les isoler.

Quelle est la différence entre React Context et Zustand ?

React Context est un mécanisme natif qui re-rend tous les consommateurs dès que sa valeur change. Zustand est une bibliothèque externe qui permet de s'abonner uniquement à une tranche précise du store via des sélecteurs, évitant ainsi les re-renders des composants non concernés. Pour les états fréquemment mis à jour (panier, position GPS), Zustand est plus performant.

Quand utiliser useMemo et quand utiliser useCallback ?

useMemo mémoïse le résultat d'un calcul coûteux — par exemple filtrer ou trier une liste de milliers d'éléments. useCallback mémoïse une référence de fonction pour éviter qu'un composant enfant enveloppé dans React.memo se re-rende à cause d'une nouvelle référence. N'ajoutez pas ces hooks partout : ils ont un coût mémoire et ne sont utiles que si la dépendance change moins souvent que le composant parent ne se re-rend.

Les React Server Components résolvent-ils les problèmes de state management ?

Partiellement. Les RSC déportent sur le serveur tout composant qui n'a pas besoin de state interactif, réduisant ainsi drastiquement le JavaScript envoyé au client. Ils ne remplacent pas Zustand ou Context pour l'état client partagé, mais ils éliminent le problème à la racine pour les parties statiques ou quasi-statiques de l'interface.

Comment profiler une application React pour trouver les lenteurs ?

Ouvrez React DevTools (onglet Profiler), cliquez sur "Record", reproduisez l'interaction lente, puis arrêtez l'enregistrement. Les barres colorées indiquent les composants re-rendus et leur durée. Complétez avec Chrome DevTools (onglet Performance) pour visualiser le thread principal, les Long Tasks et les flammes d'appels JavaScript. Cherchez en priorité les composants qui re-rendent sans raison lors d'une action non liée.

---

Ressources Complémentaires :

Guide Complet : Développement Apps Pro Module entier sur l'architecture d'état (React & Flutter) : Zustand, Riverpod, Context API, optimisation des performances, debugging avancé. Accéder au Guide Complet

---

Votre app est-elle fluide ou elle rame ? Partagez votre contexte en commentaire — type d'application, stack, symptômes observés — et nous vous indiquerons par où commencer.