Quand faut-il utiliser un store comme NgRx dans une application Angular ?

Cet article est rédigé en français. Si vous souhaitez une version anglaise, faites-le-moi savoir en commentaire !

C’est une question que je reçois souvent :

"Est-ce que tu utilises souvent un store dans tes applications Angular ?"

Et lors des échanges, deux visions reviennent régulièrement :

D’un côté, ceux qui pensent que c’est overkill dans la majorité des cas.
De l’autre, ceux qui ont tendance à en mettre partout, parfois par habitude.

Alors, qui a raison ? Et à quoi sert réellement un store ?

Le rôle d’un store

La documentation officielle de NgRx dit :

“NgRx Store provides reactive state management for Angular apps inspired by Redux. Unify the events in your application and derive state using RxJS.”

Ce petit paragraphe met en lumière un aspect souvent négligé :

l’unification des événements dans l’application.

Un store ne se limite pas à stocker des données. Il peut aussi agir comme un orchestrateur d’événements métier.

Pourquoi utiliser un store pour orchestrer des intentions métier ?

Cela permet par exemple de découpler les composants des services applicatifs :

les composants n’émettent que des intentions (via des actions),

et ce sont les effects ou handlers qui les traitent.

Résultat : une architecture claire, modulaire, et surtout testable.

🛒 Exemple concret : Ajouter un produit au panier

🔻 Sans store :

this.isLoading = true;
this.cartService.addProduct(product).subscribe({
  next: () => {
    this.cart.push(product);
    this.isLoading = false;
  },
  error: () => {
    this.error = 'Échec';
    this.isLoading = false;
  }
});

Avec NgRx (approche orientée événements) :

Le composant ne sait rien de l'objet qui exécute le comportement associé à l'action.

//component.ts 

this.store.dispatch(addToCart({ product }));


// effect.ts

// effect
createEffect(() =>
  this.actions$.pipe(
    ofType(addToCart),
    exhaustMap(product =>
      this.cartService.addProduct(product).pipe(
        map(() => addToCartSuccess({ product })),
        catchError(() => of(addToCartFailure()))
      )
    )
  )
);

Et la gestion d’état ?

Bien sûr, un store permet aussi de centraliser et structurer l’état global de ton application.

Mais si tu veux l’utiliser uniquement pour partager du state, je te recommande de le faire seulement si plusieurs composants doivent lire et écrire sur ces mêmes données.

En résumé : quand utiliser un store ?

Un store devient pertinent si :

Tu dois orchestrer une logique métier via des événements
Tu veux modéliser des intentions utilisateur de manière claire
Tu partages un même état entre plusieurs composants

Quelques cas typiques :

✅ Une app de prise de rendez-vous (avec loading, erreurs, confirmations…)
✅ Une app de chat ou de jeu en WebRTC
✅ Un tunnel de paiement à étapes multiples
✅ Des entités partagées dans plusieurs contextes

Dans tous ces cas, le store ne sert pas à stocker des données. Il sert à modéliser le comportement métier.

❌ Et quand ne pas utiliser de store ?

Pour des données statiques en lecture seule (ex : liste de pays)
Pour un état local et isolé dans un seul composant
Quand la logique métier est triviale et linéaire

En conclusion

Ne mets pas un store pour chaque jeu de données.
Mais ne le rejette pas sous prétexte que ton app est “petite”.

Mets un store quand tu veux modéliser clairement une interaction utilisateur, même locale.

Ce qui compte, ce n’est pas la taille de ton app,
mais la clarté de l’intention et la prévisibilité du comportement.

💬 Et toi, dans quels cas choisis-tu d’utiliser un store ?
Partage ton expérience ou pose tes questions en commentaire !

yvan @yvesleciel