ADR 003 — Pas de Zustand pour la V2

Statut : Accepté Date : 2026-04-17 Décideur : Hermann

Contexte

Question posée : faut-il introduire un store global (Zustand, Jotai, Redux Toolkit) dès le scaffold du frontend, en prévision de la complexité future du produit ?

Arguments en faveur d'une intégration précoce :

La T2 Live a une state machine complexe (idle → connecting → listening → speaking → processing → ended/error).
Plusieurs composants pourraient devoir lire le plan utilisateur actuel.
Un produit "scalable" justifierait une gestion d'état "moderne".

Options envisagées

Option A — Zustand dès le départ

Avantages : prêt le jour où on en aura besoin, un seul endroit pour l'état global.
Inconvénients : dépendance supplémentaire à maintenir, code plus abstrait pour des cas qui ne la nécessitent pas, risque que les devs "poussent" de l'état dans le store par réflexe même quand useState suffit.

Option B — Pas de store global, stratégie en trois couches

État serveur → TanStack Query (cache, refetch, invalidation après webhook Stripe).
État T2 Live → useReducer local avec une state machine explicite, dans features/t2-live/hooks/useT2LiveSession.ts.
État UI local → useState / useContext pour les cas simples (ex : ouverture d'une modal).
Avantages : zéro dépendance supplémentaire, chaque composant gère son propre état, TanStack Query couvre 90% des besoins (tout ce qui vient du serveur).
Inconvénients : si plusieurs composants non-parents ont besoin de partager un état client complexe (non-serveur), il faudra passer par React Context ou migrer vers Zustand à ce moment-là.

Décision

Option B — pas de store global pour la V2.

Règle d'introduction future : Zustand (ou équivalent) ne sera introduit que si un cas concret apparaît où plusieurs composants non-parents partagent un état client complexe qui ne peut pas être géré par TanStack Query ni par un Context React local. Jusque là, on s'en passe.

Conséquences

Positives :

Une dépendance en moins dans package.json.
Un nouveau dev ne se demande pas "pourquoi Zustand pour un produit aussi simple ?".
Évite le piège classique : dès qu'un store global existe, les devs y poussent tout, y compris ce qui devrait rester local. Le résultat est un store-spaghetti.
TanStack Query gère déjà la synchronisation serveur → UI, ce qui couvre le plan utilisateur, les productions, les rapports, l'historique.

Négatives :

Si un besoin complexe de partage d'état client apparaît tôt, il faudra migrer. Mitigation : TanStack Query + Context suffisent dans 95% des cas prévisibles.

À revisiter si :

Un composant du header doit réagir en temps réel à un événement du composant de simulation (sans passer par le serveur).
La state machine T2 Live devient partagée entre plusieurs écrans (peu probable).
L'application a plus de 10 écrans avec de l'état client partagé complexe.

Dans ces cas, introduire Zustand sera une session dédiée avec migration progressive — pas une réécriture.

Références

ADR 002 (API client découplé)
TanStack Query docs — stratégie de cache
ARCHITECTURE.md §4 (structure features/ + shared/)

3.3 KiB Raw Permalink Blame History