docs: capitaliser les patterns valides du 16 mars

10_frontend_patterns_valides.md

@@ -12,7 +12,7 @@ Il sert de **mémoire durable** pour éviter :
 - de redélibérer éternellement sur des sujets déjà tranchés,
 - de propager des “bonnes pratiques” théoriques non éprouvées.
 
-Dernière mise à jour : 12-03-2026
+Dernière mise à jour : 16-03-2026
 
 ---
 
@@ -23,6 +23,7 @@ Dernière mise à jour : 12-03-2026
 - [Formulaire robuste avec validation et erreurs explicites](#pattern-formulaire-robuste)
 - [Navigation réactive post-action async (React / Expo Router)](#pattern-navigation-reactive-post-action-async)
 - [Refresh idempotent sur store de liste paginée](#pattern-refresh-idempotent-liste-paginee)
+- [UI admin légère sur domaine existant](#pattern-ui-admin-legere-domaine-existant)
 
 ---
 
@@ -336,6 +337,52 @@ const handleOAuth = async () => {
 
 ---
 
+<a id="pattern-ui-admin-legere-domaine-existant"></a>
+## Pattern : UI admin légère sur domaine existant
+
+### Synthèse
+
+- **Objectif** : ajouter une capacité interne simple sans ouvrir trop tôt un back-office séparé ni dupliquer la logique métier.
+- **Contexte** : app mobile ou SPA avec un domaine métier déjà structuré et quelques actions internes ponctuelles.
+- **Quand l’utiliser** : publication, activation, modération légère, bascule de statut, action opérateur simple.
+- **Quand l’éviter** : permissions complexes, workflows multiples, audit riche ou volume d’actions qui justifie un vrai espace d’administration.
+
+### Analyse
+
+- **Avantages** :
+  - réutilise le service et le store métier existants
+  - limite le coût de structure pour une capacité admin mince
+  - garde les mutations testables et lisibles
+- **Limites / vigilance** :
+  - ne pas laisser cette approche dériver vers un pseudo back-office implicite
+  - le refresh après mutation doit être explicite sur les vues impactées
+
+### Validation
+
+- Validé le : 10-03-2026
+- Contexte technique : React Native / Expo Router / store de domaine
+
+### Implémentation (exemple minimal)
+
+```txt
+- ajouter une route dédiée minimale pour l’action interne
+- réutiliser le service/store métier existant au lieu de créer une couche parallèle
+- afficher le statut courant avant action
+- bloquer les actions concurrentes avec un flag explicite (`isUpdating*`)
+- déclencher un refresh explicite des vues impactées après succès
+- éviter les mutations en fire-and-forget
+```
+
+### Checklist
+
+- [ ] Route dédiée minimale, pas de mini back-office générique
+- [ ] Réutilisation du domaine métier existant
+- [ ] Garde-fou explicite contre les doubles actions
+- [ ] Refresh explicite après mutation réussie
+- [ ] Tests sur succès, erreur et action concurrente
+
+---
+
 ### Principes transverses
 
 - Un pattern = une responsabilité claire