Capitalise nouveaux patterns backend/frontend/BMAD et externalise les templates du post-install BMAD

10_frontend_risques_et_vigilance.md

@@ -7,7 +7,7 @@ Ce fichier recense des risques front-end susceptibles de provoquer :
 - dette technique rapide,
 - régressions UX/perf/a11y.
 
-Dernière mise à jour : 09-03-2026
+Dernière mise à jour : 10-03-2026
 
 ---
 
@@ -30,6 +30,8 @@ Dernière mise à jour : 09-03-2026
 - [Performances : sur-renders + bundle](#risque-performances-sur-renders)
 - [Accessibilité oubliée (a11y)](#risque-accessibilite-oubliee)
 - [Catch silencieux — erreur inconnue sans feedback utilisateur](#risque-catch-silencieux)
+- [Auto-reset d’un état dégradé sur toute réponse 2xx](#risque-auto-reset-etat-degrade)
+- [Refresh store en fire-and-forget après mutation](#risque-refresh-store-fire-and-forget)
 
 ---
 
@@ -205,3 +207,51 @@ Dernière mise à jour : 09-03-2026
 
 - **Règle** : tout `catch` doit avoir une branche `else` (ou `default`) qui affiche un feedback utilisateur explicite.
 - Contexte technique : React Native / Expo — 09-03-2026
+
+---
+
+<a id="risque-auto-reset-etat-degrade"></a>
+## Auto-reset d’un état dégradé sur toute réponse 2xx
+
+### Risques
+
+- Le client sort trop tôt d’un mode dégradé alors que la cause serveur est toujours présente
+- Le bandeau ou l’état read-only clignote puis disparaît à tort
+- Les utilisateurs retentent une action d’écriture qui va encore échouer
+
+### Symptômes
+
+- Un GET réussi réinitialise `isReadOnly` ou `isDegraded`
+- L’UI redevient “normale” alors que Redis ou un service critique est toujours indisponible
+- Les erreurs reviennent immédiatement à la prochaine mutation
+
+### Bonnes pratiques / mitigations
+
+- Ne réinitialiser l’état dégradé qu’après une requête d’écriture réussie
+- Exclure `GET` et `HEAD` de la logique de reset
+- Conserver le mode dégradé tant qu’aucune mutation n’a prouvé le retour à la normale
+- Contexte technique : React Native / Expo — 10-03-2026
+
+---
+
+<a id="risque-refresh-store-fire-and-forget"></a>
+## Refresh store en fire-and-forget après mutation
+
+### Risques
+
+- L’UI affiche un succès alors que la resynchronisation a échoué
+- État local incohérent avec l’état serveur
+- Erreurs silencieuses impossibles à diagnostiquer
+
+### Symptômes
+
+- Mutation réussie puis store jamais rafraîchi
+- Spinner coupé avant que l’écran soit réellement à jour
+- Données anciennes qui persistent jusqu’au prochain reload
+
+### Bonnes pratiques / mitigations
+
+- `await` explicite du refresh si l’UI dépend du résultat
+- Gestion d’erreur dédiée sur la phase de resynchronisation
+- N’utiliser le fire-and-forget que pour un effet secondaire réellement non bloquant
+- Contexte technique : React Native / Expo — 10-03-2026