Architecture de composants React : patterns pour des UI maintenables

Pourquoi l'architecture de composants détermine la durée de vie de votre projet

Un projet React peut démarrer avec une structure parfaitement propre et se transformer en un enchevêtrement inextricable en quelques mois. La différence entre les deux trajectoires tient rarement aux compétences individuelles des développeurs — elle tient aux patterns architecturaux choisis au depart. Apres avoir accompagne des dizaines d'équipes sur des projets React de toutes tailles, j'ai constaté que les mêmes erreurs structurelles se répètent et que les mêmes patterns sauvent la mise.

React 19, publié en décembre 2024, a introduit des changements significatifs qui influencent directement la manière de structurer les composants. Les Server Components sont désormais stables, les Actions simplifient la gestion des formulaires, l'API use() permet de lire des Promises pendant le rendu, et le React Compiler experimental promet de rendre le memoization manuel obsolète. Ces évolutions ne rendent pas les patterns fondamentaux obsoletes — elles les renforcent.

Dans cet article, je vais detailler les patterns de composition que j'utilise au quotidien et qui ont fait leurs preuves sur des projets en production a grande échelle. Ce sont des patterns qui survivent à la croissance de l'équipe, à l'augmentation de la complexité fonctionnelle et aux mises a jour majeures du framework.

React Server Components et le pattern container-presenter revisite

Les React Server Components, stabilisés avec Next.js et son App Router, ont ressuscite et modernise le pattern container-presenter que beaucoup croyaient dépassé. Dans le modèle RSC, les composants serveur jouent le rôle de containers : ils fetchen les données, gèrent la logique métier et preparent les props. Les composants client, marques avec la directive 'use client', jouent le rôle de presenters : ils reçoivent des données serialisables et gèrent l'interactivite.

La frontiere de serialisation entre serveur et client impose une discipline architecturale benefique. Les props qui traversent cette frontiere doivent être serialisables — pas de fonctions, pas de classes, pas de références circulaires. Cette contrainte force une séparation nette des responsabilites qui rend le code plus prévisible et plus testable. Les composants serveur sont des fonctions pures qui transforment des données, les composants client sont des modules d'interaction isolés.

Les Server Actions, marquees avec la directive 'use server', completent ce modèle en permettant aux composants client d'invoquer des mutations côté serveur de manière transparente. Avec useActionState et useFormStatus introduits dans React 19, la gestion des formulaires devient significativement plus simple. Un formulaire complet avec validation, soumission et gestion des erreurs s'écrit en une fraction du code que nécessitaient les approches précédentes.

Compound Components et composition implicite

Le pattern Compound Components est mon outil de composition préféré pour les interfaces complexes. Il consiste a créer un ensemble de composants qui partagent un état implicite via React Context. Prenez un composant Select : plutôt qu'un seul composant monolithique avec vingt props, vous exposez Select.Trigger, Select.Content et Select.Item. Chaque sous-composant gère sa propre portion de l'interface tout en accédant à l'état partagé du parent.

Ce pattern offre une flexibilite remarquable. Le consommateur peut reorganiser les sous-composants, en omettre certains, en ajouter d'autres entre eux, sans que le composant parent ait besoin de prévoir tous ces cas. C'est la composition dans sa forme la plus pure — chaque élément fait une chose et la fait bien, et l'assemblage produit un comportement émerge cohérent.

L'implementation repose sur un Context Provider au niveau du composant racine et des hooks useContext dans chaque sous-composant. React 19 simplifie cette mécanique puisque ref est désormais une prop régulière — plus besoin de forwardRef pour faire passer des références à travers les couches de composition. C'est un gain de lisibilité appreciable dans les hiérarchies de composants profondes.

Headless UI : séparer le comportement de l'apparence

Le pattern Headless UI pousse la séparation des responsabilites encore plus loin en dissociant complètement la logique d'interaction de son rendu visuel. Un composant headless fournit le comportement — gestion du focus, navigation au clavier, gestion des états ARIA — sans imposer aucun style. C'est au consommateur de fournir l'apparence visuelle, ce qui élimine les batailles interminables avec les CSS d'un design system tiers.

L'écosystème headless en 2025-2026 est riche. Radix UI Primitives, développé par l'équipe de WorkOS, est la fondation sur laquelle shadcn/ui est construit et est devenu un standard de facto pour les nouveaux projets React. React Aria d'Adobe offre une approche basée sur les hooks avec une couverture d'accessibilité exemplaire. Ark UI, de l'équipe Chakra, utilise des machines a états via Zag.js pour une prévisibilité maximale du comportement.

shadcn/ui mérite une mention speciale. Contrairement aux bibliothèques de composants classiques installees comme dépendances npm, shadcn/ui génère le code des composants directement dans votre projet via la commande npx shadcn-ui@latest add. Vous possedez le code, vous le modifiez librement, et vous n'avez aucune contrainte de mise à jour. Cette approche de composants copy-paste sur base Radix UI et Tailwind CSS est devenue le choix dominant pour les nouveaux projets React.

Gestion d'état et organisation du code en 2025-2026

Le paysage de la gestion d'état a considérablement évolue. Redux, bien que toujours present dans de nombreux projets legacy, est en déclin pour les nouveaux développements. Zustand s'est imposé comme la solution la plus populaire de nouvelle génération avec plus de quarante millions de téléchargements npm mensuels, offrant une API minimale et performante. Jotai convient parfaitement à l'état atomique. TanStack Query domine la gestion de l'état serveur avec son système de cache intelligent.

Pour l'organisation du code, j'applique le principe de colocation : chaque fonctionnalité regroupe ses composants, hooks, types et tests dans un même répertoire. Cette approche feature-based remplace l'organisation par type technique — un dossier components, un dossier hooks, un dossier utils — qui devient ingérable au-dela d'une certaine taille. La colocation rend les dépendances explicites et les refactorings locaux.

Enfin, je suis la règle du composant d'un écran : si un composant dépasse cinquante a cent lignes, c'est un signal pour extraire de la logique dans un hook custom ou decomposer en sous-composants. Les hooks personnalises sont le mecanisme de reutilisation de logique le plus puissant de React et ils doivent être utilisés genereusement. Un composant qui ne fait que composer des hooks et rendre du JSX est un composant qui sera facile a comprendre, a tester et a maintenir pendant des années.