docs(audit): analyse complète du webUI page par page (620 constats vérifiés)

Annexe générée par un audit multi-agents : pour chaque page, rôle,
tâches utilisateur, appels API tracés jusqu'au handler serveur, et
constats UX / lisibilité / performance / bugs avec preuve fichier:ligne,
vérifiés de façon contradictoire.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MsDJjQrAggcJwbbBtKhgyb

docs/audit-webui/01-dashboard.md

@@ -0,0 +1,569 @@
+# Tableau de bord
+
+_46 constats vérifiés — 9 haute, 23 moyenne, 14 basse._
+
+## Pages analysées
+
+### `/ et /dashboard (desktop, largeur >= 768px)`
+
+**Rôle :** Page d'accueil après connexion. Elle donne une vue d'ensemble du magasin : alertes DLC, 4 compteurs (livraisons du mois, commandes en attente, délai moyen, palettes), commandes en attente, livraisons prévues, publicités à venir, informations internes et tâches à faire.
+
+**Tâches principales de l'utilisateur :**
+- Voir ce qu'il faut traiter aujourd'hui (produits DLC expirés ou proches, commandes en retard, livraisons attendues)
+- Lire les informations / annonces publiées par l'administration
+- (Admin) créer, modifier ou supprimer une information
+- Marquer un produit DLC comme 'stock épuisé' depuis la fenêtre d'alerte, ou reporter l'alerte de 2 h
+- Consulter les tâches ouvertes du magasin
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/user (x5 : RouterProduction, Layout, Sidebar via useAuthSimple, Dashboard, AnnouncementCard) | au montage de chaque composant (fetch dans un useEffect, cache: 'no-cache', non partagé) | server/localAuth.ts:204 (dev) / server/localAuth.production.ts:246 ; req.user vient de deserializeUser -> storage.getUserWithGroups (storage.ts:371) | 5 appels identiques. En production, chaque instance démarre avec user=null, ce qui fausse les requêtes du Dashboard lancées au montage. |
+| GET /api/groups | au montage du Layout (enabled: !!user) | server/routes.ts:970 -> storage.getUserWithGroups + storage.getGroups (storage.ts:432) | Renvoie toutes les colonnes de groups (logo base64, config NocoDB/SMTP). |
+| GET /api/weather/current | au montage du WeatherWidget (en-tête), puis refetchInterval de 30 min | server/routes.ts:5671 -> getWeatherSettings (storage.ts:2891), getWeatherData x2 (storage.ts:2910), puis API Visual Crossing si la donnée manque | Lectures BD et appels externes séquentiels, sans timeout. Rien n'est mis en cache quand l'historique N-1 échoue. |
+| GET /api/stats/monthly?year&month[&storeId si admin] | au montage | server/routes.ts:4155 -> storage.getMonthlyStats (storage.ts:1222), 4 requêtes séquentielles | Résultat 'stats' jamais affiché : requête inutile. |
+| GET /api/stats/yearly?year[&storeId si admin] | au montage | server/routes.ts:4192 -> storage.getYearlyStats (storage.ts:1364), 4 requêtes séquentielles | Seul averageDeliveryTime est utilisé. Au montage, la requête part sans storeId (user=null) et le résultat reste en cache. |
+| GET /api/orders[?storeId si admin] | au montage, puis une 2e fois quand user est chargé (admin avec magasin sélectionné : la clé change) | server/routes.ts:1343 -> storage.getOrders (storage.ts:678) + loadDeliveriesByOrderIds (storage.ts:522) | Tout l'historique, sans limite, avec les livraisons imbriquées et les objets supplier/group complets. |
+| GET /api/deliveries[?storeId si admin] | au montage, puis une 2e fois (même cas que /api/orders) | server/routes.ts:1752 -> storage.getDeliveries (storage.ts:885) + attachOrdersAndCommentCounts | Tout l'historique, alors que la page n'affiche que 2 compteurs et 4 lignes. |
+| GET /api/customer-orders[?storeId si admin] | au montage | server/routes.ts:3486 -> storage.getCustomerOrders (storage.ts:1868) | customerOrderStats est calculé mais jamais affiché : requête inutile. |
+| GET /api/announcements?recent=true[&storeId] | au montage, après le /api/user propre au Dashboard (enabled: !!user) | server/routes.ts:5770 (requête Drizzle inline + N+1 sur users/groups, l. 5815-5866) | Paramètre 'recent' ignoré par le serveur. Filtre de 2 jours fait côté client. |
+| GET /api/announcements[?storeId] | au montage d'AnnouncementCard, après son propre /api/user | server/routes.ts:5770 | Doublon de l'appel précédent sous une autre queryKey. |
+| GET /api/ad-campaigns?year=N-1, N, N+1 | au montage, 3 appels séquentiels (boucle for + await) | server/routes.ts:4595 -> storage.getPublicities (storage.ts:1502) | Télécharge 3 années complètes pour en garder 3 lignes ; groupIds est ignoré côté storage. |
+| GET /api/dlc-products/stats?storeId | au montage, plus une invalidation forcée à chaque montage (useEffect) | server/routes.ts:2831 -> storage.getDlcStats (storage.ts:2224) | Agrégat SQL correct, mais définitions incohérentes avec la liste. |
+| GET /api/dlc-products?status=expires\|expires_soon&storeId | à l'ouverture de la modale DLC (enabled: isOpen && compteur > 0) | server/routes.ts:2797 -> storage.getDlcProducts (storage.ts:1976) | Liste complète sans LIMIT alors que 8 lignes sont affichées. |
+| GET /api/tasks[?storeId si admin] | au montage | server/routes.ts:3193 -> storage.getTasks (storage.ts:2267) | Renvoie [] pour tout non-admin sans storeId (routes.ts:3237-3249). Historique complet, tâches terminées comprises. |
+| PUT /api/dlc-products/:id/stock-epuise | au clic sur 'Stock épuisé' dans la modale DLC | server/routes.ts:3023 | Invalide /api/dlc-products et /api/dlc-products/stats. |
+| POST/PUT/DELETE /api/announcements[/:id] | au clic (admin) dans AnnouncementCard | server/routes.ts:5895 / 5976 / 6027 | La suppression part sans confirmation. L'invalidation ['/api/announcements'] ne touche pas la clé '/api/announcements/recent'. |
+
+**Lisibilité / simplicité :** Page dense : 2 bandeaux DLC, 4 compteurs, 5 cartes et jusqu'à 2 modales automatiques. Rien n'est cliquable : ni compteurs, ni lignes, ni bandeaux, alors que les cartes ont un effet d'ombre au survol. Il n'y a ni état de chargement ni état d'erreur : pendant le chargement, l'utilisateur voit '0', 'Aucune commande en attente' ou 'Toutes les tâches sont terminées', ce qui est faux. Du texte de debug est visible ('(API: NOT_ARRAY)', '(N livraisons totales)'). Certains libellés sont ambigus ('Total palettes', délai calculé sur l'année sans le dire, numéro de publicité affiché à la place de sa désignation). Le badge de jours en attente peut être négatif. Les badges de priorité ont tous la même couleur. La bordure colorée des lignes est invisible (classe border-l-3 inexistante). La modale DLC ne peut pas se fermer avec la croix : elle se rouvre aussitôt. Elle peut aussi s'empiler sur la modale d'annonce. Pour les managers et directeurs, les données ne suivent pas le magasin sélectionné : tâches toujours vides, commandes du 1er magasin, statistiques agrégées sur tous leurs magasins.
+
+### `/ et /dashboard (mobile, largeur < 768px)`
+
+**Rôle :** Accueil simplifié sur téléphone : salutation et date, 4 compteurs (commandes, livraisons, tâches en cours, tâches urgentes), accès rapides et 3 tâches à faire.
+
+**Tâches principales de l'utilisateur :**
+- Voir d'un coup d'œil l'activité du jour
+- Aller vite aux commandes, livraisons, tâches ou au calendrier
+- Voir les prochaines tâches à faire
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/user (x5 : RouterProduction, MobileApp, DashboardPage, MobileLayout, MobileBottomNav) | au montage, puis 3 de plus à chaque navigation (MobileLayout et MobileBottomNav sont remontés par chaque page) | server/localAuth.ts:204 / localAuth.production.ts:246 -> getUserWithGroups | Les requêtes de la page attendent le /api/user de leur propre instance (enabled: !!user) : une cascade de plus. |
+| GET /api/groups | au montage de MobileApp | server/routes.ts:970 | OK |
+| GET /api/stats/dashboard?storeId | au montage | aucun : la route n'existe pas dans server/routes.ts, réponse 404 | Appel mort ; 'stats' et 'isLoading' ne sont jamais utilisés. |
+| GET /api/tasks?storeId | au montage | server/routes.ts:3193 -> storage.getTasks (storage.ts:2267) | Même queryKey ['/api/tasks', storeId] que le Dashboard desktop et la page Tâches, mais pas la même URL. |
+| GET /api/orders?storeId&date=yyyy-MM-dd | au montage | server/routes.ts:1343 (ne lit que startDate/endDate, l. 1351) -> getOrders (storage.ts:678) | Paramètre 'date' ignoré : tout l'historique est téléchargé et affiché comme 'Commandes'. |
+| GET /api/deliveries?storeId&date=yyyy-MM-dd | au montage | server/routes.ts:1752 (date ignorée) -> getDeliveries (storage.ts:885) | Idem : total historique affiché comme 'Livraisons'. |
+
+**Lisibilité / simplicité :** Écran simple et lisible : salutation, grosses tuiles, accès rapides. Mais les chiffres 'Commandes' et 'Livraisons' sont des totaux historiques présentés comme l'activité du jour. Il n'y a pas d'état de chargement : '0' s'affiche d'abord. Il n'y a aucune alerte DLC ni information, contrairement au desktop, alors que les employés sur téléphone en ont besoin. Les accès rapides reprennent 3 des 4 boutons de la barre du bas. Leurs libellés au singulier ('Commande', 'Tâche') laissent croire à une création. 'Agenda' s'appelle 'Calendrier' dans la barre du bas. Les liens <a href> rechargent toute l'application.
+
+### `En-tête desktop (toutes les routes) : WeatherWidget + DateWidget`
+
+**Rôle :** Affiche dans l'en-tête la ville, la météo du jour comparée à la même date l'an dernier, et la date du jour.
+
+**Tâches principales de l'utilisateur :**
+- Comparer la météo du jour à celle de l'an dernier (prévision d'affluence)
+- Voir la date du jour
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/weather/current | au montage du Layout, puis polling toutes les 30 min ; retry: 1 | server/routes.ts:5671 -> getWeatherSettings / getWeatherData / getNearestWeatherData (storage.ts:2891-2941) + weatherService.fetchCurrentWeather / fetchPreviousYearWeather (weatherService.ts:24, 45) | Répond 404 si le service n'est pas configuré, ce qui déclenche un retry inutile. Appels BD et externes séquentiels, sans timeout. |
+
+**Lisibilité / simplicité :** Bloc compact, mais 3 colonnes (Aujourd'hui / Année dernière / Différence) prennent beaucoup de place dans l'en-tête. Le texte 'Chargement météo...' apparaît puis disparaît si le service n'est pas configuré, ce qui décale l'en-tête. La date est calculée au rendu et n'est jamais rafraîchie après minuit. La traduction des conditions météo est faite deux fois (client et serveur).
+
+### `/calendar (StatsPanel)`
+
+**Rôle :** Panneau flottant 'Statistiques du mois' sur le calendrier : commandes, livraisons, palettes, colis, délai moyen.
+
+**Tâches principales de l'utilisateur :**
+- Voir les volumes du mois affiché dans le calendrier
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/stats/monthly?year&month&storeId | au montage et à chaque changement de mois | server/routes.ts:4155 -> storage.getMonthlyStats (storage.ts:1222) | queryKey [statsUrl, storeId] différente de celle du Dashboard ['/api/stats/monthly', storeId] pour la même donnée. Sans placeholderData, un squelette s'affiche à chaque changement de mois. |
+
+**Lisibilité / simplicité :** Panneau fixé en bas à droite (min-w-80), qu'on ne peut pas replier : il masque une partie du calendrier, surtout sur tablette. Les valeurs 'Palettes' et 'Colis' sont fausses (somme de toutes les unités, et nombre de livraisons). 'Commandes en attente' est un total historique affiché sous le titre 'Statistiques du mois'.
+
+### `(non routé) RecentTasksCard, ResponsiveDashboard`
+
+**Rôle :** Composants prévus pour le tableau de bord mais importés nulle part : code mort.
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/tasks?storeId | jamais : le composant n'est pas monté | server/routes.ts:3193 | fetch sans credentials ni contrôle res.ok. |
+
+**Lisibilité / simplicité :** Pas visible par l'utilisateur. Il entretient seulement de la confusion pour les développeurs : troisième tri et troisième mise en forme des priorités de tâches.
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [DASH-01](#dash-01) | haute | bug | S | Pour les non-admins, le magasin sélectionné n'est pas envoyé : tâches toujours vides, données d'un autre magasin | `client/src/pages/Dashboard.tsx:285` |
+| [DASH-02](#dash-02) | haute | bug | S | La fenêtre d'alerte DLC se rouvre aussitôt qu'on la ferme (croix, Échap, clic à l'extérieur) | `client/src/pages/Dashboard.tsx:273` |
+| [DASH-03](#dash-03) | haute | bug | M | En production, user vaut null au montage du Dashboard : requêtes envoyées avec le mauvais périmètre puis téléchargées deux fois | `client/src/hooks/useAuthUnified.ts:23` |
+| [DASH-05](#dash-05) | haute | perf-api | L | L'historique complet des commandes et livraisons est téléchargé pour afficher 4 compteurs et 2 courtes listes | `client/src/pages/Dashboard.tsx:84` |
+| [DASH-07](#dash-07) | haute | perf-serveur | M | Chaque ligne embarque l'objet magasin complet, logo base64 et configuration NocoDB/SMTP compris | `server/storage.ts:693` |
+| [DASH-08](#dash-08) | haute | perf-serveur | S | Pas de compression HTTP ni de cache long sur les assets, et le middleware de compression maison est faux et inutilisé | `server/index.production.ts:143` |
+| [DASH-22](#dash-22) | haute | ux-simplicite | M | Aucun état de chargement ni d'erreur : l'écran affiche de fausses informations pendant le chargement | `client/src/pages/Dashboard.tsx:435` |
+| [DASH-28](#dash-28) | haute | bug | S | Mobile : 'Commandes' et 'Livraisons' affichent des totaux historiques (paramètre date ignoré), et un appel part vers une route inexistante | `client/src/pages/mobile/DashboardPage.tsx:101` |
+| [DASH-32](#dash-32) | haute | perf-bundle | M | Aucun découpage du code : les 30+ pages desktop et mobile et recharts sont chargées dès l'accueil | `client/src/components/RouterProduction.tsx:5` |
+| [DASH-04](#dash-04) | moyenne | perf-api | M | /api/user appelé 5 fois au chargement du tableau de bord, et 3 fois de plus à chaque navigation mobile | `client/src/hooks/useAuthUnified.ts:160` |
+| [DASH-06](#dash-06) | moyenne | perf-api | S | Deux requêtes dont le résultat n'est jamais affiché : /api/stats/monthly et /api/customer-orders | `client/src/pages/Dashboard.tsx:28` |
+| [DASH-09](#dash-09) | moyenne | perf-serveur | M | Chaque route relit l'utilisateur et ses magasins (2 requêtes) déjà chargés par passport | `server/routes.ts:1345` |
+| [DASH-10](#dash-10) | moyenne | perf-serveur | S | Statistiques mensuelles et annuelles : 4 requêtes SQL séquentielles, non mises en cache | `server/storage.ts:1270` |
+| [DASH-11](#dash-11) | moyenne | perf-api | S | Publicités à venir : 3 appels séquentiels qui téléchargent 3 années complètes pour en afficher 3 | `client/src/pages/Dashboard.tsx:205` |
+| [DASH-12](#dash-12) | moyenne | perf-serveur | S | Informations : requête N+1 (auteur et magasin chargés un par un) et contenu complet écrit dans les logs | `server/routes.ts:5815` |
+| [DASH-13](#dash-13) | moyenne | bug | S | Les non-admins voient les informations de tous les magasins, et le paramètre 'recent' est ignoré | `server/routes.ts:5797` |
+| [DASH-15](#dash-15) | moyenne | perf-client | S | Changer de magasin relance d'abord les requêtes de l'ancien magasin, puis affiche des zéros | `client/src/components/Layout.tsx:138` |
+| [DASH-17](#dash-17) | moyenne | perf-client | S | Calculs lourds refaits à chaque rendu, sans useMemo, et tri qui modifie le cache React Query | `client/src/pages/Dashboard.tsx:293` |
+| [DASH-18](#dash-18) | moyenne | bug | S | Le badge 'jours en attente' affiche des valeurs négatives et n'a pas de légende | `client/src/pages/Dashboard.tsx:506` |
+| [DASH-19](#dash-19) | moyenne | coherence-design | S | Badges de priorité des tâches : le variant est passé dans className, donc toutes les priorités ont la même couleur | `client/src/pages/Dashboard.tsx:687` |
+| [DASH-21](#dash-21) | moyenne | lisibilite | S | Texte de debug technique visible par les utilisateurs | `client/src/pages/Dashboard.tsx:642` |
+| [DASH-23](#dash-23) | moyenne | ux-simplicite | M | Rien n'est cliquable alors que tout réagit au survol | `client/src/pages/Dashboard.tsx:430` |
+| [DASH-24](#dash-24) | moyenne | ux-simplicite | M | Alertes DLC affichées en double (bandeaux + fenêtre), et deux fenêtres automatiques peuvent s'empiler | `client/src/pages/Dashboard.tsx:409` |
+| [DASH-25](#dash-25) | moyenne | lisibilite | S | Libellés ambigus, majuscules à l'anglaise, et numéro de publicité affiché à la place de la désignation | `client/src/pages/Dashboard.tsx:476` |
+| [DASH-26](#dash-26) | moyenne | bug | S | Statistiques 'Palettes' et 'Colis' fausses : unités mélangées et nombre de livraisons présenté comme nombre de colis | `server/storage.ts:1310` |
+| [DASH-27](#dash-27) | moyenne | bug | S | Compteurs DLC incohérents avec la liste de la fenêtre : produits du jour comptés deux fois, 'stock épuisé' traités différemment | `server/storage.ts:2245` |
+| [DASH-29](#dash-29) | moyenne | perf-client | M | Chaque page mobile remonte l'en-tête et la barre du bas, ce qui relance /api/user à chaque navigation | `client/src/pages/mobile/DashboardPage.tsx:136` |
+| [DASH-30](#dash-30) | moyenne | perf-client | S | Les liens 'Accès rapide' et le bouton de la fenêtre DLC rechargent toute l'application | `client/src/pages/mobile/DashboardPage.tsx:187` |
+| [DASH-31](#dash-31) | moyenne | ux-simplicite | M | Mobile : les accès rapides doublonnent la barre du bas, avec des libellés trompeurs, et les alertes utiles manquent | `client/src/pages/mobile/DashboardPage.tsx:179` |
+| [DASH-35](#dash-35) | moyenne | perf-serveur | S | Météo : appels séquentiels sans timeout, et l'API externe est rappelée à chaque requête si l'historique échoue | `server/routes.ts:5683` |
+| [DASH-37](#dash-37) | moyenne | ux-simplicite | S | Informations : suppression sans confirmation avec une icône 'X', boutons de 24 px sans libellé, texte non tronqué | `client/src/components/AnnouncementCard.tsx:356` |
+| [DASH-38](#dash-38) | moyenne | bug | M | Mêmes queryKeys pour des URL différentes (et l'inverse) : les données affichées dépendent de la page visitée en premier | `client/src/pages/Dashboard.tsx:282` |
+| [DASH-14](#dash-14) | basse | perf-api | S | Les informations sont récupérées deux fois sous deux clés différentes, qui ne s'invalident pas ensemble | `client/src/pages/Dashboard.tsx:97` |
+| [DASH-16](#dash-16) | basse | perf-client | S | Les requêtes DLC sont invalidées à chaque montage du tableau de bord, ce qui annule le cache | `client/src/pages/Dashboard.tsx:23` |
+| [DASH-20](#dash-20) | basse | coherence-design | S | La classe 'border-l-3' n'existe pas dans Tailwind 3 : la barre colorée à gauche des lignes est invisible | `client/src/pages/Dashboard.tsx:510` |
+| [DASH-33](#dash-33) | basse | perf-client | S | Script de bannière Replit (domaine tiers) chargé en production | `client/index.html:19` |
+| [DASH-34](#dash-34) | basse | accessibilite | S | Page déclarée en anglais et zoom bloqué sur mobile | `client/index.html:5` |
+| [DASH-36](#dash-36) | basse | ux-simplicite | S | Météo non configurée : retry inutile puis disparition du bloc, avec décalage de l'en-tête | `client/src/components/WeatherWidget.tsx:121` |
+| [DASH-39](#dash-39) | basse | lisibilite | S | Fenêtre DLC : formulations techniques ou alarmistes, et '0 jour(s)' | `client/src/components/DlcAlertModal.tsx:178` |
+| [DASH-40](#dash-40) | basse | ux-simplicite | S | 'Livraisons à venir' inclut les livraisons en retard, et les tâches sont triées différemment sur chaque écran | `client/src/pages/Dashboard.tsx:310` |
+| [DASH-41](#dash-41) | basse | accessibilite | S | Textes secondaires en gris clair 'text-gray-400' de petite taille, sous le seuil de contraste | `client/src/pages/Dashboard.tsx:568` |
+| [DASH-42](#dash-42) | basse | ux-simplicite | S | Panneau de statistiques fixe et non repliable qui masque le calendrier | `client/src/components/StatsPanel.tsx:54` |
+| [DASH-43](#dash-43) | basse | bug | S | La date de l'en-tête n'est jamais rafraîchie | `client/src/components/DateWidget.tsx:16` |
+| [DASH-44](#dash-44) | basse | perf-serveur | S | Logs volumineux à chaque appel dans les chemins les plus sollicités | `server/routes.ts:3263` |
+| [DASH-45](#dash-45) | basse | dette-code | S | Code mort : RecentTasksCard, ResponsiveDashboard, server/cache.ts, imports et variables inutilisés | `client/src/components/tasks/RecentTasksCard.tsx:25` |
+| [DASH-46](#dash-46) | basse | dette-code | S | Configurations de priorités et de types d'information dupliquées, avec des correspondances contre-intuitives | `client/src/pages/Dashboard.tsx:139` |
+
+### DASH-01
+
+**Pour les non-admins, le magasin sélectionné n'est pas envoyé : tâches toujours vides, données d'un autre magasin** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:285`
+- **Constat :** Dashboard.tsx:285 'if (selectedStoreId && user?.role === 'admin') params.append("storeId", ...)'. Même condition l. 37, 62, 79-81. Côté serveur, routes.ts:3237-3249 : non-admin sans storeId -> 'returning empty result' (res.json([])). routes.ts:1410-1420 : manager/directeur sans storeId -> 'groupIds = [userGroupIds[0]]'. routes.ts:4170-4178 : stats -> 'groupIds = userGroupIds' (tous les magasins). Les pages Commandes et Livraisons envoient storeId pour tous les rôles (Orders.tsx:72-73 'CRITICAL FIX').
+- **Impact :** Un manager ou un directeur voit toujours 'Aucune tâche en cours / Toutes les tâches sont terminées'. Les commandes et livraisons affichées sont celles de son 1er magasin, quel que soit le magasin choisi, et les statistiques sont agrégées sur tous ses magasins. L'alerte DLC, elle, suit le magasin sélectionné : la page mélange 3 périmètres différents.
+- **Recommandation :** Envoyer storeId pour tous les rôles dès qu'un magasin est sélectionné, comme dans Orders.tsx et Tasks.tsx. Centraliser la construction des URL dans un hook (ex. useStoreScopedUrl('/api/orders')) utilisé par toutes les pages, pour éviter de nouvelles divergences.
+
+### DASH-02
+
+**La fenêtre d'alerte DLC se rouvre aussitôt qu'on la ferme (croix, Échap, clic à l'extérieur)** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:273`
+- **Constat :** Dashboard.tsx:276-278 'handleCloseDlcAlertModal = () => setShowDlcAlertModal(false)'. L'effet l. 244-273 dépend de showDlcAlertModal : 'if (shouldShowDlcModal && !showDlcAlertModal) { ... } else { setShowDlcAlertModal(true); }' tant qu'aucun snooze n'est présent dans localStorage. Seul 'Traiter plus tard (2h)' (DlcAlertModal.tsx:106-112) écrit ce snooze.
+- **Impact :** Un employé ou un manager ne peut pas fermer la fenêtre normalement : elle revient instantanément. Il est bloqué jusqu'à trouver le bouton 'Traiter plus tard (2h)', ce qui est vécu comme un bug.
+- **Recommandation :** À la fermeture, mémoriser un rejet pour la session (sessionStorage 'dlcAlertDismissed' ou snooze court). Déclencher l'ouverture automatique une seule fois par chargement (useRef 'alreadyShown'), sans dépendre de showDlcAlertModal.
+
+### DASH-03
+
+**En production, user vaut null au montage du Dashboard : requêtes envoyées avec le mauvais périmètre puis téléchargées deux fois** — bug, sévérité haute, effort M
+
+- **Fichier :** `client/src/hooks/useAuthUnified.ts:23`
+- **Constat :** useAuthUnified.ts:23-24 'const [productionUser, setProductionUser] = useState<any>(null)' : chaque instance refait son fetch('/api/user') (l. 160). Au montage, Dashboard.tsx:79 construit ordersUrl sans storeId car user?.role est undefined, puis avec storeId une fois user chargé : la clé change et l'historique complet est retéléchargé. Pour /api/stats/yearly (l. 55) et /api/tasks (l. 282), la queryKey ne contient pas le rôle : le résultat 'tous magasins' obtenu avec user=null reste en cache sous la clé du magasin sélectionné.
+- **Impact :** Pour un admin avec un magasin sélectionné, l'historique de tous les magasins (commandes, livraisons, commandes clients) est téléchargé puis jeté. Le délai moyen et la liste des tâches affichent les chiffres de tous les magasins au lieu du magasin choisi.
+- **Recommandation :** Faire de useAuthUnified un simple useQuery(['/api/user'], { staleTime: Infinity }) partagé par le cache, ou un AuthContext fourni par RouterProduction. user est alors disponible dès le 1er rendu. Ajouter 'enabled: !!user' aux requêtes du Dashboard qui dépendent du rôle.
+
+### DASH-05
+
+**L'historique complet des commandes et livraisons est téléchargé pour afficher 4 compteurs et 2 courtes listes** — perf-api, sévérité haute, effort L
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:84`
+- **Constat :** Dashboard.tsx:84-90 'useQuery({ queryKey: [ordersUrl, selectedStoreId] })' sur '/api/orders' et '/api/deliveries' sans filtre de date. Ils servent à calculer côté client deliveredThisMonth (l. 318), totalPalettes (l. 328), pendingOrders (l. 302) et upcomingDeliveries (.slice(0, 4), l. 313). Côté serveur, storage.getOrders (storage.ts:678-723) : pas de LIMIT, livraisons imbriquées via loadDeliveriesByOrderIds. storage.getDeliveries (885-926) : pas de LIMIT, commande imbriquée et nombre de commentaires. getTasks (storage.ts:2267) renvoie aussi toutes les tâches, terminées comprises, pour en afficher 5.
+- **Impact :** Le temps de chargement et la mémoire grandissent avec l'historique (des Mo de JSON après quelques années), surtout sur réseau magasin ou 4G. Le serveur sérialise des milliers de lignes à chaque ouverture du tableau de bord.
+- **Recommandation :** Créer GET /api/dashboard/summary?storeId=. Il renverrait, calculés en SQL (COUNT/SUM avec WHERE et LIMIT) et lancés en parallèle (Promise.all) : nombre de commandes en attente, livraisons et palettes reçues ce mois, délai moyen, les 10 commandes en attente les plus anciennes, les 4 prochaines livraisons planifiées, les 3 prochaines publicités, les 5 tâches ouvertes prioritaires, les compteurs DLC et la dernière information. Une seule requête légère au lieu de 11.
+
+### DASH-07
+
+**Chaque ligne embarque l'objet magasin complet, logo base64 et configuration NocoDB/SMTP compris** — perf-serveur, sévérité haute, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:693`
+- **Constat :** storage.ts:692-693 'supplier: suppliers, group: groups,' dans getOrders. Même chose dans loadDeliveriesByOrderIds (l. 552-553), getDeliveries (l. 912-913), loadOrdersByIds, getCustomerOrders (l. 1868), getDlcProducts (l. 1980), getTasks (l. 2271) et getPublicities (l. 1536). Or shared/schema.ts:67 'logo: text("logo"), // Logo en data URI (data:image/png;base64,...)', l. 63 webhookUrl, l. 74 smtpPassword. Pour masquer smtpPassword, routes.ts:168 copie en profondeur chaque réponse : 'res.json = (body) => originalJson(stripSmtpPassword(body))'.
+- **Impact :** Le logo base64 (souvent 10 à 100 Ko) est répété dans chaque commande, chaque livraison imbriquée et chaque produit DLC : la taille des réponses est multipliée et le parse JSON côté navigateur ralentit. Le serveur reparcourt et recopie tout le JSON à chaque réponse. La configuration interne (webhook, NocoDB, hôte et utilisateur SMTP) est exposée à tous les utilisateurs.
+- **Recommandation :** Définir des projections par usage. Pour les listes (commandes, tâches, DLC, commandes clients, publicités) : { id, name, color }. Pour les livraisons et avoirs utilisés en rapprochement : ajouter webhookUrl, nocodbConfigId et nocodbTableName. Ne jamais sélectionner logo ni smtp*. Vérifier chaque appelant client par grep sur `.group?.` avant de changer une projection. Garder stripSmtpPassword global comme filet de sécurité. Son coût baissera de lui-même avec des objets plus petits.
+
+### DASH-08
+
+**Pas de compression HTTP ni de cache long sur les assets, et le middleware de compression maison est faux et inutilisé** — perf-serveur, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/index.production.ts:143`
+- **Constat :** server/index.production.ts:27-28 : express.json et urlencoded, aucun middleware compression. l. 143 'app.use('/assets', express.static(join(publicPath, 'assets')))' sans maxAge ni immutable. server/cache.ts:93-100 : setupCompression pose 'Content-Encoding: gzip' sans rien compresser, et n'est importé nulle part (grep vide). Aucun nginx/gzip dans le dépôt. Assets dist/public/assets : index 1,08 Mo + vendor-charts 410 Ko + vendor-react 146 Ko + CSS 121 Ko servis bruts.
+- **Impact :** Environ 1,8 Mo de JS/CSS non compressé au premier chargement (environ 450 Ko en gzip). Les assets sont revalidés à chaque visite, et les grosses réponses JSON (commandes, livraisons) circulent 5 à 10 fois plus lourdes que nécessaire.
+- **Recommandation :** (1) Mécanique : servir /assets avec express.static(..., { maxAge: '1y', immutable: true }) dans index.production.ts:143, sans toucher au static '/' ni à index.html. Supprimer setupCompression de server/cache.ts, voire tout le fichier (DASH-45). (2) Ajouter la dépendance compression et @types/compression, puis app.use(compression()) avant registerProductionRoutes dans index.production.ts et dans index.ts. Vérifier au préalable la configuration gzip du nginx externe (réseau nginx_default).
+
+### DASH-22
+
+**Aucun état de chargement ni d'erreur : l'écran affiche de fausses informations pendant le chargement** — ux-simplicite, sévérité haute, effort M
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:435`
+- **Constat :** Dashboard.tsx ne lit jamais isLoading ni isError (grep vide). Pendant le chargement : l. 435 '{deliveredThisMonth}' = 0, l. 533 'Aucune commande en attente', l. 701-702 'Aucune tâche en cours / Toutes les tâches sont terminées'. mobile/DashboardPage.tsx:63 récupère isLoading sans s'en servir. Les queryFn qui échouent renvoient [] ou null en silence (DashboardPage.tsx:88, 106, 124).
+- **Impact :** L'utilisateur peut croire que tout est traité alors que les données ne sont pas encore arrivées ou que le serveur est en erreur. C'est risqué pour des décisions opérationnelles (DLC, retards).
+- **Recommandation :** Afficher un squelette (Skeleton shadcn) par carte tant que isLoading est vrai. En cas d'erreur, afficher un message clair dans la carte ('Impossible de charger les commandes' + bouton 'Réessayer'). Ne montrer les messages d'état vide qu'après un chargement réussi.
+
+### DASH-28
+
+**Mobile : 'Commandes' et 'Livraisons' affichent des totaux historiques (paramètre date ignoré), et un appel part vers une route inexistante** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/mobile/DashboardPage.tsx:101`
+- **Constat :** DashboardPage.tsx:101 'params.append('date', format(new Date(), 'yyyy-MM-dd'))' puis 'fetch(`/api/orders?${params}`)'. Le serveur ne lit que startDate/endDate : routes.ts:1351 'const { startDate, endDate, storeId } = req.query;'. Même chose pour /api/deliveries (l. 119-121). DashboardPage.tsx:69 'fetch(`/api/stats/dashboard?...`)' : aucune route de ce nom dans server/routes.ts (404), et 'stats' n'est jamais utilisé.
+- **Impact :** Sur téléphone, l'employé voit par exemple '1 254 Commandes' en pensant que c'est l'activité du jour. L'application télécharge tout l'historique juste pour compter les lignes (.length), ce qui est lent en 4G, et fait un appel 404 inutile.
+- **Recommandation :** Supprimer l'appel /api/stats/dashboard. Utiliser 'startDate=endDate=aujourd'hui', ou mieux l'endpoint de synthèse (DASH-05) qui renvoie directement les compteurs. Libeller 'Commandes du jour' et 'Livraisons du jour'.
+
+### DASH-32
+
+**Aucun découpage du code : les 30+ pages desktop et mobile et recharts sont chargées dès l'accueil** — perf-bundle, sévérité haute, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:5`
+- **Constat :** RouterProduction.tsx:5-44 : imports statiques de toutes les pages (Analytics, BLReconciliation, Avoirs, DatabaseDebug… et les 11 pages mobiles). Aucun React.lazy dans client/src (grep vide). vite.config.ts:41-46 : manualChunks 'vendor-charts': ['recharts'], que index.html précharge (modulepreload). Build : dist/public/assets/index-*.js = 1 081 745 octets, vendor-charts = 410 243 octets.
+- **Impact :** Environ 1,7 Mo de JS à télécharger, parser et exécuter avant d'afficher l'accueil, alors que le tableau de bord n'utilise ni graphiques ni la plupart des pages. Premier affichage lent sur les PC de caisse et sur mobile.
+- **Recommandation :** Charger les pages secondaires avec React.lazy dans un <Suspense fallback={<PageSkeleton/>}>, en gardant Dashboard, AuthPage et la page mobile d'accueil en import direct. Ajouter un gestionnaire d'erreur de chargement de chunk (rechargement unique de la page). Retirer 'vendor-charts' de manualChunks, ou passer à une fonction manualChunks qui n'y place que node_modules/recharts et d3-*. Vérifier après le build que index.html ne précharge plus ce chunk.
+
+### DASH-04
+
+**/api/user appelé 5 fois au chargement du tableau de bord, et 3 fois de plus à chaque navigation mobile** — perf-api, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/hooks/useAuthUnified.ts:160`
+- **Constat :** useAuthUnified.ts:160 'const response = await fetch('/api/user', { credentials: 'include', cache: 'no-cache', ...' dans un useEffect propre à chaque instance. Instances sur le desktop : RouterProduction, Layout, Dashboard, AnnouncementCard, plus useAuthSimple dans Sidebar.tsx:44. Sur mobile : RouterProduction, MobileApp, DashboardPage, MobileLayout, MobileBottomNav. Côté serveur, chaque appel coûte la session + getUserWithGroups dans deserializeUser (localAuth.production.ts:193-196) + de nouveau getUserWithGroups dans localAuth.ts:211.
+- **Impact :** Environ 5 allers-retours et 20 à 25 requêtes SQL de plus à chaque ouverture. Sur mobile, les requêtes de la page attendent le /api/user de leur propre instance, ce qui ajoute une étape à la cascade et retarde l'affichage.
+- **Recommandation :** Une seule source d'auth (useQuery partagé ou contexte), comme pour DASH-03. Supprimer useAuthSimple au profit du même hook.
+
+### DASH-06
+
+**Deux requêtes dont le résultat n'est jamais affiché : /api/stats/monthly et /api/customer-orders** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:28`
+- **Constat :** Dashboard.tsx:28 'const { data: stats } = useQuery({ queryKey: ['/api/stats/monthly', ...' : 'stats' n'est utilisé nulle part dans le JSX. Dashboard.tsx:92 'const { data: customerOrders = [] } = useQuery(...)' : il ne sert qu'à customerOrderStats (l. 380-387), jamais rendu. recentOrders (l. 293-299) et ordersByStatus (l. 372-377) ne sont pas utilisés non plus.
+- **Impact :** 2 requêtes HTTP de plus, dont l'historique complet des commandes clients (storage.ts:1868, sans LIMIT), plus 4 requêtes SQL séquentielles pour les stats mensuelles, pour rien.
+- **Recommandation :** Supprimer ces deux useQuery et les variables mortes recentOrders, ordersByStatus et customerOrderStats.
+
+### DASH-09
+
+**Chaque route relit l'utilisateur et ses magasins (2 requêtes) déjà chargés par passport** — perf-serveur, sévérité moyenne, effort M
+
+- **Fichier :** `server/routes.ts:1345`
+- **Constat :** routes.ts:1345 'const user = await storage.getUserWithGroups(req.user.claims ? req.user.claims.sub : req.user.id);', répété l. 1754, 2799, 2833, 3195, 3488, 4157, 4194, 4597 et 5775. Or localAuth.production.ts:193-196 'passport.deserializeUser(async (id) => { const user = await storage.getUserWithGroups(id); ...' : req.user est déjà un UserWithGroups. Et getUserWithGroups (storage.ts:371-405) fait 2 requêtes séquentielles (getUser puis user_groups JOIN groups).
+- **Impact :** Par requête API : session + 2 + 2 requêtes SQL séquentielles avant la logique métier. Sur le tableau de bord (environ 20 appels), cela fait environ 80 requêtes SQL inutiles et autant de latence ajoutée.
+- **Recommandation :** Introduire un helper `getCurrentUser(req): UserWithGroups` qui renvoie req.user. L'appliquer d'abord aux routes chaudes du tableau de bord (orders, deliveries, tasks, stats, dlc stats, ad-campaigns, announcements), puis progressivement. Réécrire getUserWithGroups en une requête (users LEFT JOIN user_groups LEFT JOIN groups) en conservant exactement le format { ...user, userGroups: [{ userId, groupId, group: { id, name, color, createdAt, updatedAt } }] }.
+
+### DASH-10
+
+**Statistiques mensuelles et annuelles : 4 requêtes SQL séquentielles, non mises en cache** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:1270`
+- **Constat :** storage.ts:1270 'const ordersResult = await db...', l. 1276 'const deliveriesResult = await db...', l. 1287 'const pendingResult = await db...', l. 1308 'const deliveriesStatsResult = await db...' : 4 await successifs indépendants. Même schéma dans getYearlyStats (l. 1409, 1415, 1426, 1446), dont le Dashboard n'utilise que averageDeliveryTime (Dashboard.tsx:317).
+- **Impact :** La latence de l'endpoint vaut la somme de 4 allers-retours BD au lieu du plus long. Les statistiques annuelles, qui bougent peu, sont recalculées à chaque ouverture.
+- **Recommandation :** Auto : seulement Promise.all sur les 4 requêtes de getMonthlyStats et de getYearlyStats. Le cache mémoire est à décider séparément, avec invalidation sur création, modification ou validation de commande et de livraison.
+
+### DASH-11
+
+**Publicités à venir : 3 appels séquentiels qui téléchargent 3 années complètes pour en afficher 3** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:205`
+- **Constat :** Dashboard.tsx:202-219 'const years = [currentYear - 1, currentYear, currentYear + 1]; for (const year of years) { ... const response = await fetch(`/api/ad-campaigns?${params}`) ...' puis un filtre et un tri côté client (l. 222-224), et '.slice(0, 3)' au rendu (l. 584). Côté serveur, getPublicities (storage.ts:1502-1560) ignore groupIds et associe les participations par 'participations.filter((p) => p.publicityId === publicity.id)' (l. 1552-1553), soit O(n×m).
+- **Impact :** 3 allers-retours en cascade (l'année N-1 ne peut pas contenir de publicité future), et des centaines de publicités avec leurs participations (et le magasin complet, cf. DASH-07) transférées pour 3 lignes.
+- **Recommandation :** Ajouter GET /api/ad-campaigns/upcoming?limit=3 : WHERE start_date > CURRENT_DATE ORDER BY start_date LIMIT 3 (l'index idx_publicities_start_date existe déjà, migrations/0000_flashy_blur.sql:260). En attendant, faire les appels N et N+1 en Promise.all et supprimer N-1. Côté storage, grouper les participations dans une Map.
+
+### DASH-12
+
+**Informations : requête N+1 (auteur et magasin chargés un par un) et contenu complet écrit dans les logs** — perf-serveur, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:5815`
+- **Constat :** routes.ts:5815 'messages.map(async (message) => { ... const [userResult] = await db.select({...}).from(users).where(eq(users.username, message.createdBy));' (l. 5821) puis 'const [groupResult] = await db.select().from(groups).where(eq(groups.id, message.storeId));' (l. 5852). l. 5811 : 'console.log('🔍 [PRODUCTION] Raw messages from DB:', messages.length, 'items:', messages);'.
+- **Impact :** Jusqu'à 10 requêtes SQL de plus par appel, et cet appel est fait 2 fois par ouverture (DASH-14). Le select().from(groups) ramène aussi le logo base64. Les logs contiennent le texte intégral des annonces.
+- **Recommandation :** Une requête dashboardMessages LEFT JOIN users ON users.username = created_by LEFT JOIN groups ON groups.id = store_id. Sélectionner users.id, username, firstName, lastName, name et groups.id, name. Recalculer `author` (même logique de displayName et même repli) et `group` ({ id, name } ou null), pour garder exactement le format de réponse actuel. Supprimer les console.log l.5773, 5779, 5811, 5820, 5827 et 5865.
+
+### DASH-13
+
+**Les non-admins voient les informations de tous les magasins, et le paramètre 'recent' est ignoré** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:5797`
+- **Constat :** routes.ts:5797 'if (user.role === 'admin' && req.query.storeId) { query = query.where(or(eq(dashboardMessages.storeId, storeId), isNull(dashboardMessages.storeId))) }' : aucun filtre pour les autres rôles. Le Dashboard envoie 'recent=true' (Dashboard.tsx:104), que le serveur ne lit jamais, et refiltre sur 2 jours côté client (l. 117-124).
+- **Impact :** Un employé du magasin A voit les informations destinées au magasin B, ce qui crée de la confusion sur les consignes à appliquer. Avec la limite de 5, des informations globales peuvent aussi être évincées par celles d'autres magasins.
+- **Recommandation :** Pour les non-admins, filtrer 'store_id IS NULL OR store_id IN (userGroupIds)', ou sur le magasin sélectionné s'il est autorisé. Gérer 'recent' côté SQL (created_at >= now() - interval '2 days') ou retirer ce paramètre.
+
+### DASH-15
+
+**Changer de magasin relance d'abord les requêtes de l'ancien magasin, puis affiche des zéros** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/Layout.tsx:138`
+- **Constat :** Layout.tsx:138-146 'queryClient.invalidateQueries({ predicate: ... includes('/api/orders') || ... '/api/deliveries' || '/api/stats/monthly' || '/api/tasks' })' est appelé avant 'setSelectedStoreId(newStoreId)' (l. 154). Les requêtes encore actives, qui portent la clé de l'ancien magasin, sont donc refetchées. Toutes ces clés contiennent déjà selectedStoreId, et aucune requête du Dashboard n'a de placeholderData.
+- **Impact :** À chaque changement de magasin, l'historique complet des commandes et livraisons de l'ancien magasin est retéléchargé pour rien. Ensuite, l'écran affiche '0' et 'Aucune...' le temps du nouveau chargement.
+- **Recommandation :** Auto : supprimer seulement l'appel invalidateQueries de Layout.tsx:138-146. L'ajout de placeholderData: keepPreviousData, avec un indicateur 'Mise à jour…', est à traiter séparément comme décision produit.
+
+### DASH-17
+
+**Calculs lourds refaits à chaque rendu, sans useMemo, et tri qui modifie le cache React Query** — perf-client, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:293`
+- **Constat :** Dashboard.tsx:293-294 'const recentOrders = Array.isArray(allOrders) ? allOrders.sort(...)' : .sort() trie sur place le tableau stocké dans le cache, partagé avec la page Commandes pour l'admin. Puis 4 passes .filter sur allOrders (l. 302, 316, 373-375), 2 sur allDeliveries (l. 318, 328) et 5 sur customerOrders (l. 381-385), avec safeDate() à chaque comparaison. Le composant est re-rendu à chaque fin d'une des environ 12 requêtes.
+- **Impact :** Sur un historique de plusieurs milliers de lignes, des dizaines de millisecondes de calcul par rendu, répétées une douzaine de fois au chargement : interface saccadée sur les PC de magasin modestes. La mutation du cache peut aussi changer l'ordre d'une autre page.
+- **Recommandation :** Regrouper les dérivations dans un useMemo([allOrders, allDeliveries]) en une seule passe, et copier avant de trier ('[...allOrders].sort'). Mieux : déplacer ces agrégats côté serveur (DASH-05).
+
+### DASH-18
+
+**Le badge 'jours en attente' affiche des valeurs négatives et n'a pas de légende** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:506`
+- **Constat :** Dashboard.tsx:505-507 'const orderDate = safeDate(order.plannedDate); const daysPending = Math.floor((new Date().getTime() - orderDate.getTime()) / (1000*60*60*24)); const isOverdue = daysPending > 10;' puis l. 524 '{daysPending} jour{daysPending > 1 ? 's' : ''}'. Une commande 'pending' a généralement une date prévue future.
+- **Impact :** L'utilisateur lit '-4 jour' ou '3 jours' sans savoir s'il s'agit d'un retard ou d'un délai restant. Le rouge n'apparaît qu'au-delà de 10 jours, de façon arbitraire, donc une commande en retard d'un jour reste orange.
+- **Recommandation :** Si la date prévue est passée, afficher 'En retard de X j' en rouge. Sinon, afficher 'Prévue le 12 oct.' en neutre. Trier les retards en premier et limiter la liste à 5-10 lignes avec un lien 'Voir toutes les commandes en attente'.
+
+### DASH-19
+
+**Badges de priorité des tâches : le variant est passé dans className, donc toutes les priorités ont la même couleur** — coherence-design, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:687`
+- **Constat :** Dashboard.tsx:686-688 '<Badge className={`text-xs flex items-center gap-1 ${priorityConfig.color}`}>' alors que getPriorityConfig (l. 341-368) renvoie color: 'destructive' | 'default' | 'secondary', qui sont des noms de variant et non des classes CSS. RecentTasksCard.tsx:152 fait correctement 'variant={priorityConfig.color}'.
+- **Impact :** 'Élevée', 'Moyenne' et 'Faible' s'affichent tous en bleu primaire : l'urgence ne se voit pas d'un coup d'œil.
+- **Recommandation :** Remplacer par `<Badge variant={priorityConfig.color} className="text-xs flex items-center gap-1">`, puis partager la configuration via DASH-46 (et non DASH-34).
+
+### DASH-21
+
+**Texte de debug technique visible par les utilisateurs** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:642`
+- **Constat :** Dashboard.tsx:642 '<p className="text-xs text-gray-400 mt-1">(API: {Array.isArray(upcomingPublicities) ? upcomingPublicities.length : 'NOT_ARRAY'})</p>'. l. 568 '({Array.isArray(allDeliveries) ? allDeliveries.length : 0} livraisons totales)'. Aussi un console.log dans le queryFn (l. 217).
+- **Impact :** Des mentions comme '(API: 0)' ou '(API: NOT_ARRAY)' font croire à une panne et nuisent à la confiance dans l'outil.
+- **Recommandation :** Auto : supprimer seulement les deux <p> de debug (l.568 et l.642) en gardant les messages 'Aucune livraison programmée' et 'Aucune publicité à venir'. L'ajout d'un lien d'action est à traiter avec DASH-23.
+
+### DASH-23
+
+**Rien n'est cliquable alors que tout réagit au survol** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:430`
+- **Constat :** Dashboard.tsx:430 '<Card className="... shadow-lg hover:shadow-xl transition-shadow">' sur les 4 compteurs et les 5 cartes. Les lignes ont 'hover:bg-orange-100' (l. 510), mais il n'y a aucun Link ni onClick (grep 'Link|navigate|href' vide). Les bandeaux DLC (l. 409-425) ne mènent pas non plus à /dlc.
+- **Impact :** L'utilisateur voit '12 commandes en attente' mais doit passer par le menu, puis chercher et filtrer lui-même. L'effet de survol laisse croire à un clic qui ne fait rien.
+- **Recommandation :** Rendre chaque compteur et chaque ligne cliquables : /orders?status=pending, /deliveries?status=planned, /dlc?status=expires, /tasks, /publicities. Ajouter un lien 'Tout voir' en pied de carte. Retirer l'effet hover-shadow sur ce qui n'est pas cliquable.
+
+### DASH-24
+
+**Alertes DLC affichées en double (bandeaux + fenêtre), et deux fenêtres automatiques peuvent s'empiler** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:409`
+- **Constat :** Dashboard.tsx:409-425 : bandeaux jaune et rouge DLC. l. 244-273 : ouverture automatique de DlcAlertModal avec les mêmes chiffres. l. 174-182 : ouverture automatique de la fenêtre 'Nouvelle Annonce'. Les deux Dialog (l. 710 et 773) sont indépendants : rien n'empêche open=true sur les deux à la fois pour un non-admin.
+- **Impact :** À la connexion, un employé peut recevoir deux fenêtres superposées en plus de deux bandeaux : surcharge et confusion sur ce qu'il faut faire en premier.
+- **Recommandation :** Créer un seul bloc 'À traiter aujourd'hui' en haut de page (DLC expirés, DLC proches, commandes en retard), avec un bouton d'action chacun. Afficher au plus une fenêtre automatique par session, avec une file : l'information d'abord, l'alerte DLC ensuite.
+
+### DASH-25
+
+**Libellés ambigus, majuscules à l'anglaise, et numéro de publicité affiché à la place de la désignation** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:476`
+- **Constat :** l. 476 'Total palettes' : en réalité les palettes livrées ce mois (l. 328-338). l. 462 'Délai commande → livraison' : en réalité la moyenne annuelle (yearlyStats). l. 595-596 : '{publicity.pubNumber}' en gras et '{publicity.designation}' tronquée à max-w-40 (160 px). Titres 'Tableau de Bord', 'Commandes en Attente', 'Livraisons à Venir', 'Publicités à Venir' à côté de 'Tâches à faire'. Sous-titre générique l. 400 'Vue d'ensemble des performances et statistiques'.
+- **Impact :** Un employé ne sait pas sur quelle période portent les chiffres, et ne reconnaît pas une opération publicitaire à son numéro interne.
+- **Recommandation :** Renommer en 'Palettes reçues ce mois', 'Délai moyen commande → livraison (2026)', 'Livraisons ce mois'. Pour les publicités, afficher la désignation en premier, puis 'Pub n° 2541 · du 12 au 18 oct.'. Écrire les titres en casse française ('Commandes en attente').
+
+### DASH-26
+
+**Statistiques 'Palettes' et 'Colis' fausses : unités mélangées et nombre de livraisons présenté comme nombre de colis** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:1310`
+- **Constat :** storage.ts:1310-1311 'totalPalettes: sql`COALESCE(SUM(CAST(${deliveries.quantity} as INTEGER)), 0)`, totalPackages: sql`COALESCE(COUNT(*), 0)`' sans condition sur deliveries.unit (même chose l. 1448-1449). Affiché dans StatsPanel.tsx:79-87 comme 'Palettes' et 'Colis'. StatsPanel.tsx:101-104 affiche aussi pendingOrdersCount, qui couvre tout l'historique, sous le titre 'Statistiques du mois'.
+- **Impact :** Les volumes mensuels sont faux (colis comptés comme palettes, 'Colis' = nombre de livraisons) et peuvent fausser le pilotage du magasin.
+- **Recommandation :** Utiliser SUM(CASE WHEN unit='palettes' THEN quantity ELSE 0 END) et SUM(CASE WHEN unit='colis' THEN quantity ELSE 0 END), calculés sans innerJoin orders : seul le délai moyen a besoin de la jointure. Libeller pendingOrdersCount 'Commandes en attente (toutes dates)'.
+
+### DASH-27
+
+**Compteurs DLC incohérents avec la liste de la fenêtre : produits du jour comptés deux fois, 'stock épuisé' traités différemment** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:2245`
+- **Constat :** storage.ts:2245 'expiryDate BETWEEN today AND alertDate' (expiringSoon) et l. 2251 'expiryDate <= today' (expired) : un produit qui expire aujourd'hui est compté dans les deux. Les stats excluent stockEpuise=true, mais la liste 'expires' (l. 2019-2028) ne filtre pas stockEpuise, et DlcAlertModal.tsx:196-199 affiche alors un badge 'Stock épuisé'. La date est calculée en UTC : 'today.toISOString().split('T')[0]'.
+- **Impact :** Le titre 'Produits Expirés (3)' ne correspond pas au nombre de lignes affichées. Les bandeaux additionnent deux fois les produits du jour. Entre minuit et 2 h, heure de Paris, c'est la date de la veille qui est utilisée.
+- **Recommandation :** Définir une seule fois les conditions SQL (expiré : expiry_date < aujourd'hui ; bientôt : entre aujourd'hui et aujourd'hui + 15 ; mêmes exclusions status != 'valides', processed_until_expiry et stock_epuise) et les réutiliser pour les stats et les listes. Pour 'aujourd'hui', utiliser `(now() AT TIME ZONE 'Europe/Paris')::date` plutôt que CURRENT_DATE nu ou toISOString.
+
+### DASH-29
+
+**Chaque page mobile remonte l'en-tête et la barre du bas, ce qui relance /api/user à chaque navigation** — perf-client, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/mobile/DashboardPage.tsx:136`
+- **Constat :** DashboardPage.tsx:136 '<MobileLayout>' est rendu dans la page : 10 pages mobiles font de même (grep '<MobileLayout'). MobileLayout.tsx:22 et MobileBottomNav.tsx:47 appellent chacun useAuthUnified(), qui fait un fetch('/api/user') au montage (useAuthUnified.ts:160).
+- **Impact :** À chaque tap dans la barre du bas, l'en-tête et la navigation sont démontés puis remontés (perte d'état, petit clignotement), avec 3 appels /api/user. Le contenu attend la réponse avant de charger (enabled: !!user).
+- **Recommandation :** Déplacer MobileLayout dans MobileApp, autour du <Switch> de RouterProduction.tsx:108-143. Passer le titre de page par contexte ou par prop de route. Utiliser une auth partagée (DASH-04).
+
+### DASH-30
+
+**Les liens 'Accès rapide' et le bouton de la fenêtre DLC rechargent toute l'application** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/DashboardPage.tsx:187`
+- **Constat :** DashboardPage.tsx:187-191 '<a key={item.path} href={item.path} ...>' (lien HTML natif, pas le <Link> de wouter). DlcAlertModal.tsx:141-143 'const handleViewDlcModule = () => { window.location.href = '/dlc'; };'.
+- **Impact :** Chaque clic recharge le JS (environ 1,7 Mo non compressé, cf. DASH-08), refait l'authentification et vide le cache React Query. Sur mobile, cela représente plusieurs secondes d'attente pour une simple navigation interne.
+- **Recommandation :** Remplacer par '<Link href={item.path}>' (wouter) dans DashboardPage, et par 'const [, navigate] = useLocation(); navigate('/dlc'); onClose();' dans DlcAlertModal.
+
+### DASH-31
+
+**Mobile : les accès rapides doublonnent la barre du bas, avec des libellés trompeurs, et les alertes utiles manquent** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/mobile/DashboardPage.tsx:179`
+- **Constat :** DashboardPage.tsx:179-184 '{ label: "Commande", path: "/orders" }, { label: "Livraison", ... }, { label: "Tâche", ... }, { label: "Agenda", path: "/calendar" }'. MobileBottomNav.tsx:30-34 contient déjà Commandes, Livraisons et Tâches, et l. 37 nomme '/calendar' 'Calendrier'. La page mobile n'a ni alerte DLC ni informations, contrairement au desktop (Dashboard.tsx:409-425, 652).
+- **Impact :** La place précieuse sur téléphone répète la navigation. 'Commande' au singulier laisse croire à un bouton 'Créer', le même écran porte deux noms, et l'employé en rayon ne voit pas les produits DLC à retirer.
+- **Recommandation :** Remplacer les accès rapides par un bloc 'À traiter' : DLC expirés et proches (lien /dlc), information du jour, commandes clients à appeler. Ou proposer de vraies actions de création ('+ Nouvelle livraison'). Utiliser le même nom partout ('Calendrier').
+
+### DASH-35
+
+**Météo : appels séquentiels sans timeout, et l'API externe est rappelée à chaque requête si l'historique échoue** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:5683`
+- **Constat :** routes.ts:5673 'const settings = await storage.getWeatherSettings();', l. 5683 'let currentYearData = await storage.getWeatherData(today, true);', l. 5684 'let previousYearData = await ...' : séquentiel. Puis fetchCurrentWeather et fetchPreviousYearWeather, aussi séquentiels (l. 5687-5720). weatherService.ts:27 et 51 : 'await fetch(url)' sans AbortSignal ni timeout. En cas d'échec de l'historique (quota, 401), rien n'est enregistré : chaque appel suivant rappelle Visual Crossing.
+- **Impact :** Si l'API météo est lente, la requête bloque une des 6 connexions HTTP/1.1 du navigateur pendant tout le chargement. Le quota API s'épuise vite, ce qui entretient les échecs.
+- **Recommandation :** Auto : paralléliser les deux lectures BD, puis les deux fetch externes (Promise.all), et ajouter `signal: AbortSignal.timeout(3000)` aux deux fetch de weatherService.ts. Le cache mémoire de 30 min et le cache négatif de la journée sont à valider séparément : ils empêchent de réessayer après une panne transitoire.
+
+### DASH-37
+
+**Informations : suppression sans confirmation avec une icône 'X', boutons de 24 px sans libellé, texte non tronqué** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/AnnouncementCard.tsx:356`
+- **Constat :** AnnouncementCard.tsx:352-360 '<Button variant="ghost" size="sm" className="h-6 w-6 p-0 ..." onClick={() => deleteMutation.mutate(announcement.id)}><X className="h-3 w-3" /></Button>' : pas d'AlertDialog, pas d'aria-label. l. 324 '<p className="... whitespace-pre-wrap break-words">{announcement.content}</p>' : contenu entier. Vocabulaire mélangé : titre 'Informations' (l. 275), bouton 'Nouvelle' (l. 294), fenêtre du Dashboard 'Nouvelle Annonce' (Dashboard.tsx:715), état vide 'Créez la première annonce' (l. 308).
+- **Impact :** Un admin qui veut 'fermer' une information la supprime définitivement en un clic. Les cibles de 24 px sont difficiles à viser. Une information longue étire la carte et pousse les tâches hors de l'écran.
+- **Recommandation :** Utiliser l'icône Trash2 avec un AlertDialog 'Supprimer cette information ?', des boutons d'au moins 36 px avec aria-label 'Modifier' et 'Supprimer', et line-clamp-3 avec 'Lire la suite'. Choisir un seul terme ('Information') partout.
+
+### DASH-38
+
+**Mêmes queryKeys pour des URL différentes (et l'inverse) : les données affichées dépendent de la page visitée en premier** — bug, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:282`
+- **Constat :** ['/api/tasks', selectedStoreId] : Dashboard.tsx:282-285 n'envoie storeId que pour l'admin, Tasks.tsx:327-333 et mobile/DashboardPage.tsx:80-83 l'envoient pour tous. ['/api/dlc-products/stats', selectedStoreId] : DlcPage.tsx:96-99 n'envoie storeId que pour l'admin, Dashboard.tsx:236 pour tous. Inversement, '/api/stats/monthly' est rangé sous ['/api/stats/monthly', id] (Dashboard.tsx:29) et sous [statsUrl, id] (StatsPanel.tsx:21).
+- **Impact :** Après un passage par la page Tâches, l'accueil d'un manager affiche ses tâches pendant 30 s, puis la liste se vide au refetch. Les compteurs DLC peuvent différer entre l'accueil et la page DLC selon l'ordre de visite. La même statistique est téléchargée deux fois.
+- **Recommandation :** Centraliser les requêtes dans un module (ex. client/src/lib/queries.ts : tasksQuery(storeId), dlcStatsQuery(storeId)…). La queryKey doit être exactement l'URL appelée, construite par une seule fonction partagée par toutes les pages.
+
+### DASH-14
+
+**Les informations sont récupérées deux fois sous deux clés différentes, qui ne s'invalident pas ensemble** — perf-api, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:97`
+- **Constat :** Dashboard.tsx:98 'queryKey: ['/api/announcements/recent', selectedStoreId]' appelle '/api/announcements?...&recent=true'. AnnouncementCard.tsx:134 'queryKey: ['/api/announcements', selectedStoreId, user?.role]' appelle la même route. Après création ou suppression, AnnouncementCard.tsx:192 et 226 n'invalident que ['/api/announcements'], préfixe qui ne couvre pas '/api/announcements/recent'.
+- **Impact :** Une requête en double (avec son N+1 serveur) à chaque ouverture. Une information supprimée peut encore surgir dans la fenêtre 'Nouvelle Annonce' tant que le cache n'est pas périmé.
+- **Recommandation :** Dans Dashboard, utiliser exactement la clé ['/api/announcements', selectedStoreId, user?.role] avec le même queryFn que AnnouncementCard, extrait dans une fonction partagée (même URL, renvoie le tableau). Calculer l'annonce récente (moins de 2 jours, la plus récente) via l'option `select` ou un useMemo. Les invalidations existantes couvriront alors les deux usages.
+
+### DASH-16
+
+**Les requêtes DLC sont invalidées à chaque montage du tableau de bord, ce qui annule le cache** — perf-client, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:23`
+- **Constat :** Dashboard.tsx:23-26 'useEffect(() => { queryClient.invalidateQueries({ queryKey: ["/api/dlc-products"] }); queryClient.invalidateQueries({ queryKey: ["/api/dlc-products/stats"] }); }, [selectedStoreId, queryClient]);'. Même effet dans DlcAlertModal.tsx:45-47. Les clés contiennent déjà selectedStoreId (l. 232).
+- **Impact :** Chaque retour sur l'accueil relance les stats DLC (et marque comme périmées les listes DLC de la page DLC), même si elles datent de quelques secondes.
+- **Recommandation :** Corriger d'abord DASH-38 : une clé égale à l'URL réellement appelée, construite par une fonction partagée entre Dashboard et DlcPage. Supprimer ensuite les deux useEffect d'invalidation.
+
+### DASH-20
+
+**La classe 'border-l-3' n'existe pas dans Tailwind 3 : la barre colorée à gauche des lignes est invisible** — coherence-design, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:510`
+- **Constat :** Dashboard.tsx:510, 548, 590, 676 et AnnouncementCard.tsx:316 utilisent 'border-l-3 border-orange-500' (etc.). tailwind.config.ts n'étend pas borderWidth et index.css ne définit pas .border-l-3. Tailwind 3.4 ne fournit que border-l, -0, -2, -4 et -8.
+- **Impact :** Le code couleur prévu (orange en attente, rouge en retard, vert livraisons, violet publicités) n'apparaît pas : les lignes se ressemblent toutes et la lecture rapide en souffre.
+- **Recommandation :** Remplacer par 'border-l-4' ou 'border-l-[3px]'. Pour les informations, adapter la couleur au type (rouge Important, orange Attention…).
+
+### DASH-33
+
+**Script de bannière Replit (domaine tiers) chargé en production** — perf-client, sévérité basse, effort S
+
+- **Fichier :** `client/index.html:19`
+- **Constat :** client/index.html:18-19 '<!-- This is a replit script ... development mode --> <script type="text/javascript" src="https://replit.com/public/js/replit-dev-banner.js"></script>', présent aussi dans le build dist/public/index.html.
+- **Impact :** Une requête DNS + TLS vers un domaine tiers à chaque chargement, avec un script bloquant en fin de body. Exécution de code externe inutile sur un outil interne.
+- **Recommandation :** Supprimer cette balise, ou l'injecter seulement en dev via un plugin Vite conditionnel.
+
+### DASH-34
+
+**Page déclarée en anglais et zoom bloqué sur mobile** — accessibilite, sévérité basse, effort S
+
+- **Fichier :** `client/index.html:5`
+- **Constat :** client/index.html:2 '<html lang="en">' alors que toute l'interface est en français. l. 5 '<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1" />'.
+- **Impact :** Chrome propose de 'traduire la page', les lecteurs d'écran prononcent le français avec une voix anglaise, et les utilisateurs malvoyants ne peuvent pas zoomer sur téléphone (WCAG 1.4.4).
+- **Recommandation :** Auto : passer seulement à <html lang="fr">. Retirer maximum-scale=1 après avoir vérifié (grep) que les champs (input, select, textarea) affichés sous 768 px ont tous une police d'au moins 16 px.
+
+### DASH-36
+
+**Météo non configurée : retry inutile puis disparition du bloc, avec décalage de l'en-tête** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/WeatherWidget.tsx:121`
+- **Constat :** WeatherWidget.tsx:121-125 'useQuery({ queryKey: ['/api/weather/current'], refetchInterval: 30*60*1000, retry: 1 })'. routes.ts:5675-5677 renvoie 404 'Weather service not configured'. Pendant l'essai et le nouvel essai, l. 137 affiche 'Chargement météo...', puis l. 144-146 'return null'. WeatherWidget.tsx:27-54 retraduit aussi en français des conditions déjà traduites par le serveur (lang=fr, weatherService.translateConditionToFrench).
+- **Impact :** Sur chaque ouverture de l'application sans météo configurée, un texte de chargement apparaît environ 1 s puis disparaît, ce qui fait bouger le sélecteur de magasin. Une requête en double est envoyée.
+- **Recommandation :** Côté serveur, répondre 200 { configured: false }. Côté client, mettre 'retry: false' et 'staleTime: 30 min', et réserver une largeur fixe ou un squelette discret. Supprimer translateToFrench côté client.
+
+### DASH-39
+
+**Fenêtre DLC : formulations techniques ou alarmistes, et '0 jour(s)'** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/DlcAlertModal.tsx:178`
+- **Constat :** DlcAlertModal.tsx:151 'Alerte Produits DLC - Action Requise'. l. 178 'Expiré depuis {Math.abs(getDaysUntilExpiry(product.expiryDate))} jour(s)' donne 'Expiré depuis 0 jour(s)' le jour même. l. 244 '{daysLeft <= 3 ? 'URGENT' : `${daysLeft}j`}'. Toasts avec emojis (l. 80 '✅ Produit marqué', l. 89 '❌ Erreur'). l. 285 '💡 Conseil : Ce modal réapparaîtra…'. Le terme 'modal' est un anglicisme technique.
+- **Impact :** Les messages paraissent techniques ou anxiogènes. 'Expiré depuis 0 jour(s)' est déroutant et '5j' est peu lisible.
+- **Recommandation :** Écrire 'Expire aujourd'hui' ou 'Expiré depuis 2 jours' (fonction de pluriel), 'Dans 5 jours', et 'Urgent' plutôt que 'URGENT'. Titre : 'Produits à retirer ou à surveiller'. Remplacer 'Ce modal' par 'Cette fenêtre'. Retirer les emojis des toasts pour rester cohérent avec les autres pages.
+
+### DASH-40
+
+**'Livraisons à venir' inclut les livraisons en retard, et les tâches sont triées différemment sur chaque écran** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:310`
+- **Constat :** Dashboard.tsx:310-313 '.filter((d) => d.status === 'planned').sort(... scheduledDate ...).slice(0, 4)' : une livraison planifiée à une date passée s'affiche en tête sans signalement. Tâches : Dashboard.tsx:665-669 trie par createdAt croissant (les plus anciennes d'abord). mobile/DashboardPage.tsx:205-207 prend les 3 premières de l'ordre serveur (createdAt décroissant). RecentTasksCard.tsx:59-73 trie par priorité puis échéance.
+- **Impact :** Une livraison en retard est présentée comme 'à venir'. Les tâches les plus urgentes ou en retard peuvent ne pas apparaître dans le top 5, et l'ordre change d'un écran à l'autre.
+- **Recommandation :** Ajouter un badge rouge 'En retard' aux livraisons planifiées dans le passé, ou une section dédiée. Trier les tâches partout de la même façon : en retard, puis priorité haute, puis échéance la plus proche.
+
+### DASH-41
+
+**Textes secondaires en gris clair 'text-gray-400' de petite taille, sous le seuil de contraste** — accessibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:568`
+- **Constat :** Dashboard.tsx:568 et 642 '<p className="text-xs text-gray-400 mt-1">', l. 702 'text-xs text-gray-400', AnnouncementCard.tsx:307 'text-xs text-gray-400'. #9ca3af sur fond blanc donne un ratio d'environ 2,5:1 (WCAG AA exige 4,5:1).
+- **Impact :** Peu lisible sur les écrans de magasin en pleine lumière et pour les utilisateurs âgés.
+- **Recommandation :** Utiliser au minimum text-gray-600 pour tout texte informatif, et réserver gray-400 aux éléments décoratifs.
+
+### DASH-42
+
+**Panneau de statistiques fixe et non repliable qui masque le calendrier** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/StatsPanel.tsx:54`
+- **Constat :** StatsPanel.tsx:54 '<Card className="fixed bottom-6 right-6 min-w-80 shadow-lg border-gray-200">'. Même chose pour le squelette (l. 37). Aucun bouton pour replier ou fermer.
+- **Impact :** Sur tablette ou petit écran, le panneau de 320 px recouvre les derniers jours du mois et leurs livraisons.
+- **Recommandation :** L'intégrer dans le flux de la page (bandeau de 4 compteurs au-dessus du calendrier), ou le rendre repliable avec mémorisation de l'état. Ajouter 'placeholderData: keepPreviousData' pour éviter le squelette à chaque changement de mois.
+
+### DASH-43
+
+**La date de l'en-tête n'est jamais rafraîchie** — bug, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/DateWidget.tsx:16`
+- **Constat :** DateWidget.tsx:16 'const now = new Date();' est calculé seulement au rendu, sans timer. Le Layout reste monté d'une page à l'autre.
+- **Impact :** Sur un poste laissé ouvert la nuit (poste de réception, caisse), l'en-tête affiche encore la date de la veille le matin.
+- **Recommandation :** Utiliser un petit hook useToday() qui programme un setTimeout jusqu'à minuit et se réarme.
+
+### DASH-44
+
+**Logs volumineux à chaque appel dans les chemins les plus sollicités** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:3263`
+- **Constat :** routes.ts:1353 'console.log('Orders API called with:', ...)' (plus 'Fetching all orders' et 'Orders returned'). l. 3263-3269 : 'taskGroups: tasks.map(t => ({ id, title, groupId })).slice(0, 3)', qui parcourt toute la liste juste pour un log. storage.ts:721 (getOrders), 1250 (stats), 2303-2313 (getTasks sampleTasks), routes.ts:5811 (contenu des annonces).
+- **Impact :** Du CPU et de l'I/O synchrone (stdout) consommés à chaque requête, des logs illisibles qui noient les vraies erreurs, et du contenu métier écrit dans les logs.
+- **Recommandation :** Supprimer ces console.log ou les placer derrière un logger à niveau (DEBUG=logiflow:*). Ne garder que les erreurs et le log d'accès existant (index.production.ts:30-38).
+
+### DASH-45
+
+**Code mort : RecentTasksCard, ResponsiveDashboard, server/cache.ts, imports et variables inutilisés** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/tasks/RecentTasksCard.tsx:25`
+- **Constat :** grep : RecentTasksCard et ResponsiveDashboard ne sont importés nulle part. RecentTasksCard.tsx:38 'fetch(`/api/tasks?...`).then(res => res.json())' sans credentials ni contrôle res.ok. server/cache.ts (cacheMiddleware, setupCompression) n'est importé nulle part. Dashboard.tsx:9 importe ShoppingCart, TrendingUp, MapPin, CheckCircle, FileText et Shield, et l. 5 CardDescription, sans les utiliser. Variables recentOrders, ordersByStatus et customerOrderStats inutilisées. Commentaire trompeur l. 649 'Section Rapprochement BL' au-dessus des informations et des tâches.
+- **Impact :** Confusion lors de la maintenance (trois implémentations de la carte des tâches), et risque de réutiliser par erreur un composant défectueux.
+- **Recommandation :** Supprimer RecentTasksCard.tsx, ResponsiveDashboard.tsx et server/cache.ts (ou le réécrire proprement), ainsi que les imports, variables et commentaires obsolètes du Dashboard.
+
+### DASH-46
+
+**Configurations de priorités et de types d'information dupliquées, avec des correspondances contre-intuitives** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:139`
+- **Constat :** Dashboard.tsx:139-171 getAnnouncementPriorityConfig est un copier-coller d'AnnouncementCard.tsx:66-98 ('error' -> 'Nouveauté' violet, 'success' -> 'Important' rouge). getPriorityConfig est dupliqué dans Dashboard.tsx:341-368 et RecentTasksCard.tsx:76-103 (commentaire 'identique au module Tasks').
+- **Impact :** Toute évolution des couleurs ou libellés doit être faite à 3 ou 4 endroits, d'où des incohérences visuelles entre pages. Les correspondances type -> libellé ('error' = Nouveauté) induisent les développeurs en erreur.
+- **Recommandation :** Auto : extraire dans client/src/lib/statusConfig.ts les configurations identiques (types d'annonce : Dashboard et AnnouncementCard ; priorités de tâches avec variante Badge : Dashboard, Tasks.tsx, RecentTasksCard s'il est conservé), sans modifier aucun libellé, couleur ni valeur. Ne pas fusionner la variante mobile (classes CSS) et ne pas faire de migration des valeurs de type.

docs/audit-webui/02-calendar-orders-deliveries.md

@@ -0,0 +1,733 @@
+# Calendrier, Commandes, Livraisons
+
+_58 constats vérifiés — 7 haute, 32 moyenne, 19 basse._
+
+## Pages analysées
+
+### `/calendar (desktop)`
+
+**Rôle :** Vue mensuelle des commandes fournisseurs, des livraisons prévues/reçues et des publicités du magasin sélectionné, avec un panneau de statistiques du mois. C'est le point d'entrée pour planifier et ouvrir la fiche d'une commande ou d'une livraison.
+
+**Tâches principales de l'utilisateur :**
+- Voir ce qui est commandé et livré chaque jour du mois
+- Passer au mois précédent ou suivant
+- Créer une commande ou une livraison à une date
+- Ouvrir la fiche d'une commande ou livraison (modifier, valider, supprimer)
+- Lire le commentaire d'une livraison
+- Consulter les chiffres du mois (commandes, livraisons, palettes, colis)
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/orders?startDate&endDate&storeId | au montage, à chaque changement de mois ou de magasin (fetch() manuel dans queryFn) | server/routes.ts:1343 -> storage.getOrdersByDateRange (storage.ts:725) + loadDeliveriesByOrderIds (storage.ts:522) | Charge chaque commande avec group complet (logo base64 compris), supplier complet, creator, et toutes les livraisons liées, elles-mêmes avec group/supplier/creator complets. Plage limitée à startOfMonth..endOfMonth alors que la grille affiche 42 jours. |
+| GET /api/deliveries?startDate&endDate&storeId | au montage, à chaque changement de mois ou de magasin | server/routes.ts:1752 -> storage.getDeliveriesByDateRange (storage.ts:939) + attachOrdersAndCommentCounts (loadOrdersByIds + loadReconciliationCommentCounts en Promise.all) | Pas de N+1 (regroupement en 2 requêtes), mais colonnes lourdes : group.* (logo), order complet imbriqué. |
+| GET /api/ad-campaigns?year&storeId(admin seulement) | au montage et au changement d'année ou de magasin | server/routes.ts:4595 -> storage.getPublicities (storage.ts:1502) | Le paramètre groupIds est ignoré côté storage : toute l'année, tous magasins, participations avec group complet. Le filtrage par magasin et par jour se fait en JS, 42 fois par rendu. |
+| GET /api/stats/monthly?year&month&storeId | au montage de StatsPanel et au changement de mois | server/routes.ts:4155 -> storage.getMonthlyStats (storage.ts:1222) | 4 requêtes SQL séquentielles. Libellés 'Colis' et 'Palettes' faux. Données fictives si NODE_ENV=development. Clé de cache [statsUrl, storeId] jamais touchée par les invalidations ['/api/stats/monthly']. |
+| GET /api/groups | Layout au montage (clé partagée avec les modales) | server/routes.ts:970 -> storage.getGroups (admin, toutes colonnes dont logo) ou user.userGroups | Rechargé à chaque ouverture de modale une fois passé le staleTime de 30 s. |
+| GET /api/suppliers, GET /api/orders (complet) | à l'ouverture de CreateOrderModal ou de CreateDeliveryModal | server/routes.ts:1141 -> storage.getSuppliers ; server/routes.ts:1343 -> storage.getOrders (storage.ts:678) | CreateDeliveryModal télécharge tout l'historique des commandes pour remplir une liste déroulante. |
+
+**Lisibilité / simplicité :** La page est dense et difficile à lire. Le mois apparaît deux fois (en-tête et barre de navigation). La légende (bleu primaire, vert foncé, gris) ne correspond pas aux couleurs de la grille (bleu clair, jaune pour 'planifié', vert clair, violet pour les pubs). Les éléments sont écrits en 11 px avec des abréviations (P/C) et des icônes de 8 px. Seuls 2 éléments sont visibles par jour, le reste passe par '+N autres', ce qui ouvre des modales imbriquées. Un clic n'importe où dans une case ouvre 'Création rapide', même pour un utilisateur sans droits. Le bouton '+' n'apparaît qu'au survol. Le panneau de statistiques, fixé en bas à droite, recouvre les dernières cases et affiche des chiffres faux. Un spinner plein écran remplace la grille à chaque changement de mois. Les jours des mois voisins sont affichés mais toujours vides. Le passage au mois suivant saute un mois les 29, 30 et 31. Il n'y a aucun état d'erreur : un échec d'API donne un calendrier vide silencieux.
+
+### `/calendar (mobile)`
+
+**Rôle :** Calendrier mensuel simplifié pour téléphone : des points de couleur indiquent les jours avec des commandes ou des livraisons, et la liste du jour sélectionné s'affiche dessous.
+
+**Tâches principales de l'utilisateur :**
+- Voir les jours avec commandes et livraisons
+- Voir la liste des événements d'un jour
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/orders?startDate&endDate&storeId | au montage et au changement de mois (enabled: !!user) | server/routes.ts:1343 -> storage.getOrdersByDateRange (storage.ts:725) | Clé ['/api/orders', storeId, 'yyyy-MM'] différente de celle du desktop pour la même donnée. Les erreurs sont avalées (return []). |
+| GET /api/deliveries?startDate&endDate&storeId | au montage et au changement de mois | server/routes.ts:1752 -> storage.getDeliveriesByDateRange (storage.ts:939) | Même charge utile lourde que sur desktop pour n'afficher qu'un titre et un statut. |
+
+**Lisibilité / simplicité :** La page est lisible mais en lecture seule : les cartes ne sont pas cliquables, et on ne peut ni ouvrir une fiche, ni valider, ni créer. Le statut s'affiche brut en anglais ('pending', 'planned', 'delivered'). Les titres 'Cmd #12' et 'Liv #34' sont techniques (orderNumber n'existe pas dans le schéma). Les jours des semaines voisines sont affichés sans données. Il n'y a ni état de chargement ni état d'erreur.
+
+### `/orders (desktop)`
+
+**Rôle :** Liste de toutes les commandes fournisseurs du magasin, avec recherche, filtre par statut, pagination, création, modification et suppression.
+
+**Tâches principales de l'utilisateur :**
+- Retrouver une commande (fournisseur, statut)
+- Créer une commande
+- Modifier une commande
+- Supprimer une commande
+- Voir le détail et les livraisons liées
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/orders?storeId | au montage et au changement de magasin (fetch() manuel, clé [ordersUrl, storeId]) | server/routes.ts:1343 (branche sans dates, 1372/1450) -> storage.getOrders (storage.ts:678) + loadDeliveriesByOrderIds (storage.ts:522) | Tout l'historique sans LIMIT, puis pagination côté client par 20. Pour un admin en 'tous magasins', ce sont toutes les commandes de tous les magasins. |
+| GET /api/groups | au montage | server/routes.ts:970 -> storage.getGroups / user.userGroups | Résultat jamais utilisé dans la page. |
+| DELETE /api/orders/:id | au clic sur 'Supprimer définitivement' | server/routes.ts:1655 -> storage.getOrder (storage.ts:783, 2 requêtes) + storage.deleteOrder (storage.ts:880) | Après succès, invalidateQueries puis refetchQueries de toutes les variantes /api/orders et /api/deliveries, y compris celles qui sont inactives. |
+| PUT /api/orders/:id | à l'enregistrement de EditOrderModal | server/routes.ts:1620 -> storage.getOrder + storage.updateOrder (storage.ts:871) | Jamais atteint : les arguments de apiRequest sont inversés côté client. |
+| POST /api/orders, GET /api/suppliers | ouverture et validation de CreateOrderModal | server/routes.ts:1552 -> storage.createOrder ; server/routes.ts:1141 -> storage.getSuppliers | Liste fournisseurs complète, sans recherche. |
+
+**Lisibilité / simplicité :** Structure claire (en-tête, filtres, tableau), mais plusieurs défauts. Le libellé 'Groupe' apparaît alors que la navigation dit 'Magasin'. L'identifiant technique '#id' est affiché. Les boutons d'action sont des icônes sans libellé ni info-bulle. Le tableau est en min-w 700px dans un conteneur overflow-hidden, donc tronqué sans défilement sur petit écran. Les couleurs de statut diffèrent du calendrier. Il n'y a ni tri ni filtre de période. La pagination revient à la page 1 après une suppression. La modification d'une commande échoue systématiquement (bug apiRequest). La suppression d'une commande liée à des livraisons renvoie un message générique. Les hooks sont appelés après un return anticipé. Les logs de debug s'exécutent par ligne à chaque frappe.
+
+### `/orders (mobile)`
+
+**Rôle :** Liste des commandes en cartes avec recherche et onglets Toutes, En attente, Livrées.
+
+**Tâches principales de l'utilisateur :**
+- Rechercher une commande
+- Filtrer par statut
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/orders?storeId | au montage (enabled: !!user) | server/routes.ts:1343 -> storage.getOrders (storage.ts:678) | Tout l'historique, tout rendu sans pagination ni virtualisation. Erreurs avalées (return []). |
+
+**Lisibilité / simplicité :** Les cartes affichent une flèche '>' mais ne sont pas cliquables, et aucune action n'est possible (icône Plus importée mais jamais utilisée). La date est toujours 'Date inconnue' (champ orderDate inexistant). La recherche par numéro ne fonctionne jamais (orderNumber inexistant). Le statut 'planned' s'affiche brut en anglais. L'accès n'est pas restreint pour les employés, alors que la version desktop les bloque. Une erreur serveur s'affiche comme 'Aucune commande trouvée'.
+
+### `/deliveries (desktop)`
+
+**Rôle :** Liste des livraisons du magasin : planifier, modifier, valider la réception (saisie du n° de BL), marquer le contrôle qualité, supprimer.
+
+**Tâches principales de l'utilisateur :**
+- Voir les livraisons à recevoir
+- Valider une livraison reçue avec le n° de BL
+- Marquer le contrôle comme effectué
+- Créer ou modifier une livraison et la lier à une commande
+- Supprimer une livraison
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/deliveries?storeId | au montage et au changement de magasin (clé ['/api/deliveries', storeId, user.role]) | server/routes.ts:1752 (branche sans dates 1781/1859) -> storage.getDeliveries (storage.ts:885) + attachOrdersAndCommentCounts | Tout l'historique sans LIMIT, pagination côté client. Filtre withBL fait en JS (routes.ts:1864). |
+| GET /api/groups | au montage | server/routes.ts:970 | Résultat jamais utilisé. |
+| POST /api/deliveries/:id/validate | ValidateDeliveryModal | server/routes.ts:2604 -> storage.getDelivery (storage.ts:1004 : 4-6 requêtes séquentielles dont getOrder) + validateDelivery + updateOrder | Le contrôle d'accès au magasin n'est fait que pour le rôle manager. |
+| PUT /api/deliveries/:id/control | au clic sur l'icône CheckCircle orange, sans confirmation | server/routes.ts:2678 -> storage.getDelivery + markDeliveryControlValidated | Aucun contrôle d'appartenance au magasin. |
+| DELETE /api/deliveries/:id | ConfirmDeleteModal | server/routes.ts:2136 -> storage.getDelivery + deleteDelivery | Côté client, /api/orders n'est pas invalidé alors que les commandes embarquent leurs livraisons. |
+| POST /api/deliveries, PUT /api/deliveries/:id, GET /api/orders (complet), GET /api/suppliers | modales de création et de modification | server/routes.ts:2072 / 1906 / 1343 -> storage.createDelivery / updateDelivery / getOrders | Tout l'historique des commandes est chargé pour la liste 'Commande liée'. |
+
+**Lisibilité / simplicité :** Le tableau a 8 colonnes, n'est pas responsive (overflow-hidden, en-tête non adapté au mobile) et ses en-têtes ont deux styles différents (xs gris et sm font-black). Jusqu'à 5 icônes d'action sans libellé, dont deux coches proches pour 'valider la livraison' et 'contrôle effectué'. Le contrôle se valide en un clic sans confirmation. Le filtre 'En attente' ne correspond à aucun statut existant (planned/delivered). Les abréviations 'P' et 'C' sont utilisées pour les quantités. Le libellé 'Groupe' est utilisé à la place de 'Magasin'. Le padding est doublé (p-6 imbriqués). On ne peut pas rechercher par n° de BL. Des logs de debug sont présents.
+
+### `/deliveries (mobile)`
+
+**Rôle :** Liste des livraisons en cartes avec recherche et onglets Toutes, En attente, Reçues.
+
+**Tâches principales de l'utilisateur :**
+- Voir les livraisons du jour ou en retard
+- Filtrer les livraisons reçues
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/deliveries?storeId | au montage | server/routes.ts:1752 -> storage.getDeliveries (storage.ts:885) | Tout l'historique, rendu intégral, erreurs avalées. |
+
+**Lisibilité / simplicité :** La page est inutilisable en l'état. expectedDate et deliveryNumber n'existent pas : toutes les dates affichent 'Date inconnue' et les badges 'Aujourd'hui' ou 'En retard' n'apparaissent jamais. Le statut 'received' n'existe pas : l'onglet 'Reçues' est toujours vide et 'En attente' contient aussi les livraisons livrées. L'icône de statut est toujours générique. Aucune action n'est possible : impossible de valider une réception depuis le téléphone, alors que c'est la tâche principale en magasin.
+
+### `Modales partagées (Calendrier / Commandes / Livraisons)`
+
+**Rôle :** Formulaires de création, modification, validation, détail et confirmation de suppression des commandes et livraisons.
+
+**Tâches principales de l'utilisateur :**
+- Créer ou modifier une commande ou une livraison
+- Lier une livraison à une commande
+- Valider une livraison (n° de BL)
+- Consulter une fiche et supprimer
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/suppliers | montage de chaque modale de formulaire | server/routes.ts:1141 -> storage.getSuppliers (storage.ts:467) | Refetch à chaque ouverture après 30 s. |
+| GET /api/groups | montage de chaque modale de formulaire | server/routes.ts:970 | Admin : toutes les colonnes, logo compris. |
+| GET /api/orders (sans paramètre) | montage de CreateDeliveryModal et EditDeliveryModal (queryFn par défaut) | server/routes.ts:1343 -> storage.getOrders (storage.ts:678) | Tout l'historique pour filtrer en JS par fournisseur, magasin et statut. |
+| PUT /api/orders/:id | EditOrderModal et le bouton 'Valider Commande' de OrderDetailModal | server/routes.ts:1620 | Cassé depuis EditOrderModal (arguments inversés). |
+| POST /api/deliveries/:id/validate | ValidateDeliveryModal | server/routes.ts:2604 | Le BL est obligatoire. Invalidation de stats inefficace. |
+
+**Lisibilité / simplicité :** Les formulaires sont courts et clairs. En revanche, la liste fournisseurs n'a pas de recherche. Un admin en 'tous magasins' ne peut pas choisir le magasin : le premier est imposé, en lecture seule. Le libellé 'Magasin/Groupe' est ambigu. Les boutons de pied de modale sont alignés tantôt à gauche, tantôt à droite, avec des couleurs incohérentes. La fiche détail utilise un en-tête bleu même pour une livraison, une zone max-h-96 et une modale d'édition empilée par-dessus ; après modification, elle affiche des données périmées. Elle a aussi sa propre confirmation de suppression au lieu de ConfirmDeleteModal. EditDeliveryModal masque la commande liée si celle-ci est livrée. La gestion de session expirée ne fonctionne pas (regex jamais vraie, redirection vers GET /api/login inexistant). Les logs s'exécutent à chaque rendu.
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [MOB-01](#mob-01) | haute | ux-simplicite | L | Versions mobiles en lecture seule : impossible d'ouvrir une fiche ou de valider une réception | `client/src/pages/mobile/DeliveriesPage.tsx:163` |
+| [MOB-02](#mob-02) | haute | bug | S | Pages mobiles basées sur des champs et statuts inexistants : dates, numéros et filtres cassés | `client/src/pages/mobile/DeliveriesPage.tsx:29` |
+| [MOD-01](#mod-01) | haute | perf-api | M | Les modales de livraison téléchargent toutes les commandes pour remplir une liste déroulante | `client/src/components/modals/CreateDeliveryModal.tsx:60` |
+| [ORD-01](#ord-01) | haute | bug | S | Modification de commande toujours en échec : arguments de apiRequest inversés | `client/src/components/modals/EditOrderModal.tsx:61` |
+| [ORD-02](#ord-02) | haute | perf-api | L | Historique complet chargé sans limite, puis pagination côté navigateur | `client/src/pages/Orders.tsx:73` |
+| [SRV-01](#srv-01) | haute | perf-api | S | Logo base64 et configuration SMTP/NocoDB du magasin renvoyés dans chaque ligne de commande ou livraison | `server/storage.ts:693` |
+| [SRV-03](#srv-03) | haute | perf-api | S | Aucune compression HTTP, et les assets hashés sont servis sans cache long | `server/index.production.ts:27` |
+| [BUNDLE-01](#bundle-01) | moyenne | perf-bundle | M | Toutes les pages, desktop et mobile, sont importées statiquement : bundle initial d'environ 1,5 Mo | `client/src/components/RouterProduction.tsx:5` |
+| [CAL-01](#cal-01) | moyenne | bug | S | Le bouton 'mois suivant' saute un mois quand on est le 29, 30 ou 31 | `client/src/pages/Calendar.tsx:171` |
+| [CAL-02](#cal-02) | moyenne | perf-client | S | Calculs de debug exécutés en production dans la boucle de rendu | `client/src/components/CalendarGrid.tsx:495` |
+| [CAL-03](#cal-03) | moyenne | perf-client | M | Filtrage O(42 × éléments) à chaque rendu, sans mémoïsation | `client/src/components/CalendarGrid.tsx:579` |
+| [CAL-04](#cal-04) | moyenne | perf-client | S | Spinner plein écran à chaque changement de mois, et la grille attend les publicités | `client/src/pages/Calendar.tsx:204` |
+| [CAL-06](#cal-06) | moyenne | coherence-design | S | La légende ne correspond pas aux couleurs utilisées dans la grille | `client/src/pages/Calendar.tsx:224` |
+| [CAL-07](#cal-07) | moyenne | lisibilite | M | Éléments du calendrier illisibles : texte de 11 px, icônes de 8 px, abréviations P/C, statut codé par des points | `client/src/components/CalendarGrid.tsx:75` |
+| [CAL-08](#cal-08) | moyenne | ux-simplicite | S | Un clic n'importe où dans une case ouvre 'Création rapide', même sans droits, et le '+' n'est visible qu'au survol | `client/src/pages/Calendar.tsx:181` |
+| [CAL-10](#cal-10) | moyenne | ux-simplicite | S | Le panneau de statistiques en position fixe masque le bas du calendrier | `client/src/components/StatsPanel.tsx:54` |
+| [CAL-11](#cal-11) | moyenne | bug | M | Panneau 'Statistiques du mois' : chiffres Palettes, Colis et 'en attente' faux | `server/storage.ts:1297` |
+| [CAL-15](#cal-15) | moyenne | perf-serveur | S | getPublicities ignore le filtre magasin, charge des groupes complets et regroupe en O(P×N) | `server/storage.ts:1502` |
+| [CAL-16](#cal-16) | moyenne | dette-code | M | fetch() manuels dupliqués : aucune gestion du 401 et aucun état d'erreur affiché | `client/src/pages/Calendar.tsx:62` |
+| [LIV-01](#liv-01) | moyenne | bug | S | Le filtre 'En attente' des livraisons ne correspond à aucun statut existant | `client/src/pages/Deliveries.tsx:325` |
+| [LIV-02](#liv-02) | moyenne | ux-simplicite | S | 'Contrôle effectué' validé en un clic, sans confirmation | `client/src/pages/Deliveries.tsx:484` |
+| [MCAL-01](#mcal-01) | moyenne | lisibilite | S | Statuts affichés bruts en anglais et titres techniques 'Cmd #' / 'Liv #' | `client/src/pages/mobile/CalendarPage.tsx:293` |
+| [MOB-03](#mob-03) | moyenne | ux-simplicite | S | Les erreurs serveur sont présentées comme 'Aucune commande trouvée' | `client/src/pages/mobile/OrdersPage.tsx:51` |
+| [MOD-02](#mod-02) | moyenne | bug | S | Gestion de session expirée inopérante : regex jamais vraie et redirection vers une route inexistante | `client/src/lib/authUtils.ts:2` |
+| [MOD-03](#mod-03) | moyenne | ux-simplicite | S | Un admin en 'Tous les magasins' ne peut pas choisir le magasin : le premier est imposé | `client/src/components/modals/CreateOrderModal.tsx:84` |
+| [MOD-04](#mod-04) | moyenne | ux-simplicite | M | Choix du fournisseur dans une longue liste sans recherche | `client/src/components/modals/CreateOrderModal.tsx:188` |
+| [ORD-03](#ord-03) | moyenne | perf-client | S | Log par ligne à chaque frappe et filtrage sans mémoïsation | `client/src/pages/Orders.tsx:169` |
+| [ORD-05](#ord-05) | moyenne | bug | M | Invalidations qui ratent leur cible : clés de cache hétérogènes pour les mêmes données | `client/src/pages/Orders.tsx:76` |
+| [ORD-06](#ord-06) | moyenne | perf-client | S | La suppression recharge toutes les variantes en cache, y compris les inactives (invalidate puis refetch) | `client/src/pages/Orders.tsx:141` |
+| [ORD-10](#ord-10) | moyenne | accessibilite | S | Actions en icônes seules, sans libellé ni info-bulle, et deux coches ambiguës | `client/src/pages/Deliveries.tsx:453` |
+| [ORD-11](#ord-11) | moyenne | ux-simplicite | S | Tableaux tronqués sur écrans étroits : pas de défilement horizontal | `client/src/pages/Orders.tsx:316` |
+| [ORD-12](#ord-12) | moyenne | coherence-design | M | Couleurs et libellés de statut différents selon les pages, et couleurs des boutons principaux incohérentes | `client/src/pages/Orders.tsx:190` |
+| [ORD-13](#ord-13) | moyenne | ux-simplicite | M | La suppression d'une commande liée à des livraisons échoue avec un message générique | `server/storage.ts:880` |
+| [PERM-01](#perm-01) | moyenne | dette-code | M | Deux matrices de permissions divergentes entre client et serveur | `client/src/lib/permissions.ts:1` |
+| [SRV-02](#srv-02) | moyenne | perf-api | M | Imbrications redondantes : livraisons complètes dans chaque commande et commande complète dans chaque livraison | `server/storage.ts:522` |
+| [SRV-04](#srv-04) | moyenne | perf-serveur | M | Utilisateur et magasins rechargés deux fois par requête API | `server/localAuth.production.ts:195` |
+| [SRV-05](#srv-05) | moyenne | perf-serveur | S | Toutes les réponses JSON sont clonées récursivement pour retirer smtpPassword | `server/routes.ts:168` |
+| [SRV-07](#srv-07) | moyenne | bug | S | Manager ou directeur multi-magasins sans sélection : seul le premier magasin est renvoyé, en silence | `server/routes.ts:1419` |
+| [SRV-08](#srv-08) | moyenne | bug | S | Contrôles d'accès par magasin incomplets (validation, contrôle, lecture, statistiques) | `server/routes.ts:2624` |
+| [CAL-05](#cal-05) | basse | bug | S | Les jours des mois voisins sont affichés mais toujours vides | `client/src/pages/Calendar.tsx:33` |
+| [CAL-12](#cal-12) | basse | perf-serveur | S | Statistiques mensuelles : 4 requêtes séquentielles, sans cache | `server/storage.ts:1270` |
+| [CAL-13](#cal-13) | basse | bug | S | La fenêtre '+X autres' affiche la date de création des commandes au lieu de la date prévue | `client/src/components/CalendarGrid.tsx:324` |
+| [CAL-14](#cal-14) | basse | ux-simplicite | M | Seulement 2 éléments par jour, et des modales imbriquées avec des contournements de z-index et d'état | `client/src/components/CalendarGrid.tsx:177` |
+| [CAL-17](#cal-17) | basse | perf-client | S | Double chargement au démarrage : les requêtes partent avant la sélection automatique du magasin | `client/src/components/Layout.tsx:70` |
+| [MOD-05](#mod-05) | basse | perf-client | S | useEffect et logs exécutés à chaque rendu (dépendance recréée) | `client/src/components/modals/CreateOrderModal.tsx:49` |
+| [MOD-06](#mod-06) | basse | perf-client | S | Données de référence rechargées à chaque ouverture de modale | `client/src/lib/queryClient.ts:77` |
+| [MOD-07](#mod-07) | basse | dette-code | S | Mutation morte, confirmation de suppression dupliquée et rôles codés en dur | `client/src/components/modals/OrderDetailModal.tsx:70` |
+| [MOD-08](#mod-08) | basse | ux-simplicite | M | Modale d'édition empilée sur la fiche, données périmées après modification, contenu limité à 384 px | `client/src/components/modals/OrderDetailModal.tsx:437` |
+| [MOD-09](#mod-09) | basse | coherence-design | S | Pieds de modale et boutons d'action incohérents | `client/src/components/modals/CreateOrderModal.tsx:245` |
+| [MOD-10](#mod-10) | basse | ux-simplicite | S | Le champ 'Commande liée' disparaît si la commande liée est déjà livrée | `client/src/components/modals/EditDeliveryModal.tsx:191` |
+| [ORD-04](#ord-04) | basse | perf-client | S | Requête /api/groups inutilisée | `client/src/pages/Orders.tsx:101` |
+| [ORD-07](#ord-07) | basse | bug | S | Hooks appelés après un return anticipé (règle des hooks violée) | `client/src/pages/Orders.tsx:41` |
+| [ORD-08](#ord-08) | basse | lisibilite | S | 'Groupe' et 'Magasin/Groupe' au lieu de 'Magasin' | `client/src/pages/Orders.tsx:323` |
+| [ORD-09](#ord-09) | basse | lisibilite | S | Identifiants techniques affichés sous des formes différentes selon l'écran | `client/src/components/modals/OrderDetailModal.tsx:209` |
+| [ORD-14](#ord-14) | basse | ux-simplicite | S | Retour à la page 1 après chaque suppression, et confirmation fermée avant la fin de l'action | `client/src/components/ui/pagination.tsx:157` |
+| [ORD-15](#ord-15) | basse | ux-simplicite | M | Pas de tri, pas de filtre de période, recherche sans n° de BL | `client/src/pages/Deliveries.tsx:176` |
+| [SRV-06](#srv-06) | basse | perf-serveur | S | Logs console à chaque appel des chemins chauds | `server/routes.ts:1353` |
+| [SRV-09](#srv-09) | basse | perf-serveur | S | Le filtre withBL est appliqué en JavaScript après le chargement complet | `server/routes.ts:1864` |
+
+### MOB-01
+
+**Versions mobiles en lecture seule : impossible d'ouvrir une fiche ou de valider une réception** — ux-simplicite, sévérité haute, effort L
+
+- **Fichier :** `client/src/pages/mobile/DeliveriesPage.tsx:163`
+- **Constat :** DeliveriesPage.tsx:163-195 `<Card key={delivery.id}>` sans onClick, mais avec `<ChevronRight>` (192) qui suggère un lien. OrdersPage.tsx:146-177 idem : `Plus` est importé (16) et jamais utilisé, aucun bouton de création. CalendarPage.tsx:266-300 : cartes d'événement non cliquables.
+- **Impact :** L'employé qui réceptionne un camion avec son téléphone ne peut ni valider la livraison ni saisir le BL. Il doit passer sur un poste fixe. La flèche affichée trompe l'utilisateur, qui touche sans résultat.
+- **Recommandation :** Rendre les cartes cliquables et ouvrir une fiche plein écran (Sheet) qui réutilise OrderDetailModal. Ajouter sur chaque livraison 'planned' un bouton visible 'Valider la réception' qui ouvre ValidateDeliveryModal. Ajouter un bouton flottant '+' pour créer (selon les permissions). Retirer le chevron tant que la carte n'est pas cliquable.
+
+### MOB-02
+
+**Pages mobiles basées sur des champs et statuts inexistants : dates, numéros et filtres cassés** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/mobile/DeliveriesPage.tsx:29`
+- **Constat :** DeliveriesPage.tsx:27-35 type `{ deliveryNumber?, expectedDate, status }`, ligne 185 `delivery.expectedDate && ... : 'Date inconnue'`, lignes 41/63-64 filtre `'received'`. OrdersPage.tsx:25-33 `{ orderNumber?, orderDate }`, lignes 167-170 `order.orderDate ... : 'Date inconnue'`. Or shared/schema.ts:121-133 (orders : plannedDate, aucun orderNumber/orderDate) et 136-146 (deliveries : scheduledDate, status 'planned, delivered'). Aucune occurrence de orderNumber, deliveryNumber ou expectedDate côté serveur (grep). CalendarPage.tsx:105/113 `Cmd #${order.orderNumber || order.id}`.
+- **Impact :** Sur téléphone, toutes les commandes et livraisons affichent 'Date inconnue'. Les badges 'Aujourd'hui' et 'En retard' n'apparaissent jamais. L'onglet 'Reçues' est toujours vide et 'En attente' inclut les livraisons déjà livrées. La recherche par numéro ne trouve rien. Le statut 'planned' s'affiche brut.
+- **Recommandation :** Correction minimale et mécanique : expectedDate→scheduledDate, orderDate→plannedDate, filtre 'received'→'delivered' (et 'pending'→status==='planned' pour les livraisons), ajout d'un badge 'planned' ('Planifiée'), suppression de orderNumber/deliveryNumber (afficher l'id). Mutualiser les libellés avec le desktop est un chantier à part (voir ORD-12).
+
+### MOD-01
+
+**Les modales de livraison téléchargent toutes les commandes pour remplir une liste déroulante** — perf-api, sévérité haute, effort M
+
+- **Fichier :** `client/src/components/modals/CreateDeliveryModal.tsx:60`
+- **Constat :** CreateDeliveryModal.tsx:60-62 `useQuery<OrderWithRelations[]>({ queryKey: ['/api/orders'] })` passe par la queryFn par défaut, soit GET /api/orders sans storeId ni dates, donc storage.getOrders() complet avec livraisons imbriquées. Le résultat est ensuite filtré en JS (65-73) par fournisseur, magasin et statut. Même chose dans EditDeliveryModal.tsx:50-61.
+- **Impact :** L'ouverture de 'Nouvelle livraison' ou 'Modifier livraison' déclenche le plus gros appel de l'application (toutes les commandes, tous magasins pour un admin). Le formulaire est lent et l'appel est refait à chaque ouverture après 30 s.
+- **Recommandation :** Ajouter `GET /api/orders?storeId=&supplierId=&status=pending,planned&light=1` qui renvoie {id, plannedDate, status}. Ne lancer la requête qu'une fois le fournisseur choisi (`enabled: !!formData.supplierId`), avec une clé ['/api/orders', 'open', {storeId, supplierId}].
+
+### ORD-01
+
+**Modification de commande toujours en échec : arguments de apiRequest inversés** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/components/modals/EditOrderModal.tsx:61`
+- **Constat :** EditOrderModal.tsx:61 `await apiRequest("PUT", `/api/orders/${order?.id}`, data);` alors que queryClient.ts:10-15 définit `apiRequest(url: string, method: string = 'GET', body?)`. Le résultat est fetch('PUT', { method: '/api/orders/12' }), qui lève un TypeError (méthode HTTP invalide). C'est le seul appel de ce type dans client/src (grep).
+- **Impact :** Aucune commande ne peut être modifiée, ni depuis la page Commandes ni depuis la fiche ouverte dans le calendrier. L'utilisateur voit seulement 'Impossible de modifier la commande'.
+- **Recommandation :** Remplacer par `await apiRequest(`/api/orders/${order?.id}`, 'PUT', data);`. Si l'on type method, utiliser `type HttpMethod = 'GET'|'POST'|'PUT'|'PATCH'|'DELETE'` pour ne casser aucun appelant existant.
+
+### ORD-02
+
+**Historique complet chargé sans limite, puis pagination côté navigateur** — perf-api, sévérité haute, effort L
+
+- **Fichier :** `client/src/pages/Orders.tsx:73`
+- **Constat :** Orders.tsx:73 `const ordersUrl = `/api/orders${selectedStoreId ? `?storeId=${selectedStoreId}` : ''}`;` appelle routes.ts:1372/1450 `storage.getOrders(groupIds)` (storage.ts:678-723 : aucun LIMIT, plus toutes les livraisons liées). Ensuite, Orders.tsx:180-188 `usePagination(filteredOrders, 20)`. Même chose pour Deliveries.tsx:80 vers getDeliveries (885-937), et pour OrdersPage.tsx:43-48 et DeliveriesPage.tsx:45-50 sur mobile, qui rendent tout sans pagination.
+- **Impact :** Le temps de chargement grandit sans fin avec l'historique. Un admin en 'Tous les magasins' télécharge toutes les commandes de tous les magasins pour n'en voir que 20. La mémoire et le rendu mobile se dégradent.
+- **Recommandation :** Créer un endpoint paginé `GET /api/orders?storeId&page&limit&status&search&from&to` qui renvoie { items, total }. Faire le filtre statut, la recherche (ILIKE sur suppliers.name, notes, bl_number) et le tri en SQL, avec par défaut les 3 derniers mois. Côté client : useQuery avec placeholderData: keepPreviousData, ou useInfiniteQuery sur mobile.
+
+### SRV-01
+
+**Logo base64 et configuration SMTP/NocoDB du magasin renvoyés dans chaque ligne de commande ou livraison** — perf-api, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:693`
+- **Constat :** storage.ts:693, 740, 913, 967, 553, 599 : `group: groups,` sélectionne toutes les colonnes de groups, dont shared/schema.ts:67 `logo: text("logo"), // Logo en data URI (data:image/png;base64,...)`, smtpHost, smtpUser, smtpSenderEmail, address, phone, nocodb*. Le groupe est répété pour chaque commande (getOrders), pour chaque livraison imbriquée dans une commande (loadDeliveriesByOrderIds:553) et pour chaque commande imbriquée dans une livraison (loadOrdersByIds:599). Même chose pour les participations de getPublicities (1536). Les pages n'utilisent que group.name et group.color, et BLReconciliation.tsx:298-325 utilise nocodbTableName, nocodbConfigId et webhookUrl.
+- **Impact :** Avec un logo de quelques dizaines de Ko, la liste des commandes pèse plusieurs Mo, voire des dizaines. Le chargement des pages Calendrier, Commandes et Livraisons, ainsi que des modales de livraison, devient lent, surtout sur mobile. Des données de configuration inutiles sont aussi exposées au navigateur.
+- **Recommandation :** Projeter group: {id, name, color, nocodbConfigId, nocodbTableName, webhookUrl} (sans logo ni smtp*) et supplier: {id, name, email, requiresControl, hasDlc, automaticReconciliation}. Créer des types dédiés (GroupSummary, SupplierSummary) dans OrderWithRelations et DeliveryWithRelations, puis vérifier tous les consommateurs (BLReconciliation, ReconciliationModal, Avoirs, CustomerOrders, Dashboard, exports serveur) avant de livrer.
+
+### SRV-03
+
+**Aucune compression HTTP, et les assets hashés sont servis sans cache long** — perf-api, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/index.production.ts:27`
+- **Constat :** index.production.ts:27-28 n'enregistre que `express.json` et `express.urlencoded`. Aucun middleware compression (absent de package.json) et aucune conf gzip dans le dépôt. Ligne 143 : `app.use('/assets', express.static(join(publicPath, 'assets')));` sans maxAge ni immutable. Le build actuel pèse 1 081 745 octets (index-CCl1yENM.js) + 410 243 octets (vendor-charts) + 120 775 octets de CSS.
+- **Impact :** Les JSON de listes (déjà gonflés, voir SRV-01 et SRV-02) et environ 1,7 Mo de JS/CSS transitent non compressés. Les assets sont revalidés à chaque visite. Le premier affichage et chaque navigation sont nettement plus lents, surtout en 4G.
+- **Recommandation :** Ajouter `compression` (et @types/compression) aux dépendances et `--external:compression` dans la commande esbuild du Dockerfile, puis `app.use(compression())` avant registerRoutes (index.production.ts et index.ts). Servir /assets avec `{ maxAge: '1y', immutable: true }` et envoyer index.html avec `Cache-Control: no-cache`. Vérifier d'abord la configuration gzip du nginx externe.
+
+### BUNDLE-01
+
+**Toutes les pages, desktop et mobile, sont importées statiquement : bundle initial d'environ 1,5 Mo** — perf-bundle, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:5`
+- **Constat :** RouterProduction.tsx:5-44 : environ 30 imports de pages en tête (Analytics, BackupManager, Utilities, BLReconciliation, DatabaseDebug, NocoDBConfig, pages mobiles…), sans React.lazy. Le build produit dist/public/assets/index-CCl1yENM.js (1 081 745 octets) et vendor-charts-gtSIDI7m.js (410 243 octets, recharts), tous deux chargés avant le premier affichage du Calendrier ou des Commandes.
+- **Impact :** Le premier affichage est lent, surtout sur les postes de magasin et en 4G, et aggravé par l'absence de gzip (SRV-03).
+- **Recommandation :** React.lazy par route avec <Suspense fallback={<PageSkeleton/>}>, en séparant les arbres desktop et mobile, ET ajouter `window.addEventListener('vite:preloadError', () => window.location.reload())` dans main.tsx, avec index.html servi en no-cache (voir SRV-03).
+
+### CAL-01
+
+**Le bouton 'mois suivant' saute un mois quand on est le 29, 30 ou 31** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Calendar.tsx:171`
+- **Constat :** Calendar.tsx:171-179 `const newDate = new Date(currentDate); ... newDate.setMonth(newDate.getMonth() + 1);`. Le 31 octobre, cela donne le 31 novembre, qui n'existe pas, donc le 1er décembre : novembre est sauté. StatsPanel suit le même currentDate. La version mobile utilise correctement addMonths/subMonths (CalendarPage.tsx:148-151).
+- **Impact :** Les utilisateurs qui ouvrent le calendrier en fin de mois ne peuvent pas afficher le mois suivant normalement. Les commandes de ce mois semblent absentes.
+- **Recommandation :** Remplacer navigateMonth par `setCurrentDate(d => direction === 'prev' ? subMonths(startOfMonth(d), 1) : addMonths(startOfMonth(d), 1))`. Le bouton 'Aujourd'hui' est un ajout produit, à traiter séparément.
+
+### CAL-02
+
+**Calculs de debug exécutés en production dans la boucle de rendu** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/CalendarGrid.tsx:495`
+- **Constat :** CalendarGrid.tsx:495-506 `console.log('📅 All orders dates:', orders.map(o => ({...})))` et 519-525 / 542-548 (log pour chaque élément trouvé, avec `format(date,'yyyy-MM-dd')`). vite.config.ts:29 retire l'appel console.log (`pure`) mais pas ses arguments. Le bundle prod contient bien `s.length>0&&v.getDate()===1&&(s.length,s[0],s.map(S=>{...plannedDate...}))`. Il reste aussi des console.warn dans les boucles (385, 402, 410, 511, 534), et des console.log non protégés par DEV aux lignes 444 et 452.
+- **Impact :** Des tableaux et des formatages de dates sont créés inutilement à chaque rendu de la grille (42 cases). Le navigateur peut être inondé de warnings si une donnée est incomplète. La console est inutilisable pour le support.
+- **Recommandation :** Supprimer ces blocs de debug (et ceux de Calendar.tsx:53-60, 71-73, 102-109, 120-122, 146-153, 164-166). Garder au plus un console.warn unique hors boucle.
+
+### CAL-03
+
+**Filtrage O(42 × éléments) à chaque rendu, sans mémoïsation** — perf-client, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/CalendarGrid.tsx:579`
+- **Constat :** CalendarGrid.tsx:575-580 : dans `paddedDays.map`, `getItemsForDate(date)` parcourt et parse (safeDate) toutes les commandes et toutes les livraisons, et `getPublicitiesForDate(date)` parcourt toutes les publicités de l'année. Aucun useMemo. CalendarGrid n'est pas memo, et l'état des modales est dans Calendar.tsx (26-30), donc l'ouverture de 'Création rapide' ou d'une fiche recalcule toute la grille. Même chose sur mobile : CalendarPage.tsx:139-145 et 224.
+- **Impact :** Avec quelques centaines d'éléments par mois, plusieurs dizaines de milliers d'opérations par rendu. L'interface rame à l'ouverture des modales et à la navigation, surtout sur les postes de magasin peu puissants.
+- **Recommandation :** Construire une seule fois, avec useMemo, une Map<'yyyy-MM-dd', {orders, deliveries, pubs}> (une passe sur chaque liste). Envelopper CalendarGrid dans React.memo et passer des handlers stables (useCallback).
+
+### CAL-04
+
+**Spinner plein écran à chaque changement de mois, et la grille attend les publicités** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Calendar.tsx:204`
+- **Constat :** Calendar.tsx:204 `const isLoading = loadingOrders || loadingDeliveries || loadingPublicities;` puis 282-285 : un spinner remplace toute la grille. Chaque mois a une nouvelle clé (38-41, 87-90), sans placeholderData et sans préchargement des mois voisins.
+- **Impact :** La grille disparaît puis réapparaît à chaque clic sur les flèches. L'affichage dépend de la requête la plus lente (publicités, sans rapport avec la logistique), ce qui donne une impression de lenteur.
+- **Recommandation :** Ajouter `placeholderData: keepPreviousData` sur les 3 requêtes et afficher la grille avec un indicateur discret (barre fine ou opacité). Ne pas bloquer sur loadingPublicities. Précharger mois-1 et mois+1 avec queryClient.prefetchQuery. Pour le premier chargement, utiliser un squelette de grille plutôt qu'un spinner.
+
+### CAL-06
+
+**La légende ne correspond pas aux couleurs utilisées dans la grille** — coherence-design, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Calendar.tsx:224`
+- **Constat :** Calendar.tsx:224-237 : la légende utilise `bg-primary` (bleu vif), `bg-secondary` (vert foncé hsl(120,61%,34%)) et `bg-delivered` (gris). La grille utilise CalendarGrid.tsx:57-61 `bg-gray-400` (livré), `bg-yellow-300` (planifié, absent de la légende), `bg-blue-300` (commande), et 102-105 `bg-green-200` (livraison). Les publicités violettes (658) ne figurent pas dans la légende.
+- **Impact :** L'utilisateur ne peut pas décoder le calendrier : il ne sait pas ce que signifient le jaune ou le violet.
+- **Recommandation :** Générer la légende à partir des mêmes constantes que la grille et ajouter 'Commande planifiée' (jaune) et 'Publicité' (violet). Voir aussi ORD-12 pour un composant de statut unique.
+
+### CAL-07
+
+**Éléments du calendrier illisibles : texte de 11 px, icônes de 8 px, abréviations P/C, statut codé par des points** — lisibilite, sévérité moyenne, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/CalendarGrid.tsx:75`
+- **Constat :** CalendarGrid.tsx:75 `style={{fontSize: '11px', lineHeight: '1.2'}}`. 81-82 `w-4 h-4 ... <Link className="w-2 h-2"`. 50 `${quantity}${unit === 'palettes' ? 'P' : 'C'}`. 85-87 et 148-150 : statut indiqué par un point de 2×2 px avec un simple title. Le mois est affiché deux fois (Calendar.tsx:217-219 et 254-256).
+- **Impact :** Des employés non techniciens, sur des écrans de magasin, ne lisent pas les noms de fournisseurs et ne comprennent pas 'P', 'C' ni les pastilles.
+- **Recommandation :** Même reco, en corrigeant la preuve : le point de statut fait 8×8 px (w-2 h-2), les icônes de liaison et de commentaire 8 px, et l'icône livré 12 px.
+
+### CAL-08
+
+**Un clic n'importe où dans une case ouvre 'Création rapide', même sans droits, et le '+' n'est visible qu'au survol** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Calendar.tsx:181`
+- **Constat :** Calendar.tsx:181-184 `handleDateClick` ouvre QuickCreate sans vérifier de permission, alors que le bouton 'Nouveau' (267) est conditionné. CalendarGrid.tsx:594-603 : onClick sur toute la case. QuickCreateMenu.tsx:67-71 affiche alors 'Vous n'avez pas les permissions…'. CalendarGrid.tsx:644 et 675 `opacity-0 group-hover:opacity-100` pour le bouton '+'.
+- **Impact :** Des modales s'ouvrent par erreur au moindre clic, avec un message d'erreur pour les employés. Sur tablette tactile, le bouton '+' est introuvable.
+- **Recommandation :** Ne pas rendre la case cliquable pour créer : utiliser un bouton '+' toujours visible, et uniquement si l'utilisateur a orders:create ou deliveries:create. Un clic sur la case peut ouvrir une vue 'jour'.
+
+### CAL-10
+
+**Le panneau de statistiques en position fixe masque le bas du calendrier** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/StatsPanel.tsx:54`
+- **Constat :** StatsPanel.tsx:54 `<Card className="fixed bottom-6 right-6 min-w-80 shadow-lg border-gray-200">` (et 37 pour le squelette). Il est rendu par Calendar.tsx:335. Il n'est ni repliable ni déplaçable.
+- **Impact :** Les cases samedi et dimanche des dernières semaines sont recouvertes : les livraisons qui y figurent ne sont pas visibles.
+- **Recommandation :** Intégrer les 4 indicateurs dans un bandeau de KPI sous l'en-tête, ou dans un panneau latéral repliable.
+
+### CAL-11
+
+**Panneau 'Statistiques du mois' : chiffres Palettes, Colis et 'en attente' faux** — bug, sévérité moyenne, effort M
+
+- **Fichier :** `server/storage.ts:1297`
+- **Constat :** storage.ts:1297-1313 : `totalPalettes: SUM(CAST(quantity as INTEGER))` sans filtre sur unit, donc palettes et colis sont additionnés. `totalPackages: COUNT(*)`, affiché 'Colis' (StatsPanel.tsx:85-87), est en fait un nombre de livraisons. `.innerJoin(orders, …)` exclut les livraisons sans commande. pendingResult (1281-1290) n'est pas filtré par mois, mais il est affiché sous 'Statistiques du mois' (StatsPanel.tsx:101-105). Les lignes 1230-1240 renvoient des statistiques fictives (12, 8, 45…) si NODE_ENV==='development'.
+- **Impact :** Les managers et directeurs lisent des volumes de palettes et de colis erronés. Ils peuvent prendre de mauvaises décisions et perdre confiance dans l'outil.
+- **Recommandation :** Calculer `SUM(quantity) FILTER (WHERE unit='palettes')` et `SUM(quantity) FILTER (WHERE unit='colis')` en leftJoin. Filtrer 'en attente' sur le mois, ou le renommer 'Commandes en attente (toutes dates)'. Supprimer le retour de données fictives.
+
+### CAL-15
+
+**getPublicities ignore le filtre magasin, charge des groupes complets et regroupe en O(P×N)** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:1502`
+- **Constat :** storage.ts:1502 `async getPublicities(year?: number, groupIds?: number[])`. groupIds n'est jamais utilisé dans la requête (seul `eq(publicities.year, year)`). 1532-1541 : participations avec `group: groups` (logo). 1551-1553 : `participations.filter(p => p.publicityId === publicity.id)` pour chaque publicité. Côté client, Calendar.tsx:137-141 charge l'année entière, puis CalendarGrid.tsx:399-455 filtre en JS, pour chacun des 42 jours.
+- **Impact :** Les publicités de toute l'année et de tous les magasins sont transférées et traitées à chaque affichage du calendrier. Le calcul est inutile côté serveur comme côté navigateur.
+- **Recommandation :** Filtrer en SQL : `publicities.end_date >= :from AND start_date <= :to` et `EXISTS (participation WHERE group_id IN groupIds)`. Projeter group {id, name, color}. Regrouper les participations avec une Map.
+
+### CAL-16
+
+**fetch() manuels dupliqués : aucune gestion du 401 et aucun état d'erreur affiché** — dette-code, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Calendar.tsx:62`
+- **Constat :** Calendar.tsx:62-68 `const response = await fetch(url, ...); if (!response.ok) { throw new Error('Failed to fetch orders'); }`. Le message ne contient pas '401', donc il n'y a pas de redirection et queryClient.ts:79-88 relance 2 fois. Aucun rendu d'erreur : `data: orders = []`, ce qui donne un calendrier vide. Même schéma dans StatsPanel.tsx:22-31, Orders.tsx:78-87 et Deliveries.tsx:84-95. Le mobile (OrdersPage.tsx:51, DeliveriesPage.tsx:53, CalendarPage.tsx:67-69) fait `return []` sur erreur.
+- **Impact :** Quand le serveur ou la session échoue, l'utilisateur voit 'Aucune commande trouvée' ou un calendrier vide, sans message ni bouton Réessayer, avec 3 fois plus d'appels.
+- **Recommandation :** Utiliser la queryFn par défaut (getQueryFn), en construisant l'URL depuis la clé, ou un helper `fetchJson(url)` commun qui lève 'status: texte'. Ajouter un composant <ErrorState onRetry={refetch}/> sur chaque page.
+
+### LIV-01
+
+**Le filtre 'En attente' des livraisons ne correspond à aucun statut existant** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Deliveries.tsx:325`
+- **Constat :** Deliveries.tsx:325 `<SelectItem value="pending">En attente</SelectItem>`. Le schéma deliveries.status vaut 'planned, delivered' (shared/schema.ts:146) et createDelivery force 'planned' (storage.ts:1099-1102). Le badge 'pending' (199) n'est donc jamais utilisé.
+- **Impact :** Le filtre renvoie toujours 'Aucune livraison trouvée'. L'utilisateur conclut à tort qu'il n'a rien à recevoir.
+- **Recommandation :** Retirer l'option 'pending' du Select de Deliveries.tsx. Renommer 'planned' en 'À recevoir' est un choix de libellé à valider séparément.
+
+### LIV-02
+
+**'Contrôle effectué' validé en un clic, sans confirmation** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Deliveries.tsx:484`
+- **Constat :** Deliveries.tsx:480-490 `onClick={() => handleMarkControlValidated(delivery.id)}` lance directement PUT /api/deliveries/:id/control. L'icône CheckCircle se trouve à côté de l'icône Check de validation de livraison (469-478). Il n'y a pas d'annulation possible.
+- **Impact :** Un clic involontaire marque le contrôle qualité comme fait, de façon irréversible depuis l'interface. Cela pose un risque de traçabilité.
+- **Recommandation :** Utiliser un bouton texte 'Contrôle fait' avec une confirmation courte (ou une annulation via toast avec 'Annuler'), placé dans la colonne Statut à côté du badge 'Contrôle à faire'.
+
+### MCAL-01
+
+**Statuts affichés bruts en anglais et titres techniques 'Cmd #' / 'Liv #'** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/CalendarPage.tsx:293`
+- **Constat :** CalendarPage.tsx:288-294 `<Badge ...>{event.status}</Badge>` affiche 'pending', 'planned' ou 'delivered'. Lignes 105 et 113 : `title: `Cmd #${order.orderNumber || order.id}`` et `Liv #…`.
+- **Impact :** Des libellés anglais et des abréviations sont présentés à des utilisateurs francophones non techniciens.
+- **Recommandation :** Partie automatisable : un helper statusLabel(status) qui renvoie pending→'En attente', planned→'Planifiée', delivered→'Livrée', utilisé dans le Badge, et suppression des références à orderNumber et deliveryNumber. La restructuration titre/sous-titre (fournisseur en titre) est à valider côté produit.
+
+### MOB-03
+
+**Les erreurs serveur sont présentées comme 'Aucune commande trouvée'** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/OrdersPage.tsx:51`
+- **Constat :** OrdersPage.tsx:51 `if (!response.ok) return [];`. DeliveriesPage.tsx:53 idem. CalendarPage.tsx:67-69 et 92-94 idem. Le rendu affiche ensuite l'état vide (OrdersPage.tsx:140-144).
+- **Impact :** Lors d'une panne ou d'une session expirée, l'employé pense qu'il n'y a aucune livraison prévue.
+- **Recommandation :** Lever une erreur, afficher 'Impossible de charger les données' avec un bouton Réessayer, et rediriger vers /auth en cas de 401.
+
+### MOD-02
+
+**Gestion de session expirée inopérante : regex jamais vraie et redirection vers une route inexistante** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/lib/authUtils.ts:2`
+- **Constat :** authUtils.ts:2 `return /^401: .*Unauthorized/.test(error.message);` alors que le serveur répond `{ message: "Authentification requise" }` (localAuth.ts:250-254), d'où un message '401: {"message":"Authentification requise"}' qui ne correspond jamais. Par ailleurs `window.location.href = "/api/login"` (CreateOrderModal.tsx:139, EditOrderModal.tsx:81, OrderDetailModal.tsx:58/91/137, CreateDeliveryModal.tsx:170, EditDeliveryModal.tsx:101, ValidateDeliveryModal.tsx:82, Orders.tsx:156, Deliveries.tsx:162) pointe vers une route qui n'existe qu'en POST (localAuth.production.ts:203), et le fallback SPA exclut /api/ (index.production.ts:158-161).
+- **Impact :** Quand la session expire, l'utilisateur voit 'Impossible de créer la commande' sans comprendre et peut ressaisir plusieurs fois. Si la branche 401 était atteinte, il tomberait sur la page brute 'Cannot GET /api/login'.
+- **Recommandation :** Remplacer la regex par `/^401\b/` ET remplacer les 25 occurrences de "/api/login" par "/auth" (y compris Users.tsx, Suppliers.tsx, Groups.tsx), dans le même changement. Centraliser via MutationCache ensuite.
+
+### MOD-03
+
+**Un admin en 'Tous les magasins' ne peut pas choisir le magasin : le premier est imposé** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/modals/CreateOrderModal.tsx:84`
+- **Constat :** CreateOrderModal.tsx:79-85 `defaultGroupId = groups[0].id.toString();` quand aucun magasin n'est sélectionné, puis 202-221 : affichage en lecture seule (aucun Select). CreateDeliveryModal.tsx:99-105 et 265-284 : même chose.
+- **Impact :** La commande ou la livraison est créée dans le premier magasin alphabétique, sans possibilité de le changer depuis le formulaire. Cela produit des erreurs de saisie difficiles à repérer.
+- **Recommandation :** Si l'utilisateur a plusieurs magasins et qu'aucun n'est sélectionné dans l'en-tête, afficher un Select 'Magasin *' obligatoire, sans valeur par défaut. Sinon, afficher le magasin en lecture seule.
+
+### MOD-04
+
+**Choix du fournisseur dans une longue liste sans recherche** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/modals/CreateOrderModal.tsx:188`
+- **Constat :** CreateOrderModal.tsx:188-199, CreateDeliveryModal.tsx:227-238, EditOrderModal.tsx:132-143 et EditDeliveryModal.tsx:155-166 utilisent un `<Select>` Radix contenant tous les fournisseurs, issus de GET /api/suppliers (routes.ts:1150 `storage.getSuppliers()`).
+- **Impact :** Avec des dizaines de fournisseurs, il faut faire défiler une liste longue : la saisie est lente et les erreurs de sélection fréquentes.
+- **Recommandation :** Utiliser un Combobox (shadcn Command) avec saisie et filtrage, en affichant d'abord les fournisseurs récents ou fréquents du magasin.
+
+### ORD-03
+
+**Log par ligne à chaque frappe et filtrage sans mémoïsation** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Orders.tsx:169`
+- **Constat :** Orders.tsx:169 `console.log('🔍 Filtering order:', order.id, { searchTerm, statusFilter });` dans le `.filter`. En production l'appel est retiré, mais l'objet littéral reste alloué pour chaque commande à chaque rendu. Lignes 93-99 : log à chaque rendu avec `orders?.slice(0, 2)`. 84-85 et 109-130 : autres logs. `searchTerm.toLowerCase()` est recalculé 3 fois par ligne (170-172) et il n'y a pas de useMemo. Deliveries.tsx:86, 92-93, 101-107 et 175 : même chose.
+- **Impact :** La saisie dans la recherche devient saccadée quand l'historique est grand, puisque tout l'historique est rechargé côté client (ORD-02).
+- **Recommandation :** Supprimer tous les logs. Faire `const q = useDeferredValue(searchTerm.toLowerCase())` puis `const filtered = useMemo(() => …, [orders, q, statusFilter])`.
+
+### ORD-05
+
+**Invalidations qui ratent leur cible : clés de cache hétérogènes pour les mêmes données** — bug, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Orders.tsx:76`
+- **Constat :** Orders.tsx:76-77 `queryKey: [ordersUrl, selectedStoreId]` donne ['/api/orders?storeId=3', 3]. Or EditOrderModal.tsx:69, OrderDetailModal.tsx:47/122, ValidateDeliveryModal.tsx:65 et EditDeliveryModal.tsx:89 font `invalidateQueries({ queryKey: ['/api/orders'] })`, qui ne correspond pas à '/api/orders?storeId=3'. StatsPanel.tsx:21 `queryKey: [statsUrl, selectedStoreId]` ('/api/stats/monthly?year=…') n'est jamais touché par `['/api/stats/monthly']` (EditOrderModal:70, EditDeliveryModal:90, ValidateDeliveryModal:66, Deliveries.tsx:152). Deliveries.tsx:126/151 invalide `[deliveriesUrl]`, qui n'existe pas. Deliveries.tsx:83 met user?.role dans la clé. Les clés mobiles (CalendarPage.tsx:53 'yyyy-MM', OrdersPage.tsx:43) diffèrent du desktop. La suppression d'une livraison (Deliveries.tsx:150-152, OrderDetailModal.tsx:123-124) n'invalide pas /api/orders, alors que chaque commande embarque `deliveries`.
+- **Impact :** Après une suppression ou une validation depuis la fiche, la liste Commandes reste inchangée quand un magasin est sélectionné. Les statistiques du mois ne se mettent jamais à jour après modification, validation ou suppression. L'icône 'liée à des livraisons' du calendrier reste affichée après suppression de la livraison. L'utilisateur croit que l'action n'a pas marché.
+- **Recommandation :** Correction minimale et sûre, en gardant les queryFn personnalisées : Orders.tsx clé ['/api/orders', 'list', selectedStoreId]. StatsPanel clé ['/api/stats/monthly', year, month, selectedStoreId]. Supprimer les invalidations [deliveriesUrl]. Ajouter l'invalidation de ['/api/orders'] et ['/api/stats/monthly'] dans les onSuccess de suppression ou de modification de livraison (Deliveries.tsx, OrderDetailModal.tsx). La fabrique lib/queryKeys.ts peut venir plus tard.
+
+### ORD-06
+
+**La suppression recharge toutes les variantes en cache, y compris les inactives (invalidate puis refetch)** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Orders.tsx:141`
+- **Constat :** Orders.tsx:133-146 : `queryClient.invalidateQueries({ predicate: … '/api/orders' || '/api/deliveries' })` suivi de `queryClient.refetchQueries({ predicate: … })` sans `type: 'active'`. Tous les mois du calendrier visités et l'historique complet des livraisons sont donc rechargés en même temps. Lignes 125-127 : `localStorage.setItem('selectedStoreId', …)` est un contournement sans effet ici.
+- **Impact :** Une suppression déclenche N gros appels simultanés. Le serveur et le réseau sont saturés juste après l'action.
+- **Recommandation :** Garder uniquement invalidateQueries (refetchType 'active' par défaut), ou retirer la ligne avec une mise à jour optimiste (setQueryData). Supprimer le contournement localStorage.
+
+### ORD-10
+
+**Actions en icônes seules, sans libellé ni info-bulle, et deux coches ambiguës** — accessibilite, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Deliveries.tsx:453`
+- **Constat :** Orders.tsx:382-406 : boutons Eye, Edit et Trash2 sans title ni aria-label. Deliveries.tsx:453-500 : jusqu'à 5 icônes (Eye, Edit, Check 'valider livraison', CheckCircle orange 'contrôle', Trash2). Seul le bouton contrôle a un title (487).
+- **Impact :** Un utilisateur non technicien ne sait pas quelle coche valide la réception ou le contrôle. Les lecteurs d'écran annoncent 'bouton' sans nom.
+- **Recommandation :** Partie automatisable : ajouter aria-label et title ('Voir', 'Modifier', 'Valider la réception', 'Marquer le contrôle comme effectué', 'Supprimer') à chaque bouton icône d'Orders.tsx et Deliveries.tsx. Le reste (bouton principal texte, menu) est à valider côté produit.
+
+### ORD-11
+
+**Tableaux tronqués sur écrans étroits : pas de défilement horizontal** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Orders.tsx:316`
+- **Constat :** Orders.tsx:314-316 : wrapper `overflow-hidden`, puis `<table className="w-full min-w-[700px]">`, ce qui coupe la colonne Actions. Deliveries.tsx:362-364 : 8 colonnes dans `overflow-hidden`. L'en-tête (281) n'a pas de variantes responsive, contrairement à Orders (234).
+- **Impact :** Sur tablette ou petit portable, les boutons Valider et Supprimer sont invisibles.
+- **Recommandation :** Utiliser `overflow-x-auto` sur le wrapper et masquer 'Créé par' et 'Magasin' sous lg (`hidden lg:table-cell`). En dessous de md, afficher des cartes.
+
+### ORD-12
+
+**Couleurs et libellés de statut différents selon les pages, et couleurs des boutons principaux incohérentes** — coherence-design, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Orders.tsx:190`
+- **Constat :** Orders.tsx:190-201, Deliveries.tsx:196-207 et OrderDetailModal.tsx:170-181 : planned en bleu, delivered en vert, pending en gris. CalendarGrid.tsx:54-63 : planned en jaune, delivered en gris, pending en bleu. Mobile OrdersPage.tsx:75-85 : pending en jaune, 'Livrée'. Boutons 'Nouveau' : orange bg-accent (Calendar.tsx:270), bleu (Orders.tsx:247), vert (Deliveries.tsx:294). En-têtes de tableau mixtes dans Deliveries.tsx:367-391 (text-xs font-medium gray-500 contre text-sm font-black gray-800). Padding doublé (278 et 361).
+- **Impact :** Le même statut change de couleur d'un écran à l'autre, ce qui empêche l'utilisateur de se fier aux repères visuels.
+- **Recommandation :** Créer un composant unique `<StatusBadge kind="order|delivery" status>` avec des tokens (lib/status.ts) utilisé partout (desktop, mobile, calendrier, légende). Utiliser une seule couleur d'action principale. Uniformiser les en-têtes de tableau.
+
+### ORD-13
+
+**La suppression d'une commande liée à des livraisons échoue avec un message générique** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `server/storage.ts:880`
+- **Constat :** storage.ts:880-882 `await db.delete(orders).where(eq(orders.id, id));` ne traite pas les livraisons liées. init.sql:450-451 : `deliveries_order_id_fkey ... ON DELETE NO ACTION`. Le serveur renvoie donc 500 'Failed to delete order' (routes.ts:1683-1686), affiché 'Impossible de supprimer la commande' (Orders.tsx:160-164). ConfirmDeleteModal ne mentionne pas les livraisons liées.
+- **Impact :** L'utilisateur ne comprend pas pourquoi la suppression échoue et retente, ou appelle le support.
+- **Recommandation :** Côté serveur, compter les livraisons liées et renvoyer 409 avec 'Cette commande a N livraison(s) liée(s). Supprimez-les ou détachez-les d'abord.' Afficher ce message dans le toast et indiquer N dans la confirmation.
+
+### PERM-01
+
+**Deux matrices de permissions divergentes entre client et serveur** — dette-code, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/lib/permissions.ts:1`
+- **Constat :** client/src/lib/permissions.ts (utilisée par Calendar.tsx:17, OrderDetailModal.tsx:15 et QuickCreateMenu.tsx:5) : orders.employee ['view'], deliveries.employee ['view'], pas de 'validate'. shared/permissions.ts (utilisée par Orders.tsx:13, Deliveries.tsx:13 et le serveur) : orders.employee [], deliveries avec 'validate'. D'où les rôles codés en dur dans OrderDetailModal.tsx:167 et la page desktop Commandes qui bloque l'employé (Orders.tsx:41-59) alors que le mobile ne le fait pas.
+- **Impact :** Les boutons affichés ne correspondent pas aux droits réels : des actions refusées par le serveur sont proposées, d'autres sont masquées à tort.
+- **Recommandation :** Supprimer client/src/lib/permissions.ts, importer @shared/permissions partout (desktop et mobile) et centraliser les gardes de page.
+
+### SRV-02
+
+**Imbrications redondantes : livraisons complètes dans chaque commande et commande complète dans chaque livraison** — perf-api, sévérité moyenne, effort M
+
+- **Fichier :** `server/storage.ts:522`
+- **Constat :** storage.ts:522-578 (loadDeliveriesByOrderIds) : chaque commande embarque ses livraisons avec 24 colonnes plus supplier, group et creator. storage.ts:584-617 (loadOrdersByIds) : chaque livraison embarque sa commande avec supplier, group et creator (email compris). Le client n'utilise que `deliveries.length`, le statut et les dates (CalendarGrid.tsx:80, OrderDetailModal.tsx:311-328) et `order.id`, plannedDate et status (Deliveries.tsx:436-439, OrderDetailModal.tsx:343-349).
+- **Impact :** La charge utile des listes double ou triple sans bénéfice. La sérialisation et le parsing JSON sont plus lents.
+- **Recommandation :** Pour les listes, renvoyer des sous-objets légers : deliveries {id, status, scheduledDate, deliveredDate, quantity, unit} et order {id, plannedDate, status}. Réserver le détail complet à GET /api/orders/:id et /api/deliveries/:id.
+
+### SRV-04
+
+**Utilisateur et magasins rechargés deux fois par requête API** — perf-serveur, sévérité moyenne, effort M
+
+- **Fichier :** `server/localAuth.production.ts:195`
+- **Constat :** localAuth.production.ts:193-196 : `deserializeUser` appelle déjà `storage.getUserWithGroups(id)` (2 requêtes : users, puis user_groups JOIN groups, storage.ts:371-407). Ensuite, chaque handler refait `storage.getUserWithGroups(req.user.claims ? … : req.user.id)` (routes.ts:1345, 1754, 4157, 4597… 91 occurrences).
+- **Impact :** 4 requêtes SQL d'authentification au lieu de 2 sur chaque appel. Le calendrier en fait 4 en parallèle (orders, deliveries, ad-campaigns, stats), soit 16 requêtes d'authentification par changement de mois.
+- **Recommandation :** Créer `async function getRequestUser(req) { return req.user?.userGroups ? req.user : storage.getUserWithGroups(req.user?.claims ? req.user.claims.sub : req.user.id); }` et remplacer les 91 appels par ce helper. Le repli couvre le cas où req.user vient d'un login sans groupes, ou d'un ancien format avec claims.
+
+### SRV-05
+
+**Toutes les réponses JSON sont clonées récursivement pour retirer smtpPassword** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:168`
+- **Constat :** routes.ts:165-170 `res.json = (body: any) => originalJson(stripSmtpPassword(body));`. sanitize.ts:13-40 parcourt et recopie chaque objet (Object.entries, WeakSet, profondeur jusqu'à 8) de chaque réponse /api, y compris les listes de milliers de commandes avec leurs imbrications.
+- **Impact :** Une copie complète supplémentaire, en CPU et en mémoire, avant JSON.stringify, sur les plus grosses réponses. La latence des listes augmente.
+- **Recommandation :** Ne jamais sélectionner smtpPassword dans les requêtes (projection, voir SRV-01) et limiter le nettoyage aux routes /api/groups* et /api/users*. Ou appliquer stripSmtpPassword seulement si le body contient un group (vérification à plat).
+
+### SRV-07
+
+**Manager ou directeur multi-magasins sans sélection : seul le premier magasin est renvoyé, en silence** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:1419`
+- **Constat :** routes.ts:1401-1428 `groupIds = [userGroupIds[0]]; // Use first assigned store automatically` (commandes), et 1810-1837 pour les livraisons. À l'inverse, /api/stats/monthly (4173-4180) agrège tous les magasins de l'utilisateur.
+- **Impact :** La liste et les statistiques ne portent pas sur le même périmètre, sans que l'écran l'indique. Les données d'un second magasin semblent manquantes.
+- **Recommandation :** Choisir une règle unique : soit tous les magasins de l'utilisateur partout, soit une sélection obligatoire côté interface (Layout.tsx:195 affiche déjà un avertissement), en affichant clairement le magasin concerné.
+
+### SRV-08
+
+**Contrôles d'accès par magasin incomplets (validation, contrôle, lecture, statistiques)** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:2624`
+- **Constat :** routes.ts:2624 `if (user.role === 'manager') {` : un directeur peut valider une livraison de n'importe quel magasin via son id. PUT /api/deliveries/:id/control (2678-2705) ne vérifie pas l'appartenance au magasin. GET /api/orders (1343) ne vérifie pas hasPermission('orders','view'), alors que shared/permissions.ts:41 donne `employee: []`. Un employé qui passe un storeId reçoit donc les commandes (et la page mobile OrdersPage ne le bloque pas). /api/stats/monthly : si userGroupIds est vide, `groupIds = []` (4179), et storage.ts:1262 (`groupIds.length > 0`) n'applique aucun filtre, ce qui renvoie les statistiques de tous les magasins.
+- **Impact :** Des actions et des données d'autres magasins sont accessibles, et le comportement diffère entre desktop et mobile.
+- **Recommandation :** Créer un helper `assertStoreAccess(user, groupId)` et l'appliquer à validate, control, PUT et DELETE. Vérifier hasPermission(module,'view') sur les GET de liste. Traiter groupIds vide comme 'aucun accès', avec une réponse vide.
+
+### CAL-05
+
+**Les jours des mois voisins sont affichés mais toujours vides** — bug, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Calendar.tsx:33`
+- **Constat :** Calendar.tsx:33-34 et 38-46 : requête de startOfMonth à endOfMonth. CalendarGrid.tsx:473-489 : grille de 42 jours qui inclut la fin du mois précédent et le début du suivant. Sur mobile : CalendarPage.tsx:55-56 (mois) contre 125-127 (startOfWeek/endOfWeek).
+- **Impact :** Une livraison prévue le 1er du mois suivant n'apparaît pas dans la dernière semaine affichée. L'utilisateur peut croire qu'il n'y a rien.
+- **Recommandation :** Desktop : calculer la plage comme la grille, from = monthStart - startPadding jours (lundi), to = from + 41 jours. Exposer ces bornes depuis un helper commun à Calendar et CalendarGrid et les utiliser dans les clés et paramètres des requêtes orders et deliveries. Mobile : requêter de startOfWeek(monthStart,{locale: fr}) à endOfWeek(monthEnd,{locale: fr}).
+
+### CAL-12
+
+**Statistiques mensuelles : 4 requêtes séquentielles, sans cache** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/storage.ts:1270`
+- **Constat :** storage.ts:1270 `const ordersResult = await db…`, 1276 `const deliveriesResult = await db…`, 1287 `const pendingResult = await db…`, 1297 `const deliveriesStatsResult = await db…` : quatre await successifs et indépendants. server/cache.ts n'est pas utilisé pour ces statistiques.
+- **Impact :** La latence du panneau est la somme de 4 allers-retours SQL à chaque affichage ou changement de mois.
+- **Recommandation :** Partie automatisable : exécuter les 4 requêtes avec `Promise.all`. Le cache de 60 s par (année, mois, magasin) est à faire séparément, avec une invalidation dans toutes les routes de mutation des commandes et livraisons.
+
+### CAL-13
+
+**La fenêtre '+X autres' affiche la date de création des commandes au lieu de la date prévue** — bug, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/CalendarGrid.tsx:324`
+- **Constat :** CalendarGrid.tsx:323-328 `{item.scheduledDate ? ... : item.deliveredDate ? ... : new Date(item.createdAt).toLocaleDateString('fr-FR')}`. Les commandes n'ont pas de scheduledDate mais un plannedDate (schema.ts:125).
+- **Impact :** Une date incohérente s'affiche dans la liste du jour.
+- **Recommandation :** Utiliser `isOrder ? item.plannedDate : item.scheduledDate` via safeFormat.
+
+### CAL-14
+
+**Seulement 2 éléments par jour, et des modales imbriquées avec des contournements de z-index et d'état** — ux-simplicite, sévérité basse, effort M
+
+- **Fichier :** `client/src/components/CalendarGrid.tsx:177`
+- **Constat :** CalendarGrid.tsx:177 `const MAX_VISIBLE_ITEMS = 2;` puis le bouton '+N autres', qui ouvre un Dialog (224, `z-[9999]`), lequel ouvre un CommentModal (15, `z-[99999]`), lequel peut ouvrir OrderDetailModal. Des drapeaux d'état servent à contourner les clics (47, 113-116, 176, 261-268) avec un setTimeout (163, 346).
+- **Impact :** Les jours chargés demandent un clic supplémentaire. La superposition de modales désoriente. Le code est fragile (clics fantômes).
+- **Recommandation :** Afficher plus d'éléments en mode compact, ou proposer une vue semaine. Ouvrir un panneau latéral 'Journée du JJ/MM' qui liste tout, avec le commentaire en ligne au lieu d'une modale de commentaire.
+
+### CAL-17
+
+**Double chargement au démarrage : les requêtes partent avant la sélection automatique du magasin** — perf-client, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/Layout.tsx:70`
+- **Constat :** Layout.tsx:70-73 sélectionne automatiquement le magasin après le chargement de /api/groups, et 77 expose `storeInitialized`. Mais les requêtes de Calendar.tsx:37, Orders.tsx:76 et Deliveries.tsx:82 n'ont pas `enabled: storeInitialized`. Le premier appel part sans storeId (le serveur prend alors le 1er magasin, routes.ts:1419-1423), puis un second part avec storeId.
+- **Impact :** Deux gros appels au lieu d'un à la première connexion d'un manager ou d'un directeur.
+- **Recommandation :** Si l'on corrige : faire passer storeInitialized à true aussi quand /api/groups a répondu avec une liste vide (ou en erreur) dans Layout.tsx, puis ajouter `enabled: !!user && storeInitialized` aux requêtes de Calendar, Orders et Deliveries. Gain faible : à prioriser bas.
+
+### MOD-05
+
+**useEffect et logs exécutés à chaque rendu (dépendance recréée)** — perf-client, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/modals/CreateOrderModal.tsx:49`
+- **Constat :** CreateOrderModal.tsx:49-53 : `const groups = ... groupsData.filter(...)` crée un nouveau tableau à chaque rendu. Il figure dans les dépendances de useEffect (103), donc l'effet tourne à chaque rendu, avec un console.log et `groups.map` (57-64). CreateDeliveryModal.tsx:53-57 et 76-124 : même chose. Logs aux lignes 107-109, 118 et 151.
+- **Impact :** Travail et allocations inutiles à chaque frappe dans le formulaire.
+- **Recommandation :** Envelopper groups dans useMemo et supprimer les console.log.
+
+### MOD-06
+
+**Données de référence rechargées à chaque ouverture de modale** — perf-client, sévérité basse, effort S
+
+- **Fichier :** `client/src/lib/queryClient.ts:77`
+- **Constat :** queryClient.ts:75-77 `refetchOnMount: true, staleTime: 30 * 1000`. Les modales sont montées conditionnellement (Orders.tsx:433-439, Calendar.tsx:318-332). À chaque ouverture après 30 s, /api/suppliers, /api/groups et /api/orders (modales livraison) sont donc refetchés.
+- **Impact :** Les formulaires s'ouvrent avec des listes qui se rechargent, et le serveur reçoit des appels redondants.
+- **Recommandation :** Définir `queryClient.setQueryDefaults(['/api/suppliers'], { staleTime: 15*60*1000 })`, et la même chose pour ['/api/groups']. Invalider ces clés seulement après une mutation fournisseur ou magasin.
+
+### MOD-07
+
+**Mutation morte, confirmation de suppression dupliquée et rôles codés en dur** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/modals/OrderDetailModal.tsx:70`
+- **Constat :** OrderDetailModal.tsx:70-101 : `validateDeliveryMutation` n'est jamais appelée (la validation passe par ValidateDeliveryModal). 405-432 : overlay de confirmation fait maison au lieu de ConfirmDeleteModal. 167-168 `canValidate = (user?.role === 'admin' || user?.role === 'directeur' || user?.role === 'manager')` au lieu de hasPermission.
+- **Impact :** Code inutile, et une confirmation visuellement différente du reste de l'application.
+- **Recommandation :** Partie automatisable : supprimer validateDeliveryMutation et remplacer le test de rôle par `hasPermission(user?.role || '', 'deliveries', 'validate')` importé de @shared/permissions (en gardant `isDelivery && item.status !== 'delivered'`). Passer à ConfirmDeleteModal est optionnel et visuel.
+
+### MOD-08
+
+**Modale d'édition empilée sur la fiche, données périmées après modification, contenu limité à 384 px** — ux-simplicite, sévérité basse, effort M
+
+- **Fichier :** `client/src/components/modals/OrderDetailModal.tsx:437`
+- **Constat :** OrderDetailModal.tsx:437-451 : EditOrderModal et EditDeliveryModal s'ouvrent par-dessus la fiche, qui reste ouverte. La fiche affiche `item`, une copie figée (Calendar.tsx:188 `setSelectedItem({ ...item, type })`), et montre donc les anciennes valeurs après modification. 220 : `overflow-y-auto max-h-96` dans une modale de 90vh. 194 : en-tête dégradé bleu même pour une livraison.
+- **Impact :** L'utilisateur croit que sa modification n'a pas été prise en compte. Il doit défiler dans une petite zone.
+- **Recommandation :** Passer la fiche en mode édition dans la même modale. Lire l'élément depuis le cache par id (useQuery(['/api/orders', id]) ou select sur la liste). Retirer max-h-96 au profit du scroll de DialogContent. Utiliser des couleurs distinctes pour commande et livraison.
+
+### MOD-09
+
+**Pieds de modale et boutons d'action incohérents** — coherence-design, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/modals/CreateOrderModal.tsx:245`
+- **Constat :** CreateOrderModal.tsx:245 et CreateDeliveryModal.tsx:334 : `flex items-center space-x-3`, boutons alignés à gauche. EditOrderModal.tsx:189, EditDeliveryModal.tsx:257 et ValidateDeliveryModal.tsx:160 : `justify-end`. EditDeliveryModal.tsx:264 : bouton bleu `bg-primary` alors que la création de livraison est verte (CreateDeliveryModal.tsx:341). Icônes Check entourées d'une bordure grise (ValidateDeliveryModal.tsx:105/175, OrderDetailModal.tsx:387/397, Deliveries.tsx:477).
+- **Impact :** L'utilisateur cherche le bouton de validation à un endroit différent selon la modale.
+- **Recommandation :** Utiliser DialogFooter partout ('Annuler' en outline à gauche, action principale à droite), avec une couleur par type d'objet, et retirer les bordures d'icônes.
+
+### MOD-10
+
+**Le champ 'Commande liée' disparaît si la commande liée est déjà livrée** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/modals/EditDeliveryModal.tsx:191`
+- **Constat :** EditDeliveryModal.tsx:55-61 filtre `order.status !== 'delivered'`, puis 191 `{availableOrders.length > 0 && (...)}`. La commande actuellement liée, si elle est livrée, n'est pas dans la liste et le champ peut être masqué.
+- **Impact :** Impossible de voir ou de détacher la commande liée lors de la correction d'une livraison.
+- **Recommandation :** Toujours afficher le champ et y inclure la commande actuellement liée (delivery.orderId), quel que soit son statut.
+
+### ORD-04
+
+**Requête /api/groups inutilisée** — perf-client, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Orders.tsx:101`
+- **Constat :** Orders.tsx:101-105 `const { data: groupsData = [] } = useQuery({ queryKey: ['/api/groups'] }); const groups = …;` : `groups` n'est jamais référencé (grep). Deliveries.tsx:109-113 : même chose.
+- **Impact :** Abonnement et refetch inutiles (la liste admin contient les logos).
+- **Recommandation :** Supprimer ces deux requêtes. Si besoin, utiliser `stores` du StoreContext.
+
+### ORD-07
+
+**Hooks appelés après un return anticipé (règle des hooks violée)** — bug, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Orders.tsx:41`
+- **Constat :** Orders.tsx:41-59 `if (user?.role === 'employee') { return (...) }` est placé avant `useState` (61-69), `useQuery` (76, 101), `useMutation` (107) et `usePagination` (180). Deliveries.tsx:46-64, puis useState à partir de 66 : même chose.
+- **Impact :** Si le rôle change pendant la session (rechargement de l'utilisateur), React plante avec 'Rendered more/fewer hooks than expected' et l'écran devient blanc.
+- **Recommandation :** Extraire le contenu dans un composant OrdersContent et faire le contrôle de rôle dans un wrapper, ou via une garde de route commune.
+
+### ORD-08
+
+**'Groupe' et 'Magasin/Groupe' au lieu de 'Magasin'** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Orders.tsx:323`
+- **Constat :** Orders.tsx:323 colonne 'Groupe' et 264 'Rechercher par fournisseur, groupe...'. Deliveries.tsx:371 et 310. CreateOrderModal.tsx:205, EditOrderModal.tsx:147, OrderDetailModal.tsx:261 et CreateDeliveryModal.tsx:268 : 'Magasin/Groupe'. La navigation dit 'Magasins' (Sidebar.tsx:347) et le sélecteur 'Magasin' (Layout.tsx:161).
+- **Impact :** Le jargon technique hérité (table groups) est incohérent et ambigu pour l'utilisateur.
+- **Recommandation :** Remplacer 'Groupe' et 'Magasin/Groupe' par 'Magasin' aux 10 emplacements, EditDeliveryModal.tsx:170 compris.
+
+### ORD-09
+
+**Identifiants techniques affichés sous des formes différentes selon l'écran** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/modals/OrderDetailModal.tsx:209`
+- **Constat :** OrderDetailModal.tsx:209 `#{isOrder ? 'CMD' : 'LIV'}-{item.id}`. Orders.tsx:350 et Deliveries.tsx:404 `#{order.id}`. Deliveries.tsx:439 `#{delivery.order.id}`. CreateDeliveryModal.tsx:252 `#{order.id} - {supplier} - date`. EditDeliveryModal.tsx:202 `Commande #…`. Mobile : `Cmd #` et `Liv #` (CalendarPage.tsx:105/113).
+- **Impact :** Une même commande apparaît sous 3 notations, ce qui complique la recherche et la communication entre collègues.
+- **Recommandation :** Adopter un format unique (CMD-123 / LIV-456) via un helper, et l'utiliser aussi dans la recherche. Dans la colonne 'Commande liée', afficher plutôt la date et le fournisseur.
+
+### ORD-14
+
+**Retour à la page 1 après chaque suppression, et confirmation fermée avant la fin de l'action** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/ui/pagination.tsx:157`
+- **Constat :** pagination.tsx:157-159 `useEffect(() => { setCurrentPage(1); }, [data.length]);`. Orders.tsx:218-224 `deleteMutation.mutate(...); setShowDeleteModal(false);` : l'état isLoading passé à ConfirmDeleteModal (468) n'est jamais visible. Même chose dans Deliveries.tsx:264-270.
+- **Impact :** Après une suppression en page 4, l'utilisateur est renvoyé en page 1 et perd sa place. Il n'a aucun retour visuel pendant la suppression.
+- **Recommandation :** Ne réinitialiser la page que si les filtres changent (et borner à totalPages). Fermer la confirmation dans onSuccess.
+
+### ORD-15
+
+**Pas de tri, pas de filtre de période, recherche sans n° de BL** — ux-simplicite, sévérité basse, effort M
+
+- **Fichier :** `client/src/pages/Deliveries.tsx:176`
+- **Constat :** Deliveries.tsx:176-178 : la recherche porte sur supplier, group et notes, mais pas sur blNumber. Orders.tsx:170-172 : même chose. L'ordre est celui du serveur, `orderBy(desc(orders.createdAt))` (storage.ts:715) et desc(deliveries.createdAt) (931), et non la date prévue. Aucun en-tête de colonne n'est triable et il n'existe pas de filtre 'cette semaine'.
+- **Impact :** Pour trouver les livraisons de demain ou un BL précis, l'utilisateur doit parcourir les pages.
+- **Recommandation :** Trier par date prévue par défaut (les prochaines en premier). Ajouter des raccourcis 'Aujourd'hui', 'Cette semaine' et 'En retard'. Inclure blNumber dans la recherche, en SQL (voir ORD-02).
+
+### SRV-06
+
+**Logs console à chaque appel des chemins chauds** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:1353`
+- **Constat :** routes.ts:1353 `console.log('Orders API called with:', …)`, 1360-1430 (un log par branche de rôle), 1456 `console.log('Orders returned:', …)`, 1762-1869 (même chose pour les livraisons). storage.ts:719 `getOrders() récupéré…`, 934, 1252 et 1330 (stats), 1519-1522 (publicités, avec la désignation des 3 premières).
+- **Impact :** Des E/S synchrones sur stdout à chaque requête et des logs de production illisibles.
+- **Recommandation :** Utiliser un logger à niveaux (debug désactivé en production) et ne garder que les erreurs.
+
+### SRV-09
+
+**Le filtre withBL est appliqué en JavaScript après le chargement complet** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:1864`
+- **Constat :** routes.ts:1864-1866 `if (withBL === 'true') { deliveries = deliveries.filter((d: any) => d.blNumber && d.status === 'delivered'); }`, exécuté après getDeliveries ou getDeliveriesByDateRange complet.
+- **Impact :** Toutes les livraisons sont lues et sérialisées pour n'en renvoyer qu'une partie.
+- **Recommandation :** Ajouter à getDeliveries un filtre SQL optionnel (status = 'delivered', voire bl_number IS NOT NULL) exposé par un paramètre de /api/deliveries, et l'utiliser depuis BLReconciliation.tsx, après avoir vérifié que la page n'a pas besoin des livraisons sans BL. Supprimer ou réutiliser le paramètre mort withBL.

docs/audit-webui/03-reconciliation-payment.md

@@ -0,0 +1,463 @@
+# Rapprochement BL/Factures & Échéancier
+
+_40 constats vérifiés — 6 haute, 22 moyenne, 12 basse._
+
+## Pages analysées
+
+### `/bl-reconciliation`
+
+**Rôle :** Rapprocher les bons de livraison (BL) des factures fournisseurs : vérifier que la facture existe dans NocoDB, compléter la référence, le montant et l'échéance, valider le rapprochement, relancer le fournisseur par mail, envoyer une facture PDF au webhook du magasin et commenter les écarts.
+
+**Tâches principales de l'utilisateur :**
+- Voir les livraisons livrées à rapprocher (onglet manuel) et celles déjà validées
+- Vérifier une facture (loupe, ou bouton « Vérifier toutes les factures »)
+- Valider ou dévalider un rapprochement
+- Modifier N° BL, montants, référence facture et échéance (modale)
+- Demander la facture ou le BL au fournisseur par mail
+- Envoyer une facture PDF au webhook (modale + attente)
+- Ajouter, modifier ou supprimer des commentaires de rapprochement
+- Rechercher par fournisseur, BL, facture ou magasin
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/suppliers | au montage | server/routes.ts:1141 -> storage.getSuppliers (storage.ts:467, SELECT * FROM suppliers) | Redondant : chaque livraison contient déjà supplier complet (jointure storage.ts:912). Bloque l'effet de vérification automatique (BLReconciliation.tsx:387) alors que suppliers n'y est pas utilisé. |
+| GET /api/supplier-mail-logs?storeId= | au montage (enabled: !!user) | server/routes.ts:2439 -> storage.getSupplierMailLogs (storage.ts:2974, LIMIT 500, index sur delivery_id et group_id) | Correct et borné. storeId ignoré pour le directeur (seul l'admin le prend en compte, routes.ts:2454). |
+| GET /api/deliveries?storeId= | au montage, staleTime 0 (refetch à chaque visite), queryKey ['/api/deliveries/bl', storeId] | server/routes.ts:1752 -> storage.getDeliveries (storage.ts:885) + attachOrdersAndCommentCounts (storage.ts:643 : loadOrdersByIds + count des commentaires) | Toutes les livraisons du magasin (ou de tous les magasins pour l'admin), tous statuts, sans pagination. Filtrage status==='delivered' fait côté navigateur (BLReconciliation.tsx:371). Chaque ligne embarque la ligne groups complète (logo base64, config SMTP/NocoDB/webhook) et la commande avec à nouveau supplier + group. Pas de compression HTTP. Toute la réponse est clonée récursivement par stripSmtpPassword (routes.ts:168-174). |
+| POST /api/deliveries/:id/verify-invoice | automatique au montage pour chaque livraison livrée sans montant facture (file de 3 requêtes simultanées), clic sur la loupe, bouton « Vérifier toutes les factures » (forceRefresh) | server/routes.ts:2466 -> getUserWithGroups (2 requêtes) + getDelivery (storage.ts:1004 : jointure + getUser + getOrder [2 requêtes] + count commentaires) + invoiceVerificationService.verifyInvoice/verifyInvoiceByBL (invoiceVerification.ts:249/612 : cache BD, getGroup, getActiveNocodbConfig, 1 à 2 appels NocoDB, upsert cache) + storage.updateDelivery | Environ 10 requêtes séquentielles par livraison, plus NocoDB en cas d'absence en cache. Le serveur enregistre déjà montant, TTC, échéance et référence (routes.ts:2555-2587), mais le client renvoie en plus un PUT identique. |
+| PUT /api/deliveries/:id | auto-remplissage après chaque vérification réussie, validation rapide, dévalidation, enregistrement de la modale | server/routes.ts:1906 -> getUserWithGroups + getDelivery + (si invoiceReference change) verifyInvoice forceRefresh synchrone + storage.updateDelivery (storage.ts:1136) + (si blNumber présent) storage.getSuppliers() complet | Le PUT d'auto-remplissage fait doublon avec verify-invoice. La modale envoie toujours blNumber, ce qui charge toute la table fournisseurs. Logs complets du corps et de l'objet mis à jour. |
+| DELETE /api/deliveries/:id | au clic (window.confirm) | server/routes.ts:2136 -> getDelivery + storage.deleteDelivery (storage.ts:1175) | Suivi de refetchQueries sur ['/api/deliveries/bl'] et ['/api/deliveries'] (toutes les requêtes livraisons en cache, même inactives). |
+| POST /api/deliveries/:id/send-supplier-mail | au clic sur l'icône mail | server/routes.ts:2330 -> getDelivery + storage.getGroup + sendSupplierDocumentRequest + storage.createSupplierMailLog (storage.ts:2969) | OK fonctionnellement ; invalide ensuite /api/supplier-mail-logs. |
+| POST /api/reconciliation/send-invoice (multipart) | au clic « Envoyer » dans la modale Envoyer Facture | server/routes.ts:883 -> parse multipart manuel + fetch(parts.webhookUrl) sans timeout | L'URL du webhook vient du client (risque SSRF), le corps est lu sans limite de taille, il n'y a de timeout ni côté client ni côté serveur, et la modale d'attente ne peut pas être fermée. Réservé admin/directeur côté serveur, mais le bouton est affiché sans contrôle de rôle. |
+| GET /api/deliveries/:id/reconciliation-comments | ouverture de la modale commentaires ou de l'onglet Commentaires de ReconciliationModal | server/routes.ts:2175 -> getDelivery + storage.getReconciliationComments (storage.ts:3035) | Sélectionne author: users (ligne complète, hash du mot de passe inclus), group: groups (logo) et une copie de la livraison pour chaque commentaire. |
+| POST /api/deliveries/:id/reconciliation-comments, PUT/DELETE /api/reconciliation-comments/:id | au clic Ajouter / Enregistrer / Supprimer | server/routes.ts:2211 / 2254 / 2292 -> storage.createReconciliationComment / updateReconciliationComment / deleteReconciliationComment (storage.ts:3142-3163) | Chaque mutation invalide toute la liste des livraisons (['/api/deliveries'] et ['/api/deliveries/bl']) juste pour mettre à jour un compteur. |
+
+**Lisibilité / simplicité :** La page est dense et technique. Le tableau a 10 colonnes (min-w 900px, même sur mobile) et jusqu'à 6 boutons-icônes par ligne, sans texte, expliqués seulement par l'attribut title (invisible au toucher). Les deux onglets n'ont ni le même ordre de colonnes, ni la même unité d'écart (€ avec seuil 10 € d'un côté, % avec seuil 5 % de l'autre), ni le même style de boutons. Les compteurs apparaissent deux fois (badges d'en-tête et badges d'onglets). Le jargon est fréquent : « Rapprochement Manuel », « AUTO », « Ref. Facture », « Montant Fact. », « webhook », « workflow », URL technique du webhook affichée. Les coches verte et rouge n'expliquent pas pourquoi une facture est introuvable. Le bouton Valider reste grisé avec une consigne trompeuse quand le magasin n'a pas NocoDB. La modale d'attente ne se ferme jamais si le webhook ne répond pas. Les erreurs s'affichent en JSON brut anglais (« 403: {"message":...} »). Les confirmations utilisent window.confirm, alors qu'Avoirs et DLC utilisent AlertDialog. Le chargement est un simple texte « Chargement... » en pleine page. La pagination revient à la page 1 après chaque validation. La modale de détail est éditable même depuis « Voir les détails » et duplique la gestion des commentaires. Les règles d'accès se contredisent : le message de la page parle des managers, le menu latéral ne cite qu'admin et directeur, la barre mobile inclut les managers.
+
+### `/payment-schedule`
+
+**Rôle :** Afficher, pour le magasin sélectionné, les factures fournisseurs à payer dans le mois choisi (date d'échéance, fournisseur, mode de paiement, montants HT et TTC), avec totaux par mode de paiement et export CSV pour Excel.
+
+**Tâches principales de l'utilisateur :**
+- Choisir un mois et voir les échéances
+- Lire le total HT/TTC du mois et par mode de paiement
+- Exporter les échéances (filtrées par mode de paiement, colonnes HT/TTC) en CSV
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/payment-schedule?groupId= | au montage et à chaque changement de magasin (staleTime par défaut 30 s, donc rappelée à chaque retour sur la page après 30 s) | server/routes.ts:390 -> storage.getUser + getUserGroups (directeur) + getGroup + storage.getDeliveries() SANS filtre (tous magasins, storage.ts:885) + boucles séquentielles verificationService.verifyInvoice + storage.updateDelivery + storage.getSuppliers() | Endpoint le plus lent du périmètre. Il charge toutes les livraisons de tous les magasins avec leurs relations, filtre en JS, puis appelle NocoDB et écrit en base un par un (await dans des boucles for) au sein d'une requête GET. Le repli TTC écrit dans la mauvaise colonne, donc la boucle recommence à chaque chargement. |
+| POST /api/payment-schedule/export | au clic « Exporter » dans la modale | server/routes.ts:549 -> storage.getDeliveries() complet + storage.getSuppliers() + filtrage mois et mode de paiement en JS + génération CSV | Même chargement complet que le GET. Champs CSV non échappés. Logs verbeux (paramètres, utilisateur). |
+
+**Lisibilité / simplicité :** Page plutôt claire et plus simple que le rapprochement, mais hors charte. En-tête h1 text-3xl sans bandeau blanc, alors qu'Avoirs, Commandes et Rapprochement utilisent h2 text-xl/2xl dans un bandeau. Icône dollar pour des euros. La carte « Période » répète le mois déjà affiché dans le sélecteur. Les montants s'affichent en « 1234.50 € » au lieu de « 1 234,50 € ». Le TTC vaut souvent « 0.00 € » à cause d'un bug serveur. On change de mois uniquement par une liste de 25 mois, sans flèches précédent/suivant. Le filtre par mode de paiement n'existe que dans l'export. Le vocabulaire mélange CSV et Excel. Un spinner plein écran remplace aussi l'en-tête à chaque changement de magasin. Les erreurs 403 (manager arrivé par URL) donnent une carte générique. La ligne d'en-tête (titre + bouton + sélecteur de 256 px) n'est pas responsive alors que la route est servie telle quelle sur mobile.
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [ECHE-01](#eche-01) | haute | perf-serveur | M | GET /api/payment-schedule charge toutes les livraisons de tous les magasins puis appelle NocoDB et écrit en base, une livraison à la fois | `server/routes.ts:430` |
+| [ECHE-02](#eche-02) | haute | bug | S | Le repli TTC écrit le montant HT au lieu du TTC : boucle infinie à chaque chargement et TTC affiché à 0,00 € | `server/routes.ts:501` |
+| [RAPPRO-01](#rappro-01) | haute | perf-api | M | La liste des livraisons transporte la fiche magasin complète (logo base64, SMTP, NocoDB) et toutes les livraisons de tous les statuts | `server/storage.ts:912` |
+| [RAPPRO-02](#rappro-02) | haute | perf-api | M | Avalanche de vérifications automatiques (POST verify-invoice + PUT redondant) à chaque ouverture de la page | `client/src/pages/BLReconciliation.tsx:386` |
+| [RAPPRO-03](#rappro-03) | haute | bug | S | Les commentaires renvoient la ligne users complète (hash du mot de passe) et la fiche magasin complète | `server/storage.ts:3047` |
+| [RAPPRO-04](#rappro-04) | haute | ux-simplicite | S | La modale « Traitement en cours » ne peut pas être fermée et aucun timeout n'existe (client ni serveur) | `client/src/pages/BLReconciliation.tsx:1684` |
+| [ECHE-03](#eche-03) | moyenne | perf-serveur | S | L'export recharge toutes les livraisons de tous les magasins et produit un CSV non échappé | `server/routes.ts:596` |
+| [ECHE-04](#eche-04) | moyenne | coherence-design | S | En-tête hors charte, non responsive, icône dollar et carte « Période » redondante | `client/src/pages/PaymentSchedulePage.tsx:295` |
+| [ECHE-05](#eche-05) | moyenne | lisibilite | S | Montants affichés au format anglais (« 1234.50 € ») au lieu du format français | `client/src/pages/PaymentSchedulePage.tsx:340` |
+| [NOCO-01](#noco-01) | moyenne | bug | S | Les erreurs techniques NocoDB (timeout, HTTP 5xx, réseau) sont mises en cache 12 à 24 h comme « facture introuvable » | `server/invoiceVerification.ts:488` |
+| [NOCO-02](#noco-02) | moyenne | bug | S | L'upsert du cache de vérification ne met à jour ni expiresAt ni invoiceAmountTTC : le cache « permanent » expire au bout de 6 h | `server/storage.ts:1746` |
+| [NOCO-03](#noco-03) | moyenne | perf-serveur | S | Clés de cache BL incohérentes, et un hit BL ne renvoie ni montant ni échéance | `server/invoiceVerification.ts:635` |
+| [RAPPRO-05](#rappro-05) | moyenne | perf-serveur | M | getDelivery() sert au contrôle d'accès mais lance 5 à 7 requêtes séquentielles | `server/storage.ts:1004` |
+| [RAPPRO-06](#rappro-06) | moyenne | perf-serveur | S | PUT /api/deliveries/:id charge toute la table fournisseurs pour en lire un seul | `server/routes.ts:2043` |
+| [RAPPRO-07](#rappro-07) | moyenne | bug | S | Changer la référence facture déclenche un appel NocoDB synchrone qui efface l'échéance saisie à la main | `server/routes.ts:1992` |
+| [RAPPRO-08](#rappro-08) | moyenne | perf-client | S | Rafraîchissements trop larges : refetchQueries sur toutes les requêtes livraisons, même inactives, et rechargement complet pour un compteur de commentaires | `client/src/pages/BLReconciliation.tsx:758` |
+| [RAPPRO-09](#rappro-09) | moyenne | perf-client | M | Calculs non mémoïsés en O(n×m) et re-rendu de toute la page chaque seconde ou à chaque résultat de vérification | `client/src/pages/BLReconciliation.tsx:456` |
+| [RAPPRO-10](#rappro-10) | moyenne | perf-api | S | Requête /api/suppliers redondante qui retarde la vérification automatique | `client/src/pages/BLReconciliation.tsx:78` |
+| [RAPPRO-11](#rappro-11) | moyenne | perf-client | S | staleTime 0, clé de cache isolée et écran « Chargement... » texte en pleine page | `client/src/pages/BLReconciliation.tsx:376` |
+| [RAPPRO-12](#rappro-12) | moyenne | bug | S | Les livraisons des fournisseurs en mode « automatique » validées depuis Livraisons/Calendrier n'apparaissent dans aucun onglet | `client/src/pages/BLReconciliation.tsx:456` |
+| [RAPPRO-13](#rappro-13) | moyenne | ux-simplicite | S | Bouton Valider grisé avec une consigne impossible à suivre quand le magasin n'a pas NocoDB | `client/src/pages/BLReconciliation.tsx:1258` |
+| [RAPPRO-14](#rappro-14) | moyenne | ux-simplicite | M | Jusqu'à 6 boutons-icônes par ligne, sans texte, et des coches de vérification sans explication | `client/src/pages/BLReconciliation.tsx:1169` |
+| [RAPPRO-15](#rappro-15) | moyenne | coherence-design | M | Les deux onglets n'affichent pas les mêmes colonnes ni le même calcul d'écart, et « Date Livr. » montre la date prévue | `client/src/pages/BLReconciliation.tsx:1424` |
+| [RAPPRO-16](#rappro-16) | moyenne | ux-simplicite | S | Messages d'erreur affichés en JSON brut et en anglais | `client/src/lib/queryClient.ts:4` |
+| [RAPPRO-17](#rappro-17) | moyenne | coherence-design | S | Règles d'accès contradictoires entre la page, les menus, les permissions et le serveur | `client/src/pages/BLReconciliation.tsx:31` |
+| [RAPPRO-19](#rappro-19) | moyenne | ux-simplicite | M | Sur mobile, la page desktop est servie telle quelle (tableau 900px, 10 colonnes, modale en 2 colonnes) | `client/src/components/RouterProduction.tsx:121` |
+| [RAPPRO-21](#rappro-21) | moyenne | bug | S | Le proxy d'envoi de facture appelle une URL fournie par le client et lit le corps sans limite de taille | `server/routes.ts:916` |
+| [RAPPRO-22](#rappro-22) | moyenne | perf-api | S | « Vérifier toutes les factures » force un appel NocoDB pour chaque ligne, y compris celles déjà vertes, sans suivi de progression | `client/src/pages/BLReconciliation.tsx:339` |
+| [ECHE-06](#eche-06) | basse | perf-client | S | Spinner plein écran à chaque changement de magasin, cache court sur un endpoint coûteux, erreurs génériques | `client/src/pages/PaymentSchedulePage.tsx:254` |
+| [ECHE-07](#eche-07) | basse | lisibilite | S | Vocabulaire CSV/Excel incohérent et filtre par mode de paiement réservé à l'export | `client/src/pages/PaymentSchedulePage.tsx:309` |
+| [NOCO-04](#noco-04) | basse | perf-serveur | S | Logs console volumineux sur les chemins chauds (vérification, liste et mise à jour des livraisons) | `server/invoiceVerification.ts:22` |
+| [RAPPRO-18](#rappro-18) | basse | lisibilite | S | En-tête redondant et vocabulaire technique (webhook, workflow, AUTO, abréviations) | `client/src/pages/BLReconciliation.tsx:911` |
+| [RAPPRO-20](#rappro-20) | basse | ux-simplicite | S | Retour en page 1 après chaque validation, et la validation rapide n'a pas d'état « en cours » | `client/src/components/ui/pagination.tsx:157` |
+| [RAPPRO-23](#rappro-23) | basse | dette-code | S | Code mort, imports inutilisés et logs de debug dans le rendu | `client/src/pages/BLReconciliation.tsx:1032` |
+| [RAPPRO-24](#rappro-24) | basse | bug | S | Hooks appelés après un return conditionnel (règle des hooks violée) | `client/src/pages/BLReconciliation.tsx:31` |
+| [RAPPRO-25](#rappro-25) | basse | bug | S | Le minuteur de la modale d'attente n'est pas nettoyé au démontage | `client/src/pages/BLReconciliation.tsx:527` |
+| [RAPPRO-26](#rappro-26) | basse | ux-simplicite | S | Modale de rapprochement surchargée : commentaires en double, « Voir les détails » qui ouvre une édition, titre et badge redondants | `client/src/components/modals/ReconciliationModal.tsx:147` |
+| [RAPPRO-27](#rappro-27) | basse | lisibilite | S | Commentaires signés par l'email, boutons sans libellé, confirmation native | `client/src/components/ReconciliationComments.tsx:287` |
+| [RAPPRO-28](#rappro-28) | basse | ux-simplicite | S | Envoi de facture : annuler le sélecteur de fichier affiche une erreur, et le libellé Facture/Avoir est trompeur | `client/src/pages/BLReconciliation.tsx:543` |
+| [RAPPRO-29](#rappro-29) | basse | perf-bundle | S | Pages Rapprochement et Échéancier importées dans le bundle initial | `client/src/components/RouterProduction.tsx:14` |
+
+### ECHE-01
+
+**GET /api/payment-schedule charge toutes les livraisons de tous les magasins puis appelle NocoDB et écrit en base, une livraison à la fois** — perf-serveur, sévérité haute, effort M
+
+- **Fichier :** `server/routes.ts:430`
+- **Constat :** routes.ts:430-431 `const allDeliveries = await storage.getDeliveries();
+const groupDeliveries = allDeliveries.filter((d: any) => d.groupId === groupId && d.invoiceReference);`. 444-481 `for (const delivery of deliveriesWithoutDueDate) { ... await verificationService.verifyInvoice(...) ... await storage.updateDelivery(...)`. 491-516 deuxième boucle séquentielle identique pour le TTC. 519 `await storage.getSuppliers()` alors que delivery.supplier est déjà joint.
+- **Impact :** Le temps de réponse croît avec le nombre total de livraisons de l'enseigne et avec le nombre de factures sans échéance ou sans TTC. Si NocoDB est lent (timeout 10 s par appel, invoiceVerification.ts:535), le chargement peut durer plusieurs minutes et l'utilisateur reste face au spinner. Un GET qui écrit en base est aussi rejoué à chaque visite.
+- **Recommandation :** Remplacer par une requête SQL ciblée : SELECT d.id, d.invoice_reference, d.due_date, d.invoice_amount, d.invoice_amount_ttc, s.name, s.payment_method FROM deliveries d JOIN suppliers s ... WHERE d.group_id=$1 AND d.invoice_reference IS NOT NULL AND d.due_date IS NOT NULL (index idx_deliveries_due_date / (group_id, due_date)). Sortir le repli NocoDB du GET : il est déjà fait par verify-invoice qui persiste dueDate et TTC (routes.ts:2555-2587). Si on le garde, le passer en tâche de fond ou en Promise.all avec concurrence limitée.
+
+### ECHE-02
+
+**Le repli TTC écrit le montant HT au lieu du TTC : boucle infinie à chaque chargement et TTC affiché à 0,00 €** — bug, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:501`
+- **Constat :** routes.ts:487 `const deliveriesNeedingTTC = allDeliveriesWithDueDate.filter((d: any) => !d.invoiceAmountTTC || parseFloat(d.invoiceAmountTTC) === 0);` puis 501-504 `const updates: any = { invoiceAmount: result.invoiceAmount.toString(), supplierName: result.supplierName };` : invoiceAmountTTC n'est jamais écrit et supplierName n'est pas une colonne de deliveries. 506 `updates.dueDate = new Date(result.dueDate)` sans normalizeDateString, contrairement à 457.
+- **Impact :** Les mêmes livraisons repartent dans la boucle NocoDB + UPDATE à chaque ouverture de l'échéancier (ECHE-01). La colonne « Montant TTC » et le total TTC du mois restent faux (0,00 €) pour ces factures, ce qui fausse la trésorerie affichée et exportée.
+- **Recommandation :** N'écrire invoiceAmountTTC que si result.invoiceAmountTTC > 0. Ne réécrire invoiceAmount que s'il est absent. Retirer supplierName et normaliser la date. Corriger NOCO-02 d'abord. Idéalement, sortir ce repli du GET (ECHE-01) ou mémoriser la tentative pour ne pas la relancer à chaque chargement. Côté client, afficher « — » quand le TTC vaut 0 ou est inconnu.
+
+### RAPPRO-01
+
+**La liste des livraisons transporte la fiche magasin complète (logo base64, SMTP, NocoDB) et toutes les livraisons de tous les statuts** — perf-api, sévérité haute, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:912`
+- **Constat :** storage.ts:912-913 `supplier: suppliers, group: groups,` (groups contient `logo: text("logo") // Logo en data URI (data:image/png;base64,...)` schema.ts:66, smtpHost/smtpUser, webhookUrl, mapping NocoDB) ; storage.ts:598-599 loadOrdersByIds rejoint encore `supplier: suppliers, group: groups` dans chaque commande. routes.ts:1781/1859 `deliveries = await storage.getDeliveries(groupIds);` sans filtre de statut ni pagination ; filtrage client BLReconciliation.tsx:371 `deliveries.filter((d: any) => d.status === 'delivered')`. Aucun middleware compression (server/index.ts:30). Chaque réponse est clonée récursivement par stripSmtpPassword (routes.ts:168-174, sanitize.ts:13-44).
+- **Impact :** Si un logo est configuré, chaque ligne transporte ce logo une à deux fois. Avec 1 000 livraisons, cela fait des dizaines de Mo de JSON non compressé à télécharger, parser et cloner côté serveur. Le chargement initial de la page est lent et la mémoire du navigateur gonfle. Les livraisons « planned », inutiles ici, sont aussi transférées.
+- **Recommandation :** Étape 1, sans risque : dans getDeliveries, getDeliveriesByDateRange et loadOrdersByIds, remplacer `group: groups` par une projection {id, name, color, nocodbConfigId, nocodbTableName, webhookUrl}. Ce sont les seuls champs group lus par le client (name, webhookUrl, color, nocodbTableName, nocodbConfigId) et le serveur ne lit que group.name. Ajouter compression() (nouvelle dépendance) dans index.ts et index.production.ts. Étape 2 : créer l'endpoint dédié /api/reconciliation/deliveries (WHERE status='delivered', pagination, totaux par onglet). Ne retirer webhookUrl de la projection qu'après RAPPRO-21, une fois que le serveur retrouve lui-même l'URL du webhook.
+
+### RAPPRO-02
+
+**Avalanche de vérifications automatiques (POST verify-invoice + PUT redondant) à chaque ouverture de la page** — perf-api, sévérité haute, effort M
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:386`
+- **Constat :** BLReconciliation.tsx:396-436 parcourt TOUTES les livraisons livrées (les deux onglets, y compris celles qui ne s'affichent nulle part) et appelle `handleVerifyInvoice(delivery, false, true)`. Puis onSuccess (151-186) envoie `apiRequest(`/api/deliveries/${variables.deliveryId}`, "PUT", updateData)`, alors que le serveur a déjà enregistré ces données (routes.ts:2555-2587 `await storage.updateDelivery(deliveryId, updateData)`). autoRequestedIdsRef (124) est un useRef, donc remis à zéro à chaque montage, et verificationResults est un état local perdu à la navigation.
+- **Impact :** Pour 200 livraisons sans montant : 400 requêtes HTTP à chaque visite. Côté serveur, environ 10 requêtes SQL séquentielles par vérification (voir RAPPRO-05) plus NocoDB. Les coches arrivent lentement, la page re-rend à chaque résultat, puis un refetch complet de la liste suit quand la file se vide (269-270).
+- **Recommandation :** En supprimant le PUT, conserver `needsCacheInvalidationRef.current = true` dans onSuccess quand result.exists apporte des données (montant, échéance ou référence). Sinon la liste ne se rafraîchit plus après l'auto-remplissage fait côté serveur.
+
+### RAPPRO-03
+
+**Les commentaires renvoient la ligne users complète (hash du mot de passe) et la fiche magasin complète** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:3047`
+- **Constat :** storage.ts:3047-3048 `author: users,
+ group: groups,` dans getReconciliationComments (idem getReconciliationCommentById 3101-3102). La table users contient `password: varchar("password")` (schema.ts:39). sanitize.ts:36 ne retire que `smtpPassword`/`smtp_password`. Le client n'utilise que `comment.author.email` (ReconciliationComments.tsx:287).
+- **Impact :** Fuite du hash de mot de passe de chaque auteur de commentaire vers tout utilisateur qui ouvre la modale. La réponse est aussi alourdie par le logo du magasin et une copie de la livraison répétés pour chaque commentaire.
+- **Recommandation :** Projeter author {id,email,firstName,lastName,username,role}, retirer group et delivery ainsi que le .map qui les remballe, dans les deux fonctions (3035 et 3088), et alléger le type ReconciliationCommentWithRelations en conséquence. Dans sanitize.ts, supprimer simplement la clé `password`. Aucune autre colonne password n'existe dans le schéma.
+
+### RAPPRO-04
+
+**La modale « Traitement en cours » ne peut pas être fermée et aucun timeout n'existe (client ni serveur)** — ux-simplicite, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:1684`
+- **Constat :** BLReconciliation.tsx:1684 `<Dialog open={showWaitingModal} onOpenChange={() => {}}>`, sans bouton Fermer. 588-592 `fetch('/api/reconciliation/send-invoice', {...})` sans AbortController, donc la branche `error.name === 'AbortError'` (633) est du code mort. Côté serveur, routes.ts:940-943 `await fetch(parts.webhookUrl, { method: 'POST', body: formData })` sans signal ni timeout. Le texte affiche « 60s restantes (max) » puis « Finalisation... » indéfiniment (1720).
+- **Impact :** Si le webhook n8n/Make ne répond pas, l'écran reste bloqué : l'utilisateur doit recharger la page et ne sait pas si la facture est partie.
+- **Recommandation :** Fixer le délai serveur un peu au-dessus de la durée annoncée (par exemple AbortSignal.timeout(90 000)) et le délai client au-dessus du délai serveur (par exemple 100 s). En cas de dépassement, afficher : « Le traitement prend plus de temps que prévu ; il peut encore aboutir. Vérifiez la ligne avant de renvoyer la facture. » Ajouter un bouton « Continuer en arrière-plan » qui ferme la modale sans annuler la requête et affiche un toast à la fin.
+
+### ECHE-03
+
+**L'export recharge toutes les livraisons de tous les magasins et produit un CSV non échappé** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:596`
+- **Constat :** routes.ts:596-601 `const allDeliveries = await storage.getDeliveries();
+const groupDeliveries = allDeliveries.filter((d: any) => d.groupId === validatedGroupId && d.invoiceReference && d.dueDate);`, puis filtre du mois en JS (609-616) et `await storage.getSuppliers()` (619). Lignes CSV 654-662 `row.join(';')` sans guillemets.
+- **Impact :** L'export est lent sur une base volumineuse. Un nom de fournisseur ou une référence contenant « ; » ou un retour à la ligne décale les colonnes dans Excel.
+- **Recommandation :** Requête SQL filtrée sur group_id et due_date BETWEEN début/fin du mois, avec jointure suppliers. Échapper chaque champ (`"${v.replace(/"/g,'""')}"`). Réutiliser la même fonction que le GET.
+
+### ECHE-04
+
+**En-tête hors charte, non responsive, icône dollar et carte « Période » redondante** — coherence-design, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/PaymentSchedulePage.tsx:295`
+- **Constat :** PaymentSchedulePage.tsx:295-297 `<div className="flex justify-between items-center">` + `<h1 className="text-3xl font-bold">Échéancier des Paiements</h1>`, alors qu'Avoirs, Orders et BLReconciliation utilisent un bandeau `bg-white border-b` + `h2 text-xl sm:text-2xl` avec icône. 311 `<div className="w-64">` sur la même ligne, sans flex-col mobile, alors que la route est servie sur mobile (RouterProduction.tsx:129). 333 `<DollarSign .../>` pour des euros. 382-395 carte « Période » qui répète le mois déjà dans le sélecteur. Libellé du menu « Échéance » (Sidebar.tsx:266) différent du titre.
+- **Impact :** L'utilisateur ne retrouve pas la mise en page des autres modules. Sur téléphone, l'en-tête déborde. Le symbole $ prête à confusion.
+- **Recommandation :** Reprendre l'en-tête standard (bandeau blanc, h2, icône CreditCard), `flex-col sm:flex-row`, icône Euro, remplacer la carte Période par une carte utile (prochaine échéance, ou montant restant à payer cette semaine). Harmoniser le libellé du menu en « Échéancier ». Ajouter des flèches mois précédent/suivant autour du sélecteur.
+
+### ECHE-05
+
+**Montants affichés au format anglais (« 1234.50 € ») au lieu du format français** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/PaymentSchedulePage.tsx:340`
+- **Constat :** PaymentSchedulePage.tsx:340 `{monthTotal.toFixed(2)} €`, idem 346, 368, 373, 448, 451. BLReconciliation.tsx:1071 `${parseFloat(delivery.blAmount).toFixed(2)}€`, idem 1123, 1157, 1471, 1479.
+- **Impact :** Les grands montants sont difficiles à lire (pas de séparateur de milliers) et le point décimal ne correspond pas aux habitudes françaises ni à Excel FR.
+- **Recommandation :** Créer un utilitaire partagé `formatEuro = (n) => new Intl.NumberFormat('fr-FR', { style: 'currency', currency: 'EUR' }).format(n)` et l'utiliser dans les deux pages, avec des colonnes de montants alignées à droite et `tabular-nums`.
+
+### NOCO-01
+
+**Les erreurs techniques NocoDB (timeout, HTTP 5xx, réseau) sont mises en cache 12 à 24 h comme « facture introuvable »** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/invoiceVerification.ts:488`
+- **Constat :** invoiceVerification.ts:394-403 `if (matchResult.error) { ... await this.saveToCache(invoiceReference, groupId, result, undefined, isReconciled);` avec exists:false, donc expiration +12 h (106-108). 488-489, même chose dans le catch. Pour les BL : 762-786 erreur mise en cache `expiresAt.setHours(expiresAt.getHours() + 24)`. Côté client, exists === false grise le bouton Valider (BLReconciliation.tsx:1248-1257).
+- **Impact :** Une micro-coupure NocoDB affiche une croix rouge et bloque la validation pendant 12 à 24 h pour toutes les factures vérifiées à ce moment. Seul le bouton « Vérifier toutes » (forceRefresh) contourne le problème, ce que l'utilisateur ne peut pas deviner.
+- **Recommandation :** Ne pas mettre en cache les résultats avec matchResult.error, ou seulement 2 à 5 minutes. Renvoyer un statut distinct (`status: 'error'`) et l'afficher côté UI par une icône orange « Service de vérification indisponible — réessayer » plutôt qu'une croix rouge.
+
+### NOCO-02
+
+**L'upsert du cache de vérification ne met à jour ni expiresAt ni invoiceAmountTTC : le cache « permanent » expire au bout de 6 h** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:1746`
+- **Constat :** storage.ts:1746-1760 `onConflictDoUpdate({ target: invoiceVerificationCache.cacheKey, set: { exists, matchType, errorMessage, supplierName, invoiceReference, invoiceAmount, dueDate, isReconciled, cacheHit, apiCallTime, updatedAt } })` : ni expiresAt ni invoiceAmountTTC. updateCacheAsReconciled (invoiceVerification.ts:186-195) calcule `expiresAt + 50 ans` mais l'upsert l'ignore. getInvoiceVerificationCache supprime la ligne une fois expirée (storage.ts:1729-1732).
+- **Impact :** Les factures validées sont re-interrogées dans NocoDB après 6 h au lieu d'être servies depuis le cache, d'où des appels externes inutiles et des pages plus lentes. Un forceRefresh ne rallonge pas non plus la durée de vie, et le TTC reste périmé dans le cache.
+- **Recommandation :** Ajouter `expiresAt: cacheData.expiresAt, invoiceAmountTTC: cacheData.invoiceAmountTTC, groupId: cacheData.groupId` au `set` de onConflictDoUpdate.
+
+### NOCO-03
+
+**Clés de cache BL incohérentes, et un hit BL ne renvoie ni montant ni échéance** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/invoiceVerification.ts:635`
+- **Constat :** verifyInvoiceByBL : `const cacheKey = `bl_${groupId}_${blNumber.trim().toLowerCase()}_${supplierName.toLowerCase()}`;` (635), alors que updateCacheAsReconciled(blNumber) utilise generateCacheKey = `${groupId}_${ref}` (13, appelé routes.ts:2653 et invoiceVerification.ts:232), donc la clé BL n'est jamais marquée réconciliée. Le hit cache BL (641-651) ne renvoie que exists/matchType/invoiceReference/supplierName, et la sauvegarde succès (827-839) ne stocke ni invoiceAmount ni dueDate.
+- **Impact :** Le cache BL ne devient jamais permanent (rappels NocoDB toutes les 24 h). Un hit BL donne une coche verte sans montant ni échéance, ce qui laisse des cellules « Non renseigné » et relance d'autres vérifications.
+- **Recommandation :** Centraliser la construction de clé (buildKey(type, groupId, value, supplier)) et l'utiliser partout. Stocker et renvoyer invoiceAmount, invoiceAmountTTC et dueDate dans le cache BL comme pour la référence facture.
+
+### RAPPRO-05
+
+**getDelivery() sert au contrôle d'accès mais lance 5 à 7 requêtes séquentielles** — perf-serveur, sévérité moyenne, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:1004`
+- **Constat :** storage.ts:1005-1034 jointure, 1041 `await this.getUser(delivery.createdBy)`, 1060 `await this.getOrder(delivery.orderId)` (qui fait lui-même une jointure commande + une jointure de toutes ses livraisons, storage.ts:816-856), 1079-1082 count des commentaires. getDelivery est appelé pour le seul contrôle d'accès dans verify-invoice (routes.ts:2474), PUT (1914), DELETE (2144), commentaires (2183, 2219), send-supplier-mail (2338), toujours après getUserWithGroups qui fait 2 requêtes séquentielles (storage.ts:372-387).
+- **Impact :** Chaque vérification ou modification coûte 7 à 9 allers-retours SQL avant même le travail utile. Multiplié par les centaines de vérifications automatiques (RAPPRO-02), cela sature le pool Postgres et ralentit toutes les pages.
+- **Recommandation :** Gain immédiat sans changer le format : dans getDelivery, lancer getUser, getOrder et le count en Promise.all après la jointure principale. Pour getDeliveryForAccess, inclure id, groupId, supplierId, status, reconciled, blNumber, invoiceReference, scheduledDate, deliveredDate, supplier {id,name,email,automaticReconciliation} et group {id,name}, et ne l'utiliser que dans les routes qui ne lisent rien d'autre : verify-invoice, PUT, DELETE et commentaires. Garder getDelivery pour GET /api/deliveries/:id. Lancer getUserWithGroups et le chargement de la livraison en parallèle.
+
+### RAPPRO-06
+
+**PUT /api/deliveries/:id charge toute la table fournisseurs pour en lire un seul** — perf-serveur, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:2043`
+- **Constat :** routes.ts:2040-2044 `if (data.status === 'delivered' || data.blNumber) { ... const suppliers = await storage.getSuppliers();
+ const supplier = suppliers.find((s: any) => s.id === updatedDelivery.supplierId);`. La modale envoie toujours blNumber s'il est rempli (ReconciliationModal.tsx:86), et delivery.supplier est déjà chargé par getDelivery (storage.ts:1028).
+- **Impact :** Chaque enregistrement depuis la modale lit inutilement toute la table fournisseurs.
+- **Recommandation :** `const supplier = (data.supplierId === undefined || data.supplierId === delivery.supplierId) ? delivery.supplier : (await storage.getSuppliers()).find((s: any) => s.id === updatedDelivery.supplierId);`
+
+### RAPPRO-07
+
+**Changer la référence facture déclenche un appel NocoDB synchrone qui efface l'échéance saisie à la main** — bug, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:1992`
+- **Constat :** routes.ts:1992-2030 : si `data.invoiceReference !== delivery.invoiceReference`, appel `verificationService.verifyInvoice(data.invoiceReference, delivery.groupId, true, ...)` (forceRefresh, jusqu'à 2 × 10 s de timeout), puis `data.dueDate = null;` si NocoDB ne trouve pas l'échéance (2017) ou en cas d'erreur (2023). Cela écrase la dueDate envoyée par la modale (ReconciliationModal.tsx:90).
+- **Impact :** L'utilisateur saisit référence et échéance, clique Enregistrer, attend parfois plus de 10 s (« Enregistrement... »), puis découvre que son échéance a disparu. Perte de donnée et lenteur perçue.
+- **Recommandation :** Ne respecter la saisie que si l'utilisateur a modifié l'échéance, c'est-à-dire si data.dueDate diffère de delivery.dueDate. Sinon, compléter depuis NocoDB. Ne jamais remplacer par null en cas d'échec ou de résultat vide : conserver la valeur existante. Le cas 2027 (référence vidée, donc échéance vidée) peut rester. Faire l'appel NocoDB après la réponse HTTP ou le laisser à verify-invoice.
+
+### RAPPRO-08
+
+**Rafraîchissements trop larges : refetchQueries sur toutes les requêtes livraisons, même inactives, et rechargement complet pour un compteur de commentaires** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:758`
+- **Constat :** BLReconciliation.tsx:758-759 `queryClient.refetchQueries({ queryKey: ['/api/deliveries/bl'] }); queryClient.refetchQueries({ queryKey: ['/api/deliveries'] });` (idem 481-482, 797-798, 837-838). En TanStack 5.83, refetchQueries fait `this.#queryCache.findAll(filters)` sans filtre `type` (node_modules/@tanstack/query-core/build/modern/queryClient.js:172), donc les requêtes inactives (mois du calendrier visités, etc.) sont aussi rechargées. ReconciliationModal.tsx:67-69 invalide, puis onSave (BLReconciliation.tsx:481-482) refait un refetch. ReconciliationComments.tsx:62-63, 88-89, 113-114 invalident toute la liste pour un compteur.
+- **Impact :** Une validation ou un commentaire peut déclencher plusieurs téléchargements de la liste complète (lourde, voir RAPPRO-01), y compris pour des pages non affichées. L'interface rame juste après chaque action.
+- **Recommandation :** Après validation, suppression ou commentaire : `queryClient.setQueryData(['/api/deliveries/bl', selectedStoreId], ...)` (mise à jour locale, compteur +1/-1), puis une seule `invalidateQueries({ queryKey: ['/api/deliveries/bl', selectedStoreId] })` (refetchType 'active' par défaut). Remplacer les refetchQueries(['/api/deliveries']) par invalidateQueries. Supprimer le refetch en double de handleSaveReconciliation.
+
+### RAPPRO-09
+
+**Calculs non mémoïsés en O(n×m) et re-rendu de toute la page chaque seconde ou à chaque résultat de vérification** — perf-client, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:456`
+- **Constat :** BLReconciliation.tsx:456-461 `deliveriesWithBL.filter(... suppliers.find(s => s.id === delivery.supplierId) ...)` recalculé à chaque rendu, de même que filterDeliveries (851-866) et `suppliers.find` dans chaque ligne validée (1422). startProcessingTimer (527-537) fait `setProcessingSeconds(prev => prev + 1)` chaque seconde dans le composant page. Chaque vérification fait 2 setState (144-147, 189-193).
+- **Impact :** Pendant l'envoi d'une facture, la page entière (10 colonnes × N lignes, filtres complets) est recalculée chaque seconde. Pendant la vérification auto de 200 lignes, il y a plus de 400 rendus complets, ce qui rend la saisie et le scroll saccadés.
+- **Recommandation :** useMemo pour manualNotValidatedDeliveries, allValidatedDeliveries et les listes filtrées, avec une Map supplierById ou directement delivery.supplier.automaticReconciliation. Extraire la ligne dans un composant React.memo qui reçoit son seul résultat de vérification. Déplacer le compteur de secondes dans un composant WaitingDialog isolé. Ajouter useDeferredValue sur searchTerm.
+
+### RAPPRO-10
+
+**Requête /api/suppliers redondante qui retarde la vérification automatique** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:78`
+- **Constat :** BLReconciliation.tsx:78-80 `useQuery<any[]>({ queryKey: ['/api/suppliers'] })` sert à `supplier?.automaticReconciliation` (457, 1423) et à l'email de repli (681). Ces champs sont déjà dans `delivery.supplier` (storage.ts:912 `supplier: suppliers`). L'effet 387 `if (!deliveriesWithBL.length || !suppliers.length) return;` attend suppliers alors que le corps de l'effet ne l'utilise pas.
+- **Impact :** Une requête inutile, et un enchaînement en cascade (waterfall) : les coches de vérification n'apparaissent qu'après le chargement des fournisseurs. Si la liste fournisseurs est vide ou en erreur, aucune vérification automatique n'a lieu.
+- **Recommandation :** Supprimer la requête suppliers, utiliser `delivery.supplier?.automaticReconciliation` et `delivery.supplier?.email`, retirer `suppliers` des dépendances et de la garde de l'effet.
+
+### RAPPRO-11
+
+**staleTime 0, clé de cache isolée et écran « Chargement... » texte en pleine page** — perf-client, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:376`
+- **Constat :** BLReconciliation.tsx:350 `queryKey: ['/api/deliveries/bl', selectedStoreId]` alors que l'URL appelée est `/api/deliveries` (357), donc aucun partage avec les autres pages. 376 `staleTime: 0 // Éviter la mise en cache`. 892-894 `if (isLoading) { return <div className="flex justify-center items-center h-64">Chargement...</div>; }`.
+- **Impact :** Chaque retour sur la page retélécharge la liste complète (lourde). Pendant ce temps, l'utilisateur voit un texte gris sans structure. Un changement de magasin vide tout l'écran.
+- **Recommandation :** Renommer d'abord la clé en ['/api/deliveries', 'reconciliation', selectedStoreId] pour que toutes les invalidations de ['/api/deliveries'] la touchent par préfixe. Mettre à jour en même temps les setQueryData de BLReconciliation et le prédicat de ValidateDeliveryModal. Passer ensuite à staleTime 60 s avec placeholderData: keepPreviousData, et afficher un squelette sous l'en-tête et la recherche.
+
+### RAPPRO-12
+
+**Les livraisons des fournisseurs en mode « automatique » validées depuis Livraisons/Calendrier n'apparaissent dans aucun onglet** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:456`
+- **Constat :** Onglet manuel : `const isManual = supplier?.automaticReconciliation !== true;` (458). Onglet validé : `delivery.reconciled === true` (464). Or POST /api/deliveries/:id/validate (routes.ts:2643 `await storage.validateDelivery(id, blData);`, storage.ts:1179-1194) ne met jamais reconciled=true. Seul le PUT générique le fait (routes.ts:2040-2056).
+- **Impact :** Des factures de fournisseurs « automatiques » peuvent n'être ni rapprochées ni visibles. Elles échappent au contrôle, alors que la vérification automatique les traite en arrière-plan.
+- **Recommandation :** Appliquer la même auto-réconciliation dans /validate (si supplier.automaticReconciliation et blNumber), ou ajouter un filtre ou onglet « Automatiques en attente » pour les rendre visibles.
+
+### RAPPRO-13
+
+**Bouton Valider grisé avec une consigne impossible à suivre quand le magasin n'a pas NocoDB** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:1258`
+- **Constat :** BLReconciliation.tsx:1258-1267 bouton désactivé avec `title="Validation impossible : veuillez d'abord vérifier la facture en cliquant sur l'icône de recherche"`. Or l'icône de recherche n'est affichée que si `delivery.group?.nocodbTableName || nocodbConfigId || webhookUrl` (1085), et handleVerifyInvoice sort en silence sans config (298-307).
+- **Impact :** Dans un magasin sans NocoDB, l'utilisateur ne peut valider une ligne qu'en devinant qu'il doit saisir un montant facture dans la modale. Il est bloqué et appelle le support.
+- **Recommandation :** Sans configuration NocoDB, ou si un montant facture est saisi, autoriser la validation manuelle avec une confirmation (« Valider sans vérification automatique ? »). Rédiger un tooltip exact selon le cas (pas de référence, pas de NocoDB, facture introuvable).
+
+### RAPPRO-14
+
+**Jusqu'à 6 boutons-icônes par ligne, sans texte, et des coches de vérification sans explication** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:1169`
+- **Constat :** Cellule Actions 1169-1316 : Mail, Upload, MessageSquare, Check, Edit, Trash2, en `h-8 w-8 p-0` sans libellé, expliqués seulement par `title=`. Coches 1089-1094 `<CheckCircle className="h-4 w-4 text-green-500 cursor-help" />` / `<XCircle ... cursor-help />` sans title ni Tooltip, alors que `errorMessage` est stocké (202) mais jamais affiché.
+- **Impact :** Un employé non technicien ne sait pas quel bouton faire en premier ni pourquoi une facture est en rouge. Les title ne s'affichent pas au toucher (tablette, mobile).
+- **Recommandation :** Garder une seule action principale visible avec du texte (« Valider » en vert, ou « Compléter » si des données manquent) et regrouper le reste (Relancer le fournisseur, Envoyer la facture, Commentaires, Modifier, Supprimer) dans un menu « ⋯ » (DropdownMenu) avec libellés. Ajouter un Tooltip/Popover sur la coche qui affiche errorMessage en français et un bouton « Revérifier ».
+
+### RAPPRO-15
+
+**Les deux onglets n'affichent pas les mêmes colonnes ni le même calcul d'écart, et « Date Livr. » montre la date prévue** — coherence-design, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:1424`
+- **Constat :** Onglet manuel, Écart en € et rouge au-delà de 10 € : 1150-1157 `diffAbs > 10 ? 'text-red-600'` ... `{diff.toFixed(2)}€`. Onglet validé, Écart en % et rouge au-delà de 5 % : 1424-1425 `(... / parseFloat(delivery.blAmount) * 100).toFixed(1)` et 1498 `Math.abs(parseFloat(ecart)) > 5 ? "destructive"`. Ordre des colonnes : manuel « Montant BL, Ref. Facture » (1004-1009), validé « Ref. Facture, Montant BL » (1397-1402). « Date Livr. » affiche `delivery.scheduledDate` (1065, 1458) alors que le tri utilise deliveredDate (373). Formats dd/MM/yy et dd/MM/yyyy mélangés. « Non renseigné » et « Non renseignée » mélangés (1452/1464). Styles de boutons différents (Button outline 1176 contre <button opacity-70> 1519).
+- **Impact :** L'utilisateur compare deux tableaux qui ne se lisent pas de la même façon. Un écart de 8 € apparaît orange d'un côté et peut apparaître rouge en % de l'autre. La date affichée n'est pas celle de la livraison réelle.
+- **Recommandation :** Factoriser une définition de colonnes et un composant <ReconciliationRow> commun aux deux onglets. Fixer une seule règle d'écart (montant € + % en sous-texte, mêmes seuils). Renommer en « Livrée le » avec deliveredDate (repli scheduledDate) et utiliser dd/MM/yyyy partout.
+
+### RAPPRO-16
+
+**Messages d'erreur affichés en JSON brut et en anglais** — ux-simplicite, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/lib/queryClient.ts:4`
+- **Constat :** queryClient.ts:4-7 `const text = (await res.text()) || res.statusText; throw new Error(`${res.status}: ${text}`);`. Les toasts affichent error.message tel quel : ReconciliationComments.tsx:95 `description: error?.message || ...`, BLReconciliation.tsx:702, ReconciliationModal.tsx:76. Messages serveur en anglais : routes.ts:2270 "Only comment author or admin can edit comments", 2598 "Failed to verify invoice".
+- **Impact :** Un manager voit par exemple « 403: {"message":"Only comment author or admin can edit comments"} ». Le message est incompréhensible et anxiogène.
+- **Recommandation :** Garder le message actuel et ajouter à l'Error les propriétés `status` et `userMessage` (body.message || body.error). Les toasts passent par un helper getUserErrorMessage(error). Adapter isUnauthorizedError et les tests de retry pour lire error.status en priorité, avec repli sur l'ancien test. Traduire ensuite les messages serveur et masquer Modifier/Supprimer pour les non-auteurs.
+
+### RAPPRO-17
+
+**Règles d'accès contradictoires entre la page, les menus, les permissions et le serveur** — coherence-design, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:31`
+- **Constat :** La page bloque seulement `user?.role === 'employee'` avec le texte « Seuls les managers et administrateurs peuvent accéder » (31-42). Sidebar.tsx:259-262 `roles: ["admin", "directeur"]`, PhoneBottomNav.tsx:37 `roles: ["admin", "directeur", "manager"]`, shared/permissions.ts:53-57 `manager: []`. Le bouton Upload s'affiche sans contrôle de rôle (shouldShowInvoiceButton 653-672), alors que le serveur refuse les managers (routes.ts:891 `user.role !== 'admin' && user.role !== 'directeur'`).
+- **Impact :** Un manager arrive sur la page depuis la barre mobile, voit des boutons, envoie un PDF, attend, puis obtient « Accès refusé ». Le message d'accès restreint est lui-même faux.
+- **Recommandation :** Garder la page avec `permissions.canView('reconciliation')`, aligner Sidebar et PhoneBottomNav sur la même matrice, masquer Upload/Valider/Supprimer selon canCreate/canValidate/canDelete, et corriger le texte (« réservé aux directeurs et administrateurs »).
+
+### RAPPRO-19
+
+**Sur mobile, la page desktop est servie telle quelle (tableau 900px, 10 colonnes, modale en 2 colonnes)** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:121`
+- **Constat :** RouterProduction.tsx:121 `<Route path="/bl-reconciliation" component={BLReconciliation} />` dans le bloc mobile (« Pages sans version mobile »). BLReconciliation.tsx:992 `<table className="w-full min-w-[900px]">`, colonnes `px-6`. ReconciliationModal.tsx:120 et 162 `grid grid-cols-2 gap-4` sans breakpoint.
+- **Impact :** Sur téléphone (accessible aux rôles listés dans PhoneBottomNav), il faut faire défiler horizontalement pour atteindre les actions. Les champs de la modale font la moitié de l'écran.
+- **Recommandation :** Sous md, rendu en cartes (fournisseur + montants + statut + bouton principal) comme les pages mobiles existantes. `grid-cols-1 sm:grid-cols-2` dans la modale.
+
+### RAPPRO-21
+
+**Le proxy d'envoi de facture appelle une URL fournie par le client et lit le corps sans limite de taille** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:916`
+- **Constat :** Client BLReconciliation.tsx:582 `formData.append('webhookUrl', selectedDeliveryForInvoice.group.webhookUrl);`. Serveur routes.ts:907-918, lecture complète `req.on('data', (chunk: Buffer) => chunks.push(chunk));` sans plafond, puis 940 `await fetch(parts.webhookUrl, ...)` sans vérifier que l'URL est celle du magasin.
+- **Impact :** Un compte directeur peut faire appeler n'importe quelle URL interne par le serveur (SSRF). Un gros fichier peut saturer la mémoire du serveur et ralentir toute l'application.
+- **Recommandation :** Envoyer deliveryId et retrouver group.webhookUrl côté serveur après contrôle d'accès. Plafonner la taille (par exemple 15 Mo, multer ou busboy avec limits), contrôler le type PDF côté client et serveur, et ajouter un timeout (voir RAPPRO-04).
+
+### RAPPRO-22
+
+**« Vérifier toutes les factures » force un appel NocoDB pour chaque ligne, y compris celles déjà vertes, sans suivi de progression** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:339`
+- **Constat :** BLReconciliation.tsx:322-340 filtre toutes les lignes de manualNotValidatedDeliveries ayant une référence, puis `handleVerifyInvoice(delivery, true); // Force refresh pour toutes`. Le seul retour est le toast initial « Vérification de N facture(s)/BL en cours... » (342-345). Aucun toast de fin.
+- **Impact :** Contournement du cache : 1 à 2 requêtes NocoDB par ligne (invoiceVerification.ts:386-429), donc des minutes d'attente sur un gros magasin. L'utilisateur ne sait pas quand c'est fini.
+- **Recommandation :** Forcer le rafraîchissement seulement pour les lignes rouges ou non vérifiées. Afficher une progression (« 12 / 40 vérifiées ») et un toast final récapitulatif (x trouvées, y introuvables, z erreurs).
+
+### ECHE-06
+
+**Spinner plein écran à chaque changement de magasin, cache court sur un endpoint coûteux, erreurs génériques** — perf-client, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/PaymentSchedulePage.tsx:254`
+- **Constat :** PaymentSchedulePage.tsx:69-81 useQuery sans staleTime (30 s par défaut, queryClient.ts:76) ni placeholderData. 254-260 `if (isLoading) { return (<div ...><Loader2 .../></div>); }` remplace aussi l'en-tête. 262-275 carte « Une erreur est survenue » identique pour un 403 (manager arrivé par URL, routes.ts:398-399). 278-289 « Configuration requise » affiché pour le message serveur « Groupe non trouvé » (routes.ts:424).
+- **Impact :** Chaque retour sur la page après 30 s relance l'endpoint lent (ECHE-01). Changer de magasin fait disparaître toute la page. Les messages d'erreur n'aident pas l'utilisateur.
+- **Recommandation :** staleTime 5 min, `placeholderData: keepPreviousData`, squelette des cartes et du tableau sous l'en-tête, message spécifique pour 403 (« Réservé aux directeurs et administrateurs ») et pour un magasin introuvable.
+
+### ECHE-07
+
+**Vocabulaire CSV/Excel incohérent et filtre par mode de paiement réservé à l'export** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/PaymentSchedulePage.tsx:309`
+- **Constat :** Bouton « Exporter CSV » (309), modale « Exporter vers CSV ... (ouvrez le fichier dans Excel) » (468-471), toast d'erreur « l'export du fichier Excel » (230). Les modes de paiement ne se filtrent que dans la modale d'export (477-509) : le tableau (425-454) n'a ni filtre ni recherche fournisseur.
+- **Impact :** Les utilisateurs ne savent pas quel format ils obtiennent et ne peuvent pas afficher à l'écran seulement les virements ou les traites qu'ils vont payer.
+- **Recommandation :** Libellé unique « Exporter pour Excel ». Ajouter au-dessus du tableau des puces de filtre par mode de paiement (réutilisées par défaut dans l'export) et une recherche fournisseur.
+
+### NOCO-04
+
+**Logs console volumineux sur les chemins chauds (vérification, liste et mise à jour des livraisons)** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/invoiceVerification.ts:22`
+- **Constat :** invoiceVerification.ts:22-31, 111-119, 140-148, 261, 273, 276 `console.log('✅ [INVOICE] Résultat depuis cache:', cachedResult)`, 294-299 : environ 8 logs d'objets par vérification. storage.ts:1718-1722 et 1736 à chaque lecture de cache, storage.ts:935 à chaque liste. routes.ts:1762, 1868 (GET /api/deliveries), 1932 `console.log('🔄 Updating delivery:', { id, data: req.body ...})`, 2033 `console.log('✅ Delivery updated successfully:', { id, updatedDelivery })`, 2516-2523, 2552.
+- **Impact :** Pendant les centaines de vérifications automatiques, les sorties console synchrones ralentissent l'event loop Node et remplissent les logs Docker, ce qui rend les vraies erreurs difficiles à trouver.
+- **Recommandation :** Commencer, sans risque, par réduire les logs qui sérialisent des objets complets (routes.ts:1932 et 2033, invoiceVerification.ts:273 et 2552) à un identifiant et quelques champs. Introduire ensuite un logger avec LOG_LEVEL, défaut 'info' en production, et passer les logs [CACHE]/[INVOICE] en debug, après accord de l'exploitant.
+
+### RAPPRO-18
+
+**En-tête redondant et vocabulaire technique (webhook, workflow, AUTO, abréviations)** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:911`
+- **Constat :** Compteurs en double : badges 911-916 « {n} à traiter » / « {n} validées » et badges d'onglets 935-944. Sous-titre « Gestion des rapprochements manuels et automatiques » (907), onglet « Rapprochement Manuel » (934). En-têtes abrégés « Date Livr. », « Ref. Facture », « Montant Fact. » (1002-1012). Badge « AUTO » (1445). URL affichée `Envoi via: {selectedDeliveryForInvoice.group.webhookUrl}` (1662-1666), « Le workflow peut prendre jusqu'à 1 minute » (1706), toast « Facture traitée avec succès via le webhook » (603). Encadré vert permanent dans l'onglet Validées (1342-1357).
+- **Impact :** Le bruit visuel et le jargon informatique ralentissent la compréhension. Exposer l'URL du webhook n'apporte rien à l'utilisateur.
+- **Recommandation :** Onglets « À traiter (n) » / « Validées (n) » et suppression des badges d'en-tête. En-têtes complets : « Livrée le », « N° facture », « Montant facture ». « AUTO » remplacé par « Validé automatiquement ». Supprimer l'URL et dire « Envoi au service de traitement des factures… ». Remplacer l'encadré par une ligne d'aide discrète ou un tooltip.
+
+### RAPPRO-20
+
+**Retour en page 1 après chaque validation, et la validation rapide n'a pas d'état « en cours »** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/ui/pagination.tsx:157`
+- **Constat :** pagination.tsx:157-159 `useEffect(() => { setCurrentPage(1); }, [data.length]);`. Valider une ligne la retire de la liste et renvoie donc l'utilisateur en page 1. BLReconciliation.tsx:735-769 handleQuickValidate est une fonction async sans état pending : le bouton (1239-1247) reste cliquable pendant la requête.
+- **Impact :** En traitant la page 3, chaque validation renvoie en page 1, ce qui fait perdre le fil. Un double clic envoie deux PUT et affiche deux toasts.
+- **Recommandation :** Ajouter à usePagination un paramètre optionnel resetKey (par exemple `${searchTerm}|${activeTab}`). Quand il est fourni, remettre la page à 1 sur ce changement plutôt que sur data.length, et garder le comportement actuel par défaut pour les 7 autres appelants. Le bornage à totalPages existe déjà (166-170).
+
+### RAPPRO-23
+
+**Code mort, imports inutilisés et logs de debug dans le rendu** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:1032`
+- **Constat :** Imports inutilisés : Card, CardContent, CardHeader, CardTitle (7), Settings, AlertTriangle, X, Filter (15), Select... (17), Textarea (19). Branches mortes de l'onglet manuel, filtré sur `reconciled !== true` (459) : style `delivery.reconciled === true ? 'bg-gray-100 opacity-60'` (1032-1035) et bloc dévalidation (1290-1315). console.log dans le rendu de chaque ligne (662-669, 1429-1435). console.log non conditionné (624). ReconciliationModal.tsx:57,59 `console.log('Sending update for delivery:'...)`. formData.reconciled jamais utilisé (ReconciliationModal.tsx:38,50). PaymentSchedulePage.tsx:6-7 imports Building et startOfMonth inutilisés.
+- **Impact :** Le fichier de 1 787 lignes est plus difficile à maintenir, la console est polluée en production (624, ReconciliationModal), et des appels de log tournent pendant le rendu en dev.
+- **Recommandation :** Supprimer les imports inutilisés, les branches mortes, les logs de rendu et les console.log non conditionnés. Retirer reconciled de l'état de la modale.
+
+### RAPPRO-24
+
+**Hooks appelés après un return conditionnel (règle des hooks violée)** — bug, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:31`
+- **Constat :** BLReconciliation.tsx:31-49 `if (user?.role === 'employee') { return (...); }` placé avant `const [activeTab, setActiveTab] = useState("manual");` (51) et tous les useQuery/useMutation/useEffect qui suivent.
+- **Impact :** Si le rôle passe de undefined à « employee » pendant la vie du composant (rechargement de session), React lève « Rendered fewer hooks than expected » et la page plante.
+- **Recommandation :** Extraire le contenu dans <BLReconciliationContent/> et garder dans BLReconciliation le seul test de rôle qui rend soit le message, soit le contenu.
+
+### RAPPRO-25
+
+**Le minuteur de la modale d'attente n'est pas nettoyé au démontage** — bug, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:527`
+- **Constat :** BLReconciliation.tsx:529 `const interval = setInterval(...)` stocké dans un state (538 `setProcessingTimeout(interval)`), nettoyé seulement dans handleCloseWaitingModal par `clearTimeout(processingTimeout)` (522). Aucun useEffect de nettoyage au démontage.
+- **Impact :** Si l'utilisateur quitte la page pendant l'envoi, l'intervalle continue d'appeler setState sur un composant démonté (fuite mineure).
+- **Recommandation :** Stocker l'intervalle dans un useRef, utiliser clearInterval et nettoyer dans un useEffect de démontage. Ou isoler le minuteur dans le composant de la modale (voir RAPPRO-09).
+
+### RAPPRO-26
+
+**Modale de rapprochement surchargée : commentaires en double, « Voir les détails » qui ouvre une édition, titre et badge redondants** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/modals/ReconciliationModal.tsx:147`
+- **Constat :** ReconciliationModal.tsx:147-157 onglet « Commentaires », en doublon de la modale commentaires dédiée de la page (BLReconciliation.tsx:1744-1785). 102-112 titre « Rapprochement Automatique/Manuel » suivi d'un badge « AUTO/MANUEL ». 136-139 statut « Rapproché / En attente » alors que la page dit « Validées ». 242-248 bouton principal Enregistrer en `variant="outline"`. L'icône Eye « Voir les détails » de l'onglet validé (BLReconciliation.tsx:1582-1588) ouvre ce même formulaire éditable.
+- **Impact :** Deux chemins pour la même action, un vocabulaire qui change d'un écran à l'autre, et un risque de modifier par erreur une ligne déjà validée en croyant seulement la consulter.
+- **Recommandation :** Retirer l'onglet Commentaires de la modale (ou retirer la modale commentaires séparée), garder un titre simple « Facture de {fournisseur} », utiliser « Validé / À traiter », mettre Enregistrer en bouton plein, et ouvrir les lignes validées en lecture seule avec un bouton « Modifier » explicite.
+
+### RAPPRO-27
+
+**Commentaires signés par l'email, boutons sans libellé, confirmation native** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/ReconciliationComments.tsx:287`
+- **Constat :** ReconciliationComments.tsx:287 `Par {comment.author.email} • ...`. Boutons 292-307 `<Edit2 className="w-3 h-3" />` et `<Trash2 className="w-3 h-3" />` sans title ni aria-label, affichés pour tous les commentaires. 152 `if (confirm("Êtes-vous sûr ..."))`. Même usage de window.confirm dans BLReconciliation.tsx:781 et 818, alors qu'Avoirs.tsx et DlcPage.tsx utilisent AlertDialog.
+- **Impact :** L'auteur est peu lisible (email au lieu du nom), les icônes de 12 px sont difficiles à viser, et les confirmations n'ont pas le même style que le reste de l'application.
+- **Recommandation :** Afficher « Prénom Nom » (repli username), ajouter aria-label et title, n'afficher Modifier/Supprimer que pour l'auteur ou l'admin, et utiliser un composant ConfirmDialog commun basé sur AlertDialog.
+
+### RAPPRO-28
+
+**Envoi de facture : annuler le sélecteur de fichier affiche une erreur, et le libellé Facture/Avoir est trompeur** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:543`
+- **Constat :** BLReconciliation.tsx:543-551 `if (file && file.type === 'application/pdf') {...} else { toast({ title: "Erreur", description: "Veuillez sélectionner un fichier PDF" ...` : déclenché aussi quand l'utilisateur annule (file undefined). Le bouton dit `title="Envoyer Facture/Avoir"` (1212), la modale « Envoyer Facture » (1629), et le type envoyé est toujours `formData.append('type', 'Facture')` (585).
+- **Impact :** Un toast d'erreur rouge apparaît alors que l'utilisateur n'a rien fait de mal, et il pense pouvoir envoyer un avoir alors que ce n'est pas possible.
+- **Recommandation :** Ne rien faire si aucun fichier n'est choisi. Soit proposer un choix Facture/Avoir dans la modale, soit renommer le bouton « Envoyer la facture (PDF) ». Utiliser une zone de dépôt avec le nom et la taille du fichier.
+
+### RAPPRO-29
+
+**Pages Rapprochement et Échéancier importées dans le bundle initial** — perf-bundle, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:14`
+- **Constat :** RouterProduction.tsx:14 `import BLReconciliation from "@/pages/BLReconciliation";` et 29 `import PaymentSchedulePage from "@/pages/PaymentSchedulePage";` en imports statiques, sans React.lazy dans le routeur.
+- **Impact :** Les 1 787 lignes du rapprochement, ses modales et date-fns/locale sont téléchargés par tous les utilisateurs (y compris les employés qui n'y ont pas accès) avant le premier affichage.
+- **Recommandation :** `const BLReconciliation = lazy(() => import("@/pages/BLReconciliation"))` (idem PaymentSchedulePage) avec <Suspense fallback={<PageSkeleton/>}> autour du Switch.

docs/audit-webui/04-avoirs.md

@@ -0,0 +1,476 @@
+# Avoirs
+
+_41 constats vérifiés — 8 haute, 21 moyenne, 12 basse._
+
+## Pages analysées
+
+### `/avoirs (bureau)`
+
+**Rôle :** Suivre les demandes d'avoir fournisseurs d'un magasin : créer une demande, la faire passer de 'En attente de demande' à 'Demandé' puis à 'Reçu', vérifier que la facture d'avoir existe en comptabilité (NocoDB), valider l'avoir, envoyer le PDF au système externe (webhook) et consulter l'historique des avoirs finalisés.
+
+**Tâches principales de l'utilisateur :**
+- Créer une demande d'avoir (fournisseur, magasin, référence, montant, commentaire)
+- Changer le statut d'un avoir (En attente de demande, Demandé, Reçu)
+- Vérifier la présence de la facture d'avoir en comptabilité (loupe ou bouton 'Vérifier toutes')
+- Valider ou dévalider un avoir (admin/directeur)
+- Envoyer le PDF de l'avoir reçu
+- Modifier ou supprimer un avoir (admin/directeur)
+- Rechercher un avoir et consulter les onglets En cours / Finalisés
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/user | au montage (useQuery ['/api/user']) | server/localAuth.production.ts:246 (lit req.user en session, sans requête BD) | En production, ce cache react-query n'est jamais rempli par useAuthUnified (enabled: isDevelopment, useAuthUnified.ts:43). La requête est donc refaite, et toutes les autres requêtes de la page l'attendent (enabled: !!user). |
+| GET /api/groups | au montage, après /api/user ; puis queryClient.fetchQuery à l'envoi du PDF | server/routes.ts:970 → storage.getUserWithGroups (storage.ts:371, 2 requêtes) + storage.getGroups (storage.ts:432, select * avec le logo base64) pour admin ; sinon userGroups[].group (id, name, color seulement) | N'est utile qu'aux formulaires création/édition. Pour un non-admin, la réponse ne contient pas webhookUrl, ce qui casse l'envoi du PDF. |
+| GET /api/suppliers | au montage, après /api/user | server/routes.ts:1141 → storage.getUser + storage.getSuppliers | Liste complète des fournisseurs, utilisée seulement dans les modales. |
+| GET /api/avoirs?storeId=X | au montage (après /api/user), puis refetch après chaque création, modification ou suppression (invalidation par prédicat) | server/routes.ts:3711 → storage.getUserWithGroups + storage.getAvoirs (storage.ts:2528 : 3 LEFT JOIN, groups.* complet, aucune limite) | queryKey [avoirsUrl, selectedStoreId, role] différente de celle du mobile. Charge tout l'historique, y compris le logo du magasin répété dans chaque ligne. |
+| POST /api/avoirs/:id/verify-invoice | boucle séquentielle dans un useEffect à chaque changement de 'avoirs' (montage et chaque refetch) ; clic sur la loupe ; 'Vérifier toutes' (forceRefresh, toutes les 200 ms) ; 1 s après l'envoi du PDF | server/routes.ts:3982 → getUserWithGroups + storage.getAvoir (storage.ts:2575) + invoiceVerificationService.verifyInvoice (invoiceVerification.ts:249 → getInvoiceVerificationCache, getGroup, getActiveNocodbConfig, appel HTTP NocoDB, saveInvoiceVerificationCache) | N appels séquentiels à chaque affichage. Si le cache a expiré (6 h ou 12 h), chaque appel va jusqu'à NocoDB. |
+| POST /api/avoirs | clic 'Créer' | server/routes.ts:3774 → getUserWithGroups, createAvoir (storage.ts:2619), getGroup, fetch webhook attendu sans timeout, updateAvoirWebhookStatus | Réponse bloquée tant que le webhook externe n'a pas répondu. supplierName codé en dur à 'Unknown'. |
+| PUT /api/avoirs/:id | modale Modifier ; changement de statut dans le menu de la ligne ; remplissage automatique du montant après une vérification réussie | server/routes.ts:3851 → getUserWithGroups, getAvoir, updateAvoir (storage.ts:2624), puis getGroup et webhook si passage à 'Reçu' | 3 logs JSON complets par appel. Les champs non envoyés sont remis à null. |
+| DELETE /api/avoirs/:id | confirmation de suppression | server/routes.ts:3945 → getUserWithGroups, getAvoir, deleteAvoir (storage.ts:2633) | Réservé à admin et directeur. |
+| PUT /api/avoirs/:id/nocodb-verification | clic Valider / Dévalider | server/routes.ts:4083 → getUserWithGroups, updateAvoirNocodbVerification (storage.ts:2644), getAvoir, updateCacheAsReconciled | Réservé à admin et directeur, mais le bouton est affiché à tous les rôles. L'invalidation côté client ne correspond pas à la queryKey quand un magasin est sélectionné. |
+| POST /api/cache/mark-reconciled | juste après un Valider réussi | server/routes.ts:4126 → invoiceVerificationService.updateCacheAsReconciled | Redondant : la route nocodb-verification marque déjà le cache comme réconcilié. |
+| POST {group.webhookUrl} (URL externe) | clic 'Envoyer' dans la modale d'envoi du PDF | aucun : appel direct depuis le navigateur | Dépend du CORS du service externe. La page BLReconciliation passe, elle, par le proxy /api/reconciliation/send-invoice (routes.ts:883). |
+
+**Lisibilité / simplicité :** La page est dense et ambiguë pour un utilisateur non technicien. Le tableau a 8 colonnes. Chaque ligne contient un menu de statut modifiable directement, sans confirmation, alors qu'un passage à 'Reçu' déclenche un webhook externe, et la même ligne affiche parfois 'Lecture seule'. La colonne Actions aligne jusqu'à 6 boutons-icônes de couleurs différentes, sans texte (seulement un title au survol), et la colonne Vérification se réduit à une loupe de 16 px. Le badge vert 'Validé' apparaît dès que la facture est trouvée, alors que l'avoir n'est pas validé et que le bouton 'Valider' est toujours proposé, ce qui rend le flux principal contradictoire. Tout l'onglet Finalisés est grisé (opacity-75), donc peu lisible. Les compteurs sont affichés trois fois (en-tête, onglets, carte). Plusieurs messages emploient du jargon (NocoDB, webhook) ou sont en anglais ('Failed to create avoir', '403: {"message":...}'). Formats peu soignés : '#Sans référence', '12.50 €' avec un point. Le formulaire de création n'est pas réinitialisé après envoi et ignore le magasin sélectionné en haut. Le PDF ne peut pas être envoyé par un directeur ou un employé. Côté performance, chaque affichage déclenche une cascade (/api/user, puis 3 requêtes, puis N POST de vérification séquentiels). 'Vérifier toutes' produit O(N²) requêtes et N toasts. De nombreux console.log de debug restent actifs en production.
+
+### `/avoirs (mobile)`
+
+**Rôle :** Version téléphone du suivi des avoirs : voir la liste des avoirs du magasin sélectionné, en créer un rapidement et changer leur statut ou les supprimer.
+
+**Tâches principales de l'utilisateur :**
+- Consulter les avoirs du magasin sélectionné
+- Rechercher par fournisseur ou référence de facture
+- Créer une demande d'avoir (feuille du bas)
+- Changer le statut via le menu '⋮'
+- Supprimer un avoir
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/user | au montage, via useAuthUnified dans la page et dans MobileLayout (fetch direct no-cache en production) | server/localAuth.production.ts:246 | 2 requêtes supplémentaires à chaque ouverture de la page. La liste attend l'une d'elles (enabled: !!user). |
+| GET /api/avoirs?storeId=X | au montage, seulement si un magasin est sélectionné et l'utilisateur chargé | server/routes.ts:3711 → getUserWithGroups + storage.getAvoirs (storage.ts:2528) | Avec 'Tous les magasins', la requête n'est pas lancée et la page affiche 'Aucun avoir trouvé'. queryKey ['/api/avoirs', storeId] différente de celle du bureau. |
+| GET /api/suppliers | au montage | server/routes.ts:1141 → storage.getUser + storage.getSuppliers | Utile seulement quand la feuille de création est ouverte. |
+| GET /api/groups | au montage | server/routes.ts:970 → getUserWithGroups (+ getGroups pour admin) | Même clé que MobileApp, donc dédoublonnée, mais inutile : StoreContext fournit déjà 'stores'. |
+| POST /api/avoirs | clic 'Créer la demande' | server/routes.ts:3774 → createAvoir + webhook synchrone | Montant envoyé à 0 par défaut. |
+| PUT /api/avoirs/:id | menu '⋮' > Marquer En attente / Demandé / Reçu | server/routes.ts:3851 → getAvoir, updateAvoir, webhook si 'Reçu' | Envoie l'objet avoir complet, relations comprises (group avec le logo base64). Aucun onError. |
+| DELETE /api/avoirs/:id | menu '⋮' > Supprimer (sans confirmation) | server/routes.ts:3945 → deleteAvoir | Erreur 403 pour manager et employé, avalée sans message. |
+
+**Lisibilité / simplicité :** La présentation en cartes est plus lisible que le tableau du bureau. En revanche : la liste est vide avec le message trompeur 'Aucun avoir trouvé' quand 'Tous les magasins' est sélectionné. La suppression se fait d'un tap, sans confirmation, et est proposée à tous les rôles. Les échecs (403) sont silencieux. Le menu de statut propose toujours les 3 états, sans indiquer l'état courant et sans les restrictions du bureau (manager vers 'Reçu', avoirs validés). Le formulaire n'affiche aucune erreur de validation et force le montant à 0 €. Les libellés, couleurs et statuts diffèrent du bureau ('Suivi' contre 'Gestion', indigo contre bleu, 'En attente' contre 'En attente de demande', 'Vérifié Compta' contre 'Validé'). Il n'y a pas de séparation En cours / Finalisés, la date s'affiche sans l'année, et le chargement utilise un spinner alors que le bureau utilise un skeleton.
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [AVOIRS-01](#avoirs-01) | haute | perf-api | M | Boucle séquentielle de N appels POST verify-invoice à chaque chargement de la liste | `client/src/pages/Avoirs.tsx:192` |
+| [AVOIRS-02](#avoirs-02) | haute | perf-api | M | « Vérifier toutes » déclenche une cascade O(N²) de requêtes, N toasts et ferme la modale d'édition | `client/src/pages/Avoirs.tsx:689` |
+| [AVOIRS-03](#avoirs-03) | haute | bug | S | Après Valider ou Dévalider, la liste n'est pas rafraîchie quand un magasin est sélectionné | `client/src/pages/Avoirs.tsx:528` |
+| [AVOIRS-04](#avoirs-04) | haute | bug | M | Envoi du PDF impossible pour directeur et employé, et appel direct au webhook externe depuis le navigateur | `client/src/pages/Avoirs.tsx:776` |
+| [AVOIRS-05](#avoirs-05) | haute | ux-simplicite | S | Badge « Validé » affiché alors que l'avoir n'est pas validé (la facture a seulement été trouvée) | `client/src/pages/Avoirs.tsx:1037` |
+| [AVOIRS-API-01](#avoirs-api-01) | haute | perf-api | S | La liste renvoie la ligne complète du magasin (logo base64, SMTP, webhook) dans chaque avoir | `server/storage.ts:2546` |
+| [MOB-AVOIRS-01](#mob-avoirs-01) | haute | bug | S | Liste vide « Aucun avoir trouvé » quand « Tous les magasins » est sélectionné | `client/src/pages/mobile/AvoirsPage.tsx:83` |
+| [MOB-AVOIRS-02](#mob-avoirs-02) | haute | ux-simplicite | S | Suppression sans confirmation, proposée à tous les rôles, avec échec silencieux | `client/src/pages/mobile/AvoirsPage.tsx:257` |
+| [AVOIRS-06](#avoirs-06) | moyenne | ux-simplicite | M | Statut modifié immédiatement par un menu déroulant dans chaque ligne, sans confirmation, avec effet externe | `client/src/pages/Avoirs.tsx:994` |
+| [AVOIRS-07](#avoirs-07) | moyenne | ux-simplicite | M | Jusqu'à 6 boutons-icônes sans texte par ligne et une loupe de 16 px | `client/src/pages/Avoirs.tsx:1060` |
+| [AVOIRS-08](#avoirs-08) | moyenne | lisibilite | S | Onglet « Finalisés » entièrement grisé et semi-transparent | `client/src/pages/Avoirs.tsx:989` |
+| [AVOIRS-09](#avoirs-09) | moyenne | lisibilite | S | Messages techniques (NocoDB, webhook) et erreurs brutes en anglais affichés à l'utilisateur | `client/src/pages/Avoirs.tsx:666` |
+| [AVOIRS-10](#avoirs-10) | moyenne | bug | S | Bouton « Valider » proposé à des rôles que le serveur refuse | `client/src/pages/Avoirs.tsx:1076` |
+| [AVOIRS-11](#avoirs-11) | moyenne | perf-client | S | Requête /api/user redondante qui bloque toutes les autres (cascade) | `client/src/pages/Avoirs.tsx:147` |
+| [AVOIRS-12](#avoirs-12) | moyenne | bug | S | Formulaire de création non réinitialisé, et magasin par défaut qui ignore le magasin sélectionné | `client/src/pages/Avoirs.tsx:263` |
+| [AVOIRS-13](#avoirs-13) | moyenne | perf-client | S | Filtrages non mémoïsés et code mort exécuté à chaque frappe, avec un risque de plantage | `client/src/pages/Avoirs.tsx:871` |
+| [AVOIRS-14](#avoirs-14) | moyenne | perf-client | M | Aucune pagination : tout l'historique est rendu avec un Select Radix par ligne | `client/src/pages/Avoirs.tsx:988` |
+| [AVOIRS-15](#avoirs-15) | moyenne | dette-code | S | console.log de débogage actifs en production dans les chemins chauds | `client/src/pages/Avoirs.tsx:168` |
+| [AVOIRS-API-02](#avoirs-api-02) | moyenne | perf-api | M | Ni pagination ni filtre de statut en SQL : la séparation En cours / Finalisés se fait en JavaScript | `server/storage.ts:2561` |
+| [AVOIRS-API-03](#avoirs-api-03) | moyenne | perf-serveur | S | Logs JSON volumineux à chaque création, modification et vérification | `server/routes.ts:3874` |
+| [AVOIRS-API-04](#avoirs-api-04) | moyenne | perf-api | S | Création et modification bloquées par l'appel au webhook externe, sans timeout | `server/routes.ts:3821` |
+| [AVOIRS-API-05](#avoirs-api-05) | moyenne | bug | S | Le webhook avoir est envoyé avec un nom de fournisseur factice | `server/routes.ts:3813` |
+| [AVOIRS-API-06](#avoirs-api-06) | moyenne | bug | S | Le PUT efface montant, référence et commentaire s'ils ne sont pas envoyés, ce qui oblige à renvoyer tout l'objet | `server/routes.ts:3879` |
+| [AVOIRS-API-07](#avoirs-api-07) | moyenne | bug | S | Règles métier appliquées seulement côté client (statut « Reçu », avoirs validés, changement de magasin) | `server/routes.ts:3866` |
+| [MOB-AVOIRS-03](#mob-avoirs-03) | moyenne | ux-simplicite | S | Menu de statut sans indication de l'état courant ni restrictions | `client/src/pages/mobile/AvoirsPage.tsx:239` |
+| [MOB-AVOIRS-04](#mob-avoirs-04) | moyenne | perf-api | S | Le changement de statut envoie l'objet avoir complet avec ses relations | `client/src/pages/mobile/AvoirsPage.tsx:241` |
+| [MOB-AVOIRS-05](#mob-avoirs-05) | moyenne | bug | S | Montant forcé à 0 € lors d'une création sur mobile | `client/src/pages/mobile/AvoirsPage.tsx:135` |
+| [MOB-AVOIRS-06](#mob-avoirs-06) | moyenne | ux-simplicite | S | Erreurs de validation invisibles dans le formulaire mobile | `client/src/pages/mobile/AvoirsPage.tsx:46` |
+| [MOB-AVOIRS-07](#mob-avoirs-07) | moyenne | perf-client | M | Requêtes /api/user répétées et cascade avant le chargement des avoirs | `client/src/pages/mobile/AvoirsPage.tsx:72` |
+| [AVOIRS-16](#avoirs-16) | basse | ux-simplicite | S | Compteurs affichés trois fois et deux composants Tabs séparés | `client/src/pages/Avoirs.tsx:1168` |
+| [AVOIRS-17](#avoirs-17) | basse | lisibilite | S | Formats incohérents : « #Sans référence », montants « 12.50 € », couleur CSS invalide | `client/src/pages/Avoirs.tsx:1012` |
+| [AVOIRS-18](#avoirs-18) | basse | bug | S | La règle « un admin peut modifier un avoir validé » est inaccessible depuis le menu de statut | `client/src/pages/Avoirs.tsx:997` |
+| [AVOIRS-19](#avoirs-19) | basse | perf-api | S | Double marquage du cache lors de la validation, et validation hors useMutation | `client/src/pages/Avoirs.tsx:510` |
+| [AVOIRS-20](#avoirs-20) | basse | bug | S | Timer du modal d'attente jamais nettoyé, et modal fermable pendant l'envoi | `client/src/pages/Avoirs.tsx:746` |
+| [AVOIRS-21](#avoirs-21) | basse | dette-code | S | Code mort, imports inutilisés et typage faible | `client/src/pages/Avoirs.tsx:882` |
+| [AVOIRS-22](#avoirs-22) | basse | perf-bundle | S | Pages Avoirs (bureau et mobile) chargées dans le bundle initial | `client/src/components/RouterProduction.tsx:26` |
+| [AVOIRS-API-08](#avoirs-api-08) | basse | bug | S | Périmètre du directeur incohérent d'une route avoirs à l'autre | `server/routes.ts:3721` |
+| [AVOIRS-API-09](#avoirs-api-09) | basse | perf-serveur | S | verify-invoice recharge des données déjà disponibles et ne met pas en cache les résultats négatifs | `server/invoiceVerification.ts:285` |
+| [MOB-AVOIRS-08](#mob-avoirs-08) | basse | perf-client | S | Données de référence chargées inutilement et tri redondant | `client/src/pages/mobile/AvoirsPage.tsx:91` |
+| [MOB-AVOIRS-09](#mob-avoirs-09) | basse | coherence-design | M | Libellés, couleurs et statuts différents de la version bureau | `client/src/pages/mobile/AvoirsPage.tsx:180` |
+| [MOB-AVOIRS-10](#mob-avoirs-10) | basse | dette-code | S | Imports inutilisés, typage any et schéma dupliqué | `client/src/pages/mobile/AvoirsPage.tsx:19` |
+
+### AVOIRS-01
+
+**Boucle séquentielle de N appels POST verify-invoice à chaque chargement de la liste** — perf-api, sévérité haute, effort M
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:192`
+- **Constat :** useEffect(() => { const loadCachedVerifications = async () => { ... for (const avoir of avoirs) { if (avoir.invoiceReference?.trim()) { const result = await apiRequest(`/api/avoirs/${avoir.id}/verify-invoice`, 'POST', { invoiceReference: avoir.invoiceReference, forceRefresh: false }); ... } } }; loadCachedVerifications(); }, [avoirs]); (l.192-245). Le commentaire de la l.716 ('✅ SUPPRIMÉ : Le chargement automatique causait des crashes JavaScript') est contredit : la boucle est toujours active. Les avoirs déjà validés (nocodbVerified) ne sont pas exclus. Côté serveur, chaque appel exécute getUserWithGroups (2 requêtes), getAvoir (3 JOIN) et une lecture du cache. Le cache expire au bout de 6 h ou 12 h (invoiceVerification.ts:101-108), après quoi l'appel va jusqu'à NocoDB. Les magasins sans configuration ne sont jamais mis en cache (invoiceVerification.ts:302-309).
+- **Impact :** Avec 100 avoirs ayant une référence : 100 allers-retours successifs (plusieurs secondes à plusieurs dizaines de secondes de trafic) après chaque affichage. Chaque refetch (après toute création, modification ou suppression) relance la boucle entière. Les badges 'Validé' et les boutons 'Valider' apparaissent au compte-gouttes. Le serveur est chargé et le quota NocoDB consommé le matin, à l'expiration du cache.
+- **Recommandation :** Supprimer ce useEffect. Renvoyer l'état de vérification avec la liste : dans storage.getAvoirs, ajouter un LEFT JOIN invoice_verification_cache ON cache_key = avoirs.group_id || '_' || lower(trim(avoirs.invoice_reference)) AND expires_at > now(), exposé sous la forme verification {exists, invoiceAmount, isReconciled}. À défaut, créer un endpoint groupé POST /api/avoirs/verifications {ids} qui lit uniquement le cache (un seul SELECT ... WHERE cache_key IN (...)) sans jamais appeler NocoDB, consommé par un useQuery. Exclure les avoirs nocodbVerified.
+
+### AVOIRS-02
+
+**« Vérifier toutes » déclenche une cascade O(N²) de requêtes, N toasts et ferme la modale d'édition** — perf-api, sévérité haute, effort M
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:689`
+- **Constat :** avoirsToVerify.forEach((avoir, index) => { setTimeout(() => { handleVerifyAvoirInvoice(avoir, true); }, index * 200); }); (l.703-708). forceRefresh=true contourne le cache, d'où un appel NocoDB par avoir, y compris pour les avoirs déjà validés (le filtre des l.690-693 n'exclut pas nocodbVerified). En cas de succès : editAvoirMutation.mutate({ id: variables.avoirId, data: { ..., amount: result.invoiceAmount, ... } }) (l.601-612). Son onSuccess invalide toutes les clés '/api/avoirs' (l.303-307), affiche le toast 'Avoir modifié' et exécute setIsEditDialogOpen(false); setSelectedAvoir(null) (l.308-313). Le refetch produit un nouveau tableau 'avoirs', ce qui relance la boucle d'AVOIRS-01 (N POST).
+- **Impact :** Pour N avoirs : N appels NocoDB, N PUT, N GET /api/avoirs et jusqu'à N×N POST verify-invoice. L'utilisateur reçoit N toasts 'Avoir modifié'. Si une modale d'édition est ouverte, elle se ferme toute seule. Le montant saisi est remplacé sans prévenir par le montant HT de la facture.
+- **Recommandation :** Créer un endpoint serveur POST /api/avoirs/verify-all, limité aux groupes accessibles et excluant les avoirs nocodbVerified. Il traite les vérifications en parallèle avec une concurrence limitée (4) et ne remplit le montant côté serveur que s'il est vide. Côté client : une seule mutation suivie d'une seule invalidation. En attendant, utiliser une mutation de remplissage automatique séparée, sans toast ni fermeture de modale, qui met à jour la ligne avec queryClient.setQueryData au lieu d'invalider la liste.
+
+### AVOIRS-03
+
+**Après Valider ou Dévalider, la liste n'est pas rafraîchie quand un magasin est sélectionné** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:528`
+- **Constat :** La queryKey est [avoirsUrl, selectedStoreId, (user as any)?.role] avec avoirsUrl = `/api/avoirs${selectedStoreId ? `?storeId=${selectedStoreId}` : ''}` (l.164-166). handleValidateAvoir et handleDevalidateAvoir appellent queryClient.invalidateQueries({ queryKey: ['/api/avoirs'] }) (l.528 et l.560). TanStack compare les clés élément par élément : '/api/avoirs' ≠ '/api/avoirs?storeId=3', donc aucune requête n'est invalidée. Les autres mutations utilisent un prédicat includes('/api/avoirs') (l.265-269), qui fonctionne.
+- **Impact :** Dès qu'un magasin est sélectionné (cas le plus courant), un avoir validé reste dans l'onglet 'En cours'. Après 'Dévalider', l'état local est supprimé (l.551-555) mais avoir.nocodbVerified reste à true dans le cache : la ligne affiche toujours 'Validé' et reste dans 'Finalisés' jusqu'au rechargement de la page. L'utilisateur croit que l'action a échoué et recommence.
+- **Recommandation :** Correction auto limitée au minimum : remplacer aux l.528 et 560 par queryClient.invalidateQueries({ predicate: q => q.queryKey[0]?.toString().includes('/api/avoirs') || false }). La normalisation de la clé ['/api/avoirs', {storeId}] avec un queryFn dédié (bureau et mobile) se fait à part, sans automatisation.
+
+### AVOIRS-04
+
+**Envoi du PDF impossible pour directeur et employé, et appel direct au webhook externe depuis le navigateur** — bug, sévérité haute, effort M
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:776`
+- **Constat :** const groups = await queryClient.fetchQuery({ queryKey: ['/api/groups'] }); const group = (groups as any[]).find(g => g.id === groupId); if (!group?.webhookUrl) { toast({ ... description: 'Aucun webhook configuré pour ce magasin' }) } (l.776-786). Pour un non-admin, GET /api/groups renvoie (user as any).userGroups?.map((ug: any) => ug.group) (server/routes.ts:983). Ces groupes viennent de getUserWithGroups, qui ne sélectionne que g.id, g.name, g.color, created_at et updated_at (server/storage.ts:376-399) : webhookUrl est donc toujours undefined. Le bouton Upload est affiché si role !== 'manager' (l.1063), donc aux directeurs et aux employés. L'envoi se fait ensuite par fetch(group.webhookUrl, { method: 'POST', body: formData }) (l.805) directement depuis le navigateur, alors que BLReconciliation passe par le proxy '/api/reconciliation/send-invoice' (BLReconciliation.tsx:587-592, routes.ts:883), justement pour les « problèmes CORS ».
+- **Impact :** Pour un directeur ou un employé, le bouton 'Envoyer fichier avoir' échoue toujours avec un message incompréhensible. Pour un admin, l'envoi dépend du CORS du service externe et l'URL du webhook est visible dans le navigateur.
+- **Recommandation :** Créer POST /api/avoirs/:id/send-file. Le serveur vérifie l'accès au groupe de l'avoir, lit webhookUrl via storage.getGroup(avoir.groupId) et relaie le fichier (même parseur multipart que send-invoice). Ne pas réutiliser send-invoice, qui fait confiance à une URL fournie par le client. Décider explicitement si les employés peuvent envoyer ce fichier.
+
+### AVOIRS-05
+
+**Badge « Validé » affiché alors que l'avoir n'est pas validé (la facture a seulement été trouvée)** — ux-simplicite, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:1037`
+- **Constat :** {(avoirVerificationResults[avoir.id]?.exists === true || avoir.nocodbVerified) ? (<div className='... bg-green-100 text-green-800 ...'><CheckCircle .../>Validé</div>) (l.1037-1041). Dans la même ligne : {avoirVerificationResults[avoir.id]?.exists === true && !avoir.nocodbVerified && (<Button ... title="Valider l'avoir"><CheckCircle/></Button>)} (l.1076-1086).
+- **Impact :** L'utilisateur voit 'Validé' en vert et, en même temps, un bouton vert ✓ 'Valider'. Il pense que le travail est fait, et l'avoir ne passe jamais dans 'Finalisés'. C'est le flux principal de la page qui devient ambigu.
+- **Recommandation :** Afficher 3 états explicites avec du texte : 'Non vérifié' (gris, avec un bouton 'Vérifier'), 'Facture trouvée – à valider' (bleu ou orange, avec un bouton texte 'Valider'), et 'Validé' (vert) uniquement si avoir.nocodbVerified.
+
+### AVOIRS-API-01
+
+**La liste renvoie la ligne complète du magasin (logo base64, SMTP, webhook) dans chaque avoir** — perf-api, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:2546`
+- **Constat :** getAvoirs sélectionne supplier: suppliers, group: groups, creator: { id, firstName, lastName, username, email: users.email } (l.2546-2554) avec .leftJoin(groups, eq(avoirs.groupId, groups.id)). La table groups contient logo: text('logo'), // Logo en data URI (data:image/png;base64,...) (shared/schema.ts:67), smtpHost, smtpUser et smtpSenderEmail (l.70-76), webhookUrl (l.63), address et phone. getAvoir fait de même (l.2593-2594) ; il est appelé par chaque PUT, DELETE et verify-invoice. Le middleware global stripSmtpPassword (server/routes.ts:168-174, server/sanitize.ts:13-45) parcourt ensuite récursivement tous les objets de la réponse.
+- **Impact :** Le logo (souvent plusieurs dizaines à centaines de Ko) est répété dans chaque avoir : environ 200 avoirs × 100 Ko ≈ 20 Mo de JSON pour une seule liste, soit un chargement très lent, surtout en 4G. Sérialisation et nettoyage récursif consomment du CPU. webhookUrl et la configuration SMTP sont exposés aux employés et aux managers.
+- **Recommandation :** Projection : group {id, name, color, nocodbTableName, nocodbConfigId}, supplier {id, name}, creator {id, firstName, lastName, username}, dans getAvoirs et getAvoir. Mettre à jour AvoirWithRelations (ou un type dédié) pour que tsc passe. MemStorage peut rester tel quel.
+
+### MOB-AVOIRS-01
+
+**Liste vide « Aucun avoir trouvé » quand « Tous les magasins » est sélectionné** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/mobile/AvoirsPage.tsx:83`
+- **Constat :** queryFn: async () => { if (!selectedStoreId) return []; ... }, enabled: !!selectedStoreId && !!user (l.82-88). MobileLayout propose 'Tous les magasins' (MobileLayout.tsx:28, 40-46), et MobileApp ne présélectionne un magasin que s'il n'y en a qu'un (MobileApp.tsx:37). L'état vide affiche <p>Aucun avoir trouvé</p> (l.200-204).
+- **Impact :** Un admin ou un directeur multi-magasins ouvre la page et lit 'Aucun avoir trouvé' alors que des avoirs existent. Il croit qu'il n'y en a pas.
+- **Recommandation :** Appeler /api/avoirs sans storeId quand aucun magasin n'est sélectionné (le serveur filtre déjà selon le rôle, routes.ts:3721-3733). À défaut, afficher 'Choisissez un magasin en haut de l'écran pour voir ses avoirs'.
+
+### MOB-AVOIRS-02
+
+**Suppression sans confirmation, proposée à tous les rôles, avec échec silencieux** — ux-simplicite, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/mobile/AvoirsPage.tsx:257`
+- **Constat :** <DropdownMenuItem onClick={() => deleteMutation.mutate(avoir.id)} className='text-red-600'> (l.257-263). deleteMutation et updateStatusMutation n'ont pas d'onError (l.113-127). Le serveur refuse la suppression aux rôles autres qu'admin et directeur (routes.ts:3960-3962).
+- **Impact :** Sur téléphone, un tap malheureux supprime définitivement un avoir pour un admin. Pour un manager ou un employé, rien ne se passe et aucun message n'apparaît.
+- **Recommandation :** Ajouter une confirmation par AlertDialog. Masquer 'Supprimer' pour les rôles autres qu'admin et directeur. Ajouter un onError qui affiche un toast en français.
+
+### AVOIRS-06
+
+**Statut modifié immédiatement par un menu déroulant dans chaque ligne, sans confirmation, avec effet externe** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:994`
+- **Constat :** <Select value={avoir?.status || ''} onValueChange={(newStatus) => handleStatusChange(avoir.id, newStatus)} disabled={avoir.nocodbVerified}> (l.994-1009) envoie un PUT immédiatement. Le serveur envoie un webhook quand le statut passe à 'Reçu' (server/routes.ts:3891-3928). Pour un rôle autre qu'admin ou directeur, la même ligne affiche {!canEditDelete && avoir?.status !== 'Reçu' && (<span>Lecture seule</span>)} (l.1136-1138) alors que le menu reste modifiable.
+- **Impact :** Un clic accidentel change le statut et envoie une notification irréversible au système externe. La mention 'Lecture seule' contredit un menu modifiable. Un Select large dans chaque ligne alourdit le tableau.
+- **Recommandation :** Afficher le statut sous forme de badge coloré (gris 'À demander', bleu 'Demandé', vert 'Reçu'). Ajouter un seul bouton texte contextuel ('Marquer comme demandé' puis 'Marquer comme reçu'), avec confirmation pour 'Reçu'. Supprimer la mention 'Lecture seule'.
+
+### AVOIRS-07
+
+**Jusqu'à 6 boutons-icônes sans texte par ligne et une loupe de 16 px** — ux-simplicite, sévérité moyenne, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:1060`
+- **Constat :** La colonne Actions contient Upload (bleu), CheckCircle 'Valider' (vert), XCircle 'Dévalider' (orange), MessageSquare 'Voir le commentaire' (violet), Edit et Trash2 (rouge), tous en className='h-8 w-8 p-0' avec seulement un title= (l.1062-1135). La colonne Vérification contient <button className='h-4 w-4 text-gray-400 ...' title='Cliquer pour vérifier la facture'><Search className='h-4 w-4'/></button> (l.1047-1053). Le commentaire n'est lisible que dans une modale (l.1102-1112), alors que le mobile l'affiche dans la carte (mobile/AvoirsPage.tsx:268-272).
+- **Impact :** Un utilisateur non technicien doit survoler chaque icône pour la comprendre, et le title ne fonctionne pas sur écran tactile. Une cible de 16 px est difficile à cliquer. Les 6 couleurs n'ont pas de légende.
+- **Recommandation :** Même recommandation, en corrigeant le constat : jusqu'à 5 icônes par ligne.
+
+### AVOIRS-08
+
+**Onglet « Finalisés » entièrement grisé et semi-transparent** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:989`
+- **Constat :** <tr className={`hover:bg-gray-50 ${avoir?.nocodbVerified ? 'bg-gray-100 opacity-75' : ''}`}> (l.989), alors que completedAvoirs = avoirs.filter(avoir => avoir.status === 'Reçu' && avoir.nocodbVerified) (l.911). Toutes les lignes de cet onglet sont donc à 75 % d'opacité. Les dates sont déjà en text-gray-500 (l.1033).
+- **Impact :** Le contraste est insuffisant (gris 500 à 75 % sur gris 100, sous 4,5:1). L'historique, justement consulté pour des vérifications, devient difficile à lire.
+- **Recommandation :** Supprimer opacity-75 et bg-gray-100. Le badge 'Validé' suffit à distinguer ces lignes.
+
+### AVOIRS-09
+
+**Messages techniques (NocoDB, webhook) et erreurs brutes en anglais affichés à l'utilisateur** — lisibilite, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:666`
+- **Constat :** 'Ce magasin n'a pas de configuration NocoDB' (l.666) ; 'Aucun webhook configuré pour ce magasin' (l.782) ; 'Avoir traité avec succès via le webhook' (l.821) ; 'Envoi du fichier vers le webhook... {processingSeconds}s' (l.1695). Les mutations font throw new Error('Failed to create avoir') (l.259), 'Failed to edit avoir' (l.297) et 'Failed to delete avoir' (l.332), affichées via description: error.message (l.279, 318, 353). apiRequest produit des erreurs de la forme `${res.status}: ${text}` (client/src/lib/queryClient.ts:3-8), d'où un toast du type '403: {"message":"Insufficient permissions"}' (l.537).
+- **Impact :** Les messages sont incompréhensibles pour un employé de magasin, qui ne sait pas quoi faire.
+- **Recommandation :** Créer getErrorMessage(err) côté client, utilisé seulement au moment d'afficher le toast. Il lit le code HTTP en tête du message et le traduit (401 « Session expirée », 403 « Vous n'avez pas les droits pour cette action », 404 « Avoir introuvable », 400 « Données invalides », 5xx « Erreur serveur, réessayez »). Ne pas modifier le format des erreurs de apiRequest. Reformuler en français simple les textes 'NocoDB' et 'webhook'.
+
+### AVOIRS-10
+
+**Bouton « Valider » proposé à des rôles que le serveur refuse** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:1076`
+- **Constat :** Côté client : {avoirVerificationResults[avoir.id]?.exists === true && !avoir.nocodbVerified && (<Button ... onClick={() => handleValidateAvoir(avoir.id)}>)} (l.1076), sans contrôle de rôle. Côté serveur : if (user.role !== 'admin' && user.role !== 'directeur') { return res.status(403).json({ message: 'Insufficient permissions' }) } (server/routes.ts:4094-4096).
+- **Impact :** Un manager ou un employé qui clique reçoit un toast rouge 'Erreur de validation : 403: {"message":"Insufficient permissions"}'.
+- **Recommandation :** Ajouter && canEditDelete (défini l.928) à la condition d'affichage du bouton.
+
+### AVOIRS-11
+
+**Requête /api/user redondante qui bloque toutes les autres (cascade)** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:147`
+- **Constat :** const { data: user } = useQuery({ queryKey: ['/api/user'] }); (l.147-149), puis groups, suppliers et avoirs en enabled: !!user (l.154, 160, 188), et if (!user) { return <div>Chargement...</div>; } (l.1149-1151). En production, l'authentification passe par useAuthUnified en fetch direct, la variante react-query étant en enabled: isDevelopment (client/src/hooks/useAuthUnified.ts:43, 147-217). Le cache ['/api/user'] n'est donc jamais rempli.
+- **Impact :** Chaque affichage ajoute un aller-retour séquentiel avant de lancer les 3 requêtes, elles-mêmes suivies des N vérifications. Pendant ce temps, l'utilisateur voit une page blanche avec un 'Chargement...' sans mise en forme.
+- **Recommandation :** Remplir ['/api/user'] depuis useAuthUnified (setQueryData) ou lire l'utilisateur via useAuthUnified(). Retirer (user as any)?.role de la queryKey des avoirs avant de supprimer enabled: !!user. Remplacer 'Chargement...' par le skeleton.
+
+### AVOIRS-12
+
+**Formulaire de création non réinitialisé, et magasin par défaut qui ignore le magasin sélectionné** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:263`
+- **Constat :** Le onSuccess de createAvoirMutation invalide la liste, ferme la modale (setIsCreateDialogOpen(false)) et affiche un toast, sans form.reset() (l.263-275). defaultValues: { supplierId: 0, groupId: getDefaultGroupId(), ... } (l.374-376) est évalué au premier rendu. getDefaultGroupId renvoie 1 pour un admin, sinon le premier groupe de l'utilisateur, et 0 si l'utilisateur n'est pas encore chargé (l.360-369). selectedStoreId (l.141) n'est pas utilisé.
+- **Impact :** En rouvrant 'Nouvel avoir', on retrouve les données de l'avoir précédent, d'où un risque de doublon. L'utilisateur qui a choisi le magasin X en haut doit le resélectionner ; un admin risque de créer l'avoir sur le magasin 1.
+- **Recommandation :** À l'ouverture de la modale et après un succès, appeler form.reset({ ...valeursParDéfaut, groupId: selectedStoreId ?? getDefaultGroupId() }).
+
+### AVOIRS-13
+
+**Filtrages non mémoïsés et code mort exécuté à chaque frappe, avec un risque de plantage** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:871`
+- **Constat :** const filteredAvoirs = avoirs.filter(avoir => ... (avoir.creator.firstName && avoir.creator.lastName ? ... : avoir.creator.username.toLowerCase().includes(...))) (l.871-879) n'est jamais utilisé. pendingAvoirs, completedAvoirs et filterAvoirs sont recalculés à chaque rendu (l.910-926), avec un searchTerm.toLowerCase() par élément. renderAvoirTable(filteredPendingAvoirs) et renderAvoirTable(filteredCompletedAvoirs) sont tous deux évalués (l.1246 et l.1263) alors qu'un seul onglet est visible. creator provient d'un LEFT JOIN sur users (server/storage.ts:2548-2559) : si le créateur a été supprimé, Drizzle renvoie creator = null et avoir.creator.firstName lève une TypeError qui fait planter toute la page (plausible).
+- **Impact :** À chaque frappe dans la recherche : 4 parcours de la liste et la construction du JSX des deux tableaux. Risque de page blanche.
+- **Recommandation :** Supprimer filteredAvoirs. Calculer pending, completed et les listes filtrées dans des useMemo, en passant la recherche par useDeferredValue(searchTerm). Ne rendre que le tableau de l'onglet actif. Utiliser le chaînage optionnel sur creator.
+
+### AVOIRS-14
+
+**Aucune pagination : tout l'historique est rendu avec un Select Radix par ligne** — perf-client, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:988`
+- **Constat :** {avoirsList?.filter(avoir => avoir && avoir.id).map((avoir) => (<tr ...> ... <Select ...> (l.988-1009). Côté serveur, getAvoirs n'a pas de LIMIT : const results = await query.orderBy(desc(avoirs.createdAt)); (server/storage.ts:2565). L'onglet 'Finalisés' grossit indéfiniment.
+- **Impact :** Après une année d'utilisation (des centaines d'avoirs), le DOM est lourd, et le rendu comme la recherche ralentissent. Chaque Select ajoute plusieurs composants Radix et leurs écouteurs.
+- **Recommandation :** Paginer par 50, ou limiter 'Finalisés' aux 3 derniers mois avec un bouton 'Voir plus'. Remplacer le Select de chaque ligne par un badge (voir AVOIRS-06).
+
+### AVOIRS-15
+
+**console.log de débogage actifs en production dans les chemins chauds** — dette-code, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:168`
+- **Constat :** Dans le queryFn : console.log('💰 Fetching avoirs from:', avoirsUrl) puis console.log('🔍 Premiers avoirs avec nocodbVerified:', data.map(a => ({ id: a.id, invoiceReference: ..., nocodbVerified: ... }))) (l.168-184), qui parcourt toute la liste à chaque fetch. Dans la boucle : console.log('🔍 LoadCache - Avoir analysé:', {...}) pour chaque avoir (l.205-210), ainsi qu'aux l.220, 224 et 233-240. Autres logs aux l.414-420, 525, 557, 600 et 672-677. Aucun n'est protégé par import.meta.env.DEV, contrairement à apiRequest (queryClient.ts:17).
+- **Impact :** Console saturée, allocations inutiles, et références et montants exposés dans la console du poste du magasin.
+- **Recommandation :** Supprimer ces console.log, surtout ceux dont les arguments calculent quelque chose (l.178 data.map, l.205-210). Ce nettoyage est sans risque, mais le gain en production est minime, car le minifieur retire déjà les appels.
+
+### AVOIRS-API-02
+
+**Ni pagination ni filtre de statut en SQL : la séparation En cours / Finalisés se fait en JavaScript** — perf-api, sévérité moyenne, effort M
+
+- **Fichier :** `server/storage.ts:2561`
+- **Constat :** if (groupIds && groupIds.length > 0) { query = query.where(inArray(avoirs.groupId, groupIds)); } const results = await query.orderBy(desc(avoirs.createdAt)); (l.2561-2565), sans limite. Le client sépare ensuite les listes : pendingAvoirs = avoirs.filter(avoir => !(avoir.status === 'Reçu' && avoir.nocodbVerified)) (Avoirs.tsx:910-911). Un admin sans magasin sélectionné reçoit tous les avoirs de tous les magasins (routes.ts:3721-3722).
+- **Impact :** La réponse grossit avec l'historique. L'essentiel des données transférées concerne des avoirs finalisés rarement consultés.
+- **Recommandation :** Ajouter les paramètres ?scope=pending|completed&limit=50&offset=, traduits en SQL par WHERE (status <> 'Reçu' OR nocodb_verified = false). Ne charger 'Finalisés' qu'à l'ouverture de l'onglet (useQuery avec enabled: activeTab === 'completed'). L'index (group_id, status) existe déjà (migrations/20260814_add_performance_indexes.sql).
+
+### AVOIRS-API-03
+
+**Logs JSON volumineux à chaque création, modification et vérification** — perf-serveur, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:3874`
+- **Constat :** PUT : console.log('💰 PUT Avoir - Raw body received:', JSON.stringify(req.body, null, 2)), puis les logs 'Validated data' et 'Data for DB' (l.3874, 3876, 3885). POST : l.3782, 3783 et 3791. GET : l.3735 et 3737. verify-invoice : l.4032-4038 et 4048. invoiceVerification.checkCache écrit 2 à 3 logs par appel (server/invoiceVerification.ts:22-31, 35-41, 58), et getInvoiceVerificationCache en ajoute (server/storage.ts:1718-1736). Le mobile envoie l'avoir complet, groupe et logo compris, dans le PUT (mobile/AvoirsPage.tsx:239-256), qui est donc journalisé 3 fois en pretty-print.
+- **Impact :** Les écritures synchrones sur stdout bloquent la boucle d'événements. Les logs gonflent de plusieurs centaines de Ko par changement de statut, multipliés par N pendant la boucle de vérification.
+- **Recommandation :** Supprimer les console.log de données (et non les console.error), ou les placer derrière un if (process.env.DEBUG). Ne jamais journaliser req.body en entier.
+
+### AVOIRS-API-04
+
+**Création et modification bloquées par l'appel au webhook externe, sans timeout** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:3821`
+- **Constat :** POST : const webhookResponse = await fetch(group.webhookUrl, { method: 'POST', headers: {...}, body: JSON.stringify(webhookData) }); est attendu avant res.json(avoir) (l.3821-3840). Le PUT fait de même lors du passage à 'Reçu' (l.3914-3934). Aucun AbortSignal ni timeout.
+- **Impact :** Si le service externe est lent ou indisponible, le bouton 'Création...' reste bloqué jusqu'au timeout TCP (de quelques dizaines de secondes à plusieurs minutes), alors que l'avoir est déjà enregistré. L'utilisateur reclique et crée des doublons.
+- **Recommandation :** Répondre au client tout de suite, puis envoyer le webhook en arrière-plan (sans await, ou via une file de tâches) avec signal: AbortSignal.timeout(5000), et appeler updateAvoirWebhookStatus une fois l'envoi terminé.
+
+### AVOIRS-API-05
+
+**Le webhook avoir est envoyé avec un nom de fournisseur factice** — bug, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:3813`
+- **Constat :** supplierName: 'Unknown', // Will be fetched from relations (l.3813) et supplierName: 'Fournisseur', // Sera enrichi avec relations (l.3903) ne sont jamais enrichis. Pourtant existingAvoir, issu de getAvoir (l.3859), contient déjà supplier.name.
+- **Impact :** Le système externe (comptabilité, automatisation) reçoit 'Unknown' ou 'Fournisseur' au lieu du vrai fournisseur, ce qui impose un tri manuel.
+- **Recommandation :** POST : après createAvoir, lire const full = await storage.getAvoir(avoir.id) et utiliser full?.supplier?.name ?? ''. PUT : si validatedData.supplierId est défini et différent de existingAvoir.supplierId, relire l'avoir avec getAvoir(id) ; sinon utiliser existingAvoir.supplier?.name.
+
+### AVOIRS-API-06
+
+**Le PUT efface montant, référence et commentaire s'ils ne sont pas envoyés, ce qui oblige à renvoyer tout l'objet** — bug, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:3879`
+- **Constat :** const dataForDb: any = { ...validatedData, amount: validatedData.amount === undefined ? null : validatedData.amount, invoiceReference: ... === undefined ? null : ..., comment: ... === undefined ? null : ... }; (l.3879-3884), après insertAvoirSchema.partial().parse(req.body) (l.3875). Conséquence : le bureau reconstruit tout le payload pour un simple changement de statut (Avoirs.tsx:483-494, 601-612), et le mobile envoie { ...avoir, status } avec toutes les relations (mobile/AvoirsPage.tsx:239-256).
+- **Impact :** Un PUT { status: 'Reçu' } effacerait le montant, la référence et le commentaire. Les requêtes sont plus lourdes que nécessaire.
+- **Recommandation :** D'abord modifier le client pour qu'il envoie explicitement amount: null quand le champ est vide (Avoirs.tsx:408). Ensuite seulement, côté serveur, ne convertir en null que les clés présentes dans req.body. Les clients pourront alors n'envoyer que { status }.
+
+### AVOIRS-API-07
+
+**Règles métier appliquées seulement côté client (statut « Reçu », avoirs validés, changement de magasin)** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:3866`
+- **Constat :** Le bureau interdit aux managers de passer un avoir en 'Reçu' (Avoirs.tsx:474-481) et bloque les avoirs validés (l.464-471). Le PUT serveur ne vérifie que le magasin de l'avoir existant : if (!userGroupIds.includes(existingAvoir.groupId)) (routes.ts:3866-3871). Il ne contrôle ni le rôle pour 'Reçu', ni nocodbVerified, ni l'accès au nouveau validatedData.groupId. Le mobile propose 'Marquer Reçu' à tous les rôles (mobile/AvoirsPage.tsx:251-256).
+- **Impact :** Sur mobile, un manager peut passer un avoir en 'Reçu' (ce qui déclenche le webhook), modifier un avoir validé ou déplacer un avoir vers un magasin qu'il ne gère pas. Le comportement diffère entre bureau et mobile.
+- **Recommandation :** Appliquer ces règles dans le PUT : 403 si le rôle est manager et que le statut passe à 'Reçu' ; 409 si existingAvoir.nocodbVerified et que le rôle n'est pas admin ; vérifier userGroupIds.includes(validatedData.groupId) quand groupId change.
+
+### MOB-AVOIRS-03
+
+**Menu de statut sans indication de l'état courant ni restrictions** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/AvoirsPage.tsx:239`
+- **Constat :** Les trois entrées 'Marquer En attente', 'Marquer Demandé' et 'Marquer Reçu' sont toujours affichées, y compris pour le statut courant (l.239-256). Aucun contrôle du rôle manager ni de nocodbVerified, contrairement au bureau (Avoirs.tsx:464-481, 1005-1007).
+- **Impact :** Clics inutiles et transitions non autorisées. Un 'Reçu' accidentel déclenche le webhook externe.
+- **Recommandation :** Afficher sur la carte un bouton visible pour la seule étape suivante ('Marquer comme demandé' puis 'Marquer comme reçu'), avec confirmation pour 'Reçu'. Masquer ces actions pour les avoirs validés.
+
+### MOB-AVOIRS-04
+
+**Le changement de statut envoie l'objet avoir complet avec ses relations** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/AvoirsPage.tsx:241`
+- **Constat :** updateStatusMutation.mutate({ id: avoir.id, data: { ...avoir, status: 'Reçu' } }) (l.239-256). L'objet avoir contient supplier, group (toutes ses colonnes, logo base64 compris, via getAvoirs) et creator.
+- **Impact :** Un corps de requête qui peut atteindre plusieurs centaines de Ko sur réseau mobile, simplement pour changer un statut, et journalisé 3 fois côté serveur.
+- **Recommandation :** Envoyer { supplierId, groupId, invoiceReference: avoir.invoiceReference ?? '', amount: avoir.amount ?? null, comment: avoir.comment ?? '', commercialProcessed: !!avoir.commercialProcessed, status }. Passer à { status } seul une fois AVOIRS-API-06 corrigé.
+
+### MOB-AVOIRS-05
+
+**Montant forcé à 0 € lors d'une création sur mobile** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/AvoirsPage.tsx:135`
+- **Constat :** amount: z.coerce.number().optional() (l.65) et defaultValues: { ..., amount: 0, ... } (l.135). z.coerce convertit aussi un champ vidé ('') en 0. L'affichage {avoir.amount && (<span>{parseFloat(avoir.amount).toFixed(2)} €</span>)} (l.224-228) reçoit le décimal sous forme de chaîne '0.00', qui est truthy.
+- **Impact :** Tout avoir créé sur mobile sans montant est enregistré à 0,00 € au lieu de 'non spécifié'. Le mobile affiche '0.00 €' et le bureau aussi, au lieu de 'Non spécifié'.
+- **Recommandation :** Mettre amount: '' par défaut plutôt que undefined, pour éviter l'avertissement React sur le passage d'un champ non contrôlé à contrôlé. Utiliser amount: z.preprocess(v => v === '' || v == null ? undefined : v, z.coerce.number().optional()).
+
+### MOB-AVOIRS-06
+
+**Erreurs de validation invisibles dans le formulaire mobile** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/AvoirsPage.tsx:46`
+- **Constat :** Seuls Form, FormControl, FormField, FormItem et FormLabel sont importés (l.46-52) : il n'y a aucun FormMessage. Le schéma contient pourtant supplierId: z.coerce.number().min(1, 'Fournisseur requis') (l.63).
+- **Impact :** Un tap sur 'Créer la demande' sans fournisseur ne produit rien : ni message ni retour visuel.
+- **Recommandation :** Ajouter <FormMessage /> sous chaque champ, et un toast d'erreur lorsque la soumission est invalide.
+
+### MOB-AVOIRS-07
+
+**Requêtes /api/user répétées et cascade avant le chargement des avoirs** — perf-client, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/mobile/AvoirsPage.tsx:72`
+- **Constat :** const { user } = useAuthUnified(); (l.72) et enabled: !!selectedStoreId && !!user (l.88). En production, useAuthUnified exécute fetch('/api/user', { cache: 'no-cache' }) dans un useEffect à chaque montage (useAuthUnified.ts:147-217). MobileLayout appelle aussi useAuthUnified (MobileLayout.tsx:22).
+- **Impact :** Chaque ouverture de la page coûte 2 requêtes /api/user supplémentaires, et la liste attend l'une d'elles, soit un aller-retour de plus sur réseau mobile (souvent 200 à 500 ms en 4G).
+- **Recommandation :** Exposer l'utilisateur via un contexte, ou via le cache react-query rempli une seule fois (setQueryData(['/api/user'])) avec un staleTime long. Retirer la condition sur user dans enabled.
+
+### AVOIRS-16
+
+**Compteurs affichés trois fois et deux composants Tabs séparés** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:1168`
+- **Constat :** Badges '{pendingAvoirs.length} en cours' et '{completedAvoirs.length} finalisés' dans l'en-tête (l.1168-1173), mêmes compteurs dans les onglets (l.1200-1209), puis '{filteredPendingAvoirs.length} éléments' et '{filteredCompletedAvoirs.length} éléments' dans l'en-tête de la carte (l.1239, 1256). Deux <Tabs value={activeTab}> distincts (l.1195 et l.1233).
+- **Impact :** Surcharge visuelle : la même information répétée trois fois, sans valeur ajoutée.
+- **Recommandation :** Ne garder que les compteurs des onglets. Utiliser un seul composant Tabs englobant TabsList et TabsContent. Supprimer le CardHeader redondant.
+
+### AVOIRS-17
+
+**Formats incohérents : « #Sans référence », montants « 12.50 € », couleur CSS invalide** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:1012`
+- **Constat :** #{avoir.invoiceReference || 'Sans référence'} (l.1012) affiche '#Sans référence'. `${Number(avoir.amount).toFixed(2)} €` (l.1025) donne '12.50 €' au lieu de '12,50 €'. backgroundColor: avoir.group?.color || '#gray' (l.1018) n'est pas une couleur CSS valide. Abréviation 'Sans réf.' (l.1057).
+- **Impact :** Rendu peu professionnel, et le point décimal trouble des utilisateurs francophones.
+- **Recommandation :** Créer un helper partagé formatEuro = new Intl.NumberFormat('fr-FR', { style: 'currency', currency: 'EUR' }). Afficher '—' quand il n'y a pas de référence. Utiliser '#9CA3AF' comme couleur de repli.
+
+### AVOIRS-18
+
+**La règle « un admin peut modifier un avoir validé » est inaccessible depuis le menu de statut** — bug, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:997`
+- **Constat :** handleStatusChange laisse passer l'admin : if (avoir?.nocodbVerified && (user as any)?.role !== 'admin') (l.464). Mais le Select porte disabled={avoir.nocodbVerified} pour tous les rôles (l.997). Le bouton Modifier, lui, reste autorisé pour l'admin sur un avoir validé (l.1114).
+- **Impact :** Comportement incohérent : l'admin doit passer par la modale d'édition pour changer le statut.
+- **Recommandation :** Trancher la règle métier : soit disabled={avoir.nocodbVerified && role !== 'admin'}, soit supprimer la branche admin devenue inutile dans handleStatusChange.
+
+### AVOIRS-19
+
+**Double marquage du cache lors de la validation, et validation hors useMutation** — perf-api, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:510`
+- **Constat :** handleValidateAvoir appelle await apiRequest(`/api/avoirs/${avoirId}/nocodb-verification`, 'PUT', { verified: true }) puis await apiRequest('/api/cache/mark-reconciled', 'POST', {...}) (l.502-513). Or la route PUT nocodb-verification exécute déjà invoiceVerificationService.updateCacheAsReconciled(...) (server/routes.ts:4101-4110). Ces fonctions async ne passent pas par useMutation : aucun état 'en cours', et un double clic envoie deux requêtes.
+- **Impact :** Un aller-retour inutile à chaque validation (avec 3 requêtes BD), et des doubles soumissions possibles.
+- **Recommandation :** Supprimer l'appel à mark-reconciled. Passer la validation dans un useMutation et désactiver le bouton pendant isPending.
+
+### AVOIRS-20
+
+**Timer du modal d'attente jamais nettoyé, et modal fermable pendant l'envoi** — bug, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:746`
+- **Constat :** const interval = setInterval(() => { setProcessingSeconds(prev => prev + 1); }, 1000); setProcessingTimeout(interval); (l.746-752), sans nettoyage dans un useEffect au démontage. <Dialog open={showWaitingModal} onOpenChange={handleCloseWaitingModal}> (l.1683) permet de fermer avec Échap ou un clic extérieur alors que le fetch continue. En cas d'erreur, setShowAvoirModal(true) (l.859) rouvre la modale de sélection.
+- **Impact :** L'intervalle continue de tourner si l'utilisateur change de page. Les états affichés deviennent confus si la modale est fermée pendant l'envoi.
+- **Recommandation :** Stocker l'intervalle dans un useRef (intervalRef.current), le nettoyer dans handleCloseWaitingModal via la ref et dans un useEffect de démontage, et supprimer l'état processingTimeout. Pour la modale d'attente, ajouter onInteractOutside et onEscapeKeyDown avec preventDefault tant que isUploading, et masquer la croix de fermeture pendant l'envoi.
+
+### AVOIRS-21
+
+**Code mort, imports inutilisés et typage faible** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Avoirs.tsx:882`
+- **Constat :** getStatusVariant (l.882-893) et getStatusIcon (l.896-907) ne sont jamais appelés. Imports inutilisés : Send et Settings (l.3), DialogTrigger et DialogFooter (l.10). key={avoir?.id || Math.random()} (l.989). (user as any) est répété une quinzaine de fois. Le montant d'édition est géré hors react-hook-form, via editAmountValue (l.135, 1536-1546).
+- **Impact :** 1731 lignes difficiles à maintenir, ce qui augmente le risque de régression lors de la refonte UX.
+- **Recommandation :** Partie automatisable uniquement : supprimer getStatusVariant et getStatusIcon, ainsi que les imports Send, Settings, DialogTrigger, DialogFooter et AlertCircle (ce dernier devient inutilisé, Clock reste utilisé l.1198), et remplacer key par avoir.id. Typer user avec UserWithGroups, pas User. Le passage du montant en FormField et le découpage en composants se font à part, sans automatisation.
+
+### AVOIRS-22
+
+**Pages Avoirs (bureau et mobile) chargées dans le bundle initial** — perf-bundle, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:26`
+- **Constat :** import Avoirs from '@/pages/Avoirs'; (l.26) et import MobileAvoirsPage from '@/pages/mobile/AvoirsPage'; (l.44) sont des imports statiques. Aucun React.lazy dans client/src. manualChunks ne sépare que les dépendances (vite.config.ts:41-46).
+- **Impact :** Les 1731 lignes de la page, plus react-hook-form, zod et date-fns, sont téléchargées par tous les utilisateurs, y compris ceux qui n'ouvrent jamais les avoirs. Les versions bureau et mobile sont toutes deux téléchargées.
+- **Recommandation :** const Avoirs = lazy(() => import('@/pages/Avoirs')), et de même pour MobileAvoirsPage, avec un <Suspense> qui affiche un skeleton.
+
+### AVOIRS-API-08
+
+**Périmètre du directeur incohérent d'une route avoirs à l'autre** — bug, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:3721`
+- **Constat :** GET /api/avoirs : admin comme directeur voient tous les magasins quand aucun storeId n'est passé (l.3721-3722). verify-invoice refuse tout non-admin hors de ses groupes (l.4002-4013). DELETE vérifie le groupe du directeur (l.3965-3970). nocodb-verification ne vérifie aucun groupe (l.4093-4098). /api/groups ne renvoie au directeur que ses propres groupes (l.978-985).
+- **Impact :** Un directeur voit les avoirs des autres magasins, mais leur vérification renvoie un 403 avalé sans message par la boucle (Avoirs.tsx:226-228). Le formulaire ne propose pas ces magasins, et le directeur peut valider n'importe quel avoir par son identifiant.
+- **Recommandation :** Centraliser le calcul dans un helper getAccessibleGroupIds(user), utilisé par toutes les routes /api/avoirs*.
+
+### AVOIRS-API-09
+
+**verify-invoice recharge des données déjà disponibles et ne met pas en cache les résultats négatifs** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/invoiceVerification.ts:285`
+- **Constat :** La route charge déjà l'avoir avec son groupe (routes.ts:3990, getAvoir joint groups), puis verifyInvoice exécute à nouveau const group = await storage.getGroup(groupId); (invoiceVerification.ts:285) et storage.getActiveNocodbConfig() (l.360) à chaque appel. getInvoiceVerificationCache supprime les entrées expirées une par une (storage.ts:1730-1731). Chaque appel exécute aussi getUserWithGroups, soit 2 requêtes (storage.ts:371-388). Le résultat 'Configuration NocoDB manquante' n'est pas mis en cache (invoiceVerification.ts:302-309).
+- **Impact :** Environ 6 requêtes BD par vérification, multipliées par N avoirs dans la boucle du client.
+- **Recommandation :** Ajouter un paramètre optionnel group à verifyInvoice, sans casser les autres appelants (deliveries, /api/verify-invoice). Mémoriser getActiveNocodbConfig (TTL 5 min) et l'invalider dans les routes de mise à jour NocoDB. Mettre en cache le résultat « pas de configuration » avec un TTL court (environ 5 min), invalidé à la mise à jour du magasin.
+
+### MOB-AVOIRS-08
+
+**Données de référence chargées inutilement et tri redondant** — perf-client, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/mobile/AvoirsPage.tsx:91`
+- **Constat :** La requête suppliers part au montage (l.91-94) alors qu'elle ne sert que dans la feuille de création. La requête groups (l.96-99) double les stores déjà fournis par StoreContext (MobileApp.tsx:29-32). const sortedAvoirs = [...avoirs].sort((a: any, b: any) => new Date(b.createdAt).getTime() - new Date(a.createdAt).getTime()); (l.158) trie à chaque rendu une liste que le serveur renvoie déjà triée DESC (storage.ts:2565). Le filtre est recalculé à chaque frappe, sans useMemo (l.160-163).
+- **Impact :** Requêtes et calculs inutiles à chaque ouverture et à chaque frappe sur un téléphone.
+- **Recommandation :** Supprimer le tri. Mémoïser le filtre avec useMemo. Remplacer la requête groups par stores de useStore() (même données). Charger les fournisseurs avec enabled: isCreateOpen et un staleTime de 10 min, en acceptant un court instant de liste vide à l'ouverture de la feuille, ou précharger au clic sur le bouton +.
+
+### MOB-AVOIRS-09
+
+**Libellés, couleurs et statuts différents de la version bureau** — coherence-design, sévérité basse, effort M
+
+- **Fichier :** `client/src/pages/mobile/AvoirsPage.tsx:180`
+- **Constat :** Titre 'Suivi des Avoirs' en indigo (l.179-180), contre 'Gestion des Avoirs' en bleu au bureau (Avoirs.tsx:1159-1161). Badge 'En attente' (l.167) contre 'En attente de demande'. 'Vérifié Compta' (l.277) contre 'Validé' (Avoirs.tsx:1040). 'Déjà traité par commercial' (l.375) contre 'Avoir fait par commercial' (Avoirs.tsx:1415). Pas de séparation En cours / Finalisés. Date au format 'dd/MM' sans année (l.214). Abréviation 'Réf. Facture' (l.332). Spinner au chargement (l.196-199), contre un skeleton au bureau (Avoirs.tsx:932-941).
+- **Impact :** Un utilisateur qui passe du téléphone au PC doit réapprendre les termes. Les dates des avoirs anciens sont ambiguës.
+- **Recommandation :** Créer un module partagé shared/avoirStatus.ts (libellés et couleurs) et un composant StatusBadge commun. Ajouter des onglets ou des chips 'En cours / Finalisés' sur mobile. Afficher les dates en dd/MM/yy. Utiliser des cartes skeleton.
+
+### MOB-AVOIRS-10
+
+**Imports inutilisés, typage any et schéma dupliqué** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/mobile/AvoirsPage.tsx:19`
+- **Constat :** Filter, AlertCircle, Clock et Ban sont importés (l.19-25) mais pas utilisés. useForm n'est pas typé, et on trouve (data: any) et (a: any) aux l.103, 142, 158-163 et 206. Le schéma zod est dupliqué par rapport au bureau (Avoirs.tsx:76-101) et a divergé : pas de groupId, montant traité différemment.
+- **Impact :** Les écarts de comportement entre bureau et mobile se multiplient.
+- **Recommandation :** Partie automatisable : supprimer les imports Filter, AlertCircle, Clock et Ban. Le partage du schéma (insertAvoirSchema.omit({createdBy}), traitement du montant) se fait à part, sans automatisation.

docs/audit-webui/05-tasks.md

@@ -0,0 +1,434 @@
+# Tâches
+
+_36 constats vérifiés — 6 haute, 25 moyenne, 5 basse._
+
+## Pages analysées
+
+### `/tasks (desktop et tablette, largeur >= 768px)`
+
+**Rôle :** Lister, filtrer, créer, modifier, terminer et supprimer les tâches du magasin sélectionné (liste paginée ou vue Kanban), avec des dates de début (visibilité programmée) et d'échéance.
+
+**Tâches principales de l'utilisateur :**
+- Voir les tâches à faire aujourd'hui ou en retard
+- Marquer une tâche comme terminée
+- Créer une tâche (titre, priorité, dates, personne assignée)
+- Modifier ou supprimer une tâche
+- Filtrer par statut, priorité, échéance et rechercher
+- Basculer entre Liste et Kanban
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/user | au montage, une fois par composant qui appelle useAuthUnified/useAuthSimple (RouterProduction, Layout, Sidebar, Tasks), soit 4 appels, sans cache partagé (cache: 'no-cache') | server/localAuth.production.ts:246 (req.user déjà chargé par deserializeUser l.193-195 → storage.getUserWithGroups storage.ts:371, 2 requêtes SQL) | La requête des tâches attend la fin de l'appel /api/user propre à Tasks (enabled: !!user) : chargement en cascade. |
+| GET /api/tasks?storeId=X | au montage (enabled: !!user) + invalidation forcée par useEffect au montage et à chaque changement de magasin (Tasks.tsx:299-308) + invalidation par le sélecteur de magasin de Layout (Layout.tsx:138-146) | server/routes.ts:3193 → storage.getUserWithGroups (storage.ts:371, 2 requêtes) + storage.getTasks (storage.ts:2267, LEFT JOIN groups sur toutes les colonnes) | Aucune limite ni pagination. Chaque tâche embarque la ligne magasin complète, logo base64 compris. Renvoie [] pour un non-admin sans storeId. 6 console.log par appel. |
+| GET /api/users | au montage pour admin/manager/directeur (Tasks.tsx:385-396), résultat jamais utilisé | server/routes.ts:4268 → storage.getUsers (storage.ts:409, SELECT * avec password) + N x storage.getUserWithGroups (2 requêtes par utilisateur) | Requête inutile en N+1 qui renvoie aussi les hash de mots de passe au navigateur. |
+| POST /api/tasks | au clic sur Créer (fetch manuel dans TaskFormInline) puis window.location.reload() | server/routes.ts:3277 → storage.getUserWithGroups + storage.createTask (storage.ts:2365) | Pas de validation zod (insertTaskSchema inutilisé). Groupe 1 par défaut. Corps complet loggé. |
+| PUT /api/tasks/:id | au clic sur Modifier (fetch manuel) puis window.location.reload() | server/routes.ts:3340 → getUserWithGroups + storage.getTask (storage.ts:2348, jointure groups complète) + storage.updateTask (storage.ts:2392) | Pas de contrôle hasPermission (seule l'appartenance au magasin est vérifiée). |
+| DELETE /api/tasks/:id | au clic sur Supprimer dans la modale de confirmation | server/routes.ts:3425 → getUserWithGroups + storage.getTask + storage.deleteTask (storage.ts:2470) | Pas de hasPermission : un manager ou un employé peut supprimer. Le client attend le rechargement complet de la liste avant de fermer la modale. |
+| POST /api/tasks/:id/complete | au clic sur l'icône Terminer | server/routes.ts:3455 → getUserWithGroups + storage.getTask + storage.completeTask (storage.ts:2474) | Renvoie un simple message, pas la tâche mise à jour : le client doit recharger toute la liste. |
+
+**Lisibilité / simplicité :** Page lourde et dense : chaque carte empile jusqu'à 7 informations (priorité, badge Future, '(Programmée)', 'Visible en avance (directeur)', badge début '📅 Active' avec texte, badge échéance '⏰', 'Créée le' avec l'heure, 'Assigné à: Non assigné'). Emojis et icônes lucide se doublent dans les mêmes badges. Sur desktop, les actions sont des icônes sans libellé ni infobulle. Un bug de date affiche 'En retard de 0 jour' pour les tâches dues aujourd'hui et 'Dans 0 jour' pour celles de demain. Les compteurs 'Tâches en cours (n)' ne portent que sur la page courante. Les tâches terminées sont presque illisibles (opacité 60 %, gris 400, texte barré). Sur tablette (768-1023 px), la recherche et les filtres sont inaccessibles et l'onglet Kanban est vide. Les modales sont faites à la main (pas d'Échap ni de focus) et le formulaire mélange styles inline et Tailwind. L'assignation est un champ texte libre, et un admin en vue 'Tous les magasins' crée la tâche dans le magasin 1 sans le savoir. Les erreurs réseau s'affichent comme 'Aucune tâche trouvée avec les filtres sélectionnés'. Après chaque création ou modification, la page entière est rechargée. Un employé sur desktop ne voit aucune tâche (pas de magasin sélectionné ni sélectionnable). Les droits affichés (supprimer, terminer) ne respectent pas la matrice de permissions.
+
+### `/tasks (mobile, largeur < 768px)`
+
+**Rôle :** Version mobile de la liste des tâches : onglets Actives/Faites/Toutes, recherche, bouton flottant de création, formulaire plein écran, suppression par feuille du bas.
+
+**Tâches principales de l'utilisateur :**
+- Voir les tâches actives du magasin
+- Terminer une tâche
+- Créer ou modifier une tâche depuis le téléphone
+- Rechercher une tâche par titre
+- Supprimer une tâche
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/user | au montage, 5 fois (RouterProduction, MobileApp, MobileLayout, MobileBottomNav, TasksPage), chacun avec son propre fetch | server/localAuth.production.ts:246 | La requête des tâches attend l'appel propre à TasksPage (enabled: !!user). |
+| GET /api/tasks?storeId=X | au montage (enabled: !!user) | server/routes.ts:3193 → storage.getTasks (storage.ts:2267) | Même payload sans limite, avec la ligne magasin complète par tâche. Tout est rendu sans pagination (onglets Faites/Toutes). |
+| POST /api/tasks et PUT /api/tasks/:id | à la soumission du formulaire plein écran puis window.location.reload() | server/routes.ts:3277 / 3340 | Le formulaire mobile n'a ni date de début ni statut. |
+| POST /api/tasks/:id/complete | au clic sur Terminer (visible pour tous les rôles) | server/routes.ts:3455 | response.ok n'est pas vérifié : un toast de succès s'affiche même en cas d'erreur 403 ou 500. |
+| DELETE /api/tasks/:id | au clic sur Supprimer dans la feuille du bas | server/routes.ts:3425 | response.ok n'est pas vérifié non plus. |
+
+**Lisibilité / simplicité :** Plus simple et plus lisible que le desktop (cartes compactes, gros boutons, onglets). Plusieurs écarts : vocabulaire différent ('Actives/Faites' contre 'En cours/Terminées'), couleurs de priorité différentes (rouge/jaune/vert contre rouge/bleu/gris), recherche sur le titre seulement (titre + description sur desktop). Les tâches programmées ne sont pas distinguées et peuvent être 'terminées'. 'Terminer' est proposé à tous les rôles alors que le desktop le réserve aux managers et plus. Le formulaire n'a pas de date de début. Les boutons icône (modifier, supprimer, +) n'ont pas de libellé accessible. Le toast de succès s'affiche même si l'API échoue. Spinner pendant le chargement, page entière rechargée après enregistrement, double marge horizontale (p-3 puis px-3).
+
+### `(aucune route : code mort) client/src/components/tasks/* et client/src/components/ResponsiveTasks.tsx`
+
+**Rôle :** Six variantes successives du formulaire de tâche, une carte 'tâches récentes' et un wrapper responsive. Aucun n'est importé par l'application (vérifié par grep sur tout le dépôt).
+
+**Tâches principales de l'utilisateur :**
+- Aucune : composants non montés
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/groups, POST /api/tasks, PUT/PATCH /api/tasks/:id, GET /api/tasks | jamais (composants non importés) | server/routes.ts:3277 / 3340 (aucune route PATCH /api/tasks/:id n'existe) | TaskFormClean, SimpleTaskFormClean, TaskFormProduction et TaskFormUltraSimple appellent PATCH, qui renverrait une erreur. groupId 1 et createdBy 'admin' sont codés en dur. 2030 lignes au total. |
+
+**Lisibilité / simplicité :** Sans effet sur l'utilisateur aujourd'hui. C'est de la dette : six formulaires divergents (alert() natif, PATCH inexistant, magasin 1 codé en dur), alors que le formulaire réellement utilisé est encore un septième, écrit en ligne dans Tasks.tsx, plus un huitième dans la page mobile.
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [TASKS-01](#tasks-01) | haute | perf-api | S | Chaque tâche embarque la ligne magasin complète (logo base64, config NocoDB/SMTP) | `server/storage.ts:2271` |
+| [TASKS-02](#tasks-02) | haute | bug | S | Un employé sur desktop ne voit jamais aucune tâche | `client/src/components/Layout.tsx:69` |
+| [TASKS-03](#tasks-03) | haute | perf-client | S | Rechargement complet de la page après chaque création ou modification | `client/src/pages/Tasks.tsx:120` |
+| [TASKS-07](#tasks-07) | haute | perf-api | S | Requête /api/users inutile (jamais utilisée), en N+1 côté serveur, qui expose les mots de passe hashés | `client/src/pages/Tasks.tsx:385` |
+| [TASKS-09](#tasks-09) | haute | bug | S | Sur tablette, la recherche et les filtres sont inaccessibles et le Kanban est vide | `client/src/pages/Tasks.tsx:697` |
+| [TASKS-13](#tasks-13) | haute | bug | S | Droits incohérents entre la matrice de permissions, l'interface et l'API (supprimer, terminer, modifier) | `server/routes.ts:3425` |
+| [TASKS-04](#tasks-04) | moyenne | perf-api | S | Utilisateur et magasins rechargés en base à chaque requête alors que req.user les contient déjà | `server/routes.ts:3195` |
+| [TASKS-05](#tasks-05) | moyenne | perf-client | S | Invalidation forcée au montage et au changement de magasin : 2 à 3 requêtes /api/tasks au lieu d'une | `client/src/pages/Tasks.tsx:299` |
+| [TASKS-06](#tasks-06) | moyenne | bug | S | Même queryKey ['/api/tasks', storeId] pour deux URL différentes (Dashboard et Tasks) | `client/src/pages/Dashboard.tsx:282` |
+| [TASKS-08](#tasks-08) | moyenne | perf-client | M | Chargement en cascade /api/user puis /api/tasks, avec un faux 'Aucune tâche' affiché pendant l'attente | `client/src/hooks/useAuthUnified.ts:146` |
+| [TASKS-10](#tasks-10) | moyenne | perf-client | M | Toute la liste est rendue deux fois (version tablette et version desktop montées, l'une cachée en CSS) | `client/src/pages/Tasks.tsx:851` |
+| [TASKS-11](#tasks-11) | moyenne | bug | S | Les filtres 'Aujourd'hui', 'Cette semaine' et 'En retard' incluent les tâches sans échéance | `client/src/pages/Tasks.tsx:491` |
+| [TASKS-12](#tasks-12) | moyenne | bug | S | Une tâche due aujourd'hui s'affiche 'En retard de 0 jour', une tâche due demain 'Dans 0 jour' | `client/src/pages/Tasks.tsx:580` |
+| [TASKS-14](#tasks-14) | moyenne | ux-simplicite | S | Compteurs 'Tâches en cours (n)' et 'Tâches terminées (n)' calculés sur la page courante seulement | `client/src/pages/Tasks.tsx:1189` |
+| [TASKS-15](#tasks-15) | moyenne | accessibilite | S | Actions en icônes seules sans libellé, infobulle ni aria-label | `client/src/pages/Tasks.tsx:1296` |
+| [TASKS-16](#tasks-16) | moyenne | accessibilite | S | Modales faites à la main au lieu du Dialog shadcn importé (pas d'Échap, pas de focus, pas de rôle) | `client/src/pages/Tasks.tsx:732` |
+| [TASKS-17](#tasks-17) | moyenne | coherence-design | M | Formulaire mêlant styles inline (angles carrés, fond blanc forcé) et classes Tailwind arrondies avec mode sombre | `client/src/pages/Tasks.tsx:135` |
+| [TASKS-18](#tasks-18) | moyenne | coherence-design | S | Couleurs de priorité, vocabulaire et icônes différents entre desktop et mobile | `client/src/pages/Tasks.tsx:544` |
+| [TASKS-19](#tasks-19) | moyenne | lisibilite | M | Cartes surchargées : jusqu'à 7 informations redondantes par tâche, avec le rôle technique affiché | `client/src/pages/Tasks.tsx:1212` |
+| [TASKS-20](#tasks-20) | moyenne | accessibilite | S | Tâches terminées quasi illisibles (opacité 60 % + gris 400 + texte barré) | `client/src/pages/Tasks.tsx:1350` |
+| [TASKS-21](#tasks-21) | moyenne | ux-simplicite | M | Formulaire : assignation en texte libre, magasin implicite (magasin 1 pour un admin) et aucune vérification des dates | `client/src/pages/Tasks.tsx:90` |
+| [TASKS-22](#tasks-22) | moyenne | ux-simplicite | S | Erreurs de chargement et absence de magasin affichées comme 'Aucune tâche trouvée avec les filtres sélectionnés' | `client/src/pages/Tasks.tsx:326` |
+| [TASKS-23](#tasks-23) | moyenne | perf-client | S | Spinner plein écran à chaque changement de magasin, faute de placeholderData et de squelette | `client/src/pages/Tasks.tsx:670` |
+| [TASKS-24](#tasks-24) | moyenne | perf-client | M | Terminer et Supprimer passent par des fetch manuels qui attendent le rechargement complet de la liste avant tout retour visuel | `client/src/pages/Tasks.tsx:405` |
+| [TASKS-25](#tasks-25) | moyenne | bug | S | Mobile : 'Tâche terminée' ou 'Tâche supprimée' affiché même quand l'API refuse ou échoue | `client/src/pages/mobile/TasksPage.tsx:334` |
+| [TASKS-26](#tasks-26) | moyenne | ux-simplicite | S | Mobile : tâches programmées non signalées et 'Terminer' proposé alors que le desktop l'interdit | `client/src/pages/mobile/TasksPage.tsx:215` |
+| [TASKS-27](#tasks-27) | moyenne | perf-api | M | GET /api/tasks sans limite : tout l'historique des tâches terminées (et tous les magasins pour un admin) à chaque chargement | `server/storage.ts:2301` |
+| [TASKS-28](#tasks-28) | moyenne | perf-serveur | S | console.log volumineux dans tous les handlers tâches (corps complets, parcours de toute la liste) | `server/routes.ts:3252` |
+| [TASKS-29](#tasks-29) | moyenne | perf-serveur | S | Index de la table tasks déclarés dans un fichier SQL jamais exécuté, et absents de schema.ts | `server/migrations.ts:112` |
+| [TASKS-31](#tasks-31) | moyenne | dette-code | L | Tasks.tsx (1633 lignes) duplique 6 fois le balisage des cartes et 2 fois les filtres, et le mobile réimplémente tout | `client/src/pages/Tasks.tsx:874` |
+| [TASKS-32](#tasks-32) | moyenne | dette-code | S | Huit composants de formulaire ou de carte de tâche et ResponsiveTasks jamais importés (2030 lignes), dont plusieurs appellent une route PATCH inexistante | `client/src/components/tasks/TaskFormUltraSimple.tsx:38` |
+| [TASKS-30](#tasks-30) | basse | perf-api | S | PUT, DELETE et complete : contrôle d'accès en lecture préalable avec jointure magasin complète, puis écriture (3 à 4 allers-retours) | `server/storage.ts:2348` |
+| [TASKS-33](#tasks-33) | basse | dette-code | S | console.log de debug dans le rendu et le queryFn, imports et variables inutilisés | `client/src/pages/Tasks.tsx:285` |
+| [TASKS-34](#tasks-34) | basse | perf-client | S | Filtrage et tri recalculés à chaque rendu sans useMemo, et sous-filtres répétés dans le JSX | `client/src/pages/Tasks.tsx:472` |
+| [TASKS-35](#tasks-35) | basse | perf-bundle | S | Pages Tâches desktop et mobile importées statiquement dans le bundle principal | `client/src/components/RouterProduction.tsx:24` |
+| [TASKS-36](#tasks-36) | basse | bug | S | Avec server/index.ts (dev et `npm start`), les apostrophes des titres de tâches sont stockées échappées en HTML (&#x27;) | `server/security.ts:202` |
+
+### TASKS-01
+
+**Chaque tâche embarque la ligne magasin complète (logo base64, config NocoDB/SMTP)** — perf-api, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:2271`
+- **Constat :** storage.ts:2271-2277 `db.select({ task: tasks, group: groups }).from(tasks).leftJoin(groups, ...)`. Or shared/schema.ts:67 `logo: text("logo"), // Logo en data URI (data:image/png;base64,...)` et l.53-76 (nocodb*, webhookUrl, smtp*). Côté client, task.group n'est lu nulle part, sauf dans un console.log (Tasks.tsx:364 `hasGroup: !!data[0].group`). En plus, stripSmtpPassword (routes.ts:168) parcourt récursivement chaque objet group.
+- **Impact :** Le logo du magasin (souvent des dizaines de Ko) est répété dans le JSON autant de fois qu'il y a de tâches. Pour 200 tâches, cela fait plusieurs Mo à télécharger et à parser, en desktop comme en mobile (et sur le Dashboard, qui appelle le même endpoint). Aucun gzip n'est actif : server/cache.ts:96 ne fait que poser l'en-tête.
+- **Recommandation :** Partie automatisable : projeter les colonnes dans getTasks et getTask (`group: { id: groups.id, name: groups.name, color: groups.color }`), en gardant la forme `{...task, group, isFutureTask}` renvoyée au client. Ajouter `compression` dans index.production.ts est une étape séparée : nouvelle dépendance npm, et il faut vérifier qu'aucun reverse proxy ne compresse déjà. Ne pas réutiliser setupCompression de cache.ts, qui est défectueux.
+
+### TASKS-02
+
+**Un employé sur desktop ne voit jamais aucune tâche** — bug, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/Layout.tsx:69`
+- **Constat :** Layout.tsx:69 : la sélection automatique du magasin n'existe que pour `(user.role === 'directeur' || user.role === 'manager') && !selectedStoreId && stores.length === 1`. Layout.tsx:131 : le sélecteur de magasin n'est affiché que pour `admin || directeur || manager`. Côté serveur, routes.ts:3237-3248, sans storeId pour un non-admin : `return res.json([]);`
+- **Impact :** Sans selectedStoreId déjà en localStorage, un employé arrive sur 'Aucune tâche trouvée avec les filtres sélectionnés' et n'a aucun moyen d'en sortir. Il ne voit pas les tâches qu'on lui a assignées.
+- **Recommandation :** Corriger côté client uniquement : dans Layout.tsx et MobileApp.tsx, auto-sélectionner l'unique magasin pour tout rôle non-admin (employee compris), et afficher le sélecteur aux employés qui ont plusieurs magasins. Garder le comportement serveur actuel et afficher un état vide explicite « Choisissez un magasin » quand selectedStoreId est null.
+
+### TASKS-03
+
+**Rechargement complet de la page après chaque création ou modification** — perf-client, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Tasks.tsx:120`
+- **Constat :** Tasks.tsx:116-120 `toast({ title: "Succès", ... }); window.location.reload();`. Même chose dans mobile/TasksPage.tsx:83-87.
+- **Impact :** Chaque enregistrement recharge tout le bundle JS, refait les 4 ou 5 appels /api/user, /api/groups, /api/tasks, etc. L'écran devient blanc 1 à 3 s et le toast de succès disparaît immédiatement. La position de pagination, les filtres et la recherche sont perdus.
+- **Recommandation :** Dans TaskFormInline et MobileTaskForm, remplacer `window.location.reload()` par `await queryClient.invalidateQueries({ queryKey: ['/api/tasks'] }); onClose();` (useQueryClient), puis réactiver le bouton en cas d'erreur, comme aujourd'hui. Pas de setQueryData à partir de la réponse du POST ou du PUT.
+
+### TASKS-07
+
+**Requête /api/users inutile (jamais utilisée), en N+1 côté serveur, qui expose les mots de passe hashés** — perf-api, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:385`
+- **Constat :** Tasks.tsx:385 `const { data: users = [] } = useQuery({ queryKey: ["/api/users"], ... enabled: !!user && (admin||manager||directeur) })`. `users` n'est utilisé nulle part dans le fichier (vérifié par grep). Côté serveur, routes.ts:4276-4282 `const baseUsers = await storage.getUsers(); ... baseUsers.map(async (baseUser) => { const userWithGroups = await storage.getUserWithGroups(baseUser.id);`, soit 2 requêtes par utilisateur. Et storage.ts:409 `db.select().from(users)` inclut la colonne password (schema.ts:40).
+- **Impact :** Chaque ouverture de la page Tâches par un manager lance 2N+3 requêtes SQL pour rien et envoie au navigateur la liste de tous les utilisateurs avec leurs hash de mot de passe.
+- **Recommandation :** Partie automatisable : supprimer la useQuery '/api/users' de Tasks.tsx (aucun lecteur). Retirer `password` de la réponse de GET /api/users est une correction de sécurité à part, à traiter hors du périmètre tâches. Remplacer la boucle N+1 par une jointure demande une réécriture manuelle.
+
+### TASKS-09
+
+**Sur tablette, la recherche et les filtres sont inaccessibles et le Kanban est vide** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:697`
+- **Constat :** Tasks.tsx:697 : le bouton Filtres a `className="sm:hidden ..."`, il est donc caché dès 640 px. l.761 `${filtersOpen ? 'block' : 'hidden'} lg:hidden` : filtersOpen ne peut jamais passer à true. l.852-1089 : la zone tablette `block lg:hidden` ne contient que `<TabsContent value="list">`, alors que l'onglet Kanban (l.712) reste cliquable. Le routeur envoie vers cette page toute largeur >= 768 px (RouterProduction.tsx:107, use-screen-size.ts mobile: 768).
+- **Impact :** Sur une tablette de magasin (iPad 768-1024 px), l'utilisateur ne peut ni chercher ni filtrer. S'il clique sur 'Kanban', l'écran devient vide.
+- **Recommandation :** Remplacer `sm:hidden` par `lg:hidden` sur le bouton Filtres (ou afficher les filtres en ligne au-dessus de la liste en dessous de lg), et ajouter le TabsContent kanban dans la zone tablette. Mieux : un seul rendu (voir TASKS-10).
+
+### TASKS-13
+
+**Droits incohérents entre la matrice de permissions, l'interface et l'API (supprimer, terminer, modifier)** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/routes.ts:3425`
+- **Constat :** shared/permissions.ts:85-90 : `manager: ['view','create','edit','validate']` (pas de delete), `employee: ['view']`. Pourtant Tasks.tsx:668 `canEditTasks = admin||manager||directeur` affiche Supprimer aux managers. Tasks.tsx:1385-1394 : le bouton Supprimer des tâches terminées n'est conditionné par aucun droit (visible pour les employés). mobile/TasksPage.tsx:254 : 'Terminer' est affiché à tous (`{!isCompleted && (`). Côté serveur, PUT (routes.ts:3340), DELETE (3425) et complete (3455) ne vérifient que l'appartenance au magasin, jamais `hasPermission(user.role, 'tasks', ...)`. Seul le POST le fait (l.3285).
+- **Impact :** Un employé peut supprimer des tâches terminées depuis le desktop, terminer n'importe quelle tâche depuis le mobile et modifier des tâches via l'API. Un manager peut supprimer. Le comportement change selon l'appareil utilisé.
+- **Recommandation :** Côté serveur, ajouter `hasPermission(user.role,'tasks','edit'|'delete'|'validate')` dans PUT, DELETE et complete. Côté client, dériver canCreate, canEdit, canDelete et canComplete de `hasPermission` (shared/permissions.ts) dans les deux pages, et décider avec le métier si l'employé peut 'Terminer' (permission 'validate').
+
+### TASKS-04
+
+**Utilisateur et magasins rechargés en base à chaque requête alors que req.user les contient déjà** — perf-api, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:3195`
+- **Constat :** localAuth.production.ts:193-195 : deserializeUser fait déjà `await storage.getUserWithGroups(id)`. Chaque handler tâches le refait : routes.ts:3195, 3279, 3342, 3427, 3457 `const user = await storage.getUserWithGroups(req.user.claims ? req.user.claims.sub : req.user.id);`. getUserWithGroups (storage.ts:371-388) enchaîne lui-même 2 requêtes : getUser puis user_groups JOIN groups.
+- **Impact :** 4 allers-retours SQL séquentiels avant la vraie requête, sur chaque appel tâches. Cela ajoute plusieurs dizaines de ms de latence à chaque chargement et à chaque clic Terminer ou Supprimer.
+- **Recommandation :** Dans les 5 handlers tâches, remplacer l'appel par `const user = req.user as UserWithGroups;` (la donnée est identique, chargée par localAuth.ts:141-144 pour la même requête). Ne pas mettre en cache l'utilisateur ni ses permissions. La fusion de getUser et user_groups en une seule requête est une optimisation distincte, à faire à la main.
+
+### TASKS-05
+
+**Invalidation forcée au montage et au changement de magasin : 2 à 3 requêtes /api/tasks au lieu d'une** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:299`
+- **Constat :** Tasks.tsx:299-308 `useEffect(() => { if (user && (directeur||manager) && selectedStoreId) { ... queryClient.invalidateQueries({ queryKey: ["/api/tasks"] }); } }, [selectedStoreId, user, queryClient]);`. La queryKey contient déjà selectedStoreId (l.327). Layout.tsx:138-146 invalide aussi '/api/tasks' (l'ancien magasin, encore actif) avant setSelectedStoreId.
+- **Impact :** Pour un directeur ou un manager, chaque visite ignore le cache encore frais (staleTime de 30 s) : la requête initiale est annulée (cancelRefetch par défaut) puis relancée. Un changement de magasin produit un refetch de l'ancien magasin, un fetch du nouveau et un fetch annulé puis relancé, chacun avec le gros payload décrit en TASKS-01.
+- **Recommandation :** Supprimer ce useEffect : le changement de queryKey suffit. Dans Layout, ne pas invalider les clés de l'ancien magasin (le changement de clé déclenche le fetch). Corriger d'abord la collision de clé avec le Dashboard (TASKS-06), qui est probablement à l'origine de ce contournement.
+
+### TASKS-06
+
+**Même queryKey ['/api/tasks', storeId] pour deux URL différentes (Dashboard et Tasks)** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:282`
+- **Constat :** Dashboard.tsx:282-286 `queryKey: ["/api/tasks", selectedStoreId], ... if (selectedStoreId && user?.role === 'admin') params.append("storeId", ...)`. Pour un non-admin, l'appel part donc sans storeId et le serveur renvoie [] (routes.ts:3248). Tasks.tsx:327-333 utilise la même clé mais envoie toujours storeId.
+- **Impact :** Un directeur ou un manager qui passe du Dashboard aux Tâches dans les 30 s reçoit la liste vide mise en cache par le Dashboard. Le 'FORCE REFRESH' de Tasks.tsx:299 masque ce bug au prix de requêtes en double (TASKS-05).
+- **Recommandation :** Créer un hook partagé `useTasks(storeId)` (client/src/hooks/useTasks.ts) avec une seule queryFn qui envoie toujours storeId. L'utiliser dans Dashboard, mobile/DashboardPage, Tasks et mobile/TasksPage, puis supprimer l'invalidation forcée.
+
+### TASKS-08
+
+**Chargement en cascade /api/user puis /api/tasks, avec un faux 'Aucune tâche' affiché pendant l'attente** — perf-client, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/hooks/useAuthUnified.ts:146`
+- **Constat :** useAuthUnified.ts:23-24 et 146-217 : en production, chaque instance du hook a son propre useState et fait `fetch('/api/user', { cache: 'no-cache' })` au montage. Tasks.tsx:381 `enabled: !!user`. Quand la query est désactivée, isLoading vaut false, donc Tasks.tsx:670 ne montre pas le spinner et la page affiche '0 tâche trouvée' (l.689) puis 'Aucune tâche trouvée avec les filtres sélectionnés' (l.855-864 / 1176-1185).
+- **Impact :** Chaque visite paie un aller-retour /api/user supplémentaire (4 en desktop, 5 en mobile) avant que les tâches ne soient demandées. L'utilisateur voit brièvement 'Aucune tâche', ce qui peut l'inquiéter, puis la liste apparaît.
+- **Recommandation :** Faire de useAuthUnified une fine couche au-dessus d'une seule useQuery(['/api/user'], staleTime 5 min) partagée par tous les composants : le user est alors disponible immédiatement à la navigation. Dans Tasks, afficher le squelette tant que `!user || isPending`.
+
+### TASKS-10
+
+**Toute la liste est rendue deux fois (version tablette et version desktop montées, l'une cachée en CSS)** — perf-client, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Tasks.tsx:851`
+- **Constat :** Tasks.tsx:851 `<div className="block lg:hidden">` et l.1093 `<div className="hidden lg:flex gap-6">` : les deux sous-arbres (cartes, filtres, deux champs de recherche liés au même état) sont montés en permanence. Seul le CSS cache l'un des deux.
+- **Impact :** Deux fois plus de nœuds DOM et de calcul à chaque frappe dans la recherche. Les deux copies des cartes appellent format() et les helpers de date. Cela se ressent sur des PC de magasin modestes.
+- **Recommandation :** Utiliser useScreenSize() (déjà présent) pour ne rendre qu'une seule variante, ou mieux, un seul composant responsive <TaskCard> et un seul <TaskFilters>.
+
+### TASKS-11
+
+**Les filtres 'Aujourd'hui', 'Cette semaine' et 'En retard' incluent les tâches sans échéance** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:491`
+- **Constat :** Tasks.tsx:491-509 `if (dueDateFilter !== "all" && task.dueDate) { switch ... } else if (dueDateFilter === "no_due_date" && task.dueDate) { return false; }`. Une tâche avec dueDate null et le filtre 'overdue' passe les deux branches et arrive à `return true`. De plus, l.498 `isThisWeek(dueDate)` est appelé sans `{ weekStartsOn: 1 }`, donc la semaine commence le dimanche.
+- **Impact :** En choisissant 'En retard', le manager voit aussi toutes les tâches sans date, ce qui lui fait croire à du retard. 'Cette semaine' est décalé d'un jour par rapport à la semaine française.
+- **Recommandation :** Au début du bloc : `if (dueDateFilter !== 'all') { if (dueDateFilter === 'no_due_date') return !task.dueDate; if (!task.dueDate) return false; ... }`. Utiliser `isThisWeek(d, { weekStartsOn: 1 })`.
+
+### TASKS-12
+
+**Une tâche due aujourd'hui s'affiche 'En retard de 0 jour', une tâche due demain 'Dans 0 jour'** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:580`
+- **Constat :** schema.ts:312 `dueDate: date("due_date")` renvoie '2026-10-02'. `new Date('2026-10-02')` donne minuit UTC, soit 02:00 à Paris. Tasks.tsx:580 teste `if (isPast(due))` avant `else if (isToday(due))` (l.588) : dès 2 h du matin, la branche 'Aujourd'hui' est inatteignable et le libellé devient `En retard de ${Math.abs(daysDiff)} jour` avec daysDiff = 0. l.578 `differenceInDays(due, now)` tronque : demain 02:00 moins aujourd'hui 15:00 donne 0, d'où 'Dans 0 jour' / '0j'. Le filtre 'overdue' (l.501) range aussi les tâches du jour en retard. Mobile : TasksPage.tsx:203-210, même problème pour 'Dans 0j'.
+- **Impact :** Des badges rouges 'En retard' s'affichent à tort tous les jours et les libellés sont absurdes. Cela détruit la confiance dans l'indicateur principal de la page.
+- **Recommandation :** Parser la date en local avec `parseISO(task.dueDate)` (date-fns), qui donne minuit local, et comparer en jours calendaires : `differenceInCalendarDays(startOfDay(due), startOfDay(new Date()))`, < 0 pour en retard, 0 pour aujourd'hui, 1 pour demain. Mutualiser cette logique dans un helper partagé desktop et mobile.
+
+### TASKS-14
+
+**Compteurs 'Tâches en cours (n)' et 'Tâches terminées (n)' calculés sur la page courante seulement** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:1189`
+- **Constat :** Tasks.tsx:1189-1192 `paginatedTasks.filter(task => task.status === 'pending').length` (idem l.868-871, 1027-1030, 1337-1340). La pagination fait 10 éléments (l.542) sur une liste triée avec les tâches en cours d'abord, donc les terminées n'apparaissent qu'aux dernières pages. usePagination (pagination.tsx:157-159) revient à la page 1 dès que `data.length` change, par exemple après une suppression en page 3.
+- **Impact :** Le titre affiche 'Tâches en cours (10)' alors qu'il y en a 45. Le manager sous-estime la charge. Après chaque suppression, il est renvoyé en page 1.
+- **Recommandation :** Calculer les totaux sur filteredTasks (`pendingCount`, `completedCount`) et les afficher dans le titre ou dans des onglets 'À faire (45) / Terminées (120)'. Paginer chaque section séparément, ou n'afficher les terminées que sur demande. Ne réinitialiser la page que lorsque les filtres changent.
+
+### TASKS-15
+
+**Actions en icônes seules sans libellé, infobulle ni aria-label** — accessibilite, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Tasks.tsx:1296`
+- **Constat :** Tasks.tsx:1296-1325 `<Button size="sm" variant="outline" onClick={() => handleCompleteTask(task.id)} ...><CheckCircle className="w-4 h-4" /></Button>`, même chose pour Edit et Trash2. Kanban l.1471-1494 en h-7 (28 px). Mobile : TasksPage.tsx:267-272 (modifier, supprimer) et le FAB l.449-454 `<Plus />` sans texte.
+- **Impact :** Un employé non technicien doit deviner l'icône. Le coche vert 'Terminer' se confond facilement avec 'Modifier'. Les boutons Kanban de 28 px sont difficiles à viser sur écran tactile. Les lecteurs d'écran annoncent 'bouton' sans nom.
+- **Recommandation :** Partie automatisable : ajouter seulement `aria-label` et `title` ('Terminer la tâche', 'Modifier', 'Supprimer', 'Nouvelle tâche') sur les boutons icône desktop, Kanban et mobile (FAB compris). Libellés visibles, menu « ... » et hauteur de 36 à 44 px : à valider côté design.
+
+### TASKS-16
+
+**Modales faites à la main au lieu du Dialog shadcn importé (pas d'Échap, pas de focus, pas de rôle)** — accessibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:732`
+- **Constat :** Tasks.tsx:12 importe `Dialog, DialogContent, ...`, jamais utilisés. Les modales sont des `<div className="fixed inset-0 bg-black bg-opacity-50 z-[1000] ...">` (l.732, 1568, 1599) avec un bouton `✕` sans aria-label (l.738-744, 1574-1582). Mobile : TasksPage.tsx:96 et 469, même schéma.
+- **Impact :** Échap et le clic sur le fond ne ferment rien. Le focus clavier reste derrière la modale et le scroll de la page n'est pas bloqué. Le style diffère des autres pages qui utilisent Dialog.
+- **Recommandation :** Utiliser `<Dialog open onOpenChange>` + DialogContent/DialogHeader/DialogTitle pour la création et l'édition, AlertDialog pour la suppression (comme les autres pages), et Sheet (side="bottom") en mobile.
+
+### TASKS-17
+
+**Formulaire mêlant styles inline (angles carrés, fond blanc forcé) et classes Tailwind arrondies avec mode sombre** — coherence-design, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Tasks.tsx:135`
+- **Constat :** Tasks.tsx:135 `<div style={{ padding: '24px', backgroundColor: 'white' }}>`. Titre et description : l.155-161 `style={{ ... borderRadius: '0px', fontSize: '14px' }}`. Priorité et dates : l.194 `className="w-full p-3 border ... rounded-md text-base min-h-[44px] ... dark:bg-gray-800"`. Champs HTML natifs au lieu de Input, Select et Textarea shadcn. Bouton de soumission désactivé via `submitBtn.textContent = "..."` (l.70-72).
+- **Impact :** Dans une même modale, des champs carrés de 36 px côtoient des champs arrondis de 44 px, et le fond reste blanc en mode sombre. L'ensemble paraît bricolé et ne ressemble pas aux autres formulaires de l'application.
+- **Recommandation :** Réécrire le formulaire avec les composants UI existants (Input, Textarea, Select, Label, Button), react-hook-form + zod (insertTaskSchema) et un état isPending de useMutation pour le bouton.
+
+### TASKS-18
+
+**Couleurs de priorité, vocabulaire et icônes différents entre desktop et mobile** — coherence-design, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:544`
+- **Constat :** Desktop, Tasks.tsx:546-563 : high donne `destructive` (rouge plein), medium `default` (bleu primaire plein), low `secondary` (gris). Mobile, TasksPage.tsx:193-195 : rouge, jaune et vert pâles. Onglets mobiles l.404-420 '⏳ Actives / ✅ Faites / 📋 Toutes' contre desktop 'En cours / Terminées / Toutes'. Badges desktop avec icône lucide et emoji en double : l.934-935 `<startDateStatus.icon /> 📅 {startDateStatus.text}`, l.951-952 `<DueDateIcon /> ⏰`.
+- **Impact :** La priorité 'Moyenne' (bleu plein) attire davantage l'œil que 'Faible' et entre en concurrence avec le bouton principal. Un utilisateur qui passe du PC au téléphone ne retrouve ni les couleurs ni les mots.
+- **Recommandation :** Créer un module partagé `taskUi.ts` (libellés, couleurs, icônes de priorité et de statut) utilisé par les deux pages : Élevée rouge, Moyenne ambre, Faible gris ou vert. Un seul vocabulaire ('À faire' / 'Terminées'). Une seule icône par badge, sans emoji.
+
+### TASKS-19
+
+**Cartes surchargées : jusqu'à 7 informations redondantes par tâche, avec le rôle technique affiché** — lisibilite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Tasks.tsx:1212`
+- **Constat :** Pour une tâche programmée (l.1212-1294) : titre suivi de ' (Programmée)', badge priorité, badge 'Future', '📅 +3j' plus 'Démarre dans 3 jours (05/10/2026)', '⏰ ...', 'Assigné à: Non assigné', 'Créée: 02/10/2026 14:37', et l.1290-1293 `Visible en avance ({user?.role})` qui affiche par exemple 'Visible en avance (directeur)'. Pour une tâche déjà démarrée, l.625-632 affiche un badge '📅 Active' et le texte 'Démarrée (dd/MM/yyyy)' sur chaque carte. Kanban l.1439/1517 : `cursor-pointer` sans onClick.
+- **Impact :** L'œil ne trouve pas l'essentiel (quoi, pour quand, qui). La même notion 'programmée' apparaît trois fois, et 'Active' ou 'Créée à HH:mm' n'apportent rien au quotidien. Les cartes Kanban semblent cliquables mais ne réagissent pas.
+- **Recommandation :** Garder sur la carte : titre, échéance colorée (seulement si proche ou dépassée), priorité (seulement si Élevée), personne assignée (si renseignée). Pour les tâches programmées, un seul badge 'Visible le 05/10'. Mettre la description et la date de création dans le détail ou la modale. Retirer `cursor-pointer`, ou rendre la carte cliquable pour ouvrir l'édition.
+
+### TASKS-20
+
+**Tâches terminées quasi illisibles (opacité 60 % + gris 400 + texte barré)** — accessibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:1350`
+- **Constat :** Tasks.tsx:1350 `<Card key={task.id} className="opacity-60 bg-gray-50">`, l.1355 `text-gray-500 truncate line-through`, l.1365 `<p className="text-sm text-gray-400 mb-2 line-clamp-2 line-through">{task.description}</p>`. Tâches futures, l.1205-1212 : `opacity-75` + `italic text-gray-600`. Mobile, TasksPage.tsx:221 : `opacity-60`.
+- **Impact :** Contraste bien inférieur au minimum WCAG de 4,5:1 : la description d'une tâche terminée est pratiquement invisible sur les écrans de magasin. L'opacité appliquée aux boutons (l.997, 1311) donne l'impression qu'ils sont désactivés alors qu'ils fonctionnent.
+- **Recommandation :** Ne pas baisser l'opacité de toute la carte : un fond vert très pâle avec une coche 'Terminée' et un texte gray-600 non barré suffisent. Pour les tâches futures, un simple badge 'Programmée', sans italique ni opacité.
+
+### TASKS-21
+
+**Formulaire : assignation en texte libre, magasin implicite (magasin 1 pour un admin) et aucune vérification des dates** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Tasks.tsx:90`
+- **Constat :** Tasks.tsx:248-254 : `<input name="assignedTo" type="text" placeholder="Nom de la personne assignée">`. l.80 enregistre la chaîne 'Non assigné' si le champ est vide. l.90 `groupId = selectedStoreId ? parseInt(...) : 1` : en vue 'Tous les magasins', l'admin crée dans le magasin 1 sans aucune indication. Le serveur fait de même (routes.ts:3303-3305). Seul le titre est validé (l.60-67) : on peut saisir une échéance antérieure à la date de début. Le formulaire mobile (TasksPage.tsx:142-160) n'a pas de date de début.
+- **Impact :** Les fautes de frappe dans les noms empêchent toute recherche par personne. Des tâches peuvent être créées dans le mauvais magasin. Des incohérences de dates passent sans avertissement, et une tâche programmée ne peut pas être créée depuis un téléphone.
+- **Recommandation :** Proposer un champ assigné en liste (utilisateurs du magasin, via un endpoint léger) avec 'Non assigné' comme valeur vide (null). Afficher le magasin cible dans la modale et l'imposer quand selectedStoreId est null. Valider `dueDate >= startDate`. Ajouter la date de début au formulaire mobile.
+
+### TASKS-22
+
+**Erreurs de chargement et absence de magasin affichées comme 'Aucune tâche trouvée avec les filtres sélectionnés'** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:326`
+- **Constat :** Tasks.tsx:326 `const { data: tasks = [], isLoading, error } = useQuery(...)` : `error` n'est jamais rendu. l.855-864 et 1176-1185 affichent le même message vide dans tous les cas. Côté serveur, routes.ts:3273 `res.status(500).json([])` et l.3248 `return res.json([])` quand aucun magasin n'est sélectionné. Mobile, TasksPage.tsx:295 ne récupère même pas `error`.
+- **Impact :** En cas de panne réseau, d'erreur 500 ou de magasin non choisi, l'utilisateur pense qu'il n'a rien à faire et peut manquer des tâches urgentes.
+- **Recommandation :** Distinguer trois états : erreur ('Impossible de charger les tâches', bouton Réessayer → refetch), aucun magasin ('Choisissez un magasin en haut de l'écran') et liste vide réelle (avec un bouton 'Créer une tâche' si l'utilisateur en a le droit). Côté serveur, renvoyer `{ message }` avec le code 500, pas un tableau vide.
+
+### TASKS-23
+
+**Spinner plein écran à chaque changement de magasin, faute de placeholderData et de squelette** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:670`
+- **Constat :** Tasks.tsx:670-676 `if (isLoading) { return (<div className="flex-1 flex items-center justify-center"><div className="animate-spin ..."/></div>); }`. La queryKey (l.327) change avec selectedStoreId, sans `placeholderData: keepPreviousData`. Mobile, TasksPage.tsx:362-370 : même comportement.
+- **Impact :** Chaque changement de magasin fait disparaître en-tête, filtres et recherche au profit d'un spinner, puis tout réapparaît. La page clignote et paraît plus lente qu'elle ne l'est.
+- **Recommandation :** Ajouter `placeholderData: keepPreviousData` (TanStack v5) et un indicateur discret (isFetching) dans l'en-tête. Garder en-tête et filtres affichés et ne remplacer que la liste par 3 à 5 cartes squelette au premier chargement.
+
+### TASKS-24
+
+**Terminer et Supprimer passent par des fetch manuels qui attendent le rechargement complet de la liste avant tout retour visuel** — perf-client, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Tasks.tsx:405`
+- **Constat :** Tasks.tsx:405-424 `await fetch(`/api/tasks/${taskId}/complete`, ...); await queryClient.invalidateQueries({ queryKey: ["/api/tasks"] }); toast(...)`. l.440-460 : la modale de suppression ne se ferme qu'après `await queryClient.invalidateQueries(...)`. Aucun état pending, donc les doubles clics sont possibles. Le serveur ne renvoie pas la tâche mise à jour (routes.ts:3478 `res.json({ message: "Task completed successfully" })`).
+- **Impact :** Après un clic sur Terminer, rien ne bouge pendant tout le refetch du gros payload (TASKS-01). L'utilisateur reclique, ce qui envoie plusieurs requêtes, et la modale de suppression reste ouverte plusieurs centaines de ms.
+- **Recommandation :** Utiliser useMutation avec mise à jour optimiste (`onMutate` : setQueryData pour passer la tâche en completed ou la retirer, rollback en onError), boutons désactivés pendant `isPending`, et fermeture de la modale immédiatement. Côté serveur, renvoyer la tâche mise à jour (`.returning()`) depuis completeTask.
+
+### TASKS-25
+
+**Mobile : 'Tâche terminée' ou 'Tâche supprimée' affiché même quand l'API refuse ou échoue** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/TasksPage.tsx:334`
+- **Constat :** TasksPage.tsx:334-341 `await fetch(`/api/tasks/${taskId}/complete`, {...}); queryClient.invalidateQueries(...); toast({ title: "✅ Tâche terminée" });`, sans vérifier `response.ok`. l.350-352, même chose pour DELETE. fetch ne lève pas d'erreur sur 403 ou 500, donc le catch n'est jamais atteint.
+- **Impact :** Un employé sans droit (403), ou n'importe qui lors d'une erreur serveur, voit un message de succès alors que rien n'a changé, ce qui le désoriente.
+- **Recommandation :** Vérifier `if (!res.ok) throw new Error(...)`, ou utiliser apiRequest (queryClient.ts:10), qui lève déjà une erreur sur les statuts non-OK, et afficher le message d'erreur du serveur.
+
+### TASKS-26
+
+**Mobile : tâches programmées non signalées et 'Terminer' proposé alors que le desktop l'interdit** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/TasksPage.tsx:215`
+- **Constat :** La carte TaskCard (TasksPage.tsx:178-279) n'utilise jamais `task.isFutureTask` ni `startDate`. Pour un directeur ou un admin, getTasks renvoie les tâches futures (storage.ts:2295). Desktop : Tasks.tsx:980 `{canEditTasks && !isFuture && (` masque Terminer pour une tâche future. Mobile : l.254 `{!isCompleted && (` l'affiche.
+- **Impact :** Sur téléphone, un directeur voit les tâches de la semaine prochaine mêlées à celles du jour et peut les clôturer avant qu'elles ne soient visibles des équipes.
+- **Recommandation :** Ajouter un badge 'Programmée le dd/MM' et masquer ou désactiver 'Terminer' pour `isFutureTask`, via le helper partagé de TASKS-18 et TASKS-31.
+
+### TASKS-27
+
+**GET /api/tasks sans limite : tout l'historique des tâches terminées (et tous les magasins pour un admin) à chaque chargement** — perf-api, sévérité moyenne, effort M
+
+- **Fichier :** `server/storage.ts:2301`
+- **Constat :** storage.ts:2301 `const results = await query.orderBy(desc(tasks.createdAt));`, sans limit ni filtre de statut ou de date. routes.ts:3205 `groupIds = storeId ? [...] : undefined`, donc un admin en 'Tous les magasins' reçoit toutes les tâches de la base. La pagination est faite côté client (Tasks.tsx:534-542, 10 par page). Le mobile n'en a aucune et rend toute la liste (TasksPage.tsx:434).
+- **Impact :** Le volume grandit indéfiniment, car les tâches terminées ne sont jamais purgées. Combiné à TASKS-01, chaque visite télécharge des Mo pour en afficher 10 lignes.
+- **Recommandation :** Ajouter des paramètres `status` et `completedSince` (par défaut, tâches en cours + terminées des 30 derniers jours) ou une pagination serveur (`limit`/`offset` + total). Charger les terminées plus anciennes à la demande ('Voir l'historique').
+
+### TASKS-28
+
+**console.log volumineux dans tous les handlers tâches (corps complets, parcours de toute la liste)** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:3252`
+- **Constat :** routes.ts:3252-3269 : à chaque GET, `console.log('🔍 Tasks API called with:', ...)` puis `taskGroups: tasks.map(t => ({ id: t.id, title: t.title, groupId: t.groupId })).slice(0, 3)` (map sur toutes les tâches avant le slice). Plus les l.3206, 3220, 3228 et 3242. POST l.3294-3300 `originalBody: req.body, processedData: data`. PUT l.3354-3365 et 3391-3399. storage.ts:2303-2313, 2366-2371, 2382-2387, 2393-2399, 2436-2455. Le serveur de production (index.production.ts) ne neutralise pas console.log.
+- **Impact :** Des E/S synchrones sur stdout à chaque requête, des logs Docker qui gonflent (descriptions complètes des tâches) et une allocation O(n) inutile sur le chemin le plus fréquent.
+- **Recommandation :** Supprimer ces logs, ou les placer derrière `if (process.env.DEBUG_TASKS)`. Garder seulement les console.error dans les catch, sans réexposer req.body.
+
+### TASKS-29
+
+**Index de la table tasks déclarés dans un fichier SQL jamais exécuté, et absents de schema.ts** — perf-serveur, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/migrations.ts:112`
+- **Constat :** migrations/20260814_add_performance_indexes.sql:62-65 `CREATE INDEX IF NOT EXISTS idx_tasks_group_id ON tasks (group_id); ... idx_tasks_group_status ...`. Mais server/migrations.ts:112-114 indique `// Ignorer les fichiers de migrations ... const allMigrations = hardcodedMigrations;`, et ce fichier ne figure pas dans la liste en dur (l.40-89). shared/schema.ts:307-322 ne déclare aucun index sur tasks. Rien ne couvre non plus `ORDER BY created_at DESC` filtré par group_id.
+- **Impact :** Selon l'environnement, getTasks fait un parcours complet de la table plus un tri, à chaque appel du Dashboard comme des Tâches. Le coût grandit avec l'historique.
+- **Recommandation :** Ajouter `CREATE INDEX IF NOT EXISTS idx_tasks_group_created ON tasks (group_id, created_at DESC); CREATE INDEX IF NOT EXISTS idx_tasks_group_status ON tasks (group_id, status);` dans server/migrations.production.ts (runProductionMigrations), et déclarer les index dans shared/schema.ts (3e argument de pgTable) pour `drizzle-kit push` en dev. À décider : soit supprimer migrations.ts et migrate.js, qui sont morts, soit les rebrancher. Ce DDL s'exécute au démarrage sur la base de production : à valider avant de l'appliquer.
+
+### TASKS-31
+
+**Tasks.tsx (1633 lignes) duplique 6 fois le balisage des cartes et 2 fois les filtres, et le mobile réimplémente tout** — dette-code, sévérité moyenne, effort L
+
+- **Fichier :** `client/src/pages/Tasks.tsx:874`
+- **Constat :** Cartes en cours : l.874-1021 (tablette), 1195-1331 (desktop), 1432-1501 (Kanban). Cartes terminées : l.1033-1068, 1343-1399, 1512-1556. Filtres : l.777-846 et 1100-1165. Mobile : TasksPage.tsx a son propre formulaire (l.36-175), sa propre config de priorité (l.191-198) et son propre filtre, avec une recherche limitée au titre (l.318) alors que le desktop cherche aussi dans la description (Tasks.tsx:475-476). Les actions sur les tâches terminées divergent : aucune sur tablette (l.1039-1066), Supprimer seul en liste desktop (l.1385-1394), Modifier + Supprimer en Kanban (l.1532-1551), aucun 'Rouvrir' nulle part. La date affichée est updatedAt sur tablette (l.1062) et completedAt ailleurs (l.1377).
+- **Impact :** Chaque correction doit être faite 3 à 6 fois, d'où les bugs ci-dessus qui n'existent que dans une variante. L'utilisateur trouve des actions différentes selon la vue ou l'appareil.
+- **Recommandation :** Extraire `useTasks` (query + mutations), `taskUi.ts` (helpers de date et de priorité), `<TaskCard variant>`, `<TaskFilters>` et `<TaskFormDialog>`, utilisés par le desktop et le mobile. Définir un seul jeu d'actions par statut (À faire : Terminer, Modifier, Supprimer ; Terminée : Rouvrir, Supprimer) et toujours afficher completedAt.
+
+### TASKS-32
+
+**Huit composants de formulaire ou de carte de tâche et ResponsiveTasks jamais importés (2030 lignes), dont plusieurs appellent une route PATCH inexistante** — dette-code, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/tasks/TaskFormUltraSimple.tsx:38`
+- **Constat :** Un grep sur tout le dépôt ne trouve aucun import de NewTaskForm, TaskFormClean, SimpleTaskFormClean, TaskFormProduction, TaskFormUltraSimple, TaskForm, SimpleTaskForm, RecentTasksCard ni ResponsiveTasks (RouterProduction.tsx:24/39 importe directement Tasks et MobileTasksPage). TaskFormUltraSimple.tsx:38 `const method = task ? 'PATCH' : 'POST';` et l.41-42 `groupId = 1; createdBy = 'admin'`. TaskFormClean.tsx:136 et SimpleTaskFormClean.tsx:137 utilisent aussi `"PATCH"`, alors que le serveur n'expose que `app.put('/api/tasks/:id'` (routes.ts:3340). Tasks.tsx:35 commente : `// TaskForm inline pour éviter les problèmes d'import en production`.
+- **Impact :** Brouille la lecture : on ne sait pas quel formulaire est le bon. Si quelqu'un en rebranche un, les modifications échoueront (PATCH en 404) et les tâches seront créées dans le magasin 1.
+- **Recommandation :** Supprimer client/src/components/tasks/{NewTaskForm,TaskFormClean,SimpleTaskFormClean,TaskFormProduction,TaskFormUltraSimple,TaskForm,SimpleTaskForm,RecentTasksCard}.tsx et client/src/components/ResponsiveTasks.tsx. Recréer ensuite un seul TaskFormDialog (TASKS-31).
+
+### TASKS-30
+
+**PUT, DELETE et complete : contrôle d'accès en lecture préalable avec jointure magasin complète, puis écriture (3 à 4 allers-retours)** — perf-api, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:2348`
+- **Constat :** routes.ts:3348, 3433 et 3463 `const task = await storage.getTask(id);` seulement pour lire task.groupId. storage.ts:2349-2356 `select({ task: tasks, group: groups })...leftJoin(groups, ...)` charge logo et config du magasin. Ensuite updateTask, deleteTask ou completeTask font une requête séparée.
+- **Impact :** Latence ajoutée à chaque action utilisateur, et le logo du magasin est lu inutilement à chaque clic.
+- **Recommandation :** Partie automatisable : supprimer la jointure groups dans DatabaseStorage.getTask (`db.select().from(tasks).where(eq(tasks.id, id))`), car ses seuls appelants (routes.ts:3348, 3433, 3463) n'utilisent pas `group`. La requête conditionnelle unique est à reporter au chantier des permissions (TASKS-13).
+
+### TASKS-33
+
+**console.log de debug dans le rendu et le queryFn, imports et variables inutilisés** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:285`
+- **Constat :** Tasks.tsx:285-296 `const isQueryEnabled = ...; console.log('🔍 TASK QUERY ENABLEMENT DEBUG:', {... timestamp: new Date().toISOString() })`, exécuté à chaque rendu et à chaque frappe. isQueryEnabled n'est utilisé nulle part (la query utilise `enabled: !!user`). Autres logs l.301, 335-344, 356-366, 94-100 et 108. Imports inutilisés : l.12 `Dialog, DialogContent, DialogHeader, DialogTitle, DialogTrigger`. storeInitialized n'est lu que dans des logs.
+- **Impact :** Retirés du bundle Docker grâce à esbuild.pure (vite.config.ts:29), mais ils polluent la console en dev et en `npm start`, et nuisent à la lisibilité du code. console.error et console.warn restent actifs en production.
+- **Recommandation :** Supprimer seulement les logs, la variable isQueryEnabled, la lecture de storeInitialized et les imports Dialog. Ne pas brancher isQueryEnabled sur `enabled` dans la même passe : cela changerait le comportement de chargement selon le rôle, et relève de TASKS-02/05.
+
+### TASKS-34
+
+**Filtrage et tri recalculés à chaque rendu sans useMemo, et sous-filtres répétés dans le JSX** — perf-client, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Tasks.tsx:472`
+- **Constat :** Tasks.tsx:472-531 `const filteredTasks = tasks.filter(...).sort(...)` dans le corps du composant, avec `searchTerm.toLowerCase()` recalculé pour chaque tâche et `new Date(...)` dans le comparateur du tri. l.868, 871 et 874 : `paginatedTasks.filter(task => task.status === 'pending')` évalué 3 fois par section, deux fois (tablette et desktop). Kanban l.1429-1432 et 1509-1512 : même chose sur filteredTasks. Mobile, TasksPage.tsx:311-329 : pas de useMemo non plus.
+- **Impact :** Avec quelques centaines de tâches (TASKS-27), chaque frappe dans la recherche refait N filtres, un tri en N log N et 12 parcours de liste. Le champ de recherche devient perceptiblement lent sur les PC de magasin.
+- **Recommandation :** Envelopper le filtrage et le tri dans `useMemo` (dépendances : tasks, searchTerm, filtres), précalculer `pendingTasks`/`completedTasks` une seule fois, et utiliser `useDeferredValue(searchTerm)` pour la recherche.
+
+### TASKS-35
+
+**Pages Tâches desktop et mobile importées statiquement dans le bundle principal** — perf-bundle, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:24`
+- **Constat :** RouterProduction.tsx:24 `import Tasks from "@/pages/Tasks";` et l.39 `import MobileTasksPage from "@/pages/mobile/TasksPage";`, sans React.lazy. Les deux variantes, ainsi que toutes les autres pages (l.5-44), partent dans le chunk initial, même si un appareil n'en utilise qu'une.
+- **Impact :** Le premier chargement télécharge et parse le code des deux versions (environ 2100 lignes rien que pour les tâches) et de toutes les autres pages, ce qui retarde l'affichage du tableau de bord sur mobile.
+- **Recommandation :** Passer les pages en lazy avec un `<Suspense fallback={<PageSkeleton/>}>` et un ErrorBoundary qui recharge la page en cas d'échec de chargement d'un chunk. À tester sur un redéploiement réel, à la main et pour toutes les routes à la fois.
+
+### TASKS-36
+
+**Avec server/index.ts (dev et `npm start`), les apostrophes des titres de tâches sont stockées échappées en HTML (&#x27;)** — bug, sévérité basse, effort S
+
+- **Fichier :** `server/security.ts:202`
+- **Constat :** server/index.ts:37 `setupInputSanitization(app);`, puis security.ts:310 `req.body = sanitizeInput(req.body);`, puis l.202 `sanitized = validator.escape(sanitized);`. Un titre comme « Ranger l'entrepôt » est stocké « Ranger l&#x27;entrepôt », et React l'affiche tel quel puisqu'il échappe le texte. Le Dockerfile (l.41) compile index.production.ts, qui n'appelle pas ce middleware. En revanche, package.json:9 `start` lance dist/server/index.js, compilé depuis index.ts.
+- **Impact :** Selon le mode de démarrage, les titres et descriptions en français (très riches en apostrophes et guillemets) s'affichent avec des entités HTML, et la recherche sur « l'entrepôt » ne trouve plus rien.
+- **Recommandation :** Ne pas échapper en HTML à l'entrée (React protège déjà à l'affichage). Limiter le middleware à la suppression des octets nuls, ou l'appliquer seulement aux champs destinés à du HTML (e-mails). Aligner le comportement de index.ts et de index.production.ts.

docs/audit-webui/06-sav.md

@@ -0,0 +1,441 @@
+# SAV
+
+_38 constats vérifiés — 8 haute, 17 moyenne, 13 basse._
+
+## Pages analysées
+
+### `/sav (desktop)`
+
+**Rôle :** Suivre les retours SAV (produits défectueux, pièces manquantes...) d'un magasin : créer un ticket, suivre son statut et sa priorité, échanger des commentaires, supprimer un ticket.
+
+**Tâches principales de l'utilisateur :**
+- Créer un ticket SAV (produit, fournisseur, client, problème, priorité)
+- Retrouver un ticket (recherche texte + filtres statut/priorité/fournisseur)
+- Ouvrir le suivi d'un ticket et changer son statut ou sa priorité
+- Ajouter un commentaire de suivi
+- Modifier un ticket (bouton crayon)
+- Supprimer un ticket (admin/directeur)
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/sav/tickets?status=&priority=&supplierId=&groupId= | au montage puis à chaque changement de filtre statut/priorité/fournisseur (nouvelle queryKey) | server/routes.ts:5242 -> storage.getUserWithGroups (2 requêtes) + storage.getSavTickets (server/storage.ts:2656) | Aucune pagination/LIMIT ; SELECT de lignes complètes savTickets + suppliers + groups (dont logo base64, config SMTP/NocoDB) + users (dont hash du mot de passe) ; Promise.all de getSavTicketHistory par ticket (no-op actuellement) ; 3 console.log par appel. |
+| GET /api/sav/stats?groupId= | au montage (queryFn fetch manuel, staleTime 2 min) | server/routes.ts:5524 -> storage.getUserWithGroups + storage.getSavTicketStats (server/storage.ts:2818) | 3 requêtes SQL séquentielles (group by status, group by priority, count) + variable baseQuery morte ; 'Critiques' compte aussi les tickets résolus/fermés. |
+| GET /api/suppliers | au montage (staleTime 10 min) | server/routes.ts:1141 -> storage.getUser + storage.getSuppliers (server/storage.ts:467) | Liste complète de tous les fournisseurs pour 2 Select sans recherche (filtre + formulaire). |
+| GET /api/groups | au montage (même clé que Layout.tsx:49, donc dédupliqué) | server/routes.ts:970 -> storage.getUserWithGroups + storage.getGroups (server/storage.ts:432) | Utilisé uniquement pour le formulaire de création ; StoreContext expose déjà `stores`. |
+| GET /api/sav/tickets/:id | ouverture de la modale de suivi (staleTime 0, déclaré 2 fois lignes 142 et 376) | server/routes.ts:5288 -> storage.getUserWithGroups + storage.getSavTicket (server/storage.ts:2720) | Renvoie les mêmes données que la liste (history toujours []), donc requête redondante à chaque ouverture. |
+| POST /api/sav/tickets | clic 'Créer le ticket' | server/routes.ts:5319 -> getUserWithGroups + getGroups (admin) + storage.createSavTicket (server/storage.ts:2747) | Numéro de ticket généré dans la route puis écrasé par un count(*) annuel dans storage (doublons possibles). |
+| PATCH /api/sav/tickets/:id | changement de Statut ou Priorité dans 'Actions Rapides' (sauvegarde immédiate) | server/routes.ts:5390 -> getUserWithGroups + getSavTicket (3 jointures) + storage.updateSavTicket (server/storage.ts:2773) + addSavTicketHistory (no-op) | resolvedAt/closedAt jamais renseignés ; changement de statut non historisé. |
+| POST /api/sav/tickets/:id/history | clic 'Ajouter commentaire' | server/routes.ts:5471 -> getUserWithGroups + getSavTicket + storage.addSavTicketHistory (server/storage.ts:2808, renvoie null sans rien écrire) | Le commentaire est perdu alors que l'UI affiche 'Commentaire ajouté'. |
+| DELETE /api/sav/tickets/:id | confirmation dans la modale de suppression | server/routes.ts:5443 -> storage.getUser + getSavTicket + storage.deleteSavTicket (server/storage.ts:2783) | Aucun contrôle d'appartenance au magasin pour un directeur. |
+
+**Lisibilité / simplicité :** Page lisible dans sa structure (en-tête, 5 compteurs, filtres, grille de cartes) mais plusieurs fonctions visibles ne marchent pas : le bouton crayon ouvre un formulaire complet dont 'Sauvegarder' affiche 'Fonction en développement', les commentaires affichent un succès mais ne sont jamais enregistrés (historique toujours vide), et la liste ne se rafraîchit pas après création/suppression dès qu'un filtre ou un magasin est sélectionné (staleTime 5 min). Des codes techniques sont affichés tels quels ('pieces_manquantes', 'status_change', 'Statut changé de "en_cours" vers "resolu"'), avec 'N/A' et des emojis. Les cartes ont un curseur 'main' mais ne sont pas cliquables ; les actions sont 3 petites icônes sans libellé. La modale de détail (max-w-6xl, 5 cartes à gauche, overflow-hidden) coupe le bloc 'Actions Rapides' sur des écrans de portable. Le badge 'Nouveau' (commentaire récent) se confond avec le statut 'Nouveau', et les couleurs priorité/statut se chevauchent. Les tickets fermés restent mélangés aux tickets ouverts, sans pagination. Les états d'erreur ne sont pas gérés : une panne API affiche 'Aucun ticket trouvé'. La console est inondée de logs à chaque frappe.
+
+### `/sav (mobile)`
+
+**Rôle :** Version téléphone du SAV : consulter les tickets du magasin, appeler le client, changer rapidement le statut et créer un ticket depuis la surface de vente.
+
+**Tâches principales de l'utilisateur :**
+- Rechercher un ticket (n°, client, produit)
+- Appeler le client (bouton 'Appeler')
+- Changer le statut via le menu ⋮
+- Créer un ticket via le bouton flottant +
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/sav-tickets?storeId= | au montage (enabled si selectedStoreId) | AUCUN handler (seul /api/sav/tickets existe, server/routes.ts:5242) -> 404 Express en production (index.production.ts:157-160 fait next() pour /api/) | La liste est toujours vide : l'erreur est masquée par l'état vide 'Aucun ticket SAV'. |
+| GET /api/suppliers | au montage (queryFn apiRequest, staleTime par défaut 30 s) | server/routes.ts:1141 -> storage.getSuppliers | Nécessaire uniquement pour le formulaire de création. |
+| GET /api/groups | au montage | server/routes.ts:970 -> storage.getGroups / userGroups | Utilisé seulement en repli dans onSubmit (admin sans magasin). |
+| PATCH /api/sav-tickets/:id/status | clic sur un statut dans le menu ⋮ | AUCUN handler | Valeurs envoyées en anglais ('in_progress', 'waiting_parts', 'resolved', 'closed') hors de l'enum serveur ; pas de onError. |
+| POST /api/sav-tickets | submit du formulaire 'Créer le ticket' | AUCUN handler | En production : toast d'erreur contenant le HTML brut du 404. |
+
+**Lisibilité / simplicité :** Interface mobile simple et bien pensée (cartes compactes, bouton 'Appeler', bouton flottant), mais entièrement non fonctionnelle : elle appelle des endpoints /api/sav-tickets inexistants, donc la liste est toujours vide et la création comme le changement de statut échouent. Les erreurs de validation du formulaire ne s'affichent jamais (FormMessage absent). Le bouton + est visible pour les employés alors que le serveur refuse la création. Il n'y a ni vue détail, ni commentaires, ni confirmation avant 'Fermer'. Les libellés et couleurs divergent du desktop (badge 'Pièces' au lieu de 'Attente pièces', 'attente_echange' affiché en code brut, violet au lieu de bleu), avec du jargon ('Gencode (EAN13)', placeholder 'Scanner...' sans scanner).
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [MSAV-01](#msav-01) | haute | bug | S | La page mobile appelle des endpoints inexistants (/api/sav-tickets) : SAV mobile inutilisable | `client/src/pages/mobile/SavPage.tsx:88` |
+| [MSAV-02](#msav-02) | haute | bug | S | Valeurs de statut en anglais, hors de l'enum serveur | `client/src/pages/mobile/SavPage.tsx:230` |
+| [SAV-01](#sav-01) | haute | bug | S | La liste ne se rafraîchit pas après création/modification/suppression (queryKey incompatible avec l'invalidation) | `client/src/pages/SavTickets.tsx:98` |
+| [SAV-02](#sav-02) | haute | bug | M | Les commentaires et l'historique ne sont jamais enregistrés, mais l'UI affiche un succès | `server/storage.ts:2808` |
+| [SAV-03](#sav-03) | haute | ux-simplicite | S | Bouton 'Modifier' : formulaire complet dont la sauvegarde n'est pas implémentée | `client/src/pages/SavTickets.tsx:1338` |
+| [SAV-04](#sav-04) | haute | bug | S | Le hash du mot de passe du créateur est envoyé au navigateur pour chaque ticket | `server/storage.ts:2669` |
+| [SAV-05](#sav-05) | haute | perf-api | S | Chaque ticket embarque la ligne magasin complète, logo base64 et config SMTP/NocoDB compris | `server/storage.ts:2668` |
+| [SAV-06](#sav-06) | haute | bug | S | Un utilisateur non admin sans magasin assigné voit les tickets de tous les magasins | `server/routes.ts:5272` |
+| [MSAV-03](#msav-03) | moyenne | ux-simplicite | S | Les erreurs de validation du formulaire mobile ne s'affichent jamais | `client/src/pages/mobile/SavPage.tsx:283` |
+| [MSAV-04](#msav-04) | moyenne | ux-simplicite | S | Bouton + et menu de statut visibles pour les employés, qui n'ont pas le droit | `client/src/pages/mobile/SavPage.tsx:397` |
+| [MSAV-05](#msav-05) | moyenne | ux-simplicite | M | Mobile : ni détail, ni commentaires, ni confirmation de fermeture, ni gestion d'erreur du statut | `client/src/pages/mobile/SavPage.tsx:106` |
+| [SAV-07](#sav-07) | moyenne | bug | S | Création par un admin : ticket rattaché au premier magasin alphabétique et non au magasin sélectionné | `client/src/pages/SavTickets.tsx:337` |
+| [SAV-08](#sav-08) | moyenne | bug | S | Le formulaire 'Nouveau Ticket' est pré-rempli avec le dernier ticket ouvert en modification | `client/src/pages/SavTickets.tsx:400` |
+| [SAV-09](#sav-09) | moyenne | bug | S | DELETE : aucun contrôle d'appartenance au magasin | `server/routes.ts:5446` |
+| [SAV-10](#sav-10) | moyenne | perf-serveur | S | Chaque route SAV recharge l'utilisateur et ses magasins déjà fournis par la session | `server/routes.ts:5245` |
+| [SAV-11](#sav-11) | moyenne | perf-serveur | S | Statistiques SAV : 3 requêtes séquentielles au lieu d'une seule | `server/storage.ts:2832` |
+| [SAV-12](#sav-12) | moyenne | perf-serveur | M | Schéma N+1 : un appel getSavTicketHistory par ticket de la liste | `server/storage.ts:2704` |
+| [SAV-13](#sav-13) | moyenne | perf-api | M | Liste sans pagination ni limite, rendue entièrement en cartes | `server/storage.ts:2701` |
+| [SAV-14](#sav-14) | moyenne | perf-client | S | Chaque changement de filtre vide la liste et affiche un spinner (aucun placeholderData) | `client/src/pages/SavTickets.tsx:97` |
+| [SAV-15](#sav-15) | moyenne | dette-code | S | console.log de debug exécutés à chaque rendu (chaque frappe clavier) | `client/src/pages/SavTickets.tsx:294` |
+| [SAV-18](#sav-18) | moyenne | lisibilite | S | Codes techniques, anglais et emojis affichés à l'utilisateur | `client/src/pages/SavTickets.tsx:1034` |
+| [SAV-19](#sav-19) | moyenne | ux-simplicite | S | Modale de suivi trop chargée : 'Actions Rapides' coupé en bas sur écran de portable | `client/src/pages/SavTickets.tsx:966` |
+| [SAV-20](#sav-20) | moyenne | accessibilite | S | Cartes non cliquables malgré cursor-pointer ; actions en icônes minuscules sans libellé | `client/src/pages/SavTickets.tsx:846` |
+| [SAV-22](#sav-22) | moyenne | ux-simplicite | S | Compteurs trompeurs et non cliquables (Critiques inclut les tickets clos, Résolus inclut Fermés) | `server/storage.ts:2882` |
+| [SAV-23](#sav-23) | moyenne | ux-simplicite | S | Pas d'état d'erreur, état vide sans action, et compteurs qui apparaissent en décalant la page | `client/src/pages/SavTickets.tsx:832` |
+| [MSAV-06](#msav-06) | basse | coherence-design | S | Libellés et couleurs de statut différents du desktop ; statut 'attente_echange' affiché brut | `client/src/pages/mobile/SavPage.tsx:165` |
+| [MSAV-07](#msav-07) | basse | lisibilite | S | Jargon 'Gencode (EAN13)' et placeholder 'Scanner...' sans scanner | `client/src/pages/mobile/SavPage.tsx:284` |
+| [MSAV-08](#msav-08) | basse | dette-code | S | Imports inutilisés et requêtes chargées au montage pour un formulaire fermé | `client/src/pages/mobile/SavPage.tsx:100` |
+| [MSAV-09](#msav-09) | basse | ux-simplicite | S | Erreur ou absence de magasin sélectionné affichée comme 'Aucun ticket SAV' | `client/src/pages/mobile/SavPage.tsx:202` |
+| [SAV-16](#sav-16) | basse | perf-serveur | S | Logs console sur chaque requête GET SAV (chemin chaud) | `server/routes.ts:5258` |
+| [SAV-17](#sav-17) | basse | dette-code | S | Requête de détail déclarée deux fois, plus fetch manuels incohérents | `client/src/pages/SavTickets.tsx:376` |
+| [SAV-21](#sav-21) | basse | coherence-design | S | Badges ambigus : 'Nouveau' commentaire contre statut 'Nouveau', couleurs priorité/statut qui se chevauchent | `client/src/pages/SavTickets.tsx:856` |
+| [SAV-24](#sav-24) | basse | ux-simplicite | S | Changement de statut/priorité enregistré immédiatement, sans confirmation, avec un message inexact | `client/src/pages/SavTickets.tsx:1123` |
+| [SAV-25](#sav-25) | basse | ux-simplicite | S | Les tickets fermés sont mélangés aux tickets à traiter par défaut | `client/src/pages/SavTickets.tsx:59` |
+| [SAV-26](#sav-26) | basse | bug | S | Numéros de ticket dupliqués possibles (count(*) + 1) et génération en double | `server/storage.ts:2750` |
+| [SAV-27](#sav-27) | basse | perf-serveur | S | Index SAV absents du schéma Drizzle, pas d'index composite magasin+date ni fournisseur | `shared/schema.ts:869` |
+| [SAV-28](#sav-28) | basse | ux-simplicite | M | Formulaire de création : fournisseur sans recherche et validation non localisée | `client/src/pages/SavTickets.tsx:536` |
+| [SAV-29](#sav-29) | basse | perf-bundle | S | Pages SAV desktop et mobile importées statiquement dans le bundle initial | `client/src/components/RouterProduction.tsx:25` |
+
+### MSAV-01
+
+**La page mobile appelle des endpoints inexistants (/api/sav-tickets) : SAV mobile inutilisable** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/mobile/SavPage.tsx:88`
+- **Constat :** L88 `fetch(`/api/sav-tickets?storeId=${selectedStoreId}`)`, L108 `apiRequest(`/api/sav-tickets/${id}/status`, 'PATCH', ...)`, L116 `apiRequest('/api/sav-tickets', 'POST', data)`. Aucune route de ce nom dans le serveur (grep 'sav-tickets' dans server/ : 0 résultat). Seuls `/api/sav/tickets` et `/api/sav/tickets/:id` existent (routes.ts:5242-5443). En production, index.production.ts:157-160 fait `next()` pour /api/, d'où un 404.
+- **Impact :** Sur téléphone, la liste affiche toujours 'Aucun ticket SAV', la création renvoie un toast d'erreur contenant le HTML du 404, et le changement de statut échoue sans message. Les employés en magasin ne peuvent pas utiliser le SAV.
+- **Recommandation :** Utiliser `/api/sav/tickets` (GET avec `groupId` pour l'admin, comme sur desktop, en partageant la même queryKey), `PATCH /api/sav/tickets/:id` avec `{ status }`, et `POST /api/sav/tickets`. Idéalement, extraire un hook commun `useSavTickets()` partagé entre desktop et mobile.
+
+### MSAV-02
+
+**Valeurs de statut en anglais, hors de l'enum serveur** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/mobile/SavPage.tsx:230`
+- **Constat :** L230-239 : `status: 'in_progress'`, `'waiting_parts'`, `'resolved'`, `'closed'`. Le schéma attend `z.enum(["nouveau", "en_cours", "attente_pieces", "attente_echange", "resolu", "ferme"])` (schema.ts:919), et init.sql:356 impose un CHECK sur ces valeurs. Le menu ne propose pas non plus 'Nouveau' ni 'Attente échange'.
+- **Impact :** Même après correction de l'URL (MSAV-01), chaque changement de statut sera rejeté (400 Validation error), et un ticket en 'Attente échange' ne pourra pas être géré sur mobile.
+- **Recommandation :** Utiliser les valeurs de l'enum ('en_cours', 'attente_pieces', 'attente_echange', 'resolu', 'ferme') via un statusConfig partagé avec le desktop (à extraire dans un fichier commun).
+
+### SAV-01
+
+**La liste ne se rafraîchit pas après création/modification/suppression (queryKey incompatible avec l'invalidation)** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:98`
+- **Constat :** L95-100 : `const ticketsUrl = `/api/sav/tickets${queryParams...}`` puis `queryKey: [ticketsUrl, selectedStoreId], staleTime: 1000 * 60 * 5`. Les mutations font `queryClient.invalidateQueries({ queryKey: ['/api/sav/tickets'] })` (L170, 209, 240, 268). TanStack compare les éléments du tableau un à un : '/api/sav/tickets' !== '/api/sav/tickets?groupId=3'. Dès qu'un admin a un magasin sélectionné (L91-93 ajoute groupId) ou qu'un filtre est actif, l'invalidation ne correspond à aucune requête.
+- **Impact :** Un ticket créé n'apparaît pas, un ticket supprimé reste affiché (un second clic sur Supprimer renvoie 'Ticket not found') et un statut modifié reste ancien sur la carte, pendant 5 minutes. L'utilisateur croit que l'action a échoué et la refait (doublons).
+- **Recommandation :** Partie auto-applicable : clé `['/api/sav/tickets', { status, priority, supplierId, groupId }]` avec une queryFn qui reconstruit l'URL via apiRequest (le message '401: ...' garde la redirection du retry global). Alternative minimale : `invalidateQueries({ predicate: q => String(q.queryKey[0]).startsWith('/api/sav/tickets') })`. Après un commentaire, n'invalider que le détail. Le passage à setQueryData est une optimisation à faire à part, non automatique.
+
+### SAV-02
+
+**Les commentaires et l'historique ne sont jamais enregistrés, mais l'UI affiche un succès** — bug, sévérité haute, effort M
+
+- **Fichier :** `server/storage.ts:2808`
+- **Constat :** storage.ts:2808-2816 `async addSavTicketHistory(...) { // const [history] = await db.insert(savTicketHistory)... return null; }` et 2790-2805 `getSavTicketHistory(...) { // ... return []; }`. La route routes.ts:5508 renvoie 201. Côté client, SavTickets.tsx:214-218 affiche le toast 'Commentaire ajouté', mais la colonne 'Historique et commentaires' (L1154-1177) montre toujours 'Aucun commentaire pour le moment'. Les changements de statut (routes.ts:5424-5430) ne sont pas historisés non plus, et `resolvedAt`/`closedAt` (schema.ts:887-888) ne sont jamais renseignés par le PATCH (routes.ts:5420-5421).
+- **Impact :** Perte silencieuse des informations saisies par les managers (suivi fournisseur, échanges client). La fonction 'Nouveau' (commentaire < 24 h, L853) ne s'allume jamais. Aucune traçabilité de qui a changé un statut, ni de date de résolution.
+- **Recommandation :** Recréer la table sav_ticket_history (déjà définie dans migrations/sav_production_fix.sql:41), déclarer `savTicketHistory` dans shared/schema.ts et décommenter les implémentations. Dans updateSavTicket, positionner resolvedAt/closedAt quand le statut passe à 'resolu'/'ferme'. En attendant, masquer le champ commentaire plutôt que d'afficher un faux succès.
+
+### SAV-03
+
+**Bouton 'Modifier' : formulaire complet dont la sauvegarde n'est pas implémentée** — ux-simplicite, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:1338`
+- **Constat :** L1337-1344 : `onClick={() => { // TODO: Implement update ticket functionality
+ toast({ title: "Fonction en développement", description: "La modification de tickets sera bientôt disponible." }); }}`. Le bouton crayon est pourtant affiché sur chaque carte pour admin/directeur/manager (L932-941). Le PATCH serveur accepte déjà une mise à jour partielle (routes.ts:5420 `insertSavTicketSchema.partial().parse(req.body)`).
+- **Impact :** L'utilisateur remplit 9 champs puis découvre que rien n'est enregistré : frustration et perte de temps sur une action visible en permanence.
+- **Recommandation :** Si on branche la sauvegarde : envoyer seulement les champs éditables (supplierId en entier, produit, problemType, problemDescription, priority, clientName, clientPhone), jamais groupId ni createdBy. Côté serveur, retirer groupId/createdBy/ticketNumber du schéma PATCH (ou vérifier l'accès au nouveau groupId). Sinon, masquer le bouton crayon : c'est une décision produit.
+
+### SAV-04
+
+**Le hash du mot de passe du créateur est envoyé au navigateur pour chaque ticket** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:2669`
+- **Constat :** storage.ts:2665-2669 `.select({ ticket: savTickets, supplier: suppliers, group: groups, creator: users })` et de même 2722-2726 pour getSavTicket. La table users contient `password: varchar("password")` (schema.ts:40). Le middleware de sortie (routes.ts:165-171, sanitize.ts:36) ne retire que smtpPassword. Par contraste, /api/user (localAuth.ts:217-226) choisit ses champs explicitement.
+- **Impact :** Tout employé qui ouvre la page SAV reçoit les hash bcrypt des managers/admins créateurs de tickets (craquage hors ligne possible). Cela alourdit aussi chaque ticket de colonnes inutiles.
+- **Recommandation :** Comme proposé. Ajuster aussi le type `SavTicketWithRelations.creator` (schema.ts:939) en `Pick<User,'id'|'username'|'firstName'|'lastName'>`, sinon getSavTicket ne type-checke plus. MemStorage (4940, 4962) peut faire la même projection.
+
+### SAV-05
+
+**Chaque ticket embarque la ligne magasin complète, logo base64 et config SMTP/NocoDB compris** — perf-api, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:2668`
+- **Constat :** storage.ts:2667-2668 `supplier: suppliers, group: groups` (lignes complètes). groups contient `logo: text("logo"), // Logo en data URI (data:image/png;base64,...)` (schema.ts:67), plus smtpHost/smtpUser/webhookUrl/nocodb*. Le client n'utilise que `ticket.supplier?.name` (L911, L1067) et `ticket.group?.name` (L1071).
+- **Impact :** Avec un logo de 50-200 Ko, 100 tickets donnent 5 à 20 Mo de JSON à télécharger, parser et traverser récursivement (stripSmtpPassword) à chaque chargement et chaque filtre. Le chargement est lent sur le Wi-Fi ou la 4G du magasin, et des données sensibles (hôte/utilisateur SMTP) fuient.
+- **Recommandation :** Partie auto-applicable : projection `supplier: { id, name }`, `group: { id, name, color }` dans getSavTickets/getSavTicket, et types ajustés (Pick<Supplier,...>, Pick<Group,...>). Ajouter la compression gzip est une autre décision : nouvelle dépendance, effet global sur toute l'API, et à vérifier avec un éventuel proxy nginx. À traiter à part, pas automatiquement.
+
+### SAV-06
+
+**Un utilisateur non admin sans magasin assigné voit les tickets de tous les magasins** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/routes.ts:5272`
+- **Constat :** routes.ts:5266 `groupIds = userGroups ? userGroups.map(...) : [];` puis 5272 `groupIds: groupIds.length > 0 ? groupIds : undefined`. Dans storage.ts:2678, `if (filters?.groupIds?.length)` : aucun filtre magasin n'est appliqué. Même logique pour les stats (routes.ts:5548, 5552).
+- **Impact :** Un employé ou un manager fraîchement créé, ou dont l'affectation a été retirée, voit les tickets SAV (noms et téléphones clients) de toute l'enseigne.
+- **Recommandation :** Pour un non-admin dont groupIds est vide, renvoyer immédiatement `res.json([])` (et des stats à zéro) au lieu de passer `undefined`.
+
+### MSAV-03
+
+**Les erreurs de validation du formulaire mobile ne s'affichent jamais** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/SavPage.tsx:283`
+- **Constat :** FormMessage est importé (L51), mais aucun FormItem ne le rend, par exemple L283-286 `<FormItem><FormLabel>Gencode (EAN13)</FormLabel><FormControl><Input .../></FormControl></FormItem>`. Le schéma zod définit pourtant 'Gencode requis', 'Désignation requise', 'Fournisseur requis', 'Description requise' (L66-71). supplierId vaut 0 par défaut (L135).
+- **Impact :** En appuyant sur 'Créer le ticket' avec un champ manquant, rien ne se passe à part un libellé qui devient rouge en haut d'une feuille de 90vh. L'utilisateur pense que le bouton ne marche pas.
+- **Recommandation :** Ajouter `<FormMessage />` dans chaque FormItem et faire défiler jusqu'au premier champ en erreur (`shouldFocusError` est actif par défaut avec les champs enregistrés).
+
+### MSAV-04
+
+**Bouton + et menu de statut visibles pour les employés, qui n'ont pas le droit** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/SavPage.tsx:397`
+- **Constat :** L397-402 : le FAB `<Button className="fixed bottom-20 right-4 ..." onClick={() => setIsCreateOpen(true)}>` et le menu ⋮ (L223-243) sont toujours rendus. Le desktop limite pourtant `canCreate`/`canModify` à admin/directeur/manager (SavTickets.tsx:287-288), et le serveur renvoie 403 aux employés (routes.ts:5328, 5399).
+- **Impact :** Un employé remplit tout le formulaire puis reçoit une erreur 'Insufficient permissions' en anglais.
+- **Recommandation :** Reprendre les mêmes règles de rôle que le desktop (hook partagé `useSavPermissions`) et masquer le FAB et le menu ⋮ si l'utilisateur n'a pas le droit.
+
+### MSAV-05
+
+**Mobile : ni détail, ni commentaires, ni confirmation de fermeture, ni gestion d'erreur du statut** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/mobile/SavPage.tsx:106`
+- **Constat :** Les cartes (L209-259) ne sont pas cliquables : seuls le menu ⋮ et 'Appeler' sont présents, sans accès au fournisseur, au gencode ni à l'historique. `statusMutation` (L106-113) n'a pas de onError. 'Fermer' (L239) s'applique en un tap, sans confirmation.
+- **Impact :** Sur le terrain, l'employé ne voit pas les détails nécessaires pour traiter le SAV (fournisseur, code-barres). Un tap accidentel ferme un ticket, et un échec passe inaperçu.
+- **Recommandation :** Ouvrir une Sheet de détail au tap sur la carte (infos, statut, commentaires). Ajouter onError avec un toast français et une confirmation pour Résolu/Fermé.
+
+### SAV-07
+
+**Création par un admin : ticket rattaché au premier magasin alphabétique et non au magasin sélectionné** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:337`
+- **Constat :** L328 `let selectedGroupId = formData.groupId ? parseInt(formData.groupId) : null;` puis L337-339 `if (!selectedGroupId && availableGroups.length > 0) { selectedGroupId = availableGroups[0].id; }` et L345 `groupId: selectedGroupId || 1`. Pour un admin, availableGroups = tous les groupes triés par nom (storage.ts:433). Le Select 'Magasin' (L553) n'a pas de valeur par défaut et `selectedStoreId` n'est pas utilisé.
+- **Impact :** Un admin qui travaille sur le magasin B et ne touche pas le Select crée le ticket dans le magasin A. Le ticket disparaît ensuite de sa vue filtrée sur B.
+- **Recommandation :** Initialiser `formData.groupId` avec `selectedStoreId` (ou le seul magasin de l'utilisateur) à l'ouverture de la modale. Supprimer le repli `|| 1`.
+
+### SAV-08
+
+**Le formulaire 'Nouveau Ticket' est pré-rempli avec le dernier ticket ouvert en modification** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:400`
+- **Constat :** handleEditTicket (L397-412) fait `setFormData({ supplierId: ticket.supplierId.toString(), ... })`. La modale d'édition se ferme sans réinitialisation (L1334 `setShowEditModal(false)`), et la modale de création lit le même état `formData` (L506, 516, 527...). Seul le succès de création le réinitialise (L173).
+- **Impact :** Après avoir ouvert un ticket en modification, 'Nouveau Ticket' affiche les données de l'ancien ticket. Risque de créer un doublon ou un ticket mélangé.
+- **Recommandation :** Préférer des états séparés (editFormData / createFormData), ou réinitialiser formData à la fermeture de la modale d'édition. Ne pas le réinitialiser à l'ouverture de la création : on perdrait le brouillon de création que l'utilisateur garde aujourd'hui quand il ferme et rouvre.
+
+### SAV-09
+
+**DELETE : aucun contrôle d'appartenance au magasin** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:5446`
+- **Constat :** routes.ts:5446 `const user = await storage.getUser(userId);` puis 5452 `if (!['admin', 'directeur'].includes(user.role))` puis directement 5463 `await storage.deleteSavTicket(ticketId);`. Contrairement au GET/PATCH (5304-5310, 5411-5417), userGroups n'est pas vérifié.
+- **Impact :** Un directeur peut supprimer définitivement un ticket d'un autre magasin en devinant un id.
+- **Recommandation :** Utiliser req.user (qui contient déjà userGroups) et vérifier `userGroupIds.includes(existingTicket.groupId)` pour les non-admin, comme dans le PATCH.
+
+### SAV-10
+
+**Chaque route SAV recharge l'utilisateur et ses magasins déjà fournis par la session** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:5245`
+- **Constat :** localAuth.ts:141-143 `passport.deserializeUser(async (id) => { const user = await storage.getUserWithGroups(id); ...` (idem localAuth.production.ts:193-195). Pourtant routes.ts:5245, 5291, 5322, 5393, 5474, 5527 refont `await storage.getUserWithGroups(userId)` (2 requêtes séquentielles : storage.ts:372 getUser puis 376 user_groups). Les PATCH, DELETE et history (5404, 5457, 5485) chargent aussi le ticket complet avec 3 jointures et l'historique, uniquement pour lire groupId/status.
+- **Impact :** Au montage de la page (tickets + stats), 4 requêtes SQL inutiles s'ajoutent. Chaque mutation coûte 3 à 5 allers-retours BD au lieu de 1 à 2, soit +5 à 20 ms par appel selon la latence Postgres.
+- **Recommandation :** Utiliser directement `req.user` (déjà de type UserWithGroups) dans les routes SAV. Pour les contrôles d'accès, ajouter une méthode légère `getSavTicketAccessInfo(id)` qui fait `select({ groupId, status }).from(savTickets).where(eq(id))`.
+
+### SAV-11
+
+**Statistiques SAV : 3 requêtes séquentielles au lieu d'une seule** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:2832`
+- **Constat :** storage.ts:2832-2855 : `await db.select({count, status})...groupBy(status)`, puis `await db.select({count, priority})...groupBy(priority)`, puis `await db.select({ count: sql`count(*)` })...`. Les trois sont awaités l'un après l'autre. La variable `baseQuery` (L2825-2829) est construite puis jamais utilisée.
+- **Impact :** Trois allers-retours BD par affichage de la page (plus les 2 de getUserWithGroups), ce qui retarde l'apparition des compteurs.
+- **Recommandation :** Une seule requête avec `count(*) filter (where ...)` qui garde exactement la sémantique actuelle : total ; new = 'nouveau' ; in_progress = en_cours/attente_pieces/attente_echange ; resolved = resolu/ferme ; critical = priority='critique' sans condition de statut. Convertir les résultats avec Number() (node-postgres renvoie count en chaîne). Supprimer baseQuery. Changer la définition de 'Critiques' seulement dans le cadre de SAV-22.
+
+### SAV-12
+
+**Schéma N+1 : un appel getSavTicketHistory par ticket de la liste** — perf-serveur, sévérité moyenne, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:2704`
+- **Constat :** storage.ts:2704-2715 `await Promise.all(results.map(async (result) => { const history = await this.getSavTicketHistory(result.ticket.id); ... }))`. La fonction est aujourd'hui un no-op (`return []`), mais réactiver l'historique (SAV-02) produira N requêtes SQL pour N tickets. La liste n'utilise l'historique que pour hasRecentComments (SavTickets.tsx:383-394).
+- **Impact :** Une fois l'historique réactivé, 200 tickets donnent 201 requêtes par affichage et par changement de filtre. Aujourd'hui, ce sont N promesses inutiles et un champ history vide sérialisé.
+- **Recommandation :** Pour l'instant, se contenter de supprimer l'appel no-op dans la liste et renvoyer `history: []` (même format pour le client, hasRecentComments continue de marcher). Concevoir lastCommentAt (sous-requête ou inArray groupé) en même temps que la recréation de la table (SAV-02), pas avant.
+
+### SAV-13
+
+**Liste sans pagination ni limite, rendue entièrement en cartes** — perf-api, sévérité moyenne, effort M
+
+- **Fichier :** `server/storage.ts:2701`
+- **Constat :** storage.ts:2701 `const results = await query.orderBy(desc(savTickets.createdAt));` sans limit/offset. Côté client, SavTickets.tsx:840 `{filteredTickets.map((ticket) => { ... <Card> ...` rend toutes les cartes dans une grille 3 colonnes, tickets fermés compris.
+- **Impact :** Le volume grossit indéfiniment (les tickets fermés ne sont jamais archivés) : temps de réponse, poids JSON et rendu DOM augmentent chaque mois, et la page devient longue à défiler.
+- **Recommandation :** Ajouter `limit`/`offset` (ou un curseur sur created_at) côté serveur avec un total. Côté client, afficher 30 tickets puis 'Charger plus' (useInfiniteQuery). Par défaut, exclure les tickets 'ferme' (voir SAV-24).
+
+### SAV-14
+
+**Chaque changement de filtre vide la liste et affiche un spinner (aucun placeholderData)** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:97`
+- **Constat :** L95-101 : la clé change à chaque filtre (`queryKey: [ticketsUrl, selectedStoreId]`) sans `placeholderData`. L827 `{isLoading ? (<div className="animate-spin ..."/> <p>Chargement des tickets...</p>)`. Les filtres statut/priorité/fournisseur sont envoyés au serveur (L86-88), alors que la recherche texte est faite côté client (L445-455) sur la même liste.
+- **Impact :** À chaque clic sur un filtre, la grille disparaît, un spinner s'affiche, puis un aller-retour serveur complet a lieu (avec le payload lourd de SAV-05). L'interface paraît lente et saute visuellement.
+- **Recommandation :** Partie auto-applicable : seulement `placeholderData: keepPreviousData`. Le passage à un filtrage entièrement côté client (une seule requête par magasin) dépend de SAV-13 (pagination) et n'est pas mécanique.
+
+### SAV-15
+
+**console.log de debug exécutés à chaque rendu (chaque frappe clavier)** — dette-code, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:294`
+- **Constat :** `const availableGroups = getUserGroups();` (L314) est appelé dans le corps du composant. getUserGroups loggue `console.log('🎫 [CLIENT] Admin user - can access all groups:', ...)` (L294) ou un objet complet avec username et groupes (L304-309). D'autres logs dans handleCreateTicket (L330-335, L340, L358-365) affichent les données du ticket et du client. Le filtrage `groupsData.filter(...)` est aussi recalculé à chaque rendu, alors que /api/groups renvoie déjà uniquement les magasins de l'utilisateur non admin (routes.ts:983).
+- **Impact :** Chaque caractère tapé dans la recherche ou le formulaire produit un log : console saturée, ralentissement perceptible avec les DevTools ouverts, données client (nom, téléphone) exposées dans la console.
+- **Recommandation :** Supprimer tous les console.log de la page. Remplacer getUserGroups par `const availableGroups = groupsData` (le serveur filtre déjà), ou utiliser `stores` de StoreContext, mémorisé avec useMemo.
+
+### SAV-18
+
+**Codes techniques, anglais et emojis affichés à l'utilisateur** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:1034`
+- **Constat :** L1034 `<p>{displayedTicket.problemType}</p>` affiche 'pieces_manquantes'/'defectueux'. L1160 `{entry.action === 'comment' ? 'Commentaire' : entry.action}` affiche 'status_change'. routes.ts:5428 `description: `Statut changé de "${existingTicket.status}" vers "${req.body.status}"`` produit 'de "en_cours" vers "resolu"'. L871 `{ticket.clientName || 'N/A'}`. L875 `📞 {ticket.clientPhone}` et L889 `📦 {ticket.productGencode}` mélangent emojis et icônes lucide.
+- **Impact :** Un employé non technicien lit des codes informatiques et de l'anglais ('N/A') : la compréhension baisse et l'interface paraît peu finie.
+- **Recommandation :** Créer un `problemTypeConfig` (Défectueux, Pièces manquantes, Non conforme, Autre) réutilisé partout. Traduire les actions d'historique ('Changement de statut'). Côté serveur, utiliser les libellés français dans la description. Remplacer 'N/A' par 'Client non renseigné', et les emojis par les icônes Phone/Barcode de lucide.
+
+### SAV-19
+
+**Modale de suivi trop chargée : 'Actions Rapides' coupé en bas sur écran de portable** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:966`
+- **Constat :** L966 `<DialogContent className="max-w-6xl max-h-[90vh] overflow-hidden">`. La colonne gauche (L975 `<div className="space-y-4">`, sans overflow) empile 5 Cards (Produit, Client, Problème, Informations Ticket, Actions Rapides), soit environ 900 px. Seule la colonne droite défile (L1150 `overflow-y-auto max-h-[70vh]`). En dessous de lg, `grid-cols-1` place les deux colonnes l'une sous l'autre dans un conteneur overflow-hidden.
+- **Impact :** Sur un écran 1366x768 ou une tablette, la carte 'Actions Rapides' (changer le statut, l'action principale) est invisible et inatteignable. L'utilisateur ne trouve pas comment clôturer un ticket.
+- **Recommandation :** Mettre `overflow-y-auto` sur DialogContent. Placer Statut et Priorité en haut de la modale (juste sous le titre), et fusionner Produit, Client et Problème en une seule carte compacte de type 'définition'.
+
+### SAV-20
+
+**Cartes non cliquables malgré cursor-pointer ; actions en icônes minuscules sans libellé** — accessibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:846`
+- **Constat :** L846 `<Card ... className={`hover:shadow-md transition-shadow cursor-pointer ...`}>` sans onClick. Les actions (L923-950) sont des boutons `className="text-xs h-7"` contenant seulement `<ClipboardList className="h-3 w-3" />`, `<Edit .../>`, `<Trash2 .../>`. Seul le premier a un `title`, et aucun n'a d'aria-label.
+- **Impact :** L'utilisateur clique sur la carte et rien ne se passe. Il doit deviner que l'icône presse-papier signifie 'Suivi'. Les cibles de 28 px sur des icônes de 12 px sont difficiles à viser, et les lecteurs d'écran annoncent 'bouton' sans nom.
+- **Recommandation :** Partie auto-applicable : ajouter aria-label et title ('Suivi du ticket', 'Modifier', 'Supprimer') sur les 3 boutons. Mettre `onClick={() => handleViewTicket(ticket)}` sur la Card, avec `e.stopPropagation()` dans les onClick des boutons Modifier/Supprimer/Suivi, ce qui rend réel le comportement déjà suggéré par cursor-pointer. Le menu ⋮ et l'agrandissement des boutons restent à décider côté design.
+
+### SAV-22
+
+**Compteurs trompeurs et non cliquables (Critiques inclut les tickets clos, Résolus inclut Fermés)** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:2882`
+- **Constat :** storage.ts:2879-2884 : `if (result.priority === 'critique') stats.criticalTickets = count;` sans condition de statut. L2873 : `['resolu', 'ferme']` est compté dans resolvedTickets. Côté UI (SavTickets.tsx:703-750), 5 Cards statiques sans onClick, alors que le filtre propose 6 statuts différents.
+- **Impact :** Le compteur rouge 'Critiques' reste élevé alors que tous les tickets critiques sont résolus, ce qui crée une fausse alerte. L'utilisateur ne peut pas cliquer sur 'En cours' pour voir ces tickets.
+- **Recommandation :** Ne compter que les tickets critiques ouverts. Rendre chaque carte compteur cliquable pour appliquer le filtre correspondant. Réduire à 4 compteurs utiles : À traiter, En attente, Urgents ouverts, Clôturés ce mois.
+
+### SAV-23
+
+**Pas d'état d'erreur, état vide sans action, et compteurs qui apparaissent en décalant la page** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:832`
+- **Constat :** L97 `const { data: ticketsData = [], isLoading } = useQuery(...)` : isError n'est jamais lu. Si l'API échoue, L832-836 affiche 'Aucun ticket trouvé'. Cet état vide ne distingue pas 'aucun ticket' de 'aucun résultat pour ces filtres' et ne propose ni 'Créer un ticket' ni 'Réinitialiser les filtres'. L703 `{statsData && (<div className="grid ...">` insère les 5 cartes après chargement, ce qui pousse filtres et liste vers le bas.
+- **Impact :** Pendant une panne, l'utilisateur croit qu'il n'y a pas de SAV. Après un filtrage sans résultat, il ne sait pas quoi faire. Le saut de mise en page provoque des clics ratés.
+- **Recommandation :** Afficher un encart d'erreur avec un bouton 'Réessayer' quand isError est vrai. Proposer un état vide contextuel avec une action ('Effacer les filtres' ou 'Créer un ticket'). Réserver la place des compteurs avec des Skeleton de même hauteur pendant le chargement.
+
+### MSAV-06
+
+**Libellés et couleurs de statut différents du desktop ; statut 'attente_echange' affiché brut** — coherence-design, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/mobile/SavPage.tsx:165`
+- **Constat :** L169 `case "attente_pieces": ... >Pièces</Badge>` contre 'Attente pièces' sur desktop (SavTickets.tsx:39). Il n'y a pas de cas 'attente_echange', d'où `default: return <Badge variant="outline">{status}</Badge>` (L172) qui affiche le code. Le menu L234 écrit 'Attente Pièces' (majuscule). Le header et le FAB sont violets (L181 `text-purple-600`, L398 `bg-purple-600`), alors que le desktop utilise le bleu/primary (SavTickets.tsx:464).
+- **Impact :** Un même ticket a un libellé différent selon l'appareil, et un code technique apparaît : la confiance et la compréhension s'en ressentent.
+- **Recommandation :** Partie auto-applicable : extraire statusConfig/priorityConfig/problemTypeConfig dans client/src/lib/savConfig.ts et les utiliser dans les deux pages (libellés français identiques, cas attente_echange inclus). Ne pas toucher aux couleurs d'accent mobile sans décision de design globale.
+
+### MSAV-07
+
+**Jargon 'Gencode (EAN13)' et placeholder 'Scanner...' sans scanner** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/mobile/SavPage.tsx:284`
+- **Constat :** L284-285 `<FormLabel>Gencode (EAN13)</FormLabel><FormControl><Input placeholder="Scanner..." .../>`. L'icône Camera est importée (L19) mais aucune fonction de scan n'existe. Le desktop dit 'Code-barres produit' (SavTickets.tsx:503).
+- **Impact :** Le terme technique et la promesse d'un scan inexistant déroutent l'utilisateur, qui cherche un bouton caméra.
+- **Recommandation :** Libellé 'Code-barres du produit', placeholder 'Ex. 3017620422003'. Ajouter un vrai bouton de scan plus tard, ou retirer la mention 'Scanner'.
+
+### MSAV-08
+
+**Imports inutilisés et requêtes chargées au montage pour un formulaire fermé** — dette-code, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/mobile/SavPage.tsx:100`
+- **Constat :** Imports inutilisés : `Filter, Camera, Image as ImageIcon, CheckCircle, XCircle` (L18-23) et `FormMessage` (L51). `useQuery(['/api/groups'])` (L100-103) ne sert qu'au repli `groups[0].id` de onSubmit (L145), et `/api/suppliers` (L95-98) ne sert qu'au formulaire. Les deux sont chargés au montage sans staleTime spécifique.
+- **Impact :** Deux requêtes réseau inutiles à chaque ouverture de la page sur mobile (connexion souvent lente), et du code mort.
+- **Recommandation :** Supprimer les imports morts. Remplacer useQuery('/api/groups') par `stores` de useStore(), qui contient les mêmes données (MobileApp.tsx). Mettre staleTime 10 min sur les fournisseurs. Ne pas conditionner les fournisseurs à l'ouverture de la Sheet.
+
+### MSAV-09
+
+**Erreur ou absence de magasin sélectionné affichée comme 'Aucun ticket SAV'** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/mobile/SavPage.tsx:202`
+- **Constat :** L84-93 : `isError` n'est jamais lu. Avec `enabled: !!selectedStoreId && !!user`, un admin en 'Tous les magasins' voit isLoading=false et la liste vide. L202-206 affiche alors 'Aucun ticket SAV'. Par ailleurs, L216 `format(new Date(ticket.createdAt), "dd/MM")` omet l'année et lève une exception si la date est invalide.
+- **Impact :** Panne réseau, magasin non choisi et absence réelle de ticket produisent le même message : l'utilisateur ne sait pas quoi faire.
+- **Recommandation :** Distinguer trois états : erreur ('Impossible de charger, Réessayer'), aucun magasin choisi ('Choisissez un magasin') et liste vide (avec bouton 'Créer un ticket'). Utiliser safeFormat avec 'dd/MM/yy'.
+
+### SAV-16
+
+**Logs console sur chaque requête GET SAV (chemin chaud)** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:5258`
+- **Constat :** routes.ts:5258 `console.log(`🎫 [SAV] Admin filtering by selected store: ${selectedGroupId}`)`, 5261, 5267 `console.log(`🎫 [SAV] User ${user.username} (${user.role}) can see stores:`, groupIds)`. De même pour les stats (5540, 5543, 5549) et la création (5337, 5341, 5354, 5374-5379).
+- **Impact :** Deux à trois lignes de log par affichage de page, en plus du log HTTP global. Cela pollue les logs de production et coûte en I/O synchrone sur stdout.
+- **Recommandation :** Supprimer ces console.log ou les passer derrière un logger de niveau debug désactivé en production.
+
+### SAV-17
+
+**Requête de détail déclarée deux fois, plus fetch manuels incohérents** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:376`
+- **Constat :** L142-146 `useQuery({ queryKey: [`/api/sav/tickets/${selectedTicket?.id}`], staleTime: 0 })` et L376-380, même clé, résultat `ticketDetails` jamais utilisé. Les stats utilisent un `fetch` manuel (L121-136) et la création un `fetch` brut (L154-167), alors que les autres mutations utilisent apiRequest. Le détail renvoie les mêmes données que la liste (history toujours []) et staleTime 0 force un appel à chaque ouverture.
+- **Impact :** Code plus difficile à maintenir, gestion d'erreur/401 incohérente entre les appels, et une requête réseau à chaque ouverture de ticket sans gain d'information.
+- **Recommandation :** Partie sûre : supprimer le second useQuery (L376-380), qui est placé avant le return conditionnel, donc sans risque pour l'ordre des hooks. Ne pas remplacer le fetch de création par apiRequest sans extraire le `message` du JSON d'erreur. placeholderData et staleTime 30 s pour le détail sont acceptables, puisque les mutations invalident explicitement la clé du détail.
+
+### SAV-21
+
+**Badges ambigus : 'Nouveau' commentaire contre statut 'Nouveau', couleurs priorité/statut qui se chevauchent** — coherence-design, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:856`
+- **Constat :** L853-857 badge orange `<MessageCircle/> Nouveau` pour un commentaire récent, alors que le statut 'nouveau' affiche aussi 'Nouveau' (L37, bleu). priorityConfig.normale = 'bg-blue-100 text-blue-800' (L47) a la même couleur que le statut 'Nouveau' (L37). priorityConfig.haute = 'bg-orange-100' (L48) a la même couleur que 'Attente pièces' (L39). La suppression utilise une modale maison (L1356-1394) au lieu du composant partagé `ConfirmationModal` utilisé par Avoirs, DlcPage et CustomerOrders.
+- **Impact :** Sur une carte, deux badges bleus ou deux badges orange ne permettent pas de distinguer statut et priorité. Le mot 'Nouveau' a deux sens, et les confirmations n'ont pas le même aspect d'une page à l'autre.
+- **Recommandation :** Pour harmoniser la suppression, utiliser AlertDialog comme Avoirs et DlcPage, pas ConfirmationModal. Renommer le badge en 'Nouveau message' seulement quand l'historique sera réactivé. Le code couleur de la priorité est un choix de design.
+
+### SAV-24
+
+**Changement de statut/priorité enregistré immédiatement, sans confirmation, avec un message inexact** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:1123`
+- **Constat :** L1099-1104 et L1123-1128 : `onValueChange={(value) => { setTempStatus(value); updateTicketMutation.mutate({ ticketId, status: value }); }}`, y compris pour 'ferme'. Le toast de succès dit toujours 'Le statut du ticket a été modifié avec succès.' (L249), même pour une priorité. En cas d'erreur (L252-258), tempStatus/tempPriority ne sont pas remis à zéro et le Select affiche une valeur non enregistrée. La mutation prévoit `resolutionDescription` (L231-235) mais aucun champ ne permet de la saisir.
+- **Impact :** Un mauvais clic ferme un ticket. Le message de succès ne correspond pas à l'action, et l'affichage peut mentir après une erreur.
+- **Recommandation :** Demander une confirmation (et un champ 'Comment le problème a été résolu ?') quand le statut passe à Résolu ou Fermé. Adapter le texte du toast à la priorité. Réinitialiser tempStatus/tempPriority dans onError.
+
+### SAV-25
+
+**Les tickets fermés sont mélangés aux tickets à traiter par défaut** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:59`
+- **Constat :** L59 `const [statusFilter, setStatusFilter] = useState("all");`. Les tickets fermés sont simplement grisés (L846 `${ticket.status === 'ferme' ? 'opacity-60' : ''}`) et triés uniquement par date de création (storage.ts:2701).
+- **Impact :** Au fil des mois, la page se remplit de tickets clos et les tickets urgents ouverts se perdent dans la grille.
+- **Recommandation :** Ajouter un filtre par défaut 'Ouverts' (nouveau, en cours, attente) avec des onglets simples 'À traiter / En attente / Clôturés'. Trier les tickets ouverts par priorité puis par ancienneté.
+
+### SAV-26
+
+**Numéros de ticket dupliqués possibles (count(*) + 1) et génération en double** — bug, sévérité basse, effort S
+
+- **Fichier :** `server/storage.ts:2750`
+- **Constat :** storage.ts:2750-2755 `count(*) ... where EXTRACT(year from created_at) = ${currentYear}` puis `SAV-${currentYear}-${count + 1}`. Après une suppression ou deux créations simultanées, le même numéro est réattribué. schema.ts:871 `ticketNumber: varchar(...).notNull()` n'a pas de contrainte unique. La route génère déjà un autre numéro (routes.ts:5350 `SAV-YYYYMMDD-xxxxxx`), qui est écrasé (code mort). EXTRACT(year ...) empêche aussi l'usage de l'index created_at.
+- **Impact :** Deux tickets peuvent porter le même numéro communiqué au client ou au fournisseur, d'où confusion et recherche ambiguë.
+- **Recommandation :** Corriger aussi la conversion : `Number(count[0]?.count ?? 0) + 1`. Vérifier en base les numéros existants avant de choisir une séquence ou une contrainte UNIQUE, car des doublons existants feraient échouer l'ajout de la contrainte.
+
+### SAV-27
+
+**Index SAV absents du schéma Drizzle, pas d'index composite magasin+date ni fournisseur** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `shared/schema.ts:869`
+- **Constat :** schema.ts:869-889 `pgTable("sav_tickets", {...})` sans 3e argument d'index, alors que la table session en déclare (schema.ts:28). Les index n'existent que dans init.sql:536-539 (status, priority, group_id, created_at séparés). La requête principale fait `WHERE group_id IN (...) ORDER BY created_at DESC`, plus éventuellement `supplier_id = ?` (storage.ts:2679, 2685, 2701).
+- **Impact :** Sur une base créée par `npm run db:push`, aucun index n'existe. Même avec init.sql, le tri par date après filtre magasin et le filtre fournisseur ne sont pas couverts.
+- **Recommandation :** Si on veut l'index composite, l'ajouter par `CREATE INDEX IF NOT EXISTS idx_sav_tickets_group_created ON sav_tickets(group_id, created_at DESC)` dans migrations.production.ts et init.sql, et éventuellement le refléter dans schema.ts. C'est une modification de base de données, à valider : pas d'application automatique.
+
+### SAV-28
+
+**Formulaire de création : fournisseur sans recherche et validation non localisée** — ux-simplicite, sévérité basse, effort M
+
+- **Fichier :** `client/src/pages/SavTickets.tsx:536`
+- **Constat :** L536-546 `<Select value={formData.supplierId}>` avec `{suppliersData.map(...)}` liste tous les fournisseurs sans champ de recherche. Idem pour le filtre (L789-801). Validation L318-325 : un seul toast 'Veuillez remplir tous les champs obligatoires.' sans indiquer lequel ni le mettre en rouge. La modale (L480-695) répartit 10 champs dans 3 Cards avec titres et descriptions.
+- **Impact :** Choisir un fournisseur dans une longue liste est laborieux, et l'utilisateur ne sait pas quel champ manque.
+- **Recommandation :** Utiliser un Combobox (Command de shadcn) avec recherche pour le fournisseur. Valider avec react-hook-form + zod (comme la page mobile) et afficher l'erreur sous chaque champ. Alléger la modale en 2 blocs : 'Produit et problème' (obligatoires) puis 'Client (facultatif)' repliable.
+
+### SAV-29
+
+**Pages SAV desktop et mobile importées statiquement dans le bundle initial** — perf-bundle, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:25`
+- **Constat :** RouterProduction.tsx:25 `import SavTickets from "@/pages/SavTickets";` et :43 `import MobileSavPage from "@/pages/mobile/SavPage";`, sans React.lazy. Les deux versions sont donc chargées pour tous les utilisateurs, quel que soit l'appareil.
+- **Impact :** Environ 1 800 lignes de JSX (plus react-hook-form/zod côté mobile) chargées au démarrage même si l'utilisateur n'ouvre jamais le SAV, ce qui ralentit le premier affichage.
+- **Recommandation :** Appliquer lazy() à toutes les pages en une fois, avec un seul Suspense placé à l'intérieur de Layout et de MobileApp autour du Switch, plutôt qu'au cas par cas pour le SAV. Le gain pour le seul SAV est marginal.

docs/audit-webui/07-customer-orders.md

@@ -0,0 +1,492 @@
+# Commandes clients
+
+_43 constats vérifiés — 7 haute, 23 moyenne, 13 basse._
+
+## Pages analysées
+
+### `/customer-orders (desktop)`
+
+**Rôle :** Suivre les commandes passées par les clients du magasin (produit non en stock commandé au fournisseur) : de la prise de commande jusqu'au retrait par le client, avec rappel du client quand le produit est disponible et impression d'une étiquette/fiche à code-barres.
+
+**Tâches principales de l'utilisateur :**
+- Créer une commande client (nom, téléphone, produit via recherche gencode/référence, fournisseur, acompte)
+- Retrouver une commande (recherche texte, filtre fournisseur, filtre statut)
+- Faire avancer le statut (En attente -> En cours -> Disponible -> Retiré / Annulé)
+- Voir la liste des clients à appeler (bandeau orange + modale) et marquer un client comme contacté avec commentaire
+- Imprimer la fiche/étiquette d'une commande disponible
+- Consulter le détail, modifier, supprimer une commande
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/customer-orders[?storeId=X] (storeId seulement si admin) | au montage + à chaque changement de magasin + après chaque mutation (invalidate/refetch) | server/routes.ts:3486 -> storage.getUserWithGroups (storage.ts:371) + storage.getCustomerOrders (storage.ts:1868) | Renvoie TOUTES les commandes (historique Retiré/Annulé inclus) sans pagination, avec la ligne groups complète (logo base64, SMTP, NocoDB) et la ligne suppliers complète par commande. Filtrage/tri/pagination faits côté client. Même liste aussi téléchargée par Dashboard.tsx:81-93 juste pour compter par statut. |
+| GET /api/customer-orders/pending-calls?storeId=X | au montage + polling toutes les 30 s (refetchInterval: 30000), fetch() manuel dans queryFn | server/routes.ts:3638 -> storage.getUserWithGroups + storage.getPendingClientCalls (storage.ts:1931) | Sous-ensemble de la liste déjà chargée (status Disponible && !customerNotified). 403 systématique pour le rôle employee mais la requête est quand même lancée (avec 2 retries) toutes les 30 s. storeId ignoré côté serveur pour directeur/manager. |
+| GET /api/suppliers | au montage (filtre fournisseur) + dans CustomerOrderForm (même clé, dédupliqué) | server/routes.ts:1141 -> storage.getUser + storage.getSuppliers (storage.ts:467) | Liste complète des fournisseurs, même ceux sans commande client. |
+| GET /api/groups | au montage (CustomerOrders.tsx:69) + CustomerOrderForm.tsx:76 | server/routes.ts:970 -> storage.getUserWithGroups + storage.getGroups (storage.ts:432) | Résultat jamais utilisé dans CustomerOrders.tsx (variable groups morte) ; servi par le cache du Layout. |
+| POST /api/customer-orders | au clic Créer | server/routes.ts:3517 -> storage.createCustomerOrder (storage.ts:1913) | Aucune validation Zod (insertCustomerOrderSchema importé mais inutilisé), req.body inséré tel quel ; ~12 console.log de debug dont le body complet (données personnelles client). |
+| PUT /api/customer-orders/:id | au clic Modifier (formulaire), changement de statut, 'Annuler le contact' | server/routes.ts:3577 -> storage.getCustomerOrder (storage.ts:1892, 2 jointures + logo) + storage.updateCustomerOrder (storage.ts:1918) | Pas de contrôle de rôle (employee peut modifier malgré la matrice de permissions), req.body passé directement à .set() (groupId, createdBy modifiables). |
+| DELETE /api/customer-orders/:id | au clic Supprimer (après confirmation) | server/routes.ts:3607 -> storage.getCustomerOrder + storage.deleteCustomerOrder (storage.ts:1927) | Pas de contrôle de rôle serveur : un manager (sans droit delete) peut supprimer via l'API. |
+| PATCH /api/customer-orders/:id/mark-called | au clic Confirmer (modale contact) ou 'Marquer Appelé' (ClientCallsModal) | server/routes.ts:3674 -> storage.getCustomerOrder + storage.markClientCalled (storage.ts:1961) | 403 pour employee alors que le bouton téléphone est affiché à tous et que la mutation n'a pas de onError (échec silencieux). |
+| GET /api/ffnancy/articles?ean\|codein&limit=1 puis GET /api/ffnancy/mouvements/entrees?artNoId=... | au clic sur la loupe gencode/référence du formulaire (2 appels séquentiels) | server/routes.ts:6396 et 6411 (proxy fetch vers api.ffnancy.fr, sans timeout ni cache) | Waterfall de 2 allers-retours externes ; une erreur réseau est présentée comme 'Produit non référencé' et bloque la création. |
+
+**Lisibilité / simplicité :** Page fonctionnelle mais dense et peu guidante : bandeau d'alerte collant au-dessus du titre, carte 'Recherche et Filtres' avec titre inutile, tableau de 9 colonnes sans défilement horizontal, 4 à 5 boutons-icônes sans libellé par ligne (dont l'ensemble varie selon le statut), statut modifiable en cliquant sur un badge (non découvrable, non accessible clavier) avec application immédiate y compris 'Annulé'. Pas d'état vide ni d'état d'erreur ('Chargement...' en texte brut). Libellés mélangés (option 'Status' en anglais, 'Fournisseurs' comme valeur 'tous', 'Gencode', 'Marquer Appelé' vs 'Marquer client comme contacté'). Formulaire de création/modification affiché à 90 % (transform scale) sans hauteur max : texte réduit et bouton Créer hors écran sur portable ; fournisseur n°1 présélectionné silencieusement ; le champ gencode (qui pré-remplit tout) arrive après la désignation. Modale Détails trompeuse (faux code-barres 'scannable', bloc 'Actions disponibles' sans bouton, notes et commentaire d'appel non affichés). Plusieurs bugs de données graves en modification (statut remis à 'En attente', commande déplacée de magasin, notes effacées). Console polluée de logs de debug.
+
+### `/customer-orders (mobile)`
+
+**Rôle :** Version téléphone des commandes clients : consulter la liste du magasin sélectionné, appeler le client, marquer contacté, changer rapidement le statut et créer une commande depuis le rayon.
+
+**Tâches principales de l'utilisateur :**
+- Rechercher une commande (client, produit, référence)
+- Appeler le client (lien tel:) et le marquer comme contacté avec commentaire
+- Passer une commande en Disponible / Retiré / Annulé via le menu ⋮
+- Créer une commande via le bouton flottant (+) et la feuille 'Nouvelle Commande'
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/customer-orders?storeId=X | au montage, uniquement si selectedStoreId (enabled: !!selectedStoreId && !!user), fetch() manuel | server/routes.ts:3486 -> storage.getCustomerOrders (storage.ts:1868) | Même payload lourd que desktop (group complet avec logo par commande). Clé ['/api/customer-orders', selectedStoreId] identique à la clé desktop non-admin mais données différentes (filtrées par magasin ici, pas sur desktop). |
+| GET /api/suppliers | au montage, queryFn manuelle sans contrôle res.ok | server/routes.ts:1141 -> storage.getSuppliers (storage.ts:467) | Chargé même si la feuille de création n'est jamais ouverte (pourrait être enabled: isCreateOpen). |
+| GET /api/groups | au montage (déjà en cache via MobileApp) | server/routes.ts:970 -> storage.getGroups (storage.ts:432) | Utilisé seulement pour un fallback admin dans onSubmit. |
+| PUT /api/customer-orders/:id | au clic Marquer Disponible / Retiré / Annuler (menu ⋮) et 'Annuler le contact' | server/routes.ts:3577 -> storage.getCustomerOrder + storage.updateCustomerOrder (storage.ts:1918) | Aucune confirmation, aucun onError, accessible aux employés (pas de droit edit). |
+| PATCH /api/customer-orders/:id/mark-called | au clic Confirmer dans la feuille contact | server/routes.ts:3674 -> storage.markClientCalled (storage.ts:1961) | 403 silencieux pour les employés. |
+| POST /api/customer-orders | au clic 'Valider la commande' | server/routes.ts:3517 -> storage.createCustomerOrder (storage.ts:1913) | isPromotionalPrice et customerNotified perdus (retirés par zodResolver). |
+| GET /api/ffnancy/articles puis /api/ffnancy/mouvements/entrees | au clic loupe référence/gencode (2 appels séquentiels) | server/routes.ts:6396 et 6411 | Code dupliqué à l'identique de CustomerOrderForm.tsx. |
+
+**Lisibilité / simplicité :** Cartes lisibles avec action 'Appeler' bien visible, mais : liste vide 'Aucune commande trouvée' dès que 'Tous les magasins' est sélectionné (requête désactivée), aucun filtre par statut ni séparation des commandes terminées (Retiré/Annulé mélangées aux actives), pas de pagination, menu ⋮ incomplet (pas 'Commande en cours') avec un 'Annuler' ambigu et sans confirmation, pas de bandeau 'clients à appeler'. Formulaire de création dupliqué du desktop, sans messages d'erreur de validation (FormMessage importé mais jamais rendu), cases 'Prix promotionnel' et 'Client déjà notifié' sans effet. Libellés abrégés ou fautifs ('Qty', 'Qté', 'Cmd Client', 'rév...'), date sans année, montant d'acompte non formaté, modale contact faite main (pas de focus/Échap).
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [CMDCLI-01](#cmdcli-01) | haute | perf-api | S | Chaque commande embarque la fiche magasin complète (logo base64, SMTP, NocoDB) et la fiche fournisseur complète | `server/storage.ts:1873` |
+| [CMDCLI-02](#cmdcli-02) | haute | perf-api | L | Liste sans pagination ni filtre serveur : tout l'historique est téléchargé puis filtré/trié/paginé en JS | `server/routes.ts:3508` |
+| [CMDCLI-03](#cmdcli-03) | haute | bug | S | Modifier une commande remet toujours son statut à « En attente de Commande » | `client/src/components/CustomerOrderForm.tsx:143` |
+| [CMDCLI-04](#cmdcli-04) | haute | bug | S | Modifier une commande peut la déplacer dans un autre magasin | `client/src/components/CustomerOrderForm.tsx:127` |
+| [CMDCLI-07](#cmdcli-07) | haute | bug | M | Permissions non appliquées côté serveur et corps de requête non validé (PUT/POST/DELETE) | `server/routes.ts:3599` |
+| [CMDCLI-08](#cmdcli-08) | haute | bug | S | Impression d'étiquette : injection HTML/JS (XSS) via les champs de la commande | `client/src/pages/CustomerOrders.tsx:388` |
+| [CMDCLI-20](#cmdcli-20) | haute | ux-simplicite | S | Formulaire de commande réduit à 90 % par transform et modale sans hauteur max : texte petit, bouton Créer hors écran | `client/src/pages/CustomerOrders.tsx:971` |
+| [CMDCLI-05](#cmdcli-05) | moyenne | bug | S | Modifier une commande efface ses notes et l'email client ; les notes ne sont affichées nulle part | `client/src/components/CustomerOrderForm.tsx:147` |
+| [CMDCLI-06](#cmdcli-06) | moyenne | bug | S | Mobile : les cases « Prix promotionnel / Pub » et « Client déjà notifié » n'ont aucun effet | `client/src/pages/mobile/CustomerOrdersPage.tsx:67` |
+| [CMDCLI-09](#cmdcli-09) | moyenne | perf-api | S | Polling pending-calls lancé pour les employés alors que le serveur répond 403 (avec 2 retries toutes les 30 s) | `client/src/pages/CustomerOrders.tsx:74` |
+| [CMDCLI-10](#cmdcli-10) | moyenne | bug | S | Mutations sans gestion d'erreur : échecs silencieux (statut, contact client) | `client/src/pages/CustomerOrders.tsx:171` |
+| [CMDCLI-11](#cmdcli-11) | moyenne | perf-serveur | S | getUserWithGroups rappelé dans chaque handler alors que deserializeUser l'a déjà chargé (4 requêtes SQL séquentielles par appel) | `server/routes.ts:3488` |
+| [CMDCLI-14](#cmdcli-14) | moyenne | perf-client | M | Chaque changement de statut/contact recharge toute la liste au lieu de mettre à jour la ligne | `client/src/pages/CustomerOrders.tsx:175` |
+| [CMDCLI-15](#cmdcli-15) | moyenne | bug | S | « Marquer Appelé » depuis la modale ne rafraîchit pas le tableau pour un admin avec magasin sélectionné | `client/src/components/modals/ClientCallsModal.tsx:42` |
+| [CMDCLI-16](#cmdcli-16) | moyenne | ux-simplicite | S | Le sélecteur de magasin n'a aucun effet pour directeur/manager (et clé de cache partagée avec le mobile) | `client/src/pages/CustomerOrders.tsx:95` |
+| [CMDCLI-17](#cmdcli-17) | moyenne | perf-client | S | Filtre + tri de toute la liste recalculés à chaque rendu (y compris à chaque frappe dans le commentaire d'appel) | `client/src/pages/CustomerOrders.tsx:657` |
+| [CMDCLI-18](#cmdcli-18) | moyenne | lisibilite | S | Pas d'état vide, pas d'état d'erreur, chargement en texte brut | `client/src/pages/CustomerOrders.tsx:829` |
+| [CMDCLI-21](#cmdcli-21) | moyenne | ux-simplicite | M | Formulaire peu guidant : fournisseur n°1 présélectionné, gencode « obligatoire » non exigé, recherche produit placée après la désignation | `client/src/components/CustomerOrderForm.tsx:115` |
+| [CMDCLI-22](#cmdcli-22) | moyenne | ux-simplicite | S | Une panne de l'API article est affichée comme « Produit non référencé » et bloque la création | `client/src/components/CustomerOrderForm.tsx:169` |
+| [CMDCLI-24](#cmdcli-24) | moyenne | lisibilite | M | Tableau de 9 colonnes sans défilement horizontal, informations clés absentes, texte barré illisible | `client/src/pages/CustomerOrders.tsx:832` |
+| [CMDCLI-25](#cmdcli-25) | moyenne | accessibilite | S | Éléments cliquables non accessibles : badge de statut, bandeau d'alerte, boutons-icônes sans libellé | `client/src/pages/CustomerOrders.tsx:882` |
+| [CMDCLI-26](#cmdcli-26) | moyenne | ux-simplicite | S | Changement de statut appliqué immédiatement, y compris « Annulé », sans confirmation (et menu mobile incomplet) | `client/src/pages/CustomerOrders.tsx:1037` |
+| [CMDCLI-29](#cmdcli-29) | moyenne | ux-simplicite | S | Modale Détails trompeuse : faux code-barres « scannable », bloc d'actions sans bouton, infos d'appel absentes | `client/src/components/CustomerOrderDetails.tsx:126` |
+| [CMDCLI-30](#cmdcli-30) | moyenne | bug | S | Le code-barres imprimé peut différer du gencode du produit | `client/src/pages/CustomerOrders.tsx:309` |
+| [CMDCLI-31](#cmdcli-31) | moyenne | ux-simplicite | S | Mobile : « Aucune commande trouvée » dès que « Tous les magasins » ou aucun magasin n'est sélectionné | `client/src/pages/mobile/CustomerOrdersPage.tsx:91` |
+| [CMDCLI-32](#cmdcli-32) | moyenne | ux-simplicite | M | Mobile : erreurs de validation invisibles et formulaire dupliqué du desktop | `client/src/pages/mobile/CustomerOrdersPage.tsx:54` |
+| [CMDCLI-33](#cmdcli-33) | moyenne | perf-client | M | Mobile : toutes les commandes (historique compris) rendues d'un bloc, sans filtre de statut ni pagination | `client/src/pages/mobile/CustomerOrdersPage.tsx:270` |
+| [CMDCLI-39](#cmdcli-39) | moyenne | dette-code | S | Logs de debug en production, dont des données personnelles clients | `server/routes.ts:3530` |
+| [CMDCLI-40](#cmdcli-40) | moyenne | perf-serveur | S | Réponses JSON non compressées et recopiées récursivement à chaque envoi | `server/routes.ts:168` |
+| [CMDCLI-41](#cmdcli-41) | moyenne | perf-api | S | Les « clients à appeler » sont rechargés par un 2e endpoint polled alors qu'ils sont déjà dans la liste | `client/src/pages/CustomerOrders.tsx:74` |
+| [CMDCLI-12](#cmdcli-12) | basse | perf-serveur | S | PUT/DELETE/mark-called chargent la commande avec 2 jointures (et le logo) juste pour lire groupId | `server/routes.ts:3585` |
+| [CMDCLI-13](#cmdcli-13) | basse | perf-client | S | Création : invalidateQueries + refetchQueries en double (y compris caches inactifs) | `client/src/pages/CustomerOrders.tsx:110` |
+| [CMDCLI-19](#cmdcli-19) | basse | perf-client | S | Changement de magasin : écran « Chargement... » au lieu de garder la liste précédente | `client/src/pages/CustomerOrders.tsx:96` |
+| [CMDCLI-23](#cmdcli-23) | basse | perf-api | M | Recherche article : 2 appels externes séquentiels via un proxy sans timeout ni cache | `server/routes.ts:6402` |
+| [CMDCLI-27](#cmdcli-27) | basse | lisibilite | S | Libellés incohérents, en anglais ou abrégés | `client/src/pages/CustomerOrders.tsx:808` |
+| [CMDCLI-28](#cmdcli-28) | basse | coherence-design | S | Couleurs et listes de statuts dupliquées et divergentes (3 copies) | `client/src/components/CustomerOrderDetails.tsx:13` |
+| [CMDCLI-34](#cmdcli-34) | basse | dette-code | S | Mobile : queryFn manuels sans contrôle d'erreur au lieu du fetcher par défaut | `client/src/pages/mobile/CustomerOrdersPage.tsx:105` |
+| [CMDCLI-35](#cmdcli-35) | basse | lisibilite | S | Dates et montants mal formatés | `client/src/pages/mobile/CustomerOrdersPage.tsx:328` |
+| [CMDCLI-36](#cmdcli-36) | basse | accessibilite | S | Mobile : feuille « contact client » faite main (pas de focus, pas d'Échap, pas de rôle dialog) | `client/src/pages/mobile/CustomerOrdersPage.tsx:628` |
+| [CMDCLI-37](#cmdcli-37) | basse | ux-simplicite | S | Deux parcours différents pour « client contacté » (avec et sans commentaire) et double défilement | `client/src/components/modals/ClientCallsModal.tsx:25` |
+| [CMDCLI-38](#cmdcli-38) | basse | ux-simplicite | S | Mise en page chargée et tri incohérent (Retiré en fin de liste mais pas Annulé, tri non modifiable) | `client/src/pages/CustomerOrders.tsx:680` |
+| [CMDCLI-42](#cmdcli-42) | basse | perf-bundle | S | JsBarcode et la page importés en statique alors qu'ils ne servent qu'à l'impression | `client/src/pages/CustomerOrders.tsx:33` |
+| [CMDCLI-43](#cmdcli-43) | basse | dette-code | S | Code mort et contournements dans la page et le formulaire | `client/src/pages/CustomerOrders.tsx:69` |
+
+### CMDCLI-01
+
+**Chaque commande embarque la fiche magasin complète (logo base64, SMTP, NocoDB) et la fiche fournisseur complète** — perf-api, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:1873`
+- **Constat :** storage.ts:1870-1874 `.select({ customerOrder: customerOrders, supplier: suppliers, group: groups })` (idem getPendingClientCalls storage.ts:1945-1949 et getCustomerOrder 1894-1898). shared/schema.ts:67 `logo: text("logo"), // Logo en data URI (data:image/png;base64,...)` ; Groups.tsx:39 `const MAX_LOGO_KB = 200;` ; schema.ts:52-76 nocodb*, webhookUrl, smtpHost, smtpUser... Le client n'utilise que group.name/color et supplier.id/name.
+- **Impact :** Le logo (jusqu'à ~270 Ko en base64) est répété pour CHAQUE commande : 300 commandes d'un magasin avec logo = plusieurs dizaines de Mo de JSON non compressé, téléchargés à l'ouverture de la page, après chaque mutation, sur le Dashboard, et toutes les 30 s pour pending-calls. Expose aussi la config SMTP/NocoDB/webhook aux employés.
+- **Recommandation :** Sélectionner explicitement les colonnes utiles : `group: { id: groups.id, name: groups.name, color: groups.color }, supplier: { id: suppliers.id, name: suppliers.name }` dans getCustomerOrders, getCustomerOrder et getPendingClientCalls ; supprimer le mapping mort `creator: row.creator || {...}` (storage.ts:1886, row.creator n'est jamais sélectionné).
+
+### CMDCLI-02
+
+**Liste sans pagination ni filtre serveur : tout l'historique est téléchargé puis filtré/trié/paginé en JS** — perf-api, sévérité haute, effort L
+
+- **Fichier :** `server/routes.ts:3508`
+- **Constat :** routes.ts:3508 `const customerOrders = await storage.getCustomerOrders(groupIds);` sans limit/offset/status ; CustomerOrders.tsx:657-734 filtre, tri puis `usePagination(sortedOrders, 10)` côté client ; Dashboard.tsx:92-93 recharge la même liste et 381-386 ne fait que `customerOrders.filter(o => o.status === '...').length`.
+- **Impact :** Le temps de chargement croît indéfiniment avec l'historique (les commandes Retiré/Annulé ne sont jamais purgées de la réponse) alors que l'utilisateur ne voit que 10 lignes ; le Dashboard télécharge toute la liste pour afficher 5 compteurs.
+- **Recommandation :** Ajouter `?status=&supplierId=&q=&page=&limit=` à GET /api/customer-orders (WHERE + ILIKE + LIMIT/OFFSET + COUNT(*) OVER()), exclure par défaut Retiré/Annulé de plus de 30 jours, et créer GET /api/customer-orders/stats (SELECT status, COUNT(*) GROUP BY status) pour le Dashboard. Côté client : queryKey ['/api/customer-orders', {storeId, status, supplierId, q, page}] + placeholderData: keepPreviousData.
+
+### CMDCLI-03
+
+**Modifier une commande remet toujours son statut à « En attente de Commande »** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/components/CustomerOrderForm.tsx:143`
+- **Constat :** CustomerOrderForm.tsx:116 `status: "En attente de Commande", // Statut fixe` (même en mode édition, aucun champ statut dans le formulaire) puis :143 `status: data.status || "En attente de Commande",` envoyé par handleEditOrder -> PUT /api/customer-orders/:id (CustomerOrders.tsx:257-260).
+- **Impact :** Corriger un simple numéro de téléphone sur une commande « Disponible » la renvoie en « En attente de Commande » : elle disparaît du bandeau « clients à appeler » et le client risque de ne jamais être prévenu.
+- **Recommandation :** En mode édition, ne pas envoyer `status` (ou utiliser `order.status` en defaultValue) ; n'imposer « En attente de Commande » qu'à la création (`...(order ? {} : { status: 'En attente de Commande' })`).
+
+### CMDCLI-04
+
+**Modifier une commande peut la déplacer dans un autre magasin** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/components/CustomerOrderForm.tsx:127`
+- **Constat :** CustomerOrderForm.tsx:127 `const groupId = getUserAssignedGroupId();` puis :148 `groupId: groupId,` — ignore `order.groupId`. getUserAssignedGroupId (86-103) renvoie `user.userGroups[0].groupId`, sinon selectedStoreId, sinon `groups[0].id`. Le serveur applique tel quel : routes.ts:3599 `storage.updateCustomerOrder(id, req.body)`.
+- **Impact :** Un directeur multi-magasins ou un admin (vue « tous magasins ») qui édite une commande du magasin B la réaffecte silencieusement à son premier magasin : la commande disparaît de la liste du bon magasin.
+- **Recommandation :** Auto : dans handleSubmit, `const groupId = order?.groupId ?? getUserAssignedGroupId();`. Non auto, à traiter avec CMDCLI-07 : côté serveur, ignorer ou valider groupId dans le PUT. À noter aussi : à la création, un directeur multi-magasins crée dans userGroups[0] même si un autre magasin est sélectionné (selectedStoreId n'est pris en compte que pour l'admin).
+
+### CMDCLI-07
+
+**Permissions non appliquées côté serveur et corps de requête non validé (PUT/POST/DELETE)** — bug, sévérité haute, effort M
+
+- **Fichier :** `server/routes.ts:3599`
+- **Constat :** shared/permissions.ts:69-74 : manager sans 'delete', employee seulement ['view','create']. Or routes.ts:3577-3605 (PUT) et 3607-3635 (DELETE) ne vérifient que l'appartenance au magasin, pas le rôle ; :3524-3527 `const data = { ...req.body, createdBy: user.id }` et :3599 `updateCustomerOrder(id, req.body)` sans Zod (insertCustomerOrderSchema importé :127 mais jamais utilisé). Côté client, bouton Modifier (CustomerOrders.tsx:901-907) et badge statut cliquable (881-887) affichés sans `permissions.canEdit`, menu ⋮ mobile (339-356) idem.
+- **Impact :** Un employé peut modifier/annuler n'importe quelle commande, un manager peut supprimer via l'API ; un body arbitraire peut changer groupId/createdBy/createdAt ; une donnée invalide provoque un 500 générique.
+- **Recommandation :** Sans risque : `requireModulePermission('customer-orders','delete')` sur DELETE (le bouton est déjà masqué par canDelete, CustomerOrders.tsx:933). Pour le PUT : schéma Zod dédié (champs éditables, deposit en z.coerce.number().transform(String), notifiedAt et notifiedComment nullables, sans groupId ni createdBy), et décider avec le métier si les employés gardent le changement de statut ou de contact avant d'imposer 'edit'. Côté client, masquer Modifier selon canEdit.
+
+### CMDCLI-08
+
+**Impression d'étiquette : injection HTML/JS (XSS) via les champs de la commande** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:388`
+- **Constat :** CustomerOrders.tsx:383 `window.open('', '_blank')` puis :388 `printWindow.document.write(` avec interpolation brute `${order.customerName}` (560), `${order.productDesignation}` (583), `${order.productReference}` (589), `${order.orderTaker}` (634), `${order.group.name}` (639). La fenêtre about:blank hérite de l'origine de l'application.
+- **Impact :** Un nom client du type `<img src=x onerror=...>` saisi par un collègue s'exécute avec la session de celui qui imprime (appels API en son nom). Un simple « < » ou « & » casse aussi la mise en page de l'étiquette.
+- **Recommandation :** Échapper toutes les valeurs (fonction escapeHtml remplaçant & < > " ') avant interpolation, ou construire la fenêtre via DOM (textContent).
+
+### CMDCLI-20
+
+**Formulaire de commande réduit à 90 % par transform et modale sans hauteur max : texte petit, bouton Créer hors écran** — ux-simplicite, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:971`
+- **Constat :** CustomerOrders.tsx:967 `<DialogContent className="max-w-3xl" style={{ height: 'auto', maxHeight: 'none' }}>` puis :971 `<div style={{ transform: 'scale(0.9)', transformOrigin: 'top left', width: '111%' }}>` (idem 983-987 en édition). Le formulaire empile ~10 champs + 3 titres sur une colonne (CustomerOrderForm.tsx:220-435).
+- **Impact :** Sur un portable 1366×768, la modale centrée dépasse l'écran sans barre de défilement : haut et bouton « Créer » inaccessibles ; texte réduit (et parfois flou) pour des utilisateurs non techniciens.
+- **Recommandation :** Auto : supprimer le wrapper transform et le style inline, et utiliser `className="max-w-3xl max-h-[90vh] overflow-y-auto"` sur les deux DialogContent. Non auto, choix de design : grille 2 colonnes et pied de modale collant.
+
+### CMDCLI-05
+
+**Modifier une commande efface ses notes et l'email client ; les notes ne sont affichées nulle part** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/CustomerOrderForm.tsx:147`
+- **Constat :** CustomerOrderForm.tsx:107-121 defaultValues sans `notes` ni `customerEmail` (aucun champ dans le formulaire), puis :137 `customerEmail: data.customerEmail || ''` et :147 `notes: data.notes || ''`. La version mobile saisit pourtant des « Notes internes » (mobile/CustomerOrdersPage.tsx:593-604). CustomerOrderDetails.tsx n'affiche ni notes, ni notifiedAt, ni notifiedComment.
+- **Impact :** Les notes saisies sur téléphone sont invisibles sur PC puis écrasées à la première modification.
+- **Recommandation :** Partie sûre et invisible : ajouter `notes: order?.notes || ''` et `customerEmail: order?.customerEmail || ''` aux defaultValues. RHF conserve les valeurs par défaut des champs non enregistrés et le schéma Zod (43-44) les garde, donc l'édition n'efface plus rien. Ajouter un Textarea « Notes internes » et l'affichage « Contacté le … » dans les Détails change l'interface : à valider séparément.
+
+### CMDCLI-06
+
+**Mobile : les cases « Prix promotionnel / Pub » et « Client déjà notifié » n'ont aucun effet** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/CustomerOrdersPage.tsx:67`
+- **Constat :** Le schéma Zod (67-78) ne déclare ni isPromotionalPrice ni customerNotified ; les champs sont forcés avec `name={"isPromotionalPrice" as any}` (555) et `name={"customerNotified" as any}` (575). zodResolver renvoie les valeurs parsées (z.object retire les clés inconnues), donc :263-264 `isPromotionalPrice: data.isPromotionalPrice, customerNotified: data.customerNotified` valent undefined.
+- **Impact :** Le vendeur coche « Prix publicité » sur téléphone mais la commande est enregistrée au prix normal (valeur par défaut false) : litige possible au retrait.
+- **Recommandation :** Ajouter `isPromotionalPrice: z.boolean().default(false), customerNotified: z.boolean().default(false)` au schéma et aux defaultValues, puis retirer les `as any`. Pour la factorisation, voir CMDCLI-32. Option produit : masquer « Client déjà notifié » à la création comme sur desktop, car notifiedAt reste null.
+
+### CMDCLI-09
+
+**Polling pending-calls lancé pour les employés alors que le serveur répond 403 (avec 2 retries toutes les 30 s)** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:74`
+- **Constat :** CustomerOrders.tsx:74-87 useQuery sans `enabled`, `refetchInterval: 30000` ; routes.ts:3648-3650 `if (user.role === 'employee') { return res.status(403)... }` ; queryClient.ts retry `return failureCount < 2;` pour toute erreur non-401.
+- **Impact :** Chaque poste employé ouvert sur la page génère 3 requêtes en échec toutes les 30 s (chacune = 4 requêtes SQL d'auth, voir CMDCLI-11) pour rien.
+- **Recommandation :** `enabled: !!user && user.role !== 'employee'` (ou permission dédiée), et `refetchIntervalInBackground: false` explicite.
+
+### CMDCLI-10
+
+**Mutations sans gestion d'erreur : échecs silencieux (statut, contact client)** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:171`
+- **Constat :** CustomerOrders.tsx:171-181 statusMutation, 184-194 markCalledMutation, 197-206 unmarkCalledMutation : aucun `onError`. Idem mobile 122-129, 131-140, 142-150. Or routes.ts:3684-3686 renvoie 403 aux employés pour mark-called, alors que le bouton téléphone (CustomerOrders.tsx:917-932) et « Marquer contacté » (mobile 369-375) leur sont affichés.
+- **Impact :** Un employé clique « Confirmer » : rien ne se passe, la modale reste ouverte, aucun message. Toute erreur réseau sur un changement de statut est invisible.
+- **Recommandation :** Auto : ajouter un onError avec un toast destructive en français (« Impossible de changer le statut », « Impossible d'enregistrer le contact ») sur les 6 mutations. Non auto : masquer le bouton contact pour les employés ou les autoriser côté serveur (décision produit).
+
+### CMDCLI-11
+
+**getUserWithGroups rappelé dans chaque handler alors que deserializeUser l'a déjà chargé (4 requêtes SQL séquentielles par appel)** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:3488`
+- **Constat :** localAuth.ts:141-148 `passport.deserializeUser(... storage.getUserWithGroups(id) ...)` ; puis routes.ts:3488, 3519, 3579, 3609, 3640, 3676 `const user = await storage.getUserWithGroups(req.user.claims ? ... : req.user.id);`. storage.ts:371-386 : getUser puis requête user_groups JOIN groups, séquentielles.
+- **Impact :** Chaque appel /api/customer-orders* (dont le polling 30 s) paie 4 allers-retours BD avant le travail utile ; latence ajoutée à chaque action.
+- **Recommandation :** Utiliser `const user = req.user as UserWithGroups` dans ces handlers ; dans getUserWithGroups, faire une seule requête users LEFT JOIN user_groups JOIN groups (ou Promise.all).
+
+### CMDCLI-14
+
+**Chaque changement de statut/contact recharge toute la liste au lieu de mettre à jour la ligne** — perf-client, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:175`
+- **Constat :** CustomerOrders.tsx:132, 153, 175, 188, 201 `queryClient.invalidateQueries({ predicate: (query) => query.queryKey[0]?.toString()?.includes('/api/customer-orders') })` ; le PUT renvoie pourtant la commande mise à jour (routes.ts:3600 `res.json(updatedOrder)`).
+- **Impact :** Latence visible (aller-retour PUT + re-téléchargement de toute la liste) à chaque clic de statut ; l'utilisateur ne voit pas de retour immédiat.
+- **Recommandation :** Mise à jour optimiste : onMutate -> `queryClient.setQueryData(key, old => old.map(o => o.id === id ? { ...o, status } : o))`, rollback onError, puis invalidation ciblée de pending-calls uniquement.
+
+### CMDCLI-15
+
+**« Marquer Appelé » depuis la modale ne rafraîchit pas le tableau pour un admin avec magasin sélectionné** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/modals/ClientCallsModal.tsx:42`
+- **Constat :** ClientCallsModal.tsx:42 `queryClient.invalidateQueries({ queryKey: ['/api/customer-orders'] });` alors que la clé du tableau est CustomerOrders.tsx:95-97 `[`/api/customer-orders?storeId=${selectedStoreId}`, selectedStoreId]` pour un admin : le préfixe ne correspond pas.
+- **Impact :** Le client est marqué appelé mais l'icône téléphone reste grise dans le tableau (staleTime 30 s, pas de refetch au focus) : risque de double appel.
+- **Recommandation :** Correction minimale et sûre dans ClientCallsModal.tsx:37-42 : remplacer les deux invalidations par `queryClient.invalidateQueries({ predicate: q => String(q.queryKey[0] ?? '').startsWith('/api/customer-orders') })` (couvre aussi pending-calls). L'unification des clés reste à planifier avec CMDCLI-02.
+
+### CMDCLI-16
+
+**Le sélecteur de magasin n'a aucun effet pour directeur/manager (et clé de cache partagée avec le mobile)** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:95`
+- **Constat :** CustomerOrders.tsx:95 `/api/customer-orders${selectedStoreId && user?.role === 'admin' ? `?storeId=${selectedStoreId}` : ''}` — le serveur sait pourtant filtrer pour les non-admins (routes.ts:3500-3501). Le tableau n'a pas de colonne Magasin. Mobile 92-96 utilise la même clé `['/api/customer-orders', selectedStoreId]` mais avec ?storeId.
+- **Impact :** Un directeur multi-magasins choisit « Magasin B » et voit les commandes de tous ses magasins mélangées sans pouvoir les distinguer ; en passant de l'affichage mobile au desktop, le cache affiche des données filtrées différemment.
+- **Recommandation :** Toujours passer `storeId` quand un magasin est sélectionné (quel que soit le rôle) et inclure le paramètre dans la clé ; afficher une colonne Magasin quand aucun magasin n'est sélectionné.
+
+### CMDCLI-17
+
+**Filtre + tri de toute la liste recalculés à chaque rendu (y compris à chaque frappe dans le commentaire d'appel)** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:657`
+- **Constat :** CustomerOrders.tsx:657-675 `customerOrders.filter(...)` avec `searchTerm.toLowerCase()` recalculé 5 fois par commande ; 678-723 tri avec `safeDate(a.createdAt)` parsé à chaque comparaison ; aucun useMemo ni debounce. L'état `contactComment` (61) vit dans ce composant : chaque caractère tapé dans la modale contact relance filtre + tri de toutes les commandes.
+- **Impact :** Saisie qui rame sur de grosses listes ou des PC de magasin modestes.
+- **Recommandation :** Auto : useMemo sur filteredOrders et sortedOrders ([customerOrders, searchTerm, filterSupplier, filterStatus, sortBy, sortOrder]), `const q = searchTerm.toLowerCase()` calculé une fois, timestamps pré-calculés. Optionnel, refactor : useDeferredValue et extraction de la modale contact.
+
+### CMDCLI-18
+
+**Pas d'état vide, pas d'état d'erreur, chargement en texte brut** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:829`
+- **Constat :** CustomerOrders.tsx:829-831 `{isLoading ? (<div>Chargement...</div>) : (<Table>...` ; 847 `paginatedOrders.map(...)` sans branche « aucune commande » ; aucune lecture de `isError`. Côté serveur routes.ts:3513 `res.status(500).json([])`.
+- **Impact :** Sans commande ou en cas de panne, l'utilisateur voit un tableau vide avec seulement les en-têtes et ne sait pas si c'est normal, filtré ou cassé.
+- **Recommandation :** Skeleton de 5 lignes pendant le chargement ; ligne « Aucune commande ne correspond à votre recherche » + bouton « Effacer les filtres » ; Alert rouge « Impossible de charger les commandes — Réessayer » si isError.
+
+### CMDCLI-21
+
+**Formulaire peu guidant : fournisseur n°1 présélectionné, gencode « obligatoire » non exigé, recherche produit placée après la désignation** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/CustomerOrderForm.tsx:115`
+- **Constat :** CustomerOrderForm.tsx:115 `supplierId: order?.supplierId || 1` et 272 `value={field.value?.toString() || "1"}` ; 344 `<FormLabel>Gencode (obligatoire)</FormLabel>` alors que 36 `gencode: z.string().optional()` ; ordre : Fournisseur (266) avant Produit, Désignation (295) avant Gencode (339) alors que la loupe gencode remplit désignation, référence et fournisseur (175-200) ; téléphone optionnel (33) alors qu'il sert à rappeler le client.
+- **Impact :** Commandes enregistrées chez le mauvais fournisseur sans que le vendeur s'en rende compte ; saisie manuelle inutile de la désignation ; commandes sans téléphone impossibles à rappeler.
+- **Recommandation :** Placer « Scanner / saisir le gencode » en premier avec autofocus et recherche à la touche Entrée ; fournisseur vide par défaut et requis (placeholder « Choisir un fournisseur ») ; aligner libellé et validation du gencode ; rendre le téléphone obligatoire (décision produit).
+
+### CMDCLI-22
+
+**Une panne de l'API article est affichée comme « Produit non référencé » et bloque la création** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/CustomerOrderForm.tsx:169`
+- **Constat :** CustomerOrderForm.tsx:169 `if (!res.ok) { setArticleNotFound(true); return; }` et 202 `catch { setArticleNotFound(true); }` ; 438-441 « Produit non référencé — … La commande ne peut pas être créée. » ; 456 `disabled={... || (articleNotFound && !order) || ...}`. Identique mobile 194-227, 606-611.
+- **Impact :** Si api.ffnancy.fr est lent ou indisponible, le vendeur ne peut plus créer la commande et reçoit un message faux ; il doit fermer et rouvrir la modale.
+- **Recommandation :** Distinguer 3 cas : introuvable (404/aucun article), erreur technique (« Recherche indisponible, saisissez le produit manuellement ») qui ne bloque pas, et réinitialiser articleNotFound dès que l'utilisateur modifie le gencode.
+
+### CMDCLI-24
+
+**Tableau de 9 colonnes sans défilement horizontal, informations clés absentes, texte barré illisible** — lisibilite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:832`
+- **Constat :** CustomerOrders.tsx:835-843 colonnes Client, Téléphone, Produit, Quantité, Fournisseur, Gencode, Statut, Date, Actions ; ui/table.tsx:9 wrapper `<div className="relative w-full">` sans overflow-auto ; 852-889 `line-through` appliqué à chaque cellule (et au badge) des commandes Retiré/Annulé ; acompte et « prix publicité » non affichés ; 908-916 bouton Imprimer présent seulement si Disponible (colonne Actions irrégulière).
+- **Impact :** Sur écran 1280 px avec sidebar, le tableau déborde ; au comptoir, l'information utile (acompte à déduire) exige d'ouvrir le détail ; les lignes barrées sont difficiles à lire.
+- **Recommandation :** Fusionner Client + Téléphone, remplacer Gencode par Acompte, ajouter `overflow-x-auto` au wrapper, griser (opacity-60) sans barrer, et regrouper les actions secondaires dans un menu « ⋯ » à côté d'un bouton principal contextuel (« Prévenir le client » si Disponible, « Remis au client » ensuite).
+
+### CMDCLI-25
+
+**Éléments cliquables non accessibles : badge de statut, bandeau d'alerte, boutons-icônes sans libellé** — accessibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:882`
+- **Constat :** CustomerOrders.tsx:882-887 `<Badge ... onClick={() => openStatusModal(order)}>` (Badge = `<div>`, ui/badge.tsx:32) ; 740-743 `<Alert ... onClick={() => setShowClientCallsModal(true)}>` ; 894-941 boutons Eye/Edit/Printer/Trash2 sans `title` ni `aria-label` ; loupes du formulaire CustomerOrderForm.tsx:322-331 et 348-357 idem.
+- **Impact :** Changement de statut impossible au clavier et non découvrable ; l'utilisateur doit deviner la fonction de chaque icône.
+- **Recommandation :** Remplacer le badge cliquable par un `<button>` (ou un Select de statut), rendre le bandeau un `<button>` ; ajouter `aria-label` + `title` (« Voir le détail », « Modifier », « Imprimer l'étiquette », « Supprimer », « Rechercher le produit »).
+
+### CMDCLI-26
+
+**Changement de statut appliqué immédiatement, y compris « Annulé », sans confirmation (et menu mobile incomplet)** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:1037`
+- **Constat :** CustomerOrders.tsx:1037-1042 `onClick={() => { handleStatusChange(selectedOrder.id, status); setShowStatusModal(false); }}` pour les 5 statuts dont « Annulé » ; mobile 346-354 menu ⋮ : « Marquer Disponible », « Marquer Retiré », « Annuler » (libellé ambigu, sans confirmation), pas d'option « Commande en Cours », proposé même sur une commande déjà Retiré.
+- **Impact :** Un clic de travers annule une commande client sans possibilité d'annulation ; sur mobile « Annuler » peut être compris comme « fermer le menu ».
+- **Recommandation :** Confirmation (ConfirmationModal) pour Annulé/Retiré, toast avec bouton « Annuler l'action » ; sur mobile libellé « Annuler la commande » en rouge séparé, et proposer uniquement le statut suivant logique.
+
+### CMDCLI-29
+
+**Modale Détails trompeuse : faux code-barres « scannable », bloc d'actions sans bouton, infos d'appel absentes** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/CustomerOrderDetails.tsx:126`
+- **Constat :** CustomerOrderDetails.tsx:126 « Code-barres EAN13 scannable » au-dessus d'un SVG de barres codées en dur (129-167), identique pour tous les produits ; 237-246 « Actions disponibles : • Étiquette imprimable disponible • Notification client possible » sans aucun bouton ; renderBarcode (31-42) jamais appelé ; notes, notifiedAt et notifiedComment non affichés ; 79 « Client notifié » affiché seulement si statut Disponible.
+- **Impact :** Un vendeur peut tenter de scanner un code-barres factice ; l'utilisateur doit fermer la modale pour agir ; l'historique d'appel est invisible.
+- **Recommandation :** Supprimer le faux SVG (afficher le numéro ou générer un vrai code avec JsBarcode en lazy) et le code mort ; remplacer le bloc texte par de vrais boutons (Imprimer, Prévenir, Modifier) ; afficher « Contacté le … — commentaire » et les notes.
+
+### CMDCLI-30
+
+**Le code-barres imprimé peut différer du gencode du produit** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:309`
+- **Constat :** CustomerOrders.tsx:309-315 code complété `padStart(12, '0')` s'il est court, tronqué à 12 chiffres sinon, puis :318-319 checksum recalculé ; 618 `<div class="barcode-number">${order.gencode}</div>` affiche le gencode original sous un code-barres encodant un autre numéro (EAN-8, codes internes, checksum invalide).
+- **Impact :** À la caisse, le scan de l'étiquette peut renvoyer un autre article ou aucun.
+- **Recommandation :** Encoder le gencode tel quel avec le format adapté (EAN13 si 13 chiffres valides, EAN8 si 8, sinon CODE128) et afficher sous l'image la valeur réellement encodée.
+
+### CMDCLI-31
+
+**Mobile : « Aucune commande trouvée » dès que « Tous les magasins » ou aucun magasin n'est sélectionné** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/CustomerOrdersPage.tsx:91`
+- **Constat :** mobile 94 `if (!selectedStoreId) return [];` et 102 `enabled: !!selectedStoreId && !!user` ; 312-316 affiche « Aucune commande trouvée ». MobileLayout.tsx:152-159 propose « Tous les magasins » à l'admin et l'en-tête affiche « Tous les magasins » par défaut (28) ; MobileApp.tsx:36-41 n'auto-sélectionne un magasin que pour directeur/manager mono-magasin (pas les employés).
+- **Impact :** L'utilisateur croit qu'il n'y a aucune commande alors qu'il doit d'abord choisir un magasin.
+- **Recommandation :** Auto : quand !selectedStoreId, afficher un état dédié « Choisissez un magasin pour voir ses commandes » (avec ouverture du menu ou sélecteur) à la place de « Aucune commande trouvée ». Non auto : charger toutes les commandes autorisées, ou auto-sélectionner le magasin unique d'un employé.
+
+### CMDCLI-32
+
+**Mobile : erreurs de validation invisibles et formulaire dupliqué du desktop** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/mobile/CustomerOrdersPage.tsx:54`
+- **Constat :** `FormMessage` importé (54) mais jamais rendu dans les FormField 409-604 ; orderTaker initialisé à `user?.username` (180, identifiant de connexion) contre `user?.name` sur desktop (CustomerOrderForm.tsx:108) ; schéma Zod, recherche article (190-240) et logique groupId recopiés de CustomerOrderForm.tsx ; la case « Client déjà notifié » est proposée à la création alors que le desktop la masque (CustomerOrderForm.tsx:434).
+- **Impact :** Si un champ requis manque, le bouton « Valider la commande » ne fait rien de visible ; deux formulaires à maintenir qui divergent déjà (voir CMDCLI-06).
+- **Recommandation :** Ajouter `<FormMessage />` à chaque champ, puis factoriser : réutiliser CustomerOrderForm (prop `variant="mobile"`) et un hook `useArticleLookup` partagé.
+
+### CMDCLI-33
+
+**Mobile : toutes les commandes (historique compris) rendues d'un bloc, sans filtre de statut ni pagination** — perf-client, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/mobile/CustomerOrdersPage.tsx:270`
+- **Constat :** mobile 270-274 `orders.filter(...)` sans useMemo ni filtre de statut ; 318-389 rend une Card + un DropdownMenu Radix par commande, Retiré/Annulé mélangées aux actives (tri serveur par date).
+- **Impact :** Liste interminable et lente sur téléphone ; les commandes à traiter sont noyées dans l'historique.
+- **Recommandation :** Onglets/puces « À traiter / Disponibles / Terminées » (par défaut : hors Retiré/Annulé), useMemo, chargement par pages de 20 (« Voir plus ») une fois la pagination serveur en place (CMDCLI-02).
+
+### CMDCLI-39
+
+**Logs de debug en production, dont des données personnelles clients** — dette-code, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:3530`
+- **Constat :** Serveur routes.ts:3530-3531 `console.log('🔍 CUSTOMER ORDER - Received data from frontend:', req.body)` (nom + téléphone client), 3532-3566 ~10 autres logs, 3507/3509 à chaque GET, 3666 à chaque poll pending-calls. Client CustomerOrders.tsx:83 (toutes les 30 s), 103, 107, 118, 246-254, 321.
+- **Impact :** Journaux serveur gonflés et contenant des données personnelles (RGPD) ; console navigateur polluée ; léger coût sur les chemins chauds.
+- **Recommandation :** Auto : supprimer, ou conditionner à process.env.DEBUG_CUSTOMER_ORDERS, les console.log serveur de routes.ts:3507, 3509, 3530-3566 et 3666 ; ne jamais logguer req.body. Le nettoyage des console.log client est cosmétique (déjà retirés du build de production).
+
+### CMDCLI-40
+
+**Réponses JSON non compressées et recopiées récursivement à chaque envoi** — perf-serveur, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:168`
+- **Constat :** routes.ts:165-170 `res.json = (body) => originalJson(stripSmtpPassword(body))` parcourt et recopie chaque objet de la liste (sanitize.ts:13-40) ; aucun middleware de compression dans server/index.ts / index.production.ts, et `setupCompression` (server/cache.ts:93-101) n'est jamais appelé (et ne compresse rien : il pose seulement l'en-tête).
+- **Impact :** La liste des commandes (déjà alourdie, CMDCLI-01) part en clair sur le réseau du magasin ; CPU serveur consommé à recopier chaque ligne.
+- **Recommandation :** Vérifier d'abord la configuration gzip du nginx frontal. Si elle est absente : `npm i compression` et `app.use(compression())` avant registerRoutes dans index.ts et index.production.ts. Conserver stripSmtpPassword (filet de sécurité global). Supprimer setupCompression, mort et trompeur.
+
+### CMDCLI-41
+
+**Les « clients à appeler » sont rechargés par un 2e endpoint polled alors qu'ils sont déjà dans la liste** — perf-api, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:74`
+- **Constat :** CustomerOrders.tsx:74-87 GET pending-calls toutes les 30 s ; storage.ts:1931-1935 `customerNotified = false AND status IN ('Disponible', ...)` — sous-ensemble exact des commandes déjà chargées par la requête de la ligne 96 (même périmètre de magasins).
+- **Impact :** Double transfert des mêmes données (avec jointures lourdes) et 2 requêtes BD + 4 requêtes d'auth toutes les 30 s par poste ouvert.
+- **Recommandation :** Si l'on dérive : `const pendingCalls = useMemo(() => user?.role === 'employee' ? [] : customerOrders.filter(o => PENDING_STATUSES.includes(o.status) && !o.customerNotified), ...)` avec la même liste de statuts que storage.ts:1934, et garder un rafraîchissement de la liste (refetchInterval 60 s, onglet visible) une fois la liste allégée (CMDCLI-01/02).
+
+### CMDCLI-12
+
+**PUT/DELETE/mark-called chargent la commande avec 2 jointures (et le logo) juste pour lire groupId** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:3585`
+- **Constat :** routes.ts:3585, 3615, 3689 `const customerOrder = await storage.getCustomerOrder(id);` puis seul `customerOrder.groupId` est utilisé ; storage.ts:1892-1911 jointure suppliers + groups complète.
+- **Impact :** Requête et transfert inutiles à chaque changement de statut ou contact ; s'ajoute au refetch complet de la liste.
+- **Recommandation :** Créer `getCustomerOrderGroupId(id)` (SELECT group_id) ou faire `UPDATE ... WHERE id = $1 AND group_id = ANY($2) RETURNING *` et renvoyer 404/403 si 0 ligne.
+
+### CMDCLI-13
+
+**Création : invalidateQueries + refetchQueries en double (y compris caches inactifs)** — perf-client, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:110`
+- **Constat :** CustomerOrders.tsx:109 `queryClient.invalidateQueries({ predicate: ... includes('/api/customer-orders') })` puis :110 `queryClient.refetchQueries({ predicate: ... })` — refetchQueries recharge aussi les clés inactives (autres magasins visités, clé mobile, Dashboard).
+- **Impact :** Après chaque création, la liste complète (lourde, voir CMDCLI-01) est téléchargée 2 fois ou plus.
+- **Recommandation :** Supprimer la ligne 110 ; invalidateQueries suffit (refetch des requêtes actives, les autres marquées stale).
+
+### CMDCLI-19
+
+**Changement de magasin : écran « Chargement... » au lieu de garder la liste précédente** — perf-client, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:96`
+- **Constat :** CustomerOrders.tsx:96-98 useQuery sans `placeholderData` ; la clé change avec selectedStoreId donc `isLoading` repasse à true et le tableau est remplacé par le texte (829-831).
+- **Impact :** Clignotement et perte de repère à chaque changement de magasin.
+- **Recommandation :** `placeholderData: keepPreviousData` + indicateur discret `isFetching` dans l'en-tête de la carte.
+
+### CMDCLI-23
+
+**Recherche article : 2 appels externes séquentiels via un proxy sans timeout ni cache** — perf-api, sévérité basse, effort M
+
+- **Fichier :** `server/routes.ts:6402`
+- **Constat :** Client CustomerOrderForm.tsx:168 puis 182-185 (article puis `/api/ffnancy/mouvements/entrees?artNoId=...&limit=1&dateDebut=2000-01-01`) ; serveur routes.ts:6402 `await fetch(`https://api.ffnancy.fr/api/articles?${params}`)` et 6417 sans AbortController ni mise en cache.
+- **Impact :** Recherche lente (2 allers-retours navigateur→serveur→ffnancy) et spinner potentiellement infini qui garde le bouton Créer désactivé (456).
+- **Recommandation :** Créer un endpoint unique `/api/ffnancy/article-lookup?ean=` qui enchaîne les 2 appels côté serveur avec timeout 5 s (AbortController) et cache mémoire 10 min (server/cache.ts).
+
+### CMDCLI-27
+
+**Libellés incohérents, en anglais ou abrégés** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:808`
+- **Constat :** CustomerOrders.tsx:805/808 placeholder et option « Status » (anglais) ; 792/795 option « Fournisseurs » pour « tous » ; titres « Commandes Client » (761, Sidebar.tsx:300) vs « Commandes Clients » (mobile 292) vs « Cmd Client » (MobileBottomNav.tsx:39) ; « Marquer Appelé » (ClientCallsModal.tsx:142) vs « Marquer client comme contacté » (1081) vs « Marquer contacté » (mobile 374) ; « Prix publicité » (form 424) vs « Prix promotionnel / Pub » (mobile 566) ; mobile « Qty: » (378), « Qté » (488), placeholder « Client, produit, rév... » (299, faute pour réf.) ; « Gencode » partout.
+- **Impact :** Vocabulaire déroutant pour des employés non techniciens ; impression d'application non finie.
+- **Recommandation :** Auto, corrections évidentes uniquement : « Status » en « Tous les statuts » (placeholder et option all), option all « Fournisseurs » en « Tous les fournisseurs », « Qty: » en « Qté : », « rév... » en « réf... ». Glossaire global (titres, Gencode, libellés de contact, Prix promo) : à valider avec le métier.
+
+### CMDCLI-28
+
+**Couleurs et listes de statuts dupliquées et divergentes (3 copies)** — coherence-design, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/CustomerOrderDetails.tsx:13`
+- **Constat :** getStatusColor dupliqué : CustomerOrders.tsx:208-223 (bg-*-50 / text-*-700), CustomerOrderDetails.tsx:13-28 (idem), mobile 276-284 (bg-*-100 / text-*-800, statut inconnu = jaune au lieu de gris) ; liste des statuts dupliquée CustomerOrders.tsx:233-239 et CustomerOrderForm.tsx:57-63 (STATUS_OPTIONS jamais utilisé) ; fiche imprimée 420-427 badge toujours jaune quel que soit le statut.
+- **Impact :** Un même statut n'a pas la même couleur selon l'écran ; toute évolution doit être faite à 3 endroits.
+- **Recommandation :** Créer `client/src/lib/customerOrderStatus.ts` exportant `CUSTOMER_ORDER_STATUSES`, `statusClass(status)` et un composant `<CustomerOrderStatusBadge>` réutilisé partout (y compris l'impression).
+
+### CMDCLI-34
+
+**Mobile : queryFn manuels sans contrôle d'erreur au lieu du fetcher par défaut** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/mobile/CustomerOrdersPage.tsx:105`
+- **Constat :** mobile 93-101 fetch manuel de la liste ; 105-111 `queryFn: async () => { const res = await fetch('/api/suppliers', ...); return res.json(); }` et 113-119 idem pour /api/groups, sans `res.ok` ; ces clés sont identiques à celles servies par le fetcher par défaut (queryClient.ts). /api/suppliers chargé même si la feuille de création n'est jamais ouverte. Desktop : CustomerOrders.tsx:76-85 fetch manuel avec console.log pour pending-calls.
+- **Impact :** Une réponse d'erreur ({message}) est mise en cache comme liste → `suppliers.map is not a function` à l'ouverture du formulaire ; pas de redirection 401 homogène.
+- **Recommandation :** Auto : supprimer seulement les queryFn manuels de /api/suppliers et /api/groups (le fetcher par défaut renvoie le même JSON, avec gestion d'erreur) ; `enabled: isCreateOpen` facultatif pour suppliers. Ne pas toucher à la clé ni au queryFn de la liste tant que les clés ne sont pas unifiées (CMDCLI-15/02).
+
+### CMDCLI-35
+
+**Dates et montants mal formatés** — lisibilite, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/mobile/CustomerOrdersPage.tsx:328`
+- **Constat :** mobile 328 `format(new Date(order.createdAt), "dd/MM", ...)` sans année ni safeFormat ; 644 `format(new Date(contactOrder.notifiedAt), "dd/MM/yyyy 'à' HH:mm")` sans locale ; 382 `Acompte: {parseFloat(order.deposit)}€` (« 12.5€ ») ; desktop CustomerOrderDetails.tsx:202 et CustomerOrders.tsx:600 `toFixed(2)}€` (« 12.50€ », point décimal).
+- **Impact :** Commande de l'an dernier indiscernable ; montants au format anglo-saxon.
+- **Recommandation :** Auto : `new Intl.NumberFormat('fr-FR', { style: 'currency', currency: 'EUR' }).format(parseFloat(order.deposit))` aux 3 endroits (mobile 382, Details 202, impression 600), et safeFormat (dateUtils.ts:8, locale fr par défaut) à la place de format(new Date(...)) en mobile 328/644. Ajouter l'année est optionnel (dd/MM/yy).
+
+### CMDCLI-36
+
+**Mobile : feuille « contact client » faite main (pas de focus, pas d'Échap, pas de rôle dialog)** — accessibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/mobile/CustomerOrdersPage.tsx:628`
+- **Constat :** mobile 628-630 `<div className="fixed inset-0 z-50 ..." onClick=...><div className="w-full max-w-lg bg-white rounded-t-2xl ...">` alors que la page utilise déjà Sheet (395) ; boutons natifs <button> stylés à la main (664-682).
+- **Impact :** Comportement différent des autres feuilles (pas de bouton retour/Échap, focus non piégé, lecteurs d'écran perdus), style incohérent.
+- **Recommandation :** Remplacer par `<Sheet side="bottom">` + composants Button/Textarea de shadcn.
+
+### CMDCLI-37
+
+**Deux parcours différents pour « client contacté » (avec et sans commentaire) et double défilement** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/modals/ClientCallsModal.tsx:25`
+- **Constat :** ClientCallsModal.tsx:25 `apiRequest(`/api/customer-orders/${customerOrderId}/mark-called`, 'PATCH')` sans commentaire, bouton « Marquer Appelé » (142) ; la modale par ligne (CustomerOrders.tsx:1074-1136) demande un commentaire ; 67 `max-h-[80vh] overflow-y-auto` + 87 `<ScrollArea className="max-h-[50vh]">` imbriqués ; pas de date de mise à disposition ni de lien tel:.
+- **Impact :** L'utilisateur ne sait pas lequel utiliser ; impossible de noter « message laissé » depuis la liste dédiée ; deux barres de défilement.
+- **Recommandation :** Réutiliser la même mini-modale contact (commentaire optionnel) depuis ClientCallsModal, afficher « Disponible depuis le … » et le téléphone en lien tel:, garder un seul conteneur scrollable.
+
+### CMDCLI-38
+
+**Mise en page chargée et tri incohérent (Retiré en fin de liste mais pas Annulé, tri non modifiable)** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:680`
+- **Constat :** CustomerOrders.tsx:680-681 seules les commandes « Retiré » sont renvoyées en fin de liste alors que 225-227 grise aussi « Annulé » ; 63-64 `sortBy`/`sortOrder` sans aucun contrôle UI (setSortBy/setSortOrder jamais appelés) ; 777-780 carte « Recherche et Filtres » avec titre ; 740-752 bandeau collant au-dessus du titre de page avec emoji 📞 en plus de l'icône Phone ; pas de bouton « Effacer les filtres ».
+- **Impact :** Commandes annulées intercalées entre les commandes actives ; espace vertical perdu avant d'atteindre le tableau.
+- **Recommandation :** Traiter Annulé comme Retiré dans le tri (ou filtre par défaut « En cours »), supprimer l'état de tri mort ou ajouter des en-têtes triables, barre de filtres compacte sans titre avec bouton « Effacer », bandeau d'appels placé sous le titre.
+
+### CMDCLI-42
+
+**JsBarcode et la page importés en statique alors qu'ils ne servent qu'à l'impression** — perf-bundle, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:33`
+- **Constat :** CustomerOrders.tsx:33 `import JsBarcode from 'jsbarcode';` utilisé uniquement dans generateEAN13Barcode (324) ; RouterProduction.tsx:19 et :41 importent CustomerOrders et MobileCustomerOrdersPage sans React.lazy (toutes les pages sont importées en statique).
+- **Impact :** JsBarcode et le code des commandes clients sont téléchargés au premier chargement de l'application, même pour un utilisateur qui n'ouvre jamais cette page.
+- **Recommandation :** Ouvrir la fenêtre de façon synchrone (`const w = window.open('', '_blank')`), puis `const { default: JsBarcode } = await import('jsbarcode')`, puis écrire le document. Le lazy-loading des pages doit se faire globalement dans RouterProduction (toutes les pages), avec un fallback Suspense, plutôt que pour une seule page.
+
+### CMDCLI-43
+
+**Code mort et contournements dans la page et le formulaire** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/CustomerOrders.tsx:69`
+- **Constat :** CustomerOrders.tsx:69-71 requête /api/groups jamais utilisée ; 922-925/1095-1100 `(order as any).notifiedAt` alors que le type CustomerOrder contient déjà notifiedAt ; CustomerOrderForm.tsx:154-158 `form.setValue('groupId', …)` appelé pendant le rendu ; :129 `alert("ERREUR: …")` natif ; :134 `user?.firstName + ' ' + user?.lastName || …` (toujours vrai, fallback username inatteignable) ; `useRef` et insertCustomerOrderFrontendSchema importés sans usage (6, 27).
+- **Impact :** Lecture et maintenance plus difficiles, re-rendus inutiles, message d'erreur non stylé (popup navigateur).
+- **Recommandation :** Supprimer la requête groups, les `as any`, les imports inutilisés ; déplacer le setValue dans un useEffect ; remplacer alert() par un toast destructive.

docs/audit-webui/08-dlc.md

@@ -0,0 +1,596 @@
+# DLC
+
+_51 constats vérifiés — 12 haute, 21 moyenne, 18 basse._
+
+## Pages analysées
+
+### `/dlc (desktop, client/src/pages/DlcPage.tsx via RouterProduction.tsx:164)`
+
+**Rôle :** Suivre les produits à date courte (DLC/DDM/DLUO) du magasin : saisir un produit et sa date, voir ceux qui expirent bientôt ou sont expirés, et les traiter (retrait du rayon, rupture de stock, suppression), imprimer les listes.
+
+**Tâches principales de l'utilisateur :**
+- Ajouter un produit DLC (nom, fournisseur, EAN avec recherche automatique, date, type de date)
+- Repérer les produits expirés / expirant dans 15 jours (cartes compteurs + filtre Statut)
+- Traiter un produit : Valider (retrait), Marquer traité, Stock épuisé, Restaurer, Annuler traitement
+- Modifier / supprimer un produit
+- Imprimer la liste des produits expirés ou expirant bientôt
+- Rechercher / filtrer par statut et fournisseur
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/groups | au montage (enabled: !authLoading), cache partagé avec Layout | server/routes.ts:970 -> storage.getUserWithGroups (storage.ts:371) + storage.getGroups (storage.ts:432) pour admin | Sert uniquement au fallback groupId de onSubmit ; doublon de useStore().stores déjà chargé par Layout.tsx:48. |
+| GET /api/suppliers?dlc=true | au montage, staleTime 10 min | server/routes.ts:1141 -> storage.getSuppliers (storage.ts:467) puis filtre JS hasDlc | Charge tous les fournisseurs puis filtre en JS au lieu d'un WHERE has_dlc. |
+| GET /api/dlc-products?storeId&status&supplierId&search | au montage + à chaque changement de filtre / recherche (debounce 500 ms), staleTime 2 min | server/routes.ts:2797 -> storage.getUserWithGroups (2 requêtes) + storage.getDlcProducts (storage.ts:1976) | Aucune limite/pagination serveur ; SELECT complet de suppliers et groups (dont groups.logo en data URI) pour chaque ligne ; storeId envoyé seulement pour admin. |
+| GET /api/dlc-products/stats?storeId | au montage, staleTime 5 min | server/routes.ts:2831 -> storage.getUserWithGroups + storage.getDlcStats (storage.ts:2224) | Même queryKey que Dashboard.tsx:232 mais URL différente (storeId admin uniquement ici) ; compteurs renvoyés en chaînes (COUNT bigint). |
+| POST /api/dlc-products | au clic Créer | server/routes.ts:2889 -> storage.createDlcProduct (storage.ts:2110) | req.body inséré tel quel, sans validation zod ni liste blanche de champs. |
+| PUT /api/dlc-products/:id | au clic Mettre à jour | server/routes.ts:2917 -> storage.getDlcProduct (storage.ts:2088) + storage.updateDlcProduct (storage.ts:2115) | req.body passé tel quel à .set() : groupId/status/validatedBy modifiables. |
+| DELETE /api/dlc-products/:id | au clic Supprimer (après AlertDialog) | server/routes.ts:2947 -> storage.getDlcProduct + storage.deleteDlcProduct (storage.ts:2124) | Aucun contrôle de rôle : tout employé peut supprimer. |
+| POST /api/dlc-products/:id/validate | au clic bouton vert (admin/manager/directeur) | server/routes.ts:2977 -> storage.getDlcProduct + storage.validateDlcProduct (storage.ts:2128) | 2 console.log par appel ; pas de confirmation côté client pour une action définitive. |
+| PUT /api/dlc-products/:id/stock-epuise | au clic PackageX | server/routes.ts:3023 -> storage.getDlcProduct + storage.markDlcProductStockEpuise (storage.ts:2142) | Invalide liste + stats (2 refetchs complets). |
+| PUT /api/dlc-products/:id/restore-stock | au clic RotateCcw (admin/manager/directeur) | server/routes.ts:3063 -> storage.getDlcProduct + storage.restoreDlcProductStock (storage.ts:2156) | Idem. |
+| PUT /api/dlc-products/:id/mark-processed | au clic CheckCircle2 | server/routes.ts:3108 -> storage.getDlcProduct + storage.markDlcProductAsProcessed (storage.ts:2170) | Le produit traité est ensuite exclu définitivement des filtres/compteurs « Expirés ». |
+| PUT /api/dlc-products/:id/unmark-processed | au clic X (admin/manager/directeur) | server/routes.ts:3148 -> storage.getDlcProduct + storage.unmarkDlcProductAsProcessed (storage.ts:2197) | Idem. |
+| GET /api/ffnancy/articles?ean=…&limit=1 puis GET /api/ffnancy/mouvements/entrees?artNoId=… | saisie du champ EAN (≥ 8 caractères, debounce 600 ms) — aussi déclenché à l'ouverture en édition | server/routes.ts:6396 et 6411 -> proxy fetch https://api.ffnancy.fr sans timeout ni cache | 2 allers-retours séquentiels client→serveur→API externe, fetch() manuels sans AbortController. |
+
+**Lisibilité / simplicité :** Page fonctionnelle mais chargée et ambiguë pour un employé : filtres placés avant les compteurs, compteurs non cliquables et incohérents avec les listes filtrées (« Actifs » inclut les « Expire bientôt », le jour J compté deux fois), jusqu'à 5 boutons icônes colorés par ligne (Modifier/Supprimer sans infobulle, deux icônes de coche quasi identiques pour « Valider » et « Traité »), 4 notions qui se recouvrent (Validé, Traité, Stock épuisé, Supprimé). Bouton « Exporter PDF » inactif, mini-icônes d'impression de 24 px sans libellé. Le jour J, aucun bouton Valider/Traiter n'apparaît. Le chargement remplace le tableau par un texte à chaque frappe ; les erreurs serveur s'affichent en JSON anglais ou se déguisent en « Aucun produit ». Bug de dialogue : après « Annuler » d'une modification, « Nouveau produit DLC » rouvre en mode modification. console.log de debug dans onSubmit.
+
+### `/dlc (mobile, client/src/pages/mobile/DlcPage.tsx via RouterProduction.tsx:124)`
+
+**Rôle :** Version téléphone de la gestion DLC : consulter la liste par onglet (OK / Bientôt / Expirés / Validés), ajouter un produit (scan EAN) et valider un produit expiré.
+
+**Tâches principales de l'utilisateur :**
+- Voir les produits par onglet d'urgence
+- Rechercher un produit (nom ou EAN)
+- Ajouter un produit via le bouton flottant + feuille de saisie
+- Valider (sortir) un produit via le menu …
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/dlc-products?storeId=… | au montage puis à CHAQUE changement d'onglet et CHAQUE frappe dans la recherche (queryKey contient statusFilter et searchTerm), seulement si selectedStoreId | server/routes.ts:2797 -> storage.getDlcProducts (storage.ts:1976) | fetch() manuel sans contrôle res.ok ; le queryFn ignore statut et recherche : même réponse complète re-téléchargée à chaque fois. |
+| GET /api/suppliers?dlc=true | au montage (pas d'enabled) | server/routes.ts:1141 -> storage.getSuppliers (storage.ts:467) | Même clé que desktop, OK. |
+| GET /api/groups | au montage | server/routes.ts:970 -> storage.getUserWithGroups / getGroups | Redondant avec useStore().stores fourni par MobileApp.tsx:28. |
+| POST /api/dlc-products | soumission du formulaire | server/routes.ts:2889 -> storage.createDlcProduct (storage.ts:2110) | supplierId par défaut = 1. |
+| POST /api/dlc-products/:id/validate | menu … > Valider (Sortir) | server/routes.ts:2977 -> storage.validateDlcProduct (storage.ts:2128) | Proposé à tous les rôles, refusé (403) pour les employés, sans onError. |
+| GET /api/ffnancy/articles + /api/ffnancy/mouvements/entrees | saisie EAN ≥ 8 caractères (debounce 600 ms) | server/routes.ts:6396 / 6411 (proxy externe) | Code copié-collé du desktop. |
+
+**Lisibilité / simplicité :** Interface simple (cartes, onglets, bouton flottant) mais : liste vide pour les employés et pour « Tous les magasins » (requête désactivée sans magasin sélectionné, sans message explicatif), onglet par défaut « OK » (le moins urgent), onglets sans compteurs, badge « J-3 » identique pour « expire dans 3 jours » et « expiré depuis 3 jours », formulaire sans aucun message d'erreur, fournisseur n°1 pré-sélectionné en silence, date du jour pré-remplie, action « Valider » silencieusement refusée aux employés et sans confirmation. Fonctions absentes par rapport au desktop (modifier, supprimer, stock épuisé, traité). Chaque frappe recharge toute la liste.
+
+### `/ (Dashboard) — modale DlcAlertModal (client/src/components/DlcAlertModal.tsx, utilisée dans client/src/pages/Dashboard.tsx:773)`
+
+**Rôle :** Alerter automatiquement les utilisateurs non-admin, à l'ouverture du tableau de bord, des produits expirés ou expirant sous 15 jours, avec action rapide « Stock épuisé » et lien vers la page DLC.
+
+**Tâches principales de l'utilisateur :**
+- Prendre connaissance des produits expirés / bientôt expirés
+- Marquer un produit expiré comme « Stock épuisé »
+- Aller à la page DLC
+- Reporter l'alerte de 2 h
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/dlc-products/stats?storeId | au montage du Dashboard (Dashboard.tsx:231) + invalidation au montage (Dashboard.tsx:22-26) | server/routes.ts:2831 -> storage.getDlcStats (storage.ts:2224) | Requête lancée puis relancée par l'invalidation du useEffect au montage. |
+| GET /api/dlc-products?status=expires&storeId | à l'ouverture de la modale si stats.expired > 0 | server/routes.ts:2797 -> storage.getDlcProducts filtre 'expires' (storage.ts:2017) | fetch() manuel sans res.ok ; liste complète téléchargée pour n'en afficher que 8 ; inclut les stocks épuisés alors que le compteur les exclut. |
+| GET /api/dlc-products?status=expires_soon&storeId | à l'ouverture si stats.expiringSoon > 0 | server/routes.ts:2797 -> storage.getDlcProducts filtre 'expires_soon' (storage.ts:2000) | Idem. |
+| PUT /api/dlc-products/:id/stock-epuise | clic « Stock épuisé » | server/routes.ts:3023 -> storage.markDlcProductStockEpuise (storage.ts:2142) | Invalide liste et stats. |
+
+**Lisibilité / simplicité :** La modale ne peut pas être fermée par la croix/Échap/clic extérieur (elle se rouvre aussitôt) : seul « Traiter plus tard (2h) » fonctionne. Elle pousse à marquer un produit EXPIRÉ comme « stock épuisé » pour faire disparaître l'alerte, ce qui contredit la définition de la page DLC (« différent de périmé »). Aucun bouton d'action pour les produits qui expirent bientôt. Jargon (« Ce modal »), emojis dans les toasts, compteurs d'en-tête différents du nombre de lignes affichées, « Expiré depuis 0 jour(s) » le jour J. Le lien « Voir tous les produits DLC » recharge toute l'application.
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [DLC-01](#dlc-01) | haute | bug | S | Un produit « traité » ne réapparaît jamais une fois expiré (filtre Expirés, compteurs et alerte) | `server/storage.ts:2017` |
+| [DLC-02](#dlc-02) | haute | bug | S | Le jour J, aucun bouton « Valider » ni « Marquer traité » et badge « Expire bientôt » alors que le serveur le classe « Expiré » | `client/src/pages/DlcPage.tsx:425` |
+| [DLC-03](#dlc-03) | haute | bug | S | Après « Annuler » une modification, « Nouveau produit DLC » rouvre en mode modification et écrase l'ancien produit | `client/src/pages/DlcPage.tsx:668` |
+| [DLC-04](#dlc-04) | haute | bug | S | Ouvrir un produit en modification relance la recherche EAN et écrase son nom et son fournisseur | `client/src/pages/DlcPage.tsx:123` |
+| [DLC-05](#dlc-05) | haute | bug | S | Le magasin du produit ignore le magasin sélectionné et une modification peut déplacer le produit dans un autre magasin | `client/src/pages/DlcPage.tsx:330` |
+| [DLC-06](#dlc-06) | haute | bug | M | POST/PUT DLC sans validation : un employé peut valider un produit ou le déplacer vers un autre magasin | `server/routes.ts:2940` |
+| [DLC-07](#dlc-07) | haute | perf-api | S | Chaque produit DLC renvoie la ligne complète du magasin (logo base64, config SMTP/NocoDB) et du fournisseur | `server/storage.ts:1977` |
+| [DLC-08](#dlc-08) | haute | bug | S | La modale d'alerte DLC se rouvre immédiatement quand on la ferme par la croix, Échap ou clic extérieur | `client/src/pages/Dashboard.tsx:257` |
+| [DLC-09](#dlc-09) | haute | perf-client | S | Mobile : toute la liste est re-téléchargée à chaque frappe de recherche et à chaque changement d'onglet | `client/src/pages/mobile/DlcPage.tsx:84` |
+| [DLC-10](#dlc-10) | haute | bug | S | Mobile : liste DLC toujours vide pour les employés et pour « Tous les magasins » | `client/src/pages/mobile/DlcPage.tsx:96` |
+| [DLC-11](#dlc-11) | haute | bug | S | Mobile : fournisseur n°1 attribué en silence et choix fournisseur non synchronisé | `client/src/pages/mobile/DlcPage.tsx:137` |
+| [DLC-26](#dlc-26) | haute | bug | S | Injection HTML/JS dans l'impression (document.write avec nom de produit non échappé) | `client/src/pages/DlcPage.tsx:535` |
+| [DLC-12](#dlc-12) | moyenne | ux-simplicite | S | Mobile : formulaire sans aucun message d'erreur | `client/src/pages/mobile/DlcPage.tsx:368` |
+| [DLC-13](#dlc-13) | moyenne | bug | S | Mobile : « Valider (Sortir) » proposé à tous, refusé en silence aux employés et sans confirmation | `client/src/pages/mobile/DlcPage.tsx:121` |
+| [DLC-14](#dlc-14) | moyenne | bug | M | Compteurs incohérents avec les listes : « Actifs » inclut « Expire bientôt », le jour J compté deux fois, stocks épuisés comptés différemment | `server/storage.ts:2238` |
+| [DLC-15](#dlc-15) | moyenne | bug | S | Desktop : le magasin sélectionné est ignoré pour les non-admins et la clé de cache des stats entre en collision avec le Dashboard | `client/src/pages/DlcPage.tsx:83` |
+| [DLC-16](#dlc-16) | moyenne | perf-client | S | Le tableau disparaît à chaque changement de filtre ou de recherche (pas de placeholderData ni de squelette) | `client/src/pages/DlcPage.tsx:937` |
+| [DLC-17](#dlc-17) | moyenne | perf-api | M | Aucune pagination serveur : l'historique complet (y compris tous les produits validés) est chargé par défaut | `server/storage.ts:2063` |
+| [DLC-18](#dlc-18) | moyenne | perf-serveur | M | Chaque requête DLC recharge l'utilisateur (2 requêtes) et chaque action relit le produit avec 2 jointures | `server/routes.ts:2799` |
+| [DLC-19](#dlc-19) | moyenne | perf-client | M | Chaque clic d'action recharge toute la liste + les stats et désactive le bouton sur toutes les lignes | `client/src/pages/DlcPage.tsx:255` |
+| [DLC-20](#dlc-20) | moyenne | perf-api | S | Invalidations au montage : la requête de stats DLC part deux fois à chaque visite du tableau de bord | `client/src/components/DlcAlertModal.tsx:45` |
+| [DLC-21](#dlc-21) | moyenne | ux-simplicite | S | Messages d'erreur affichés en JSON anglais avec code HTTP | `client/src/lib/queryClient.ts:6` |
+| [DLC-22](#dlc-22) | moyenne | ux-simplicite | S | Les erreurs serveur sont déguisées en « Aucun produit » ou en compteurs à 0 | `server/routes.ts:2827` |
+| [DLC-23](#dlc-23) | moyenne | ux-simplicite | M | Jusqu'à 5 boutons icônes colorés par ligne, deux coches quasi identiques et 4 notions qui se recouvrent | `client/src/pages/DlcPage.tsx:982` |
+| [DLC-25](#dlc-25) | moyenne | ux-simplicite | S | Impression cachée dans des icônes de 24 px et liste imprimée différente du compteur affiché | `client/src/pages/DlcPage.tsx:887` |
+| [DLC-27](#dlc-27) | moyenne | ux-simplicite | S | Hiérarchie visuelle inversée : filtres avant les compteurs, compteurs non cliquables | `client/src/pages/DlcPage.tsx:817` |
+| [DLC-28](#dlc-28) | moyenne | coherence-design | M | Vocabulaire, couleurs et seuils d'urgence différents entre desktop, mobile et modale | `client/src/pages/mobile/DlcPage.tsx:293` |
+| [DLC-29](#dlc-29) | moyenne | lisibilite | S | Badge « J-3 » identique pour « expire dans 3 jours » et « expiré depuis 3 jours » | `client/src/pages/mobile/DlcPage.tsx:264` |
+| [DLC-30](#dlc-30) | moyenne | ux-simplicite | S | Mobile : l'onglet par défaut montre les produits les moins urgents et les onglets n'ont pas de compteur | `client/src/pages/mobile/DlcPage.tsx:77` |
+| [DLC-31](#dlc-31) | moyenne | ux-simplicite | M | Mobile : actions manquantes par rapport au desktop (modifier, supprimer, stock épuisé, traité) | `client/src/pages/mobile/DlcPage.tsx:336` |
+| [DLC-32](#dlc-32) | moyenne | ux-simplicite | S | La modale incite à marquer un produit périmé « stock épuisé » pour faire disparaître l'alerte | `client/src/components/DlcAlertModal.tsx:285` |
+| [DLC-36](#dlc-36) | moyenne | perf-api | M | Recherche EAN : 2 allers-retours séquentiels vers une API externe, sans cache, sans délai max, code dupliqué | `client/src/pages/DlcPage.tsx:132` |
+| [DLC-47](#dlc-47) | moyenne | ux-simplicite | S | La recherche desktop ne trouve pas un produit par son code EAN (le mobile oui) | `server/storage.ts:2049` |
+| [DLC-24](#dlc-24) | basse | ux-simplicite | S | Bouton « Exporter PDF » sans action | `client/src/pages/DlcPage.tsx:930` |
+| [DLC-33](#dlc-33) | basse | perf-client | S | Le lien vers la page DLC recharge toute l'application | `client/src/components/DlcAlertModal.tsx:142` |
+| [DLC-34](#dlc-34) | basse | lisibilite | S | Jargon, emojis et formulations maladroites dans la modale | `client/src/components/DlcAlertModal.tsx:285` |
+| [DLC-35](#dlc-35) | basse | dette-code | S | console.log de debug dans onSubmit et dans les routes de mutation | `client/src/pages/DlcPage.tsx:348` |
+| [DLC-37](#dlc-37) | basse | perf-serveur | S | Fournisseurs DLC filtrés en JavaScript après lecture de toute la table | `server/routes.ts:1150` |
+| [DLC-38](#dlc-38) | basse | dette-code | S | Les compteurs DLC sont renvoyés en chaînes (COUNT bigint), comparaison stricte morte dans la modale | `server/storage.ts:2261` |
+| [DLC-39](#dlc-39) | basse | perf-serveur | S | Les stats DLC parcourent tout l'historique (validés inclus) et utilisent la date UTC | `server/storage.ts:2229` |
+| [DLC-40](#dlc-40) | basse | dette-code | S | Index dlc_products absents de shared/schema.ts (risque de suppression par drizzle-kit push) | `shared/schema.ts:278` |
+| [DLC-41](#dlc-41) | basse | accessibilite | S | Boutons icônes sans libellé accessible (Modifier, Supprimer, Imprimer, menu …, bouton +) | `client/src/pages/DlcPage.tsx:983` |
+| [DLC-42](#dlc-42) | basse | accessibilite | S | Lignes grisées par opacité 50-60 % : texte et boutons peu lisibles | `client/src/pages/DlcPage.tsx:962` |
+| [DLC-43](#dlc-43) | basse | ux-simplicite | S | Tableau DLC non défilable et sans colonne Magasin sur tablette / vue multi-magasins | `client/src/components/ui/table.tsx:9` |
+| [DLC-44](#dlc-44) | basse | lisibilite | S | Message de validation « Required » en anglais si aucun fournisseur choisi | `client/src/pages/DlcPage.tsx:33` |
+| [DLC-45](#dlc-45) | basse | dette-code | M | Code dupliqué : 7 mutations copiées-collées, 2 fonctions d'impression identiques, TooltipProvider par bouton, imports morts | `client/src/pages/DlcPage.tsx:178` |
+| [DLC-46](#dlc-46) | basse | perf-bundle | S | Pages DLC desktop et mobile importées statiquement dans le bundle principal | `client/src/components/RouterProduction.tsx:21` |
+| [DLC-48](#dlc-48) | basse | bug | S | Recherche mobile plantée si un produit n'a pas de productName (colonne nullable) | `client/src/pages/mobile/DlcPage.tsx:236` |
+| [DLC-49](#dlc-49) | basse | ux-simplicite | S | Mobile : date d'expiration pré-remplie à aujourd'hui | `client/src/pages/mobile/DlcPage.tsx:135` |
+| [DLC-50](#dlc-50) | basse | lisibilite | S | Choix DLC / DDM / DLUO : DLUO est un terme obsolète qui ajoute de la confusion | `client/src/pages/DlcPage.tsx:777` |
+| [DLC-51](#dlc-51) | basse | ux-simplicite | S | Retour à la page 1 après chaque action qui retire une ligne de la vue filtrée | `client/src/components/ui/pagination.tsx:157` |
+
+### DLC-01
+
+**Un produit « traité » ne réapparaît jamais une fois expiré (filtre Expirés, compteurs et alerte)** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:2017`
+- **Constat :** storage.ts:2017-2027 filtre 'expires' : and(lte(expiryDate, today), ne(status,'valides'), or(isNull(processedUntilExpiry), eq(processedUntilExpiry,false))) ; storage.ts:2250-2254 compteur expired : AND (processedUntilExpiry IS NULL OR = false). Aucun job ne remet processedUntilExpiry à false (grep sans résultat hors storage.ts). Or DlcPage.tsx:1023 promet : « Indique que vous vous êtes occupé de ce produit (réapparaîtra à expiration) ».
+- **Impact :** Sécurité alimentaire : un produit marqué « traité » quand il expirait bientôt disparaît définitivement du filtre « Expirés », du compteur rouge et de la modale d'alerte du tableau de bord ; il ne reste visible qu'en vue « Tous les statuts », grisé et trié en fin de liste.
+- **Recommandation :** Comme proposé : retirer l'exclusion processedUntilExpiry du filtre 'expires' et du COUNT expired, en la gardant pour 'expires_soon'. Il faut aussi adapter le ORDER BY (storage.ts:2066-2074 : un produit traité expiré ne doit plus être classé en priorité 2) et le grisage de la ligne (DlcPage.tsx:963). Aligner MemStorage (storage.ts:4538-4549). À coordonner avec DLC-39 : si l'exclusion passe dans le WHERE des stats, elle ne doit pas s'appliquer aux expirés.
+
+### DLC-02
+
+**Le jour J, aucun bouton « Valider » ni « Marquer traité » et badge « Expire bientôt » alors que le serveur le classe « Expiré »** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:425`
+- **Constat :** daysUntilExpiry = Math.ceil((expiry - today)/86400000) avec expiry = new Date('YYYY-MM-DD') (minuit UTC, drizzle renvoie la date en chaîne : node_modules/drizzle-orm/node-postgres/session.js:31). Le jour J la valeur vaut -0 → shouldShowValidateButton exige `daysUntilExpiry < 0` (l.432) et shouldShowMarkProcessedButton exige `daysUntilExpiry > 0` (l.445) : aucun des deux. getStatusBadge l.490-493 affiche « Expire bientôt ». Côté serveur, le filtre 'expires' utilise lte(expiryDate, today) (storage.ts:2021) : le produit du jour est listé dans « Expirés ».
+- **Impact :** Le jour le plus critique, l'employé voit le produit dans « Expirés » avec un badge orange « Expire bientôt » et sans action de retrait possible : confusion et retrait oublié.
+- **Recommandation :** Créer un utilitaire partagé (ex. shared/dlc.ts) : getDaysUntilExpiry(date) = differenceInCalendarDays(parseISO(date), startOfToday()) et des seuils uniques (≤ 0 = expiré, 1-15 = bientôt). L'utiliser dans DlcPage, mobile/DlcPage, DlcAlertModal et aligner la requête SQL (expiry_date <= CURRENT_DATE).
+
+### DLC-03
+
+**Après « Annuler » une modification, « Nouveau produit DLC » rouvre en mode modification et écrase l'ancien produit** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:668`
+- **Constat :** handleEdit (l.377-389) fait setEditingProduct(product) + form.reset(...). Le bouton Annuler (l.803) fait seulement `setIsDialogOpen(false)` et `<Dialog open={isDialogOpen} onOpenChange={setIsDialogOpen}>` (l.668) ne remet ni editingProduct ni le formulaire à zéro. Le DialogTrigger « Nouveau produit DLC » (l.669-673) rouvre donc avec le titre « Modifier le produit DLC » et onSubmit appelle updateMutation (l.370-371).
+- **Impact :** Un employé qui croit créer un nouveau produit modifie en réalité le dernier produit ouvert : perte de données silencieuse.
+- **Recommandation :** Créer une fonction closeDialog() qui fait setIsDialogOpen(false), setEditingProduct(null) et form.reset(). L'utiliser dans onOpenChange (si !open), dans le bouton Annuler (un appel programmatique ne déclenche pas onOpenChange) et dans les onSuccess. Au clic sur « Nouveau produit DLC », faire setEditingProduct(null) et form.reset().
+
+### DLC-04
+
+**Ouvrir un produit en modification relance la recherche EAN et écrase son nom et son fournisseur** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:123`
+- **Constat :** useEffect([gencodeValue, suppliers]) l.123-176 se déclenche dès que gencode ≥ 8 caractères. handleEdit appelle form.reset({ gencode: product.gencode, ... }) (l.379-381) → 600 ms plus tard `form.setValue("productName", article.libelle1)` (l.138) et `form.setValue("supplierId", matched.id)` (l.163). Aucun AbortController : une réponse ancienne peut aussi écraser une saisie plus récente.
+- **Impact :** Le nom personnalisé (« Yaourt fraise lot promo ») est remplacé sans prévenir par le libellé ffnancy ; le fournisseur peut changer. L'utilisateur enregistre sans s'en rendre compte.
+- **Recommandation :** Garder le remplissage automatique en création, puisque c'est la fonctionnalité voulue ; remplacer l'écrasement par un simple message serait une décision produit. Correctif sûr : ne pas lancer la recherche en mode modification tant que le gencode est celui du produit (editingProduct?.gencode === gencodeValue), ou ne la déclencher que depuis l'onChange du champ. Ajouter un AbortController annulé dans le cleanup, et ignorer une réponse dont le gencode ne correspond plus à la valeur courante.
+
+### DLC-05
+
+**Le magasin du produit ignore le magasin sélectionné et une modification peut déplacer le produit dans un autre magasin** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:330`
+- **Constat :** onSubmit l.329-346 : « FORCE L'UTILISATION DU GROUPE ASSIGNÉ EN PREMIER » `if (user?.userGroups?.[0]?.groupId) groupId = user.userGroups[0].groupId;` puis fallback `groupId = 1` (l.344). dlcData contient groupId et est aussi envoyé en modification (l.371). Le mobile fait l'inverse : `let groupId = selectedStoreId;` (mobile/DlcPage.tsx:204).
+- **Impact :** Un manager/directeur multi-magasins qui a sélectionné le magasin B crée ses produits dans le magasin A ; modifier un produit du magasin B le transfère dans A. Les produits « disparaissent » du magasin attendu.
+- **Recommandation :** En création : groupId = selectedStoreId s'il est défini, sinon unique magasin de l'utilisateur, sinon afficher un champ « Magasin » obligatoire (supprimer le fallback 1). En modification : ne pas envoyer groupId.
+
+### DLC-06
+
+**POST/PUT DLC sans validation : un employé peut valider un produit ou le déplacer vers un autre magasin** — bug, sévérité haute, effort M
+
+- **Fichier :** `server/routes.ts:2940`
+- **Constat :** routes.ts:2896-2909 `const data = { ...req.body, createdBy: user.id }; ... storage.createDlcProduct(data)` ; routes.ts:2940 `storage.updateDlcProduct(id, req.body)` puis storage.ts:2118 `.set({ ...productData, updatedAt })`. Aucun insertDlcProductSchema.parse ; le nouveau groupId n'est pas vérifié. Le rôle requis pour /validate (routes.ts:2985 ['admin','directeur','manager']) est contournable via PUT {status:'valides'}. DELETE (routes.ts:2947) n'a aucun contrôle de rôle.
+- **Impact :** Contournement des droits (validation, transfert vers un magasin non autorisé, modification de validatedBy/stockEpuiseBy) ; payload invalide → 500 générique « Failed to create DLC product » au lieu d'erreurs de champ.
+- **Recommandation :** Schéma zod d'édition : productName, name (le client l'envoie pour garder la colonne NOT NULL synchronisée, DlcPage.tsx:361), gencode, expiryDate (accepter la chaîne ISO datetime envoyée par le client : new Date(...) sérialisé), dateType, supplierId, notes. Ignorer status, groupId et les champs validated*/processed*/stockEpuise* en PUT ; en POST, vérifier que groupId appartient aux groupes de l'utilisateur (déjà fait, routes.ts:2902-2906) et forcer status='en_cours'. Le contrôle de rôle sur DELETE est une décision produit séparée.
+
+### DLC-07
+
+**Chaque produit DLC renvoie la ligne complète du magasin (logo base64, config SMTP/NocoDB) et du fournisseur** — perf-api, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:1977`
+- **Constat :** storage.ts:1977-1985 `.select({ dlcProduct: dlcProducts, supplier: suppliers, group: groups })` ; idem getDlcProduct storage.ts:2089-2098. shared/schema.ts:67 `logo: text("logo"), // Logo en data URI (data:image/png;base64,...)` + smtpHost/smtpUser/webhookUrl/nocodb*. Le client n'utilise que product.supplier?.name (DlcPage.tsx:979, mobile l.325, DlcAlertModal l.178) et jamais product.group. Pas de compression gzip dans server/index.production.ts (aucun middleware compression). stripSmtpPassword (server/sanitize.ts) reparcourt récursivement tout ce JSON.
+- **Impact :** Avec un logo de 50 Ko et 300 produits, la réponse dépasse 15 Mo non compressés : chargement de la page DLC et de la modale de plusieurs secondes sur le Wi-Fi/4G du magasin, parsing JSON lourd sur mobile, fuite d'informations de configuration à tous les employés.
+- **Recommandation :** Partie automatisable : dans getDlcProducts, sélectionner `supplier: { id: suppliers.id, name: suppliers.name }` et `group: { id: groups.id, name: groups.name, color: groups.color }`. Dans getDlcProduct (utilisé pour les contrôles de droits et par GET /api/dlc-products/:id, qu'aucun client n'appelle), même restriction. Activer la compression demande d'ajouter une dépendance (`compression`) dans index.production.ts et index.ts : c'est un changement séparé, non automatique. Ne surtout pas brancher setupCompression de cache.ts.
+
+### DLC-08
+
+**La modale d'alerte DLC se rouvre immédiatement quand on la ferme par la croix, Échap ou clic extérieur** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:257`
+- **Constat :** DlcAlertModal.tsx:146 `<Dialog open={isOpen} onOpenChange={onClose}>` → handleCloseDlcAlertModal met showDlcAlertModal à false (Dashboard.tsx:276-278). L'effet Dashboard.tsx:243-273 a showDlcAlertModal dans ses dépendances : `if (shouldShowDlcModal && !showDlcAlertModal) { ... } else { setShowDlcAlertModal(true); }` (l.257-268) sans snooze → réouverture instantanée. Seul handleSnooze (DlcAlertModal.tsx:106-112) écrit dlcAlertSnooze.
+- **Impact :** Pour un employé, la croix « ne marche pas » : il est bloqué sur une fenêtre rouge tant qu'il ne trouve pas « Traiter plus tard (2h) ». Expérience très frustrante à chaque ouverture du tableau de bord.
+- **Recommandation :** Considérer toute fermeture comme une mise en sourdine (au minimum pour la session : sessionStorage ou useRef « dismissed »), et retirer showDlcAlertModal des dépendances de l'effet ; n'ouvrir automatiquement qu'une fois par chargement.
+
+### DLC-09
+
+**Mobile : toute la liste est re-téléchargée à chaque frappe de recherche et à chaque changement d'onglet** — perf-client, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/mobile/DlcPage.tsx:84`
+- **Constat :** `queryKey: ["/api/dlc-products", selectedStoreId, statusFilter, searchTerm]` (l.84) alors que le queryFn ignore statut et recherche : `fetch(`/api/dlc-products?storeId=${selectedStoreId}`)` (l.91). Le filtrage est déjà fait en useMemo (l.227-257). Pas de debounce sur searchTerm (l.285).
+- **Impact :** Taper « yaourt » = 6 requêtes complètes identiques (avec la charge de DLC-07) ; chaque onglet affiche un spinner alors que les données sont déjà en mémoire. Très lent en 4G en rayon.
+- **Recommandation :** queryKey ["/api/dlc-products", "mobile", selectedStoreId] (le préfixe reste invalidé par les mutations), staleTime 2 min, filtrage uniquement côté client avec useDeferredValue(searchTerm), queryFn via apiRequest.
+
+### DLC-10
+
+**Mobile : liste DLC toujours vide pour les employés et pour « Tous les magasins »** — bug, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/mobile/DlcPage.tsx:96`
+- **Constat :** `enabled: !!selectedStoreId && !!user` (l.96) et `if (selectedStoreId) {...} return [];` (l.90-94). MobileApp.tsx:33-38 ne pré-sélectionne un magasin que pour `user.role === 'directeur' || user.role === 'manager'` avec un seul magasin. Le serveur sait pourtant limiter aux magasins de l'utilisateur sans storeId (routes.ts:2809-2815). L'état vide affiche « Aucun produit trouvé » (l.306-310).
+- **Impact :** Un employé ouvre « DLC » sur son téléphone et voit « Aucun produit trouvé » alors que des produits expirent : faux sentiment de sécurité.
+- **Recommandation :** Appeler /api/dlc-products sans storeId quand selectedStoreId est null (routes.ts:2807-2815 restreint déjà aux magasins de l'utilisateur), en retirant la condition selectedStoreId de enabled ; sinon, afficher un état vide explicite « Choisissez votre magasin » avec un bouton qui ouvre le menu.
+
+### DLC-11
+
+**Mobile : fournisseur n°1 attribué en silence et choix fournisseur non synchronisé** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/mobile/DlcPage.tsx:137`
+- **Constat :** defaultValues `supplierId: 1` (l.137) ; Select non contrôlé `defaultValue={field.value.toString()}` (l.424) et dateType `defaultValue={field.value}` (l.398). Si le fournisseur 1 n'est pas « DLC », le Select affiche « Choisir... » mais la valeur 1 passe la validation `z.coerce.number().min(1)` (l.68). Le form.setValue("supplierId", matched.id) de la recherche EAN (l.188) ne met pas à jour l'affichage.
+- **Impact :** Des produits sont enregistrés avec un mauvais fournisseur sans que l'utilisateur le voie ; filtrage par fournisseur et retours fournisseurs faussés.
+- **Recommandation :** supplierId: undefined par défaut et Select contrôlé `value={field.value ? String(field.value) : ""}` ("" pour revenir au placeholder après reset), idem pour dateType. Avec z.coerce, undefined devient NaN et produit « Expected number, received nan » : utiliser `z.coerce.number({ invalid_type_error: "Fournisseur requis" }).min(1, "Fournisseur requis")`. À livrer avec DLC-12, sinon la soumission échoue sans aucun message.
+
+### DLC-26
+
+**Injection HTML/JS dans l'impression (document.write avec nom de produit non échappé)** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:535`
+- **Constat :** l.529-543 : `<td>${product.productName}</td> <td>${product.gencode || '-'}</td> ... ${product.supplier?.name}` puis l.550-554 `window.open('', '_blank')` + `printWindow.document.write(printContent)` (fenêtre about:blank de même origine). En production Docker (Dockerfile:41 compile server/index.production.ts) aucun middleware setupInputSanitization n'est appliqué (présent seulement dans server/index.ts:37).
+- **Impact :** Un nom de produit contenant `<img src=x onerror=...>` saisi par n'importe quel employé s'exécute dans la session du manager qui imprime (XSS stocké).
+- **Recommandation :** Échapper toutes les valeurs (helper escapeHtml) ou construire le tableau via DOM/textContent ; factoriser printExpired/printExpiringSoon en une fonction printList(titre, produits).
+
+### DLC-12
+
+**Mobile : formulaire sans aucun message d'erreur** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/DlcPage.tsx:368`
+- **Constat :** Aucun <FormMessage /> dans les FormItem (l.364-476), alors que le schéma définit « Nom du produit requis », « Date requise », « Fournisseur requis » (l.64-68).
+- **Impact :** Si un champ manque, le bouton « Ajouter le produit » ne fait rien de visible : l'utilisateur pense que l'application est bloquée.
+- **Recommandation :** Ajouter <FormMessage /> sous chaque champ. React Hook Form met déjà le focus sur le premier champ en erreur (shouldFocusError par défaut), le défilement explicite est facultatif.
+
+### DLC-13
+
+**Mobile : « Valider (Sortir) » proposé à tous, refusé en silence aux employés et sans confirmation** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/DlcPage.tsx:121`
+- **Constat :** validateMutation (l.121-127) n'a pas d'onError ; le menu (l.329-343) s'affiche pour tout rôle dès que statusFilter !== 'valides'. Le serveur répond 403 aux employés (routes.ts:2984-2987). Action définitive (aucune route d'annulation) sans AlertDialog.
+- **Impact :** L'employé clique, rien ne se passe (aucun message) ; un manager peut valider par erreur un produit d'un simple tap sans retour possible.
+- **Recommandation :** Partie automatisable : masquer l'entrée pour les rôles non autorisés (même règle que DlcPage.tsx:990) et ajouter un onError avec toast en français. La confirmation (AlertDialog) ajoute une étape visible : c'est recommandé, mais à valider côté produit.
+
+### DLC-14
+
+**Compteurs incohérents avec les listes : « Actifs » inclut « Expire bientôt », le jour J compté deux fois, stocks épuisés comptés différemment** — bug, sévérité moyenne, effort M
+
+- **Fichier :** `server/storage.ts:2238`
+- **Constat :** getDlcStats : active = expiryDate > today (l.2238-2243, inclut donc 1-15 jours) ; expiringSoon = BETWEEN today AND today+15 (l.2244-2249) ; expired = <= today (l.2250-2255) → jour J dans les deux. Les compteurs excluent stockEpuise, mais les filtres liste 'expires'/'expires_soon' (l.2000-2028) ne l'excluent pas ; le filtre 'en_cours' = > 15 jours (l.2029-2039) ≠ carte « Produits Actifs ». DlcAlertModal affiche « Produits Expirés ({dlcStats.expired}) » (l.165) au-dessus d'une liste qui contient les stocks épuisés (l.196-200).
+- **Impact :** La carte dit 12 « Actifs » mais le filtre « Actifs » en montre 5 ; la modale annonce 2 expirés et en liste 4 : l'utilisateur ne fait plus confiance aux chiffres.
+- **Recommandation :** Définir une seule fonction SQL de classement en catégories exclusives (expiré / bientôt / ok / épuisé / traité / validé) réutilisée par getDlcStats et getDlcProducts (CASE commun ou helper drizzle), basée sur CURRENT_DATE.
+
+### DLC-15
+
+**Desktop : le magasin sélectionné est ignoré pour les non-admins et la clé de cache des stats entre en collision avec le Dashboard** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:83`
+- **Constat :** l.83 et l.99 : `if (selectedStoreId && user?.role === 'admin') params.append("storeId", ...)`. Dashboard.tsx:232-236 utilise la même queryKey ["/api/dlc-products/stats", selectedStoreId] mais envoie storeId pour tous les rôles. Le serveur gère déjà le contrôle (routes.ts:2843-2849).
+- **Impact :** Un directeur multi-magasins voit sur la page DLC les produits de tous ses magasins mélangés (sans colonne Magasin) alors qu'il en a sélectionné un ; les cartes peuvent afficher les chiffres d'un magasin (cache Dashboard) puis basculer sur le total après refetch.
+- **Recommandation :** Toujours envoyer storeId quand il est défini ; extraire un hook partagé useDlcStats(selectedStoreId) utilisé par Dashboard et DlcPage pour garantir une seule URL par clé.
+
+### DLC-16
+
+**Le tableau disparaît à chaque changement de filtre ou de recherche (pas de placeholderData ni de squelette)** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:937`
+- **Constat :** useQuery l.79-92 sans placeholderData ; chaque nouvelle clé (statut, fournisseur, recherche) remet isLoading à true → l.937-938 `<div className="flex justify-center items-center h-32">Chargement des produits...</div>` remplace tout le tableau. authLoading affiche aussi un simple texte (l.650-652).
+- **Impact :** Clignotement et saut de mise en page à chaque frappe ; sensation de lenteur même quand la réponse est rapide.
+- **Recommandation :** placeholderData: keepPreviousData + indicateur isFetching dans l'en-tête de la carte ; squelette seulement au premier chargement.
+
+### DLC-17
+
+**Aucune pagination serveur : l'historique complet (y compris tous les produits validés) est chargé par défaut** — perf-api, sévérité moyenne, effort M
+
+- **Fichier :** `server/storage.ts:2063`
+- **Constat :** getDlcProducts (storage.ts:1976-2086) n'a ni limit ni offset ; aucune purge des produits 'valides' (aucun autre fichier serveur ne touche dlc_products). Filtre par défaut desktop `useState("all")` (DlcPage.tsx:45) + pagination purement client usePagination (l.640-648). Mobile : toutes les cartes rendues sans pagination (mobile/DlcPage.tsx:312-347) et l'onglet « Validés » affiche tout l'historique.
+- **Impact :** La page ralentit mois après mois (téléchargement + tri + rendu de centaines/milliers de produits déjà retirés), surtout sur mobile.
+- **Recommandation :** Vue par défaut « À traiter » (exclure 'valides') ; pagination serveur (limit/offset + total) ou au minimum limiter les validés aux 30 derniers jours ; archivage/purge des validés > 90 jours.
+
+### DLC-18
+
+**Chaque requête DLC recharge l'utilisateur (2 requêtes) et chaque action relit le produit avec 2 jointures** — perf-serveur, sévérité moyenne, effort M
+
+- **Fichier :** `server/routes.ts:2799`
+- **Constat :** Toutes les routes DLC font `await storage.getUserWithGroups(req.user.id)` (ex. routes.ts:2799, 2833, 2919, 2979, 3025) alors que passport.deserializeUser a déjà exécuté getUserWithGroups (server/localAuth.ts:141-143) ; getUserWithGroups = getUser + SELECT user_groups (storage.ts:371-388). Les mutations font ensuite storage.getDlcProduct(id) (3 tables, logo inclus, storage.ts:2089-2098) juste pour lire groupId.
+- **Impact :** 5 allers-retours BD par clic (2 auth + 2 rechargement user + 1 lecture) avant la mise à jour : latence cumulée sur chaque action de la liste.
+- **Recommandation :** Partie automatisable : utiliser `const user = req.user as UserWithGroups` (même donnée, calculée dans la même requête) et une méthode légère getDlcProductGroupId(id) (SELECT group_id) pour les contrôles de droits. Le UPDATE ... WHERE group_id = ANY(...) RETURNING ne permet pas de distinguer 404 et 403 sans requête supplémentaire et change les signatures de storage : non automatique.
+
+### DLC-19
+
+**Chaque clic d'action recharge toute la liste + les stats et désactive le bouton sur toutes les lignes** — perf-client, sévérité moyenne, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:255`
+- **Constat :** 7 mutations (l.179-320) font toutes invalidateQueries ["/api/dlc-products"] et ["/api/dlc-products/stats"], sans mise à jour optimiste alors que le serveur renvoie la ligne modifiée. `disabled={markStockEpuiseMutation.isPending}` (l.1065), `disabled={markProcessedMutation.isPending}` (l.1013), etc. désactivent le bouton de toutes les lignes.
+- **Impact :** Traiter 10 produits à la suite = 20 rechargements complets ; les boutons de toutes les lignes clignotent/grisent pendant chaque action.
+- **Recommandation :** Partie sûre : désactiver uniquement la ligne concernée (`mutation.isPending && mutation.variables === product.id`). Garder l'invalidation de la liste (éventuellement refetchType 'active'). Une mise à jour optimiste n'est possible qu'en fusionnant les champs modifiés dans la ligne existante ET en conservant l'invalidation.
+
+### DLC-20
+
+**Invalidations au montage : la requête de stats DLC part deux fois à chaque visite du tableau de bord** — perf-api, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/DlcAlertModal.tsx:45`
+- **Constat :** DlcAlertModal.tsx:45-47 `useEffect(() => { queryClient.invalidateQueries({ queryKey: ["/api/dlc-products"] }); }, [selectedStoreId, queryClient]);` (la modale est toujours montée, même fermée) et Dashboard.tsx:22-26 invalide aussi ["/api/dlc-products"] et ["/api/dlc-products/stats"] au montage. invalidateQueries (cancelRefetch par défaut) relance la requête déjà en cours ; le fetch n'utilise pas le signal, donc le serveur traite les deux.
+- **Impact :** Requêtes doublées à chaque ouverture du tableau de bord et cache DLC de la page /dlc systématiquement marqué périmé.
+- **Recommandation :** Supprimer les deux useEffect comme proposé (aucun appelant n'en dépend) ; justification à corriger : refetch inutile de l'ancienne clé au changement de magasin et staleTime ignoré, pas une double requête à chaque visite.
+
+### DLC-21
+
+**Messages d'erreur affichés en JSON anglais avec code HTTP** — ux-simplicite, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/lib/queryClient.ts:6`
+- **Constat :** queryClient.ts:4-7 `throw new Error(`${res.status}: ${text}`)` avec text = corps brut ; DlcPage.tsx:193 `description: error.message`. Serveur : `res.status(500).json({ message: "Failed to create DLC product" })` (routes.ts:2913), « Insufficient permissions to validate DLC products » (routes.ts:2986), « Access denied to this group » (routes.ts:2905).
+- **Impact :** L'employé voit « 403: {"message":"Insufficient permissions to validate DLC products"} » : incompréhensible pour un non-technicien.
+- **Recommandation :** Ne pas modifier le format de error.message globalement. Soit créer une classe ApiError(status, message, body) et migrer d'abord toutes les détections de 401 vers error.status ; soit ajouter un helper getUserMessage(error), qui extrait `message` du JSON après le préfixe « NNN: », et l'utiliser dans les toasts DLC. Traduire en parallèle les messages des routes DLC.
+
+### DLC-22
+
+**Les erreurs serveur sont déguisées en « Aucun produit » ou en compteurs à 0** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:2827`
+- **Constat :** routes.ts:2827 `res.status(500).json([])` et routes.ts:2857 `res.status(500).json({ active: 0, expiringSoon: 0, expired: 0 })`. Côté client, aucune gestion isError : DlcPage.tsx:79 `data: dlcProducts = []` puis l.939-942 « Aucun produit DLC trouvé ». Le fetch mobile (l.91-92) et DlcAlertModal (l.56-57) ne testent pas res.ok.
+- **Impact :** En cas de panne BD, l'écran affiche 0 produit expiré : l'équipe pense que tout est en ordre.
+- **Recommandation :** Renvoyer 500 avec { message } ; afficher un bandeau « Impossible de charger les produits – Réessayer » (isError + refetch) ; utiliser apiRequest partout.
+
+### DLC-23
+
+**Jusqu'à 5 boutons icônes colorés par ligne, deux coches quasi identiques et 4 notions qui se recouvrent** — ux-simplicite, sévérité moyenne, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:982`
+- **Constat :** Colonne Actions l.982-1113 : Edit (sans infobulle), Valider `<CheckCircle>` vert (l.1000), Marquer traité `<CheckCircle2>` bleu (l.1017), Annuler traitement `<X>` orange, Stock épuisé `<PackageX>` jaune, Restaurer `<RotateCcw>` bleu, Supprimer `<Trash2>` rouge (sans infobulle). Concepts : « Validé », « Traité », « Stock épuisé », « Supprimé ».
+- **Impact :** Un employé ne sait pas quel bouton utiliser pour « j'ai retiré le produit du rayon » ; risque d'erreurs (valider au lieu de traiter, supprimer au lieu de valider).
+- **Recommandation :** Même recommandation (une action principale libellée + menu « … ») ; corriger le décompte : 4 boutons au maximum.
+
+### DLC-25
+
+**Impression cachée dans des icônes de 24 px et liste imprimée différente du compteur affiché** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:887`
+- **Constat :** Boutons l.887-894 et l.907-914 : `className="h-6 w-6 p-0"` avec `<FileText className="h-3 w-3">`, sans texte ni infobulle. printExpiringSoon/printExpired utilisent expiringSoonProducts/expiredProducts calculés depuis la liste filtrée courante (l.617-637), donc dépendent du filtre statut/fournisseur/recherche et incluent stocks épuisés et traités, alors que la carte affiche stats.expiringSoon/expired du serveur.
+- **Impact :** Fonction d'impression introuvable pour la plupart des utilisateurs ; avec le filtre « Validés » ou une recherche active, l'impression des expirés sort une feuille vide ou partielle.
+- **Recommandation :** Bouton visible « Imprimer » avec libellé dans chaque carte (ou un menu Imprimer), alimenté par une requête dédiée status=expires / expires_soon indépendante des filtres.
+
+### DLC-27
+
+**Hiérarchie visuelle inversée : filtres avant les compteurs, compteurs non cliquables** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:817`
+- **Constat :** Ordre du rendu : en-tête (l.657), carte « Filtres » avec titre (l.818-868), puis les 3 cartes statistiques (l.871-922), puis le tableau (l.926). Les cartes n'ont pas d'onClick pour filtrer.
+- **Impact :** L'information prioritaire (combien de produits expirés ?) est sous un bloc de formulaires ; il faut 2 actions (ouvrir le Select, choisir « Expirés ») au lieu d'un clic sur la carte rouge.
+- **Recommandation :** Placer les cartes en premier, les rendre cliquables (setStatusFilter('expires') etc. avec état actif visible), et réduire les filtres à une barre compacte au-dessus du tableau (recherche + 2 selects, sans titre de carte).
+
+### DLC-28
+
+**Vocabulaire, couleurs et seuils d'urgence différents entre desktop, mobile et modale** — coherence-design, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/mobile/DlcPage.tsx:293`
+- **Constat :** Desktop filtre « Actifs » / badge « Actif » / carte « Produits Actifs » (DlcPage.tsx:835, 495, 874) vs onglet mobile « OK » (mobile l.293) ; « Expire bientôt » vs « Bientôt » vs « Expirent Bientôt » (DlcAlertModal.tsx:219) ; « Validé » vs « Valider (Sortir) » vs toast « Produit validé (retiré) » (mobile l.125, 339) ; « Code EAN13 » (DlcPage.tsx:731) vs « Gencode (Scanner si dispo) » (mobile l.448) ; rouge ≤ 3 jours sur mobile (l.265) et « URGENT » dans la modale (l.244) mais aucun seuil 3 jours sur desktop ; bouton principal bleu desktop (l.670) vs orange mobile (l.478, 488).
+- **Impact :** Un même utilisateur qui passe du téléphone au PC doit réapprendre les termes ; les couleurs ne signifient pas la même urgence.
+- **Recommandation :** Créer un module partagé (ex. client/src/lib/dlcStatus.ts) avec libellés, couleurs de badge et seuils (expiré, ≤ 3 j urgent, ≤ 15 j bientôt), et un composant <DlcStatusBadge> utilisé par les 3 écrans.
+
+### DLC-29
+
+**Badge « J-3 » identique pour « expire dans 3 jours » et « expiré depuis 3 jours »** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/DlcPage.tsx:264`
+- **Constat :** l.264 `<Badge variant="destructive">Expiré J{days}</Badge>` avec days négatif → « Expiré J-3 » ; l.265 `J-{days}` avec days = 3 → « J-3 » ; le jour J → « J-0 ».
+- **Impact :** Lecture ambiguë en rayon : « J-3 » signifie habituellement « dans 3 jours » ; un produit expiré peut être lu comme encore bon.
+- **Recommandation :** Libellés explicites : « Expiré depuis 3 j », « Expire aujourd'hui », « Encore 3 j ».
+
+### DLC-30
+
+**Mobile : l'onglet par défaut montre les produits les moins urgents et les onglets n'ont pas de compteur** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/DlcPage.tsx:77`
+- **Constat :** `useState("en_cours")` (l.77) = produits à plus de 15 jours ; TabsTrigger « OK / Bientôt / Expirés / Validés » en text-xs sans nombre (l.292-297).
+- **Impact :** En ouvrant l'écran, l'employé ne voit pas qu'il y a des produits expirés à retirer ; il doit tester chaque onglet.
+- **Recommandation :** Ouvrir par défaut sur « Expirés » s'il y en a, sinon « Bientôt » ; afficher le nombre dans chaque onglet (calculé depuis la liste déjà chargée) avec pastille rouge/orange.
+
+### DLC-31
+
+**Mobile : actions manquantes par rapport au desktop (modifier, supprimer, stock épuisé, traité)** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/mobile/DlcPage.tsx:336`
+- **Constat :** Le menu « … » ne contient qu'une entrée « Valider (Sortir) » (l.336-341) ; aucune mutation stock-epuise, mark-processed, PUT ou DELETE dans le fichier, alors que la page desktop les propose (DlcPage.tsx:255-320).
+- **Impact :** En rayon avec le téléphone, l'employé ne peut ni corriger une date mal saisie, ni marquer un produit épuisé ou vérifié : il doit retourner au PC.
+- **Recommandation :** Ajouter dans le menu les actions contextuelles réutilisant un hook commun (useDlcActions) partagé avec le desktop, et une feuille d'édition réutilisant le formulaire de création.
+
+### DLC-32
+
+**La modale incite à marquer un produit périmé « stock épuisé » pour faire disparaître l'alerte** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/DlcAlertModal.tsx:285`
+- **Constat :** Pour les expirés, seul bouton « Stock épuisé » (l.182-193) ; aide l.285-286 : « Marquez les produits comme "stock épuisé" ... pour faire disparaître l'alerte ». La page DLC définit pourtant ce statut comme « Indique que ce produit n'est plus en stock (différent de périmé) » (DlcPage.tsx:1074). Aucune action pour les produits « Expirent bientôt » (l.224-248).
+- **Impact :** Données faussées (produits périmés enregistrés comme ruptures) et traçabilité du retrait perdue ; l'utilisateur apprend un mauvais réflexe.
+- **Recommandation :** Proposer l'action adaptée : « Retiré du rayon » (validate, si rôle autorisé) pour les expirés et « Vérifié » (mark-processed) pour les bientôt expirés ; réécrire l'aide en conséquence.
+
+### DLC-36
+
+**Recherche EAN : 2 allers-retours séquentiels vers une API externe, sans cache, sans délai max, code dupliqué** — perf-api, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:132`
+- **Constat :** DlcPage.tsx:132 `fetch('/api/ffnancy/articles?ean=...')` puis l.143 `fetch('/api/ffnancy/mouvements/entrees?artNoId=...')` ; même bloc copié dans mobile/DlcPage.tsx:148-201. Proxys routes.ts:6396-6423 : `await fetch('https://api.ffnancy.fr/...')` sans AbortSignal.timeout ni cache. Aucun retour visuel si le code est inconnu (`if (!article) return;`).
+- **Impact :** 1 à plusieurs secondes après le scan avant pré-remplissage ; spinner infini si l'API externe ne répond pas ; l'utilisateur ne sait pas si le code a été reconnu.
+- **Recommandation :** Créer un endpoint serveur unique GET /api/ffnancy/ean-lookup?ean= qui enchaîne les 2 appels, matche le fournisseur en SQL et met en cache 24 h (server/cache.ts), avec timeout 5 s ; côté client un hook useEanLookup partagé basé sur useQuery ; afficher « Produit reconnu : … » ou « Code inconnu, saisissez le nom ».
+
+### DLC-47
+
+**La recherche desktop ne trouve pas un produit par son code EAN (le mobile oui)** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:2049`
+- **Constat :** storage.ts:2049-2055 : la recherche porte uniquement sur `LOWER(product_name)` et `LOWER(suppliers.name)` ; pas de gencode. Le mobile cherche aussi dans `p.gencode.includes(lower)` (mobile/DlcPage.tsx:237). Placeholder desktop « Rechercher un produit... » (DlcPage.tsx:861).
+- **Impact :** Un employé qui scanne ou tape le code-barres dans la recherche obtient « Aucun produit DLC trouvé » alors que le produit existe.
+- **Recommandation :** Ajouter `gencode LIKE search || '%'` (et `name`) à la condition OR ; placeholder « Nom, code-barres ou fournisseur ».
+
+### DLC-24
+
+**Bouton « Exporter PDF » sans action** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:930`
+- **Constat :** l.930-933 `<Button variant="outline" size="sm"><Download className="w-4 h-4 mr-2" />Exporter PDF</Button>` : aucun onClick.
+- **Impact :** L'utilisateur clique, rien ne se passe : perte de confiance dans l'outil.
+- **Recommandation :** Le brancher sur l'impression de la liste filtrée courante (« Imprimer la liste ») ou le retirer.
+
+### DLC-33
+
+**Le lien vers la page DLC recharge toute l'application** — perf-client, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/DlcAlertModal.tsx:142`
+- **Constat :** l.141-143 `const handleViewDlcModule = () => { window.location.href = '/dlc'; };`
+- **Impact :** Rechargement complet du bundle, de l'authentification et de toutes les requêtes (2 à 5 s perdues) au lieu d'une navigation instantanée.
+- **Recommandation :** Utiliser la navigation wouter : `const [, setLocation] = useLocation(); setLocation('/dlc'); onClose();`.
+
+### DLC-34
+
+**Jargon, emojis et formulations maladroites dans la modale** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/DlcAlertModal.tsx:285`
+- **Constat :** l.285 « 💡 Conseil : Ce modal réapparaîtra... » ; toasts « ✅ Produit marqué » / « ❌ Erreur » (l.80, 89) ; titre « Alerte Produits DLC - Action Requise » (l.151) ; le jour J « Expiré depuis {Math.abs(0)} jour(s) » → « Expiré depuis 0 jour(s) » (l.178) ; « et 3 autre(s) produit(s) expiré(s)... » (l.206).
+- **Impact :** Lecture moins fluide ; « modal » et les « (s) » font technique ; « depuis 0 jour » est incohérent.
+- **Recommandation :** « Cette fenêtre reviendra tant que... », supprimer les emojis (cohérence avec les autres toasts), gérer le singulier/pluriel et « Expire aujourd'hui ».
+
+### DLC-35
+
+**console.log de debug dans onSubmit et dans les routes de mutation** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:348`
+- **Constat :** DlcPage.tsx:333-357 : `console.log("🏪 DLC GroupId Selection DEBUG:", { userGroupsRaw: user?.userGroups, availableStores: ... })`. Serveur : 2 console.log par action (routes.ts:3003-3013, 3044-3053, 3089-3098, 3129-3138, 3174-3183).
+- **Impact :** Données utilisateur exposées dans la console du navigateur ; logs serveur bruités à chaque clic.
+- **Recommandation :** Supprimer les logs client ; côté serveur, garder uniquement console.error ou un logger conditionné par NODE_ENV/niveau.
+
+### DLC-37
+
+**Fournisseurs DLC filtrés en JavaScript après lecture de toute la table** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:1150`
+- **Constat :** routes.ts:1150-1154 `const suppliers = await storage.getSuppliers(); ... suppliers.filter(supplier => supplier.hasDlc === true)` ; getSuppliers = `db.select().from(suppliers)` (storage.ts:467-468).
+- **Impact :** Requête et JSON plus lourds que nécessaire à chaque ouverture de la page DLC (faible tant que la table est petite).
+- **Recommandation :** Ajouter une méthode dédiée getDlcSuppliers() (WHERE has_dlc = true, ORDER BY name, colonnes id/name/codefou) dans IStorage, DatabaseStorage et MemStorage (storage.ts:3685), plutôt que de changer la signature de getSuppliers, utilisée ailleurs (routes.ts:519, 619, 2043).
+
+### DLC-38
+
+**Les compteurs DLC sont renvoyés en chaînes (COUNT bigint), comparaison stricte morte dans la modale** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `server/storage.ts:2261`
+- **Constat :** storage.ts:2238 `sql<number>`COUNT(CASE ...)`` ; drizzle node-postgres ne surcharge que DATE/TIMESTAMP/INTERVAL (session.js:24-37) donc INT8 reste une chaîne « 3 » ; `stats.active || 0` renvoie « 0 » (chaîne truthy). DlcAlertModal.tsx:133 `if (dlcStats.expired === 0 && dlcStats.expiringSoon === 0) return null;` n'est jamais vrai.
+- **Impact :** Comparaisons fragiles (=== 0, additions qui concatènent « 2 »+« 3 » = « 23 ») au moindre calcul futur.
+- **Recommandation :** Caster en SQL : `COUNT(...)::int` ou `sql<number>`...`.mapWith(Number)`.
+
+### DLC-39
+
+**Les stats DLC parcourent tout l'historique (validés inclus) et utilisent la date UTC** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:2229`
+- **Constat :** storage.ts:2229-2232 `let whereCondition = sql`1 = 1``, seul filtre éventuel group_id ; les exclusions (status != 'valides', stockEpuise, processed) sont dans les CASE. Date calculée par `today.toISOString().split('T')[0]` (l.2239) = date UTC (entre 0 h et 2 h en France, « aujourd'hui » vaut la veille), alors que getDlcProducts utilise `today.setHours(0,0,0,0)` heure serveur (l.1996-1997).
+- **Impact :** Coût croissant avec l'historique sur une requête appelée à chaque Dashboard ; décalage d'un jour la nuit entre compteurs et liste.
+- **Recommandation :** Partie automatisable : déplacer `status <> 'valides' AND stock_epuise IS NOT TRUE` dans le WHERE. Pour processed_until_expiry, attendre DLC-01 : les expirés traités doivent être comptés. Pour le fuseau horaire : utiliser `(now() AT TIME ZONE 'Europe/Paris')::date` dans les deux requêtes, ou définir TZ=Europe/Paris. Index partiel via une migration dédiée (non automatique).
+
+### DLC-40
+
+**Index dlc_products absents de shared/schema.ts (risque de suppression par drizzle-kit push)** — dette-code, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `shared/schema.ts:278`
+- **Constat :** dlcProducts = pgTable("dlc_products", {...}) (schema.ts:278-304) sans 3e argument d'index, alors que les index existent seulement en SQL : migrations/20260814_add_performance_indexes.sql:56-59 (group_id, supplier_id, expiry_date, (group_id, status)). package.json : "db:push": "drizzle-kit push" avec schema: "./shared/schema.ts".
+- **Impact :** Un `npm run db:push` peut proposer de supprimer ces index et dégrader toutes les requêtes DLC ; aucun index composite (group_id, expiry_date) pour la requête principale.
+- **Recommandation :** Déclarer dans schema.ts exactement les index existants, avec les mêmes noms (idx_dlc_products_group_id, idx_dlc_products_supplier_id, idx_dlc_products_expiry_date, idx_dlc_products_group_status), et traiter les 47 index de la migration en une seule passe. Ajouter un nouvel index composite seulement via une migration explicite.
+
+### DLC-41
+
+**Boutons icônes sans libellé accessible (Modifier, Supprimer, Imprimer, menu …, bouton +)** — accessibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:983`
+- **Constat :** DlcPage.tsx:983-989 `<Button variant="outline" size="sm" onClick={() => handleEdit(product)}><Edit className="w-4 h-4" /></Button>` ; l.1105-1112 Trash2 ; l.887-894 et l.907-914 FileText ; mobile/DlcPage.tsx:332 MoreVertical et l.487-492 bouton flottant Plus : aucun aria-label ni title.
+- **Impact :** Pas d'infobulle au survol pour Modifier/Supprimer/Imprimer ; lecteurs d'écran annoncent « bouton » sans nom.
+- **Recommandation :** Ajouter aria-label + title (« Modifier », « Supprimer », « Imprimer les produits expirés », « Plus d'actions », « Ajouter un produit »).
+
+### DLC-42
+
+**Lignes grisées par opacité 50-60 % : texte et boutons peu lisibles** — accessibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:962`
+- **Constat :** l.961-965 `product.status === "valides" ? "opacity-60 bg-gray-50" : product.processedUntilExpiry ? "opacity-60 bg-blue-50" : product.stockEpuise ? "opacity-50 bg-yellow-50" : ""` appliqué à toute la ligne, boutons d'action compris.
+- **Impact :** Contraste insuffisant (texte gris à 50 %) pour lire nom et date ; boutons Restaurer/Annuler paraissent désactivés.
+- **Recommandation :** Remplacer l'opacité par une couleur de texte atténuée (text-gray-500) sur les cellules d'information uniquement, et garder les boutons à pleine opacité.
+
+### DLC-43
+
+**Tableau DLC non défilable et sans colonne Magasin sur tablette / vue multi-magasins** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/ui/table.tsx:9`
+- **Constat :** table.tsx:9 `<div className="relative w-full">` (pas d'overflow-x-auto) ; use-screen-size.ts:26-28 : 768-1024 px = « tablet » → layout desktop ; tableau DlcPage.tsx:945-956 avec 7 colonnes + jusqu'à 5 boutons. Aucune colonne Magasin alors que l'admin en « Tous les magasins » voit les produits de tous les magasins.
+- **Impact :** Sur tablette, la colonne Actions déborde hors écran ; l'admin ne sait pas à quel magasin appartient un produit.
+- **Recommandation :** Envelopper le tableau dans overflow-x-auto ; afficher l'EAN sous le nom (supprimer une colonne) ; ajouter une colonne Magasin (pastille couleur) quand aucun magasin n'est sélectionné.
+
+### DLC-44
+
+**Message de validation « Required » en anglais si aucun fournisseur choisi** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:33`
+- **Constat :** l.33 `supplierId: z.number().min(1, "Le fournisseur est obligatoire")` sans required_error/invalid_type_error : quand le Select n'est pas renseigné la valeur est undefined et zod renvoie son message par défaut « Required ».
+- **Impact :** Message anglais incompréhensible pour l'utilisateur final.
+- **Recommandation :** `z.number({ required_error: "Choisissez un fournisseur", invalid_type_error: "Choisissez un fournisseur" }).min(1, ...)` ; faire de même pour dlcDate (`z.string({ required_error: "La date d'expiration est obligatoire" })`) ou ajouter dlcDate: "" aux defaultValues.
+
+### DLC-45
+
+**Code dupliqué : 7 mutations copiées-collées, 2 fonctions d'impression identiques, TooltipProvider par bouton, imports morts** — dette-code, sévérité basse, effort M
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:178`
+- **Constat :** Mutations quasi identiques l.179-320 (seuls URL et texte changent) ; printExpiringSoon/printExpired l.499-615 ; un <TooltipProvider> par bouton et par ligne (l.1006, 1032, 1058, 1083) ; imports inutilisés AlertTriangle, Eye, Tabs/TabsContent/TabsList/TabsTrigger, AlertDialogTrigger (l.9-16). Fichier de 1156 lignes.
+- **Impact :** Maintenance difficile (les corrections doivent être répétées 7 fois, d'où les incohérences) ; rendu un peu plus lourd.
+- **Recommandation :** Partie automatisable : supprimer les imports morts, retirer les TooltipProvider locaux (le global d'App.tsx suffit), factoriser printList (avec l'échappement de DLC-26) et un hook useDlcAction. Le découpage en DlcFormDialog, DlcStatsCards et DlcTable est un refactor plus large, qui entre en conflit avec DLC-03, DLC-04, DLC-16 et DLC-19 : à faire après eux.
+
+### DLC-46
+
+**Pages DLC desktop et mobile importées statiquement dans le bundle principal** — perf-bundle, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:21`
+- **Constat :** RouterProduction.tsx:21 `import DlcPage from "@/pages/DlcPage";` et l.42 `import MobileDlcPage from "@/pages/mobile/DlcPage";` — aucun React.lazy ; un appareil n'utilise qu'une des deux versions.
+- **Impact :** Code DLC (≈1 650 lignes + react-hook-form/zod) téléchargé au premier chargement même par les utilisateurs qui n'ouvrent jamais la page.
+- **Recommandation :** Passer au chargement différé page par page pour tout le routeur, avec un Suspense commun et un ErrorBoundary qui recharge la page en cas d'erreur de chargement de chunk (ou vite:preloadError → location.reload()).
+
+### DLC-48
+
+**Recherche mobile plantée si un produit n'a pas de productName (colonne nullable)** — bug, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/mobile/DlcPage.tsx:236`
+- **Constat :** mobile/DlcPage.tsx:236 `p.productName.toLowerCase().includes(lower)` alors que shared/schema.ts:281 `productName: varchar("product_name")` est nullable (seul `name` est NOT NULL).
+- **Impact :** Une seule ligne ancienne sans product_name fait planter la page mobile dès la première lettre tapée.
+- **Recommandation :** `(p.productName ?? p.name ?? '').toLowerCase()` ; à terme fusionner name/productName en une seule colonne.
+
+### DLC-49
+
+**Mobile : date d'expiration pré-remplie à aujourd'hui** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/mobile/DlcPage.tsx:135`
+- **Constat :** defaultValues `dlcDate: format(new Date(), 'yyyy-MM-dd')` (l.135) ; le desktop laisse le champ vide et le rend obligatoire (DlcPage.tsx:31).
+- **Impact :** Si l'employé oublie de changer la date, le produit est créé comme expirant aujourd'hui : fausse alerte immédiate et données erronées.
+- **Recommandation :** Laisser le champ vide (obligatoire) ou proposer des raccourcis explicites (+3 j, +7 j, +15 j).
+
+### DLC-50
+
+**Choix DLC / DDM / DLUO : DLUO est un terme obsolète qui ajoute de la confusion** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/DlcPage.tsx:777`
+- **Constat :** Options l.777-779 « DLC (Date Limite de Consommation) », « DDM (Date de Durabilité Minimale) », « DLUO (Date Limite d'Utilisation Optimale) » ; badge du tableau en sigle seul `uppercase` (l.972-974). DLUO a été remplacée par DDM en 2014 (règlement INCO).
+- **Impact :** L'employé hésite entre DDM et DLUO (même notion) ; le sigle seul dans le tableau n'est pas explicite.
+- **Recommandation :** Ne proposer que « À consommer jusqu'au (DLC) » et « À consommer de préférence avant (DDM) » en création, garder l'affichage DLUO pour l'existant ; infobulle sur le badge.
+
+### DLC-51
+
+**Retour à la page 1 après chaque action qui retire une ligne de la vue filtrée** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/ui/pagination.tsx:157`
+- **Constat :** pagination.tsx:156-159 `useEffect(() => { setCurrentPage(1); }, [data.length]);` ; sur DlcPage, « Marquer traité » en filtre « Expire bientôt » retire la ligne (filtre serveur storage.ts:2010-2013) → longueur change → page 1.
+- **Impact :** En traitant une liste sur plusieurs pages, l'utilisateur est renvoyé en haut à chaque clic et perd sa position.
+- **Recommandation :** Remettre la page à 1 seulement quand les filtres changent (passer une clé de filtres au hook) et sinon borner currentPage à totalPages.

docs/audit-webui/09-publicities.md

@@ -0,0 +1,401 @@
+# Publicités
+
+_35 constats vérifiés — 3 haute, 19 moyenne, 13 basse._
+
+## Pages analysées
+
+### `/publicities (desktop, >= 768 px, tablette incluse)`
+
+**Rôle :** Consulter le planning annuel des campagnes publicitaires (catalogues/promos) et savoir quels magasins y participent. L'admin les crée, les modifie et les supprime.
+
+**Tâches principales de l'utilisateur :**
+- Voir les publicités en cours et à venir de l'année pour son magasin
+- Visualiser la couverture semaine par semaine (Vue d'ensemble) ou jour par jour (vue calendrier)
+- Ouvrir le détail d'une publicité (dates, magasins participants, créateur)
+- Exporter la liste de l'année en CSV
+- Admin : créer ou modifier une publicité et cocher les magasins participants (PublicityForm en modale)
+- Admin : supprimer une publicité après confirmation
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/ad-campaigns?year=YYYY&storeId=N | au montage, puis à chaque changement d'année ou de magasin (clé ['/api/ad-campaigns', selectedYear, selectedStoreId], fetch() manuel, staleTime par défaut 30 s, sans placeholderData ni enabled) | server/routes.ts:4595 → storage.getUserWithGroups (routes.ts:4597, 2 requêtes, en double avec deserializeUser localAuth.ts:141) → storage.getPublicities (storage.ts:1502 : SELECT publicities WHERE year, puis SELECT participations LEFT JOIN groups) | groupIds calculé par la route mais ignoré par getPublicities, donc pas de filtre magasin ni de cloisonnement par rôle. Ligne groups complète (logo base64, config SMTP/NocoDB) jointe à chaque participation. Créateur jamais joint. Triple tri (SQL, JS serveur, JS client). 2 console.log à chaque appel. Au total 6 requêtes SQL, dont 4 séquentielles avant les données. En cas d'erreur, réponse 500 avec []. |
+| GET /api/groups | au montage si user (même clé que Layout.tsx:48, donc cache partagé, pas de double appel réseau) | server/routes.ts:970 → storage.getUserWithGroups + storage.getGroups (storage.ts:432, SELECT * FROM groups) pour l'admin, sinon userGroups (id/name/color) | La page n'utilise que id, name et color. Pour l'admin, toutes les colonnes partent (logo en data URI, SMTP, webhook). Doublon de useStore().stores. |
+| POST /api/ad-campaigns | au clic sur Créer dans PublicityForm (fetch manuel) | server/routes.ts:4629 → getUserWithGroups → insertPublicitySchema.parse → storage.createPublicity (storage.ts:1586) → storage.setPublicityParticipations (storage.ts:1630 : DELETE puis INSERT) → storage.getPublicity (storage.ts:1562) | 5 à 6 requêtes séquentielles hors transaction. Un N° en double renvoie un 500 générique en anglais. La réponse complète est ignorée par le client, qui invalide toute la liste et la recharge. |
+| PUT /api/ad-campaigns/:id | au clic sur Modifier dans PublicityForm | server/routes.ts:4665 → storage.updatePublicity (storage.ts:1591, req.body brut sans validation) → setPublicityParticipations → getPublicity | Pas de validation Zod, pas de transaction, pas de 404 si l'id n'existe pas. Invalidation large côté client. |
+| POST /api/ad-campaigns/:id/delete (repli DELETE /api/ad-campaigns/:id sur 404) | au clic sur Supprimer dans la modale de confirmation | server/routes.ts:4737 (copie de routes.ts:4697) → storage.deletePublicity (storage.ts:1600 : DELETE participations RETURNING puis DELETE publicities RETURNING) | Deux handlers copiés-collés avec environ 8 console.log chacun. La suppression manuelle des participations est redondante avec le ON DELETE CASCADE. Le repli DELETE côté client est du code mort. |
+
+**Lisibilité / simplicité :** Page dense et peu hiérarchisée. L'en-tête aligne 7 contrôles sur une ligne sans retour à la ligne : bascule Liste/Grille en icônes sans libellé, bouton 'Vue d'ensemble', icône filtre, année, mois, 'Exporter CSV', 'Nouvelle publicité'. Viennent ensuite 3 cartes stats (même icône), puis une grille annuelle de 12 colonnes affichée par défaut avant la liste, qui se retrouve sous la ligne de flottaison. La liste desktop n'a ni recherche ni filtre par statut ou magasin, alors que la version mobile a une recherche. La colonne 'Créé par' affiche toujours 'Utilisateur'. Le sélecteur de magasin n'a aucun effet (bug serveur). Des statuts et la vue calendrier sont faux d'un jour (fuseau horaire), et les numéros de semaine ne sont pas ISO certaines années. Pendant le chargement, les stats affichent 0 et toutes les semaines apparaissent 'sans publicité'. Il n'y a pas d'état d'erreur : une erreur s'affiche comme 'Aucune publicité… Commencez par créer…', y compris pour les non-admins. Les messages d'erreur serveur sont en anglais. Le tableau n'est pas scrollable en tablette (colonne Actions coupée). La modale de création n'a pas de hauteur max. Des console.log s'exécutent à chaque rendu en production. La vue calendrier fait doublon avec la page /calendar.
+
+### `/publicities (mobile, < 768 px)`
+
+**Rôle :** Consulter rapidement sur téléphone les publicités de l'année pour le magasin sélectionné.
+
+**Tâches principales de l'utilisateur :**
+- Voir la liste des publicités de l'année pour son magasin
+- Rechercher par N° ou désignation
+- Lire le statut (En cours / À venir / Terminée) et les dates
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/ad-campaigns?storeId=N&year=YYYY | au montage et au changement d'année ou de magasin, seulement si selectedStoreId (clé ['/api/ad-campaigns', selectedStoreId, selectedYear], ordre inverse de la version desktop) | server/routes.ts:4595 → storage.getUserWithGroups → storage.getPublicities (storage.ts:1502) | storeId est ignoré par le serveur (groupIds non appliqué), donc la liste contient aussi les pubs où le magasin ne participe pas. Le payload contient le logo base64 de chaque magasin participant. Pas d'appel quand aucun magasin n'est sélectionné, ce qui donne une liste vide trompeuse. |
+
+**Lisibilité / simplicité :** Liste de cartes simple et lisible, avec recherche et année. En revanche : le bouton flottant '+' est visible pour tous les rôles et ne fait rien (TODO). La liste est vide avec 'Aucune publicité trouvée' quand aucun magasin n'est sélectionné (admin 'Tous les magasins'). Pas de détail ni de magasins participants. 'Créé par' affiche l'identifiant technique (admin_local, manual_...). Le statut passe à 'Terminée' pendant tout le dernier jour. Badges et couleurs différents du desktop (vert plein contre vert pâle, icône violette contre verte). Pas d'état d'erreur. Le même message s'affiche pour une liste vide et une recherche sans résultat. Les pubs en cours ne sont pas mises en avant (tri par N°).
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [PUB-01](#pub-01) | haute | bug | S | getPublicities ignore groupIds : filtre magasin et cloisonnement par rôle inopérants | `server/storage.ts:1502` |
+| [PUB-02](#pub-02) | haute | perf-api | S | Ligne groups complète (logo base64, config SMTP/NocoDB) jointe à chaque participation | `server/storage.ts:1536` |
+| [PUB-11](#pub-11) | haute | ux-simplicite | S | Bouton flottant « + » sans action, visible par tous les rôles | `client/src/pages/mobile/PublicitiesPage.tsx:162` |
+| [PUB-03](#pub-03) | moyenne | bug | S | Créateur jamais joint : « Créé par » affiche « Utilisateur » ou un identifiant technique | `server/storage.ts:1503` |
+| [PUB-04](#pub-04) | moyenne | perf-serveur | S | Utilisateur rechargé en base dans chaque handler alors que deserializeUser l'a déjà chargé | `server/routes.ts:4597` |
+| [PUB-06](#pub-06) | moyenne | dette-code | S | Route /api/ad-campaigns/debug exposée et routes de suppression dupliquées | `server/routes.ts:4529` |
+| [PUB-07](#pub-07) | moyenne | perf-client | S | Deux console.log identiques à chaque rendu, plus des logs dans queryFn et la mutation | `client/src/pages/Publicities.tsx:75` |
+| [PUB-08](#pub-08) | moyenne | perf-client | M | Vue annuelle, calendrier et stats recalculés à chaque rendu sans useMemo | `client/src/pages/Publicities.tsx:229` |
+| [PUB-09](#pub-09) | moyenne | bug | S | Fuseau horaire : 1er jour absent du calendrier, « Terminée » le dernier jour | `client/src/pages/Publicities.tsx:624` |
+| [PUB-10](#pub-10) | moyenne | bug | S | Numéros de semaine non ISO (décalés d'une semaine certaines années) | `client/src/pages/Publicities.tsx:206` |
+| [PUB-12](#pub-12) | moyenne | ux-simplicite | S | Liste vide trompeuse quand aucun magasin n'est sélectionné | `client/src/pages/mobile/PublicitiesPage.tsx:45` |
+| [PUB-13](#pub-13) | moyenne | ux-simplicite | S | Aucun état d'erreur : une panne s'affiche comme « aucune publicité » | `client/src/pages/Publicities.tsx:572` |
+| [PUB-14](#pub-14) | moyenne | perf-client | S | Requête sans keepPreviousData, staleTime ni enabled : flash à 0, double appel au montage | `client/src/pages/Publicities.tsx:42` |
+| [PUB-17](#pub-17) | moyenne | bug | M | PUT sans validation, écritures non transactionnelles (création, participations, suppression) | `server/routes.ts:4681` |
+| [PUB-18](#pub-18) | moyenne | ux-simplicite | S | Messages d'erreur génériques en anglais, N° en double non expliqué | `server/routes.ts:4661` |
+| [PUB-19](#pub-19) | moyenne | ux-simplicite | M | Champ Année manuel, bornes incohérentes, filtrage par année saisie plutôt que par dates | `client/src/components/PublicityForm.tsx:27` |
+| [PUB-20](#pub-20) | moyenne | ux-simplicite | S | Formulaire : erreurs qui persistent, alerte rouge sur un champ optionnel, watch global | `client/src/components/PublicityForm.tsx:215` |
+| [PUB-21](#pub-21) | moyenne | lisibilite | M | En-tête surchargé : 7 contrôles sur une ligne, non responsive | `client/src/pages/Publicities.tsx:321` |
+| [PUB-22](#pub-22) | moyenne | ux-simplicite | S | Tableau 7 colonnes non scrollable : colonne Actions coupée en tablette | `client/src/pages/Publicities.tsx:720` |
+| [PUB-23](#pub-23) | moyenne | ux-simplicite | M | Liste desktop sans recherche ni filtre de statut, libellés abrégés, lignes non cliquables | `client/src/pages/Publicities.tsx:748` |
+| [PUB-24](#pub-24) | moyenne | lisibilite | M | Vue d'ensemble affichée par défaut, info uniquement au survol, légende sans noms | `client/src/pages/Publicities.tsx:466` |
+| [PUB-30](#pub-30) | moyenne | perf-api | S | « Publicités à venir » : 3 appels séquentiels d'années complètes faute de filtre API | `client/src/pages/Dashboard.tsx:197` |
+| [PUB-05](#pub-05) | basse | perf-serveur | S | console.log dans le chemin chaud de lecture et logs verbeux sur la suppression | `server/storage.ts:1525` |
+| [PUB-15](#pub-15) | basse | perf-client | S | Triple tri (SQL, serveur JS, client JS) incompatible avec le format de N° suggéré | `client/src/pages/Publicities.tsx:57` |
+| [PUB-16](#pub-16) | basse | perf-serveur | S | Association participations ↔ publicités en O(N×M) et 2 requêtes séquentielles | `server/storage.ts:1550` |
+| [PUB-25](#pub-25) | basse | lisibilite | S | Vue calendrier : seul le N° est affiché, pas de navigation mois par mois, doublon avec /calendar | `client/src/pages/Publicities.tsx:651` |
+| [PUB-26](#pub-26) | basse | coherence-design | S | Icônes, badges de statut, CTA et confirmation incohérents | `client/src/pages/Publicities.tsx:775` |
+| [PUB-27](#pub-27) | basse | accessibilite | S | Boutons Liste/Grille sans nom accessible ni infobulle | `client/src/pages/Publicities.tsx:324` |
+| [PUB-28](#pub-28) | basse | dette-code | S | Code mort et requête groups redondante avec StoreContext | `client/src/pages/Publicities.tsx:303` |
+| [PUB-29](#pub-29) | basse | perf-api | S | Invalidation par préfixe après mutation : la réponse serveur complète est ignorée | `client/src/components/PublicityForm.tsx:84` |
+| [PUB-31](#pub-31) | basse | ux-simplicite | S | Modale création/édition sans hauteur max : boutons hors écran avec beaucoup de magasins | `client/src/pages/Publicities.tsx:857` |
+| [PUB-32](#pub-32) | basse | perf-bundle | M | Pages Publicités et formulaire importés statiquement dans le bundle initial | `client/src/components/RouterProduction.tsx:15` |
+| [PUB-33](#pub-33) | basse | ux-simplicite | M | Mobile : pas de détail, pas de magasins participants, pas de priorisation des pubs en cours | `client/src/pages/mobile/PublicitiesPage.tsx:119` |
+| [PUB-34](#pub-34) | basse | dette-code | M | Trois queryFn différents et clés incohérentes pour le même endpoint | `client/src/pages/mobile/PublicitiesPage.tsx:43` |
+| [PUB-35](#pub-35) | basse | perf-serveur | S | Index publicities/participations hors de shared/schema.ts, index group_id non garanti | `shared/schema.ts:166` |
+
+### PUB-01
+
+**getPublicities ignore groupIds : filtre magasin et cloisonnement par rôle inopérants** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:1502`
+- **Constat :** storage.ts:1502 `async getPublicities(year?: number, groupIds?: number[])`. Le seul filtre appliqué est l.1517-1519 `if (year) { query = query.where(eq(publicities.year, year)); }` et `groupIds` n'est jamais lu. Pourtant routes.ts:4605-4615 calcule `groupIds = userGroupIds` pour les non-admins et `[parseInt(storeId)]` pour l'admin. CalendarGrid.tsx:428-442 refiltre côté client pour compenser, Publicities.tsx et PublicitiesPage.tsx ne le font pas.
+- **Impact :** Employés et managers voient les publicités de tous les magasins. Le sélecteur de magasin ne change ni la liste, ni les stats Total/En cours/À venir, ni l'export CSV. Sur mobile, filtré par magasin, on voit des pubs où le magasin ne participe pas. Le payload est plus gros que nécessaire.
+- **Recommandation :** Quand groupIds est défini, filtrer en SQL : `and(eq(publicities.year, year), inArray(publicities.id, db.select({ id: publicityParticipations.publicityId }).from(publicityParticipations).where(inArray(publicityParticipations.groupId, groupIds))))`. Il faut garantir l'index group_id (voir PUB-35). Décision produit à prendre : l'admin en « Tous les magasins » continue-t-il de voir les pubs sans magasin ? (comportement actuel)
+
+### PUB-02
+
+**Ligne groups complète (logo base64, config SMTP/NocoDB) jointe à chaque participation** — perf-api, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:1536`
+- **Constat :** storage.ts:1533-1541 `.select({ publicityId: ..., groupId: ..., group: groups })`, idem dans getPublicity l.1570. La table groups (shared/schema.ts:48-79) contient `logo: text("logo") // Logo en data URI (data:image/png;base64,...)`, plus smtpHost, smtpUser, webhookUrl, nocodbTableName, address, phone… Les clients n'utilisent que group.name et group.color (Publicities.tsx:791-793, 939-941 ; CalendarGrid.tsx:659 ; Dashboard.tsx:618-629). Pour l'admin, /api/groups fait aussi `db.select().from(groups)` (storage.ts:432), utilisé ici seulement pour la couleur et le nom.
+- **Impact :** Le logo est dupliqué pour chaque participation de chaque publicité. Avec 100 pubs × 5 magasins × un logo de 50 Ko, la réponse JSON atteint environ 25 Mo, ce qui ralentit fortement le chargement, surtout en 4G. stripSmtpPassword (sanitize.ts, branché routes.ts:168-174) parcourt récursivement tout ce payload. La configuration SMTP, webhook et NocoDB est en plus exposée aux employés.
+- **Recommandation :** Limiter la correction à getPublicities et getPublicity : remplacer `group: groups` par `group: { id: groups.id, name: groups.name, color: groups.color }`. Ne pas modifier /api/groups ni getGroups() dans ce lot, car d'autres écrans consomment webhookUrl, logo et smtp*.
+
+### PUB-11
+
+**Bouton flottant « + » sans action, visible par tous les rôles** — ux-simplicite, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/mobile/PublicitiesPage.tsx:162`
+- **Constat :** l.162-170 : `<Button className="fixed bottom-20 right-4 h-14 w-14 rounded-full ..." onClick={() => { // TODO: Ouvrir modal création mobile }}>`, sans condition de rôle. Or shared/permissions.ts:61-66 : `manager: ['view'], employee: ['view']`, seul l'admin peut créer.
+- **Impact :** Le bouton le plus visible de l'écran ne fait rien. L'utilisateur croit à une panne et perd confiance dans l'application.
+- **Recommandation :** Masquer le bouton tant que la création mobile n'existe pas. À terme, le réserver à `user?.role === 'admin'` et ouvrir PublicityForm dans un Sheet plein écran.
+
+### PUB-03
+
+**Créateur jamais joint : « Créé par » affiche « Utilisateur » ou un identifiant technique** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:1503`
+- **Constat :** Le select de storage.ts:1503-1514 contient `createdBy` mais pas de jointure users, alors que le type PublicityWithRelations (shared/schema.ts:814-817) promet `creator: User`. Publicities.tsx:807 `{publicity.creator?.name || publicity.creator?.username || 'Utilisateur'}` affiche donc toujours « Utilisateur ». PublicitiesPage.tsx:151 `Créé par {pub.creator?.username || pub.createdBy}` affiche l'id brut (`admin_local`, `manual_1723…_x` d'après routes.ts:4342).
+- **Impact :** Une colonne entière du tableau desktop est inutile, et le mobile affiche du jargon technique aux employés.
+- **Recommandation :** Ajouter `.leftJoin(users, eq(publicities.createdBy, users.id))` en sélectionnant `creator: { id: users.id, name: users.name, firstName: users.firstName, lastName: users.lastName, username: users.username }` (jamais password). Sinon, retirer la colonne « Créé par » du tableau et ne la garder que dans le détail.
+
+### PUB-04
+
+**Utilisateur rechargé en base dans chaque handler alors que deserializeUser l'a déjà chargé** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:4597`
+- **Constat :** localAuth.ts:141-143 (et localAuth.production.ts:193-195) : `passport.deserializeUser(async (id) => { const user = await storage.getUserWithGroups(id); done(null, user); })`, donc req.user est déjà un UserWithGroups. Chaque handler ad-campaigns refait pourtant `await storage.getUserWithGroups(req.user.claims ? ... : req.user.id)` (routes.ts:4531, 4565, 4597, 4631, 4667, 4709, 4748 ; 106 occurrences dans routes.ts). getUserWithGroups enchaîne 2 requêtes (storage.ts:371-386 : getUser puis jointure user_groups).
+- **Impact :** Chaque chargement de la liste coûte 2 allers-retours SQL séquentiels de plus : 6 requêtes au total, dont 4 avant d'atteindre les publicités. Cette latence s'ajoute à chaque appel et à chaque mutation.
+- **Recommandation :** Limiter l'auto-implémentation aux handlers /api/ad-campaigns avec `const user = req.user as UserWithGroups` (en gardant `if (!user) return 404`). La fusion de getUser et user_groups en une seule requête est un chantier transverse, à traiter séparément.
+
+### PUB-06
+
+**Route /api/ad-campaigns/debug exposée et routes de suppression dupliquées** — dette-code, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:4529`
+- **Constat :** routes.ts:4529 `app.get('/api/ad-campaigns/debug', isAuthenticated, ...)` est accessible à tout utilisateur connecté. Elle duplique le GET principal avec 3 console.log et renvoie `error: (error as Error).message` (l.4559). Aucun appel client (grep). routes.ts:4697-4735 (DELETE) et 4737-4774 (POST /:id/delete) sont deux copies quasi identiques. Côté client, Publicities.tsx:101-125 tente POST puis, sur 404, `fetch(`/api/ad-campaigns/${id}`, { method: 'DELETE' })` : ce repli ne s'exécute jamais puisque la route POST existe.
+- **Impact :** Surface d'API inutile qui divulgue des messages d'erreur internes, et code dupliqué à maintenir deux fois.
+- **Recommandation :** Serveur : supprimer GET /api/ad-campaigns/debug. Extraire un seul handler `deletePublicityHandler` monté sur `app.delete('/api/ad-campaigns/:id')` et `app.post('/api/ad-campaigns/:id/delete')`, et retirer `error: (error as Error).message` des réponses 500. Client : garder `fetch(`/api/ad-campaigns/${id}/delete`, { method: 'POST' })` avec la lecture du JSON d'erreur (`error.message`), en supprimant seulement le repli DELETE sur 404 et les console.log. Ne pas passer par apiRequest tant qu'il ne parse pas le message JSON.
+
+### PUB-07
+
+**Deux console.log identiques à chaque rendu, plus des logs dans queryFn et la mutation** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Publicities.tsx:75`
+- **Constat :** Publicities.tsx:75-81 et 83-89 : deux blocs `console.log('📢 Publicities Debug:', { isLoading, publicitiesCount, selectedYear, selectedStoreId, publicities: publicities?.slice(0, 2) })` dans le corps du composant, sans garde DEV. Logs supplémentaires l.55, 66-69 (queryFn) et l.99, 109, 113, 131 (suppression). Calendar.tsx:146 les garde derrière `import.meta.env.DEV`.
+- **Impact :** Deux logs avec sérialisation d'objets à chaque rendu (ouverture de modale, bascule de vue, survol…) en production. La console est polluée pour le support.
+- **Recommandation :** Supprimer les logs des l.75-89 et ceux de queryFn et mutationFn, ou les entourer de `if (import.meta.env.DEV)`.
+
+### PUB-08
+
+**Vue annuelle, calendrier et stats recalculés à chaque rendu sans useMemo** — perf-client, sévérité moyenne, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Publicities.tsx:229`
+- **Constat :** l.229 `const yearWeeks = getYearWeeks();` s'exécute à chaque rendu, même quand showYearOverview vaut false. getWeekParticipation (l.156-192) filtre toutes les publicités avec 2 `safeDate()` (new Date) par pub pour chacune des 53 semaines, plus `groups.find` par magasin (l.188). l.480 `yearWeeks.filter(week => week.month === monthIndex)` est appelé 12 fois. La vue calendrier (l.622-628) fait 42 jours × N × 2 parses. Les stats (l.433-457) recalculent des filter avec new Date.
+- **Impact :** Pour N=100, environ 19 000 créations de Date par rendu, refaites à chaque ouverture ou fermeture de modale ou bascule de vue. Les interactions deviennent lentes sur les PC de magasin peu puissants.
+- **Recommandation :** Se limiter à de la mémoïsation pure, sans changer la logique de comparaison. `groupsById = useMemo(() => new Map(groups.map(g => [g.id, g])), [groups])`. `yearWeeks = useMemo(() => showYearOverview ? getYearWeeks() : [], [publicities, groupsById, selectedYear, showYearOverview])`. `weeksByMonth` pré-groupé en useMemo. Ne pas mémoïser les stats qui dépendent de `new Date()` (ou y inclure la date du jour dans les deps). Traiter la comparaison par chaînes dans PUB-09.
+
+### PUB-09
+
+**Fuseau horaire : 1er jour absent du calendrier, « Terminée » le dernier jour** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Publicities.tsx:624`
+- **Constat :** L'API renvoie des dates 'YYYY-MM-DD'. `safeDate('2026-03-10')` vaut `new Date('2026-03-10')`, soit minuit UTC, donc 01:00 ou 02:00 heure de Paris. Calendrier l.627 : `day >= pubStart && day <= pubEnd` avec `day` à minuit local, donc le premier jour de la campagne n'est jamais affiché. Statut l.750-755 `now >= start && now <= end` et stats l.433-438 : le dernier jour passe « Terminée » dès 01:00 ou 02:00. Mobile l.61-69 : `parseISO(endDate)` vaut minuit local, donc `isWithinInterval(now, { start, end })` est faux toute la journée du dernier jour. À l'inverse, CalendarGrid.tsx:381 et 411 compare correctement des chaînes : `dateStr < pubStart || dateStr > pubEnd`.
+- **Impact :** Les employés voient une promo « Terminée » le jour même où elle est encore en rayon, et le calendrier omet son jour de lancement. Les compteurs « En cours » sont faux.
+- **Recommandation :** Créer un helper partagé `getPublicityStatus(pub, today = format(new Date(), 'yyyy-MM-dd'))` qui compare des chaînes 'yyyy-MM-dd' (ou utilise `endOfDay(parseISO(end))`). L'utiliser pour les badges desktop et mobile, les stats, l'export CSV (l.273-275) et la vue calendrier (`format(day,'yyyy-MM-dd')` comparé aux chaînes).
+
+### PUB-10
+
+**Numéros de semaine non ISO (décalés d'une semaine certaines années)** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Publicities.tsx:206`
+- **Constat :** l.199-206 : `eachWeekOfInterval({ start: yearStart, end: yearEnd }, { weekStartsOn: 1 })` puis `const weekNumber = index + 1;`. La première semaine retournée est celle qui contient le 1er janvier. En 2027 (1er janvier un vendredi) et en 2028 (un samedi), la semaine du 28/12 est libellée « 1 » alors qu'en ISO c'est la S53 ou S52 de l'année précédente, et toute l'année est décalée de +1. `getWeek` est importé (l.12) mais jamais utilisé.
+- **Impact :** En grande distribution, les plans promo sont exprimés en semaines ISO. La vue d'ensemble affiche une mauvaise semaine, d'où des erreurs de mise en rayon.
+- **Recommandation :** Remplacer par `const weekNumber = getISOWeek(weekStart)` (date-fns) et ajuster le libellé du title (« S{n} »).
+
+### PUB-12
+
+**Liste vide trompeuse quand aucun magasin n'est sélectionné** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/PublicitiesPage.tsx:45`
+- **Constat :** l.45 `if (!selectedStoreId) return [];` et l.53 `enabled: !!selectedStoreId && !!user`. MobileLayout.tsx:146-158 propose « Tous les magasins » (null) à l'admin, et MobileApp.tsx:37 n'auto-sélectionne un magasin que pour les directeurs et managers mono-magasin. Le message affiché est alors « Aucune publicité trouvée pour {selectedYear} » (l.122).
+- **Impact :** L'admin, ou un employé sans magasin sélectionné, conclut qu'il n'y a aucune publicité alors que l'API sait répondre sans storeId (routes.ts:4605-4615).
+- **Recommandation :** Appeler l'API sans storeId quand selectedStoreId est null (supprimer le `return []` et la condition enabled sur le magasin). Sinon, afficher un état explicite « Choisissez un magasin dans le menu ☰ » avec un bouton qui ouvre le menu.
+
+### PUB-13
+
+**Aucun état d'erreur : une panne s'affiche comme « aucune publicité »** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Publicities.tsx:572`
+- **Constat :** l.42 `const { data: publicities = [], isLoading } = useQuery(...)` : isError n'est pas lu. Le serveur répond `res.status(500).json([])` (routes.ts:4625) et queryFn lance `throw new Error('Failed to fetch publicities')` (l.52). Après 2 tentatives, l'état vide l.576-593 s'affiche : « Aucune publicité pour 2026 / Commencez par créer votre première campagne publicitaire. » Même chose sur mobile (l.42 et l.119-123).
+- **Impact :** En cas de panne réseau ou serveur, l'utilisateur pense que le planning est vide. Un admin peut même recréer des publicités existantes.
+- **Recommandation :** Lire `isError` et `refetch`, puis afficher une carte « Impossible de charger les publicités. Vérifiez votre connexion. » avec un bouton « Réessayer ». Côté serveur, renvoyer `{ message: 'Erreur lors du chargement des publicités' }` avec le statut 500.
+
+### PUB-14
+
+**Requête sans keepPreviousData, staleTime ni enabled : flash à 0, double appel au montage** — perf-client, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Publicities.tsx:42`
+- **Constat :** La clé `['/api/ad-campaigns', selectedYear, selectedStoreId]` n'a ni placeholderData, ni staleTime (défaut 30 s, queryClient.ts:79), ni enabled. Les cartes stats (l.418, 432-438, 453-457) et la vue d'ensemble (l.466) ne dépendent pas de isLoading : pendant chaque chargement ou changement d'année, on voit « Total 0 / En cours 0 / À venir 0 » et toutes les semaines grises. Layout.tsx:70-76 fixe selectedStoreId après /api/groups pour les directeurs et managers mono-magasin, donc la requête part avec storeId=null puis avec l'id. SavTickets.tsx:99 utilise pourtant `enabled: ... storeInitialized`.
+- **Impact :** Clignotement et faux zéros à chaque changement d'année, et 2 appels API au premier affichage pour les managers et directeurs.
+- **Recommandation :** Ajouter `staleTime: 5 * 60 * 1000` (les mutations invalident déjà la clé). Pour éviter l'appel en double, conditionner sur la fin du chargement de /api/groups plutôt que sur storeInitialized : par exemple `enabled: !!user && (user.role === 'admin' || groupsFetched)`, avec `groupsFetched = isFetched` de la requête ['/api/groups']. Utiliser `placeholderData: keepPreviousData` seulement avec un indicateur `isPlaceholderData` (opacité ou spinner), et afficher des Skeleton dans les stats quand isLoading. Le tout à valider visuellement.
+
+### PUB-17
+
+**PUT sans validation, écritures non transactionnelles (création, participations, suppression)** — bug, sévérité moyenne, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:4681`
+- **Constat :** PUT l.4678-4681 : `const { participatingGroups, ...publicityData } = req.body; await storage.updatePublicity(id, publicityData);` sans `insertPublicitySchema.partial().parse`. createdBy, id et tout champ inconnu arrivent directement dans `.set()` (storage.ts:1591-1597). Aucun 404 si l'id n'existe pas. POST : createPublicity (l.4649), puis setPublicityParticipations (l.4653), puis getPublicity (l.4657), hors transaction. setPublicityParticipations fait un DELETE puis un INSERT non atomiques (storage.ts:1630-1640). deletePublicity supprime manuellement les participations avec `.returning()` (storage.ts:1605) alors que la FK est `ON DELETE CASCADE` (migrations/0000_flashy_blur.sql:247, init.sql:461).
+- **Impact :** Si l'insertion des participations échoue, la pub est créée mais l'utilisateur voit une erreur. S'il réessaie, il bute sur la contrainte unique du N°. Le PUT permet aussi de réécrire createdBy. Chaque écriture coûte 4 à 5 requêtes séquentielles.
+- **Recommandation :** Envelopper création et mise à jour avec les participations dans `db.transaction(async tx => ...)`. Valider le PUT avec `insertPublicitySchema.partial().omit({ createdBy: true }).parse(publicityData)` et renvoyer 400 en cas de ZodError. Renvoyer 404 si `updatedPublicity` est undefined. Garder la suppression manuelle des participations dans deletePublicity, en retirant seulement `.returning()` et les logs.
+
+### PUB-18
+
+**Messages d'erreur génériques en anglais, N° en double non expliqué** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:4661`
+- **Constat :** routes.ts:4661 `res.status(500).json({ message: "Failed to create publicity" })` est aussi renvoyé en cas de N° déjà existant (contrainte `pubNumber: varchar("pub_number").notNull().unique()`, shared/schema.ts:168). Autres messages : « Insufficient permissions » (l.4638, 4674), « Failed to update publicity » (l.4693), « Failed to delete publicity » (l.4732). Ils sont affichés tels quels dans les toasts (PublicityForm.tsx:79 et 91, Publicities.tsx:118, 128, 144). Côté client, `year: z.number().min(2020).max(2030)` (PublicityForm.tsx:27) n'a pas de message, ce qui donne « Number must be less than or equal to 2030 » ou « Expected number, received nan ».
+- **Impact :** Un utilisateur non technicien lit de l'anglais et ne comprend pas qu'il doit simplement changer le numéro.
+- **Recommandation :** Côté serveur, intercepter le code PG 23505 et renvoyer 409 « Ce numéro de publicité existe déjà ». Traduire tous les messages (« Vous n'avez pas les droits pour cette action », « Impossible d'enregistrer la publicité »). Côté Zod : `.min(2020, "Année invalide").max(..., "Année invalide")` et `invalid_type_error: "Saisissez une année"`.
+
+### PUB-19
+
+**Champ Année manuel, bornes incohérentes, filtrage par année saisie plutôt que par dates** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/PublicityForm.tsx:27`
+- **Constat :** Le filtre d'année propose currentYear-2 à currentYear+10, soit 2024 à 2036 (Publicities.tsx:38-40), mais le formulaire limite à 2020-2030 (PublicityForm.tsx:27, 168-169). Valeur par défaut codée en dur `selectedYear || 2025` (l.56). L'année est saisie à la main, indépendamment des dates (commentaire l.61). L'API filtre sur cette colonne (storage.ts:1517-1519) et non sur les dates : une campagne du 28/12/2026 au 03/01/2027 saisie en 2026 n'apparaît pas dans le calendrier ni la vue d'ensemble de janvier 2027.
+- **Impact :** Champ de plus à remplir, source d'erreurs (année ne correspondant pas aux dates), création impossible depuis le filtre 2031 et au-delà, et campagnes de fin d'année invisibles en janvier.
+- **Recommandation :** Pré-remplir l'année depuis la date de début (modifiable), ou la calculer côté serveur. Aligner les bornes partout (par exemple currentYear-5 à currentYear+2). Pour les vues calendrier et semaines, filtrer côté serveur par chevauchement `start_date <= 'YYYY-12-31' AND end_date >= 'YYYY-01-01'` (l'index idx_publicities_start_date existe).
+
+### PUB-20
+
+**Formulaire : erreurs qui persistent, alerte rouge sur un champ optionnel, watch global** — ux-simplicite, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/PublicityForm.tsx:215`
+- **Constat :** `form.setValue("startDate", date!)` (l.215, 253) et `form.setValue("participatingGroups", ...)` (l.285-287) sont appelés sans `{ shouldValidate: true }` : après un envoi raté, « La date de début est requise » reste affiché même une fois la date choisie. Recliquer la date la désélectionne (`date!` vaut undefined). Le bloc rouge « Aucun magasin sélectionné » (l.304-308) s'affiche alors que le champ est indiqué « (optionnel) » (l.273). Pas de « Tout sélectionner ». `form.watch(...)` est appelé une dizaine de fois au rendu (l.199-304), ce qui re-rend tout le formulaire à chaque frappe.
+- **Impact :** Messages contradictoires et erreurs fantômes qui bloquent ou inquiètent l'utilisateur. Cocher 10 magasins un par un est fastidieux.
+- **Recommandation :** Utiliser `setValue(name, value, { shouldValidate: form.formState.isSubmitted, shouldDirty: true })` et ignorer `undefined` dans onSelect (`if (date) ...`). Remplacer le bloc rouge par une note grise neutre, ou rendre le champ obligatoire (décision produit). Ajouter « Tous » et « Aucun ». Le remplacement de watch par useWatch est optionnel, car le gain de performance est négligeable.
+
+### PUB-21
+
+**En-tête surchargé : 7 contrôles sur une ligne, non responsive** — lisibilite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Publicities.tsx:321`
+- **Constat :** l.321-404 : `<div className="flex items-center gap-3">` sans flex-wrap, contenant le toggle Liste/Grille (icônes seules), le bouton « Vue d'ensemble », l'icône Filtre et le Select année, le Select mois (vue calendrier), « Exporter CSV » et « Nouvelle publicité ». L'en-tête `p-6 -m-6 mb-6` (l.309) n'est pas responsive alors que Layout passe à `p-3` en tablette avec `overflow-x-hidden` (Layout.tsx:211) : l'en-tête déborde et est rogné. Orders.tsx:233 et Avoirs.tsx:1156 utilisent `p-4 sm:p-6 -m-4 sm:-m-6`.
+- **Impact :** L'utilisateur ne sait pas par où commencer. Sur tablette ou petit portable, des boutons sont coupés. « CSV » est du jargon.
+- **Recommandation :** Remplacer le toggle et « Vue d'ensemble » par des onglets texte « Liste | Calendrier | Année ». Placer les filtres (année, recherche) à gauche et les actions à droite avec `flex flex-wrap gap-2`. Renommer « Exporter (Excel) » et reprendre l'en-tête responsive d'Orders.tsx.
+
+### PUB-22
+
+**Tableau 7 colonnes non scrollable : colonne Actions coupée en tablette** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Publicities.tsx:720`
+- **Constat :** l.720-721 : `<div><table className="w-full">` sans `overflow-x-auto`, 7 colonnes en `px-6`. Entre 768 et 1024 px, c'est la version desktop qui s'affiche (RouterProduction.tsx:106 `if (isMobile)`, isMobile correspondant à moins de 768 px dans use-screen-size.ts), et le conteneur de Layout est `overflow-x-hidden` (Layout.tsx:211).
+- **Impact :** Sur tablette, les boutons Voir, Modifier et Supprimer peuvent être hors écran et inaccessibles.
+- **Recommandation :** Auto-implémenter uniquement `<div className="overflow-x-auto">` autour du tableau (l.720). Le passage à px-4 et `hidden lg:table-cell` sur « Créé par » sont à valider visuellement (voir aussi PUB-03).
+
+### PUB-23
+
+**Liste desktop sans recherche ni filtre de statut, libellés abrégés, lignes non cliquables** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Publicities.tsx:748`
+- **Constat :** l.748 `publicities.map(...)` : aucune recherche ni filtre par statut ou magasin, alors que le mobile a « Rechercher une pub... » (PublicitiesPage.tsx:89-94). Tri uniquement par N°. En-tête « N° PUB » en majuscules (l.725), période en `dd/MM/yy` (l.771). Le détail n'est accessible que par l'icône œil (l.812-819), la ligne elle-même n'est pas cliquable. Les cartes stats En cours / À venir (l.424-462) ne sont pas cliquables.
+- **Impact :** Pour retrouver « la promo de la semaine prochaine », l'utilisateur doit parcourir toute l'année et lire les dates une par une.
+- **Recommandation :** Ajouter un champ de recherche (N° ou désignation) et des puces de filtre « En cours / À venir / Terminées », en rendant les cartes stats cliquables comme filtres. Trier par défaut En cours puis À venir avant les Terminées. Rendre la ligne cliquable pour ouvrir le détail. Libellé « Numéro », dates en `dd/MM/yyyy`.
+
+### PUB-24
+
+**Vue d'ensemble affichée par défaut, info uniquement au survol, légende sans noms** — lisibilite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Publicities.tsx:466`
+- **Constat :** `useState(true)` pour showYearOverview (l.22) : la grille de 12 colonnes et sa légende passent avant la liste. Les cellules ont `cursor-pointer` (l.496) mais pas de onClick, et l'information n'est donnée que par `title` (l.503), inaccessible au tactile. Les pastilles magasins font `w-1.5 h-1.5` (6 px, l.512) avec `title={`Magasin ${idx + 1}`}` (l.514) au lieu du nom. La légende « Indicateurs magasins (coin supérieur droit) » montre 3 couleurs sans nom (l.551-559).
+- **Impact :** La tâche principale (la liste) est repoussée sous la ligne de flottaison. Les pastilles sont illisibles, la légende inexploitable et le curseur promet un clic qui ne fait rien.
+- **Recommandation :** Replier la vue par défaut ou la déplacer dans un onglet « Année ». Rendre chaque semaine cliquable pour filtrer la liste ou ouvrir un popover listant ses pubs. Légende avec chaque magasin (couleur et nom), pastilles d'au moins 8 px, title avec le nom du magasin.
+
+### PUB-30
+
+**« Publicités à venir » : 3 appels séquentiels d'années complètes faute de filtre API** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:197`
+- **Constat :** Dashboard.tsx:203-218 : `for (const year of years) { ... await fetch(`/api/ad-campaigns?${params}`) ... }` sur [année-1, année, année+1], puis `.filter(p => new Date(p.startDate) > new Date())` côté client. Chaque réponse contient toutes les participations, avec logos (PUB-02).
+- **Impact :** La page d'accueil attend 3 allers-retours successifs et télécharge 3 années complètes pour afficher quelques pubs à venir.
+- **Recommandation :** Ajouter un paramètre `GET /api/ad-campaigns?upcoming=1&limit=5`, traité par `WHERE start_date >= CURRENT_DATE ORDER BY start_date LIMIT 5` (index idx_publicities_start_date présent) avec filtre magasin. À défaut, paralléliser avec Promise.all.
+
+### PUB-05
+
+**console.log dans le chemin chaud de lecture et logs verbeux sur la suppression** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/storage.ts:1525`
+- **Constat :** storage.ts:1525-1528 à chaque GET : `console.log(`📋 PUBLICITES FETCHED: ...`)` et `console.log('🔍 PREMIERS RESULTATS:', results.slice(0, 3).map(... p.designation))`. deletePublicity l.1601-1617 : 4 logs. routes.ts:4699-4728 et 4739-4767 : dump de req.user, des headers et du nom de l'admin.
+- **Impact :** Écritures stdout synchrones à chaque chargement en production, logs bruités et données métier (désignations) dans les journaux.
+- **Recommandation :** Supprimer ces logs ou les conditionner à `process.env.NODE_ENV !== 'production'` ou à un logger de niveau debug. Ne garder que console.error dans les catch.
+
+### PUB-15
+
+**Triple tri (SQL, serveur JS, client JS) incompatible avec le format de N° suggéré** — perf-client, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Publicities.tsx:57`
+- **Constat :** SQL `query.orderBy(publicities.pubNumber)` (storage.ts:1522), puis tri JS `parseInt(a.pubNumber) || 0` (storage.ts:1544-1548), puis le même tri côté client, qui mute le tableau `data.sort(...)` (Publicities.tsx:57-64). Le formulaire suggère « Ex: PUB2025-001 » (PublicityForm.tsx:155) : parseInt renvoie NaN, remplacé par 0, donc ces numéros ne sont pas triés numériquement.
+- **Impact :** Travail redondant et ordre imprévisible si les formats de N° sont mélangés.
+- **Recommandation :** Sans risque : supprimer seulement le tri client de Publicities.tsx:57-64, qui duplique exactement celui du serveur (mobile et Calendar s'appuient déjà sur l'ordre serveur), ainsi que les logs associés. Garder l'orderBy SQL tant que le comparateur parseInt est en place. Le passage à `localeCompare(..., 'fr', { numeric: true })` est une amélioration distincte, à valider car l'ordre change pour les N° mixtes.
+
+### PUB-16
+
+**Association participations ↔ publicités en O(N×M) et 2 requêtes séquentielles** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:1550`
+- **Constat :** storage.ts:1550-1559 : `sortedResults.map(publicity => ({ ...publicity, participations: participations.filter((p: any) => p.publicityId === publicity.id).map(...) }))` parcourt toutes les participations pour chaque publicité. La requête participations (l.1531-1541) attend la fin de la requête publicities.
+- **Impact :** Coût CPU quadratique sur les années chargées, et un aller-retour BD de plus.
+- **Recommandation :** Se limiter au regroupement en mémoire : `const byPub = new Map<number, any[]>(); for (const p of participations) { (byPub.get(p.publicityId) ?? byPub.set(p.publicityId, []).get(p.publicityId)!).push({ publicityId: p.publicityId, groupId: p.groupId, group: p.group }); }` puis `participations: byPub.get(publicity.id) ?? []`. Garder les deux requêtes séquentielles.
+
+### PUB-25
+
+**Vue calendrier : seul le N° est affiché, pas de navigation mois par mois, doublon avec /calendar** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Publicities.tsx:651`
+- **Constat :** Chaque jour n'affiche que `{pub.pubNumber}` (l.657), la désignation n'étant que dans `title` (l.655). La navigation passe uniquement par le Select mois (l.374-390), sans flèches précédent/suivant. La page /calendar (CalendarGrid.tsx:380-442) affiche déjà les publicités, avec un filtrage magasin correct.
+- **Impact :** Un numéro seul ne dit rien à un employé, et deux calendriers différents coexistent pour la même information.
+- **Recommandation :** Afficher « N° – désignation » tronqué et ajouter des boutons ‹ ›. Envisager de supprimer ce mode et de proposer un lien « Voir dans le calendrier » vers /calendar.
+
+### PUB-26
+
+**Icônes, badges de statut, CTA et confirmation incohérents** — coherence-design, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Publicities.tsx:775`
+- **Constat :** Icône de page `Calendar` verte (l.313), contre `Megaphone` dans Sidebar.tsx:293-296 et `Megaphone` violet sur mobile (PublicitiesPage.tsx:81). Les 3 cartes stats ont la même icône Calendar (l.413, 427, 448). Badge « En cours » `bg-green-100 text-green-800` sur desktop (l.775) contre `bg-green-500` sur mobile (l.67). La variante default du Badge garde `hover:bg-primary/80` (ui/badge.tsx:11-12) : « En cours » et « À venir » changent de couleur au survol, alors que « Aucun magasin » contourne le problème avec `hover:bg-red-100` (l.782). La même action a deux styles : « Nouvelle publicité » `bg-green-600` (l.399) et « Créer une publicité » en variante par défaut (l.587). L'état vide « Commencez par créer votre première campagne » (l.583-585) s'affiche aussi aux non-admins. La confirmation de suppression est un Dialog maison (l.964-995) alors que components/ConfirmationModal.tsx existe et qu'Avoirs utilise AlertDialog (Avoirs.tsx:1603).
+- **Impact :** L'utilisateur doit réapprendre les codes d'une page à l'autre et entre téléphone et PC, ce qui nuit à la lisibilité.
+- **Recommandation :** Créer un composant partagé `PublicityStatusBadge` (variant outline avec couleurs fixes, sans hover) utilisé par desktop et mobile. Icône Megaphone partout et icônes distinctes pour les stats. Un seul libellé et style « Nouvelle publicité ». Message vide adapté au rôle. Réutiliser ConfirmationModal (variant destructive).
+
+### PUB-27
+
+**Boutons Liste/Grille sans nom accessible ni infobulle** — accessibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Publicities.tsx:324`
+- **Constat :** l.324-339 : `<Button variant={viewMode === 'list' ? 'default' : 'ghost'} ...><List className="h-4 w-4" /></Button>` et `<Grid .../>` n'ont ni texte, ni aria-label, ni title. Les boutons d'action des lignes n'ont qu'un `title` (l.816, 827, 837). Les cellules de semaine sont des div non focusables (l.493).
+- **Impact :** Lecteurs d'écran muets, et aucun indice pour l'utilisateur sur ce que fait l'icône « Grille » (qui ouvre en fait un calendrier).
+- **Recommandation :** Ajouter `aria-label="Affichage liste"` / `"Affichage calendrier"`, `title` et `aria-pressed`. Ajouter aussi `aria-label` sur Voir, Modifier et Supprimer.
+
+### PUB-28
+
+**Code mort et requête groups redondante avec StoreContext** — dette-code, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Publicities.tsx:303`
+- **Constat :** `const canCreateOrEdit = user?.role === 'admin' || user?.role === 'manager';` et `const canDelete = ...` (l.303-304) ne sont jamais utilisés, et le premier contredit shared/permissions.ts:61-66 (manager : view). Imports inutilisés : `isWithinInterval`, `getWeek` (l.12), `safeCompareDate` (l.14). `useQuery(['/api/groups'])` (l.91-94) duplique `stores`, déjà exposé par `useStore()` (Layout.tsx:48-51, 86).
+- **Impact :** Le code induit en erreur (on croit que les managers peuvent éditer) et le bundle est alourdi.
+- **Recommandation :** Supprimer canCreateOrEdit, canDelete et les imports inutilisés (isWithinInterval, getWeek, safeCompareDate). Remplacer la requête par `const { selectedStoreId, stores: groups } = useStore();`. Ce n'est qu'une simplification de code, sans gain réseau.
+
+### PUB-29
+
+**Invalidation par préfixe après mutation : la réponse serveur complète est ignorée** — perf-api, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/PublicityForm.tsx:84`
+- **Constat :** `queryClient.invalidateQueries({ queryKey: ['/api/ad-campaigns'] })` est appelé après création (l.84), modification (l.117) et suppression (Publicities.tsx:136). Le serveur renvoie pourtant déjà la publicité complète (routes.ts:4656-4658 et 4688-4690). Le préfixe marque aussi comme périmée la clé ['/api/ad-campaigns','upcoming'] du Dashboard (3 appels séquentiels).
+- **Impact :** Rechargement complet de la liste après chaque action (6 requêtes SQL et le payload entier), donc un délai perceptible avant que la ligne apparaisse.
+- **Recommandation :** Garder l'invalidation par préfixe, qui est simple et correcte. Au plus, ajouter une mise à jour optimiste sur la suppression (retirer l'élément de la clé courante avec rollback onError), puis invalider.
+
+### PUB-31
+
+**Modale création/édition sans hauteur max : boutons hors écran avec beaucoup de magasins** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Publicities.tsx:857`
+- **Constat :** `<DialogContent className="max-w-2xl">` (l.857, 874). Le DialogContent de base est `fixed top-[50%] translate-y-[-50%] grid ... p-6`, sans max-h ni overflow (ui/dialog.tsx:41). Le formulaire grandit avec la grille de magasins (PublicityForm.tsx:276-302), le bloc rouge et le textarea.
+- **Impact :** Sur un portable de 768 px de haut avec une dizaine de magasins, les boutons Créer et Annuler sortent de l'écran sans possibilité de défiler.
+- **Recommandation :** `className="max-w-2xl max-h-[90vh] overflow-y-auto"` sur les deux DialogContent, ou un footer collant pour les boutons.
+
+### PUB-32
+
+**Pages Publicités et formulaire importés statiquement dans le bundle initial** — perf-bundle, sévérité basse, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:15`
+- **Constat :** RouterProduction.tsx:15 `import Publicities from "@/pages/Publicities";` et l.40 `import MobilePublicitiesPage ...`, chargés avec toutes les autres pages. Publicities embarque PublicityForm (react-hook-form, zod, @hookform/resolvers, react-day-picker via ui/calendar, locale date-fns) alors que seuls les admins créent.
+- **Impact :** JavaScript chargé et parsé au démarrage pour une page secondaire, ce qui allonge le premier affichage du Dashboard.
+- **Recommandation :** Traiter le lazy loading au niveau du routeur pour toutes les pages (React.lazy et Suspense avec un fallback squelette), comme chantier transverse. Ne pas présenter le lazy de Publicities seule comme un gain sur RHF, zod ou day-picker.
+
+### PUB-33
+
+**Mobile : pas de détail, pas de magasins participants, pas de priorisation des pubs en cours** — ux-simplicite, sévérité basse, effort M
+
+- **Fichier :** `client/src/pages/mobile/PublicitiesPage.tsx:119`
+- **Constat :** Les cartes (l.126-155) ne sont pas cliquables et n'affichent ni `participations` ni la période complète (`dd/MM` pour le début, l.146). Tri par N° hérité du serveur. Le message « Aucune publicité trouvée pour {selectedYear} » (l.122) est le même pour une année vide et pour une recherche sans résultat. Données typées `any` (l.56, 125).
+- **Impact :** En rayon, l'employé veut savoir ce qui est en cours maintenant et si son magasin participe : il doit faire défiler toute l'année sans cette information.
+- **Recommandation :** Grouper les cartes par sections « En cours », « À venir » et « Terminées » (repliée). Afficher les pastilles des magasins participants et un Sheet de détail au tap. Message « Aucun résultat pour « xxx » » avec un bouton Effacer. Typer avec `PublicityWithRelations[]`.
+
+### PUB-34
+
+**Trois queryFn différents et clés incohérentes pour le même endpoint** — dette-code, sévérité basse, effort M
+
+- **Fichier :** `client/src/pages/mobile/PublicitiesPage.tsx:43`
+- **Constat :** Desktop : clé `['/api/ad-campaigns', selectedYear, selectedStoreId]`, storeId envoyé pour tous les rôles (Publicities.tsx:43-49). Calendar : même clé mais storeId envoyé seulement pour l'admin (Calendar.tsx:137-142), donc une même entrée de cache pour deux URLs différentes. Mobile : `["/api/ad-campaigns", selectedStoreId, selectedYear]` dans l'ordre inverse (l.43), donc pas de partage de cache. Partout des fetch() manuels au lieu d'apiRequest ou du queryFn par défaut (queryClient.ts:47-66, qui gère le 401).
+- **Impact :** Données potentiellement différentes sous une même clé, aucun cache partagé entre écrans, et chaque correction (fuseau, tri, erreurs) doit être faite 3 fois.
+- **Recommandation :** Créer un hook `usePublicities({ year, storeId })` dans client/src/hooks avec une clé unique `['/api/ad-campaigns', { year, storeId }]`, staleTime, keepPreviousData et gestion d'erreur. L'utiliser dans Publicities, la page mobile, Calendar et Dashboard.
+
+### PUB-35
+
+**Index publicities/participations hors de shared/schema.ts, index group_id non garanti** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `shared/schema.ts:166`
+- **Constat :** shared/schema.ts:166-184 ne déclare aucun index (seulement l'unique sur pub_number et la PK (publicity_id, group_id)). idx_publicities_year et idx_publicities_start_date existent dans init.sql:521-523 et migrations/0000_flashy_blur.sql:260-261. idx_publicity_participations_group_id n'existe que dans migrations/20260814_add_performance_indexes.sql:86 et scripts/auto-migrate-production.sh:213 : il est absent d'init.sql et de la liste server/migrations.ts. drizzle.config.ts pointe sur shared/schema.ts (`db:push`: drizzle-kit push).
+- **Impact :** Une fois PUB-01 corrigé (filtre par group_id), une installation neuve sans le script de production fera un seq scan sur publicity_participations. La source de vérité des index est éclatée entre plusieurs fichiers.
+- **Recommandation :** Ajouter `CREATE INDEX IF NOT EXISTS idx_publicity_participations_group_id ON publicity_participations (group_id);` dans init.sql et dans server/migrations.production.ts, qui est réellement exécuté au démarrage, et non dans server/migrations.ts. Déclarer en option les index dans shared/schema.ts (yearIdx, startIdx, groupIdx) avec les mêmes noms, pour que `drizzle-kit push` ne les supprime pas.

docs/audit-webui/10-users-groups.md

@@ -0,0 +1,492 @@
+# Utilisateurs & Magasins
+
+_43 constats vérifiés — 7 haute, 20 moyenne, 16 basse._
+
+## Pages analysées
+
+### `/users`
+
+**Rôle :** Page réservée aux administrateurs pour gérer les comptes : créer un utilisateur (identifiant + mot de passe), modifier ses informations, changer son rôle (Administrateur, Directeur, Manager, Employé), l'affecter à un ou plusieurs magasins et le supprimer.
+
+**Tâches principales de l'utilisateur :**
+- Retrouver un utilisateur (recherche texte + filtre par rôle)
+- Créer un compte avec identifiant, mot de passe, rôle et magasins
+- Modifier nom, e-mail, identifiant, mot de passe d'un compte
+- Changer le rôle d'un utilisateur (sélecteur rapide dans la ligne ou dans la fenêtre de modification)
+- Affecter / retirer un utilisateur d'un magasin
+- Supprimer un compte
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/users | au montage (enabled: role admin) et après chaque mutation (invalidateQueries) | server/routes.ts:4268 -> storage.getUsers() (storage.ts:409) puis storage.getUserWithGroups(id) pour CHAQUE utilisateur (storage.ts:371) | N+1 : 1 + 2N requêtes SQL (getUserWithGroups refait un getUser + une jointure par utilisateur). Renvoie la colonne password (hash) de tous les comptes, et l'endpoint est ouvert aux managers/directeurs (routes.ts:4271). |
+| GET /api/groups | au montage (enabled: admin) — même clé que Layout.tsx:49, donc déjà en cache | server/routes.ts:970 -> storage.getUserWithGroups(userId) + storage.getGroups() (storage.ts:432, SELECT * ORDER BY name) | SELECT * inclut le logo base64 (jusqu'à 200 Ko par magasin) et toute la config SMTP/NocoDB alors que la page n'utilise que id, name, color. |
+| PUT /api/users/:id | au clic (sélecteur rapide de rôle après confirmation, ou bouton « Mettre à jour ») | server/routes.ts:4392 -> storage.updateUser (storage.ts:418) | Recharge getUserWithGroups (2 requêtes) juste pour vérifier le rôle ; renvoie l'utilisateur complet avec le hash du mot de passe (routes.ts:4431) ; aucune protection contre l'auto-rétrogradation ni contre la suppression du dernier admin. |
+| POST /api/users | au clic « Créer l'utilisateur » | server/routes.ts:4309 -> hashPasswordSimple + storage.createUser (storage.ts:413) | Renvoie le hash (routes.ts:4356). L'affectation aux magasins est faite ensuite par N appels séparés, sans transaction. |
+| POST /api/users/:id/groups | au clic « Assigner » dans la modale de modification, et N fois en parallèle à la création | server/routes.ts:4228 -> storage.assignUserToGroup (storage.ts:1210, INSERT simple) | Aucune contrainte d'unicité (user_id, group_id) : les doublons sont possibles. Une 2e route identique existe en routes.ts:4461 et n'est jamais atteinte. |
+| DELETE /api/users/:id/groups/:groupId | au clic « Retirer » dans la modale de modification | server/routes.ts:4249 -> storage.removeUserFromGroup (storage.ts:1215) | Doublon inaccessible en routes.ts:4481. |
+| DELETE /api/users/:id | au clic sur la poubelle puis window.confirm | server/routes.ts:4497 -> storage.getUserWithGroups + boucle séquentielle storage.removeUserFromGroup + storage.deleteUser (storage.ts:427) | Boucle d'await séquentielle (1 DELETE par magasin) sans transaction au lieu d'un seul DELETE ... WHERE user_id. |
+
+**Lisibilité / simplicité :** Page fonctionnelle mais confuse pour un non-technicien : le tableau affiche un identifiant technique (« ID: manual_1712_x9… ») au lieu de l'identifiant de connexion, et le rôle apparaît deux fois par ligne (badge + sélecteur rapide). Le filtre et la création ne proposent pas le rôle « Directeur ». Le vocabulaire alterne entre « Groupes » et « Magasins ». Dans la fenêtre de modification, l'affectation aux magasins est enregistrée tout de suite (sans passer par « Mettre à jour », sans être annulable) et le bouton ne change pas d'état après le clic, ce qui pousse à cliquer deux fois et crée des doublons. La confirmation de changement de rôle affiche le code anglais (« employee ») sans nommer la personne. Les messages d'erreur précis du serveur (identifiant déjà utilisé…) ne sont jamais affichés. Plusieurs façons de confirmer cohabitent (window.confirm natif / Dialog). Sur mobile, le tableau est coupé et la colonne Actions devient inaccessible. Il reste des console.log de debug et du code mort.
+
+### `/groups`
+
+**Rôle :** Gestion des magasins (« groupes ») : créer ou modifier un magasin (nom, couleur, coordonnées et logo pour la signature des mails, envoi de mails SMTP propre au magasin, intégration NocoDB pour vérifier les factures, webhook), voir le nombre de commandes et de livraisons de chaque magasin et le supprimer.
+
+**Tâches principales de l'utilisateur :**
+- Voir la liste des magasins et leur activité (commandes, livraisons, % livrées)
+- Créer un magasin
+- Modifier les coordonnées, le logo et la couleur d'un magasin
+- Configurer et tester l'envoi de mails (SMTP) du magasin
+- Relier le magasin à une table NocoDB (vérification des factures) et à un webhook
+- Supprimer un magasin sans activité
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/groups | au montage (pas de enabled ; partagé avec Layout.tsx:49 et une vingtaine de composants) | server/routes.ts:970 -> storage.getUserWithGroups (storage.ts:371, 2 requêtes) puis storage.getGroups (storage.ts:432) pour l'admin, ou user.userGroups[].group (5 colonnes seulement) pour les autres rôles | Admin : SELECT * avec logo base64 + config SMTP/NocoDB pour chaque magasin, sans compression gzip côté Express. Non-admin : objets tronqués {id,name,color,createdAt,updatedAt}, donc le contrat de réponse diffère selon le rôle. |
+| GET /api/nocodb-config | au montage, sans condition (même si la modale n'est jamais ouverte) | server/routes.ts:5090 -> storage.getUserWithGroups + storage.getNocodbConfigs (storage.ts:1655, déchiffrement du jeton pour chaque config) | Réservé aux admins : un manager qui ouvre la page reçoit un 403, relancé 2 fois par la politique retry du queryClient (3 requêtes en échec). |
+| GET /api/stats/by-group | au montage | server/routes.ts:1485 -> storage.getUserWithGroups + storage.getOrderDeliveryStatsByGroup (storage.ts:1817) | Correct : deux COUNT ... GROUP BY group_id en Promise.all, couverts par idx_orders_group_id et idx_deliveries_group_id (migrations/20260814_add_performance_indexes.sql:21,32). Seul surcoût : le getUserWithGroups redondant. |
+| POST /api/groups | au clic « Créer » dans la modale | server/routes.ts:992 -> storage.getUser + insertGroupSchema.parse + storage.createGroup (storage.ts:441) | Une dizaine de console.log par requête, dont le corps avec le logo base64 complet (l.1001) et l'objet validé avec le mot de passe SMTP en clair (l.1038). |
+| PUT /api/groups/:id | au clic « Modifier » dans la modale | server/routes.ts:1067 -> storage.getUser + storage.updateGroup (storage.ts:449) | Accepté pour tout manager, sur n'importe quel magasin (aucune vérification d'appartenance). |
+| POST /api/groups/:id/test-smtp | au clic « Tester la connexion SMTP » (édition seulement) | server/routes.ts:1092 -> storage.getGroup (storage.ts:436) + verifySmtpConfig | Teste la configuration ENREGISTRÉE et non les valeurs en cours de saisie dans le formulaire. |
+| DELETE /api/groups/:id | au clic sur la poubelle puis window.confirm | server/routes.ts:1124 -> storage.deleteGroup (storage.ts:462) | Aucune vérification côté serveur (le contrôle commandes/livraisons n'existe que côté client). Pas de FK ni de nettoyage de user_groups. |
+
+**Lisibilité / simplicité :** La liste en cartes est claire mais montre du bruit technique (« #12 », code couleur hexadécimal avec une icône palette) au lieu d'informations utiles (nombre d'utilisateurs, mails configurés ou non). Le menu dit « Magasins » alors que la page parle de « Groupes/Magasins », « Nouveau Groupe », « Groupe créé ». La fenêtre de création/modification est très lourde : environ 25 champs sur deux colonnes en sm:max-w-4xl, avec un jargon technique (NocoDB, Mapping des colonnes, Webhook, SMTP, STARTTLS, SSL/TLS, Port). Le bouton « 🔍 Tester la configuration NocoDB » n'est pas implémenté (toast « Fonctionnalité à implémenter »). Le champ Webhook est caché tant qu'aucune config NocoDB n'est choisie. Les erreurs du test SMTP s'affichent en JSON brut. Un clic hors de la fenêtre efface toute la saisie sans prévenir. Les composants mélangent select/checkbox natifs, emojis et shadcn/lucide. Le bouton de modification est proposé aux managers alors que l'API leur renvoie des magasins tronqués : enregistrer efface alors la configuration du magasin.
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [GROUPS-01](#groups-01) | haute | bug | S | Un manager qui modifie un magasin efface sa configuration (NocoDB, SMTP, coordonnées, logo) | `client/src/pages/Groups.tsx:348` |
+| [GROUPS-02](#groups-02) | haute | perf-api | M | GET /api/groups renvoie les logos base64 et toute la configuration à chaque page de l'application | `server/storage.ts:432` |
+| [GROUPS-05](#groups-05) | haute | ux-simplicite | M | Fenêtre de création/modification surchargée (environ 25 champs) et pleine de jargon technique | `client/src/pages/Groups.tsx:508` |
+| [GROUPS-14](#groups-14) | haute | bug | S | POST /api/groups écrit le mot de passe SMTP en clair et le logo base64 dans les logs | `server/routes.ts:1038` |
+| [USERS-01](#users-01) | haute | perf-serveur | S | N+1 sur GET /api/users : 1 + 2N requêtes SQL à chaque chargement | `server/routes.ts:4280` |
+| [USERS-02](#users-02) | haute | bug | S | Hash des mots de passe renvoyé au navigateur (GET/POST/PUT /api/users), y compris aux managers | `server/storage.ts:409` |
+| [USERS-03](#users-03) | haute | bug | S | Modale de modification : le bouton Assigner/Retirer ne se met pas à jour, ce qui crée des affectations en double | `client/src/pages/Users.tsx:898` |
+| [GROUPS-03](#groups-03) | moyenne | bug | S | La réponse de /api/groups change selon le rôle : les non-admins reçoivent des magasins tronqués | `server/routes.ts:982` |
+| [GROUPS-04](#groups-04) | moyenne | perf-serveur | S | Chaque handler recharge l'utilisateur et ses magasins, déjà chargés par passport | `server/routes.ts:972` |
+| [GROUPS-06](#groups-06) | moyenne | ux-simplicite | S | Le bouton « 🔍 Tester la configuration NocoDB » ne fait rien (TODO) | `client/src/pages/Groups.tsx:704` |
+| [GROUPS-07](#groups-07) | moyenne | bug | S | Le champ Webhook n'apparaît que si une configuration NocoDB est choisie | `client/src/pages/Groups.tsx:680` |
+| [GROUPS-08](#groups-08) | moyenne | lisibilite | S | Test SMTP : erreur affichée en JSON brut, et test fait sur les valeurs enregistrées et non sur la saisie | `client/src/pages/Groups.tsx:181` |
+| [GROUPS-09](#groups-09) | moyenne | bug | M | Suppression d'un magasin : contrôle fait seulement côté client, données orphelines | `server/routes.ts:1131` |
+| [GROUPS-11](#groups-11) | moyenne | lisibilite | S | La page Magasins parle de « Groupes » | `client/src/pages/Groups.tsx:358` |
+| [GROUPS-13](#groups-13) | moyenne | ux-simplicite | S | Un clic hors de la fenêtre ou la touche Échap efface toute la saisie sans avertir | `client/src/pages/Groups.tsx:502` |
+| [PERF-BUNDLE-01](#perf-bundle-01) | moyenne | perf-bundle | S | Pages d'administration (Utilisateurs, Magasins…) chargées par tous les utilisateurs | `client/src/components/RouterProduction.tsx:12` |
+| [PERM-01](#perm-01) | moyenne | dette-code | M | Deux matrices de permissions divergentes (client et shared), sans module Utilisateurs ni Magasins | `client/src/lib/permissions.ts:42` |
+| [USERS-04](#users-04) | moyenne | bug | S | Les messages d'erreur précis du serveur ne sont jamais affichés | `client/src/pages/Users.tsx:216` |
+| [USERS-05](#users-05) | moyenne | perf-api | M | Création avec magasins : N appels séparés, N toasts, 2N rechargements et opération non atomique | `client/src/pages/Users.tsx:411` |
+| [USERS-06](#users-06) | moyenne | perf-client | S | Invalidation inutile de /api/groups après chaque affectation | `client/src/pages/Users.tsx:245` |
+| [USERS-07](#users-07) | moyenne | ux-simplicite | M | Magasins enregistrés tout de suite dans la modale, contrairement aux autres champs (« Annuler » ne les annule pas) | `client/src/pages/Users.tsx:893` |
+| [USERS-08](#users-08) | moyenne | bug | S | Le rôle « Directeur » manque dans le filtre et dans le formulaire de création | `client/src/pages/Users.tsx:631` |
+| [USERS-09](#users-09) | moyenne | lisibilite | S | Le tableau affiche un ID technique au lieu de l'identifiant de connexion, qui n'est pas non plus cherchable | `client/src/pages/Users.tsx:712` |
+| [USERS-10](#users-10) | moyenne | lisibilite | S | La confirmation de changement de rôle affiche le code anglais et ne dit pas de qui il s'agit | `client/src/pages/Users.tsx:516` |
+| [USERS-11](#users-11) | moyenne | bug | S | Deux réglages du rôle avec des règles différentes : la modale permet de modifier son propre rôle sans confirmation | `client/src/pages/Users.tsx:877` |
+| [USERS-14](#users-14) | moyenne | ux-simplicite | S | Mobile : tableau coupé, la colonne Actions devient inaccessible | `client/src/pages/Users.tsx:658` |
+| [USERS-17](#users-17) | moyenne | lisibilite | S | Vocabulaire incohérent « Groupes » / « Magasins » sur la page Utilisateurs | `client/src/pages/Users.tsx:673` |
+| [GROUPS-10](#groups-10) | basse | lisibilite | S | Cartes magasin : informations techniques inutiles, état de configuration absent | `client/src/pages/Groups.tsx:433` |
+| [GROUPS-12](#groups-12) | basse | perf-client | S | Configs NocoDB chargées au montage sans condition (403 relancé 2 fois pour un manager) | `client/src/pages/Groups.tsx:84` |
+| [GROUPS-15](#groups-15) | basse | coherence-design | S | Composants natifs et emojis mélangés aux composants shadcn et aux icônes lucide | `client/src/pages/Groups.tsx:579` |
+| [GROUPS-16](#groups-16) | basse | ux-simplicite | S | Grilles du formulaire non adaptées au mobile | `client/src/pages/Groups.tsx:616` |
+| [PERM-02](#perm-02) | basse | perf-serveur | M | Middleware global qui recopie récursivement toutes les réponses JSON pour masquer smtpPassword | `server/routes.ts:168` |
+| [USERS-12](#users-12) | basse | ux-simplicite | S | Délai artificiel de 1 seconde avant la fermeture de la modale après enregistrement | `client/src/pages/Users.tsx:159` |
+| [USERS-13](#users-13) | basse | coherence-design | S | Confirmations incohérentes : window.confirm natif pour supprimer, Dialog pour le rôle, AlertDialog ailleurs | `client/src/pages/Users.tsx:558` |
+| [USERS-15](#users-15) | basse | dette-code | S | console.log de debug dans les mutations des deux pages | `client/src/pages/Users.tsx:227` |
+| [USERS-16](#users-16) | basse | dette-code | S | Code mort : gestion 401 jamais déclenchée (répétée 8 fois), états et fonctions inutilisés | `client/src/pages/Users.tsx:100` |
+| [USERS-18](#users-18) | basse | bug | S | Le texte d'aide « Minimum 6 caractères » n'est vérifié nulle part | `client/src/pages/Users.tsx:870` |
+| [USERS-19](#users-19) | basse | dette-code | S | La clé primaire est générée côté client à partir de l'e-mail (« _1712… » si e-mail vide) | `client/src/pages/Users.tsx:191` |
+| [USERS-20](#users-20) | basse | ux-simplicite | S | Aucune explication de ce que permet chaque rôle | `client/src/pages/Users.tsx:1029` |
+| [USERS-21](#users-21) | basse | perf-serveur | S | Suppression d'un utilisateur : boucle d'await séquentielle sans transaction | `server/routes.ts:4514` |
+| [USERS-22](#users-22) | basse | dette-code | S | Routes en double pour l'affectation utilisateur ↔ magasin (la 2e n'est jamais atteinte) | `server/routes.ts:4461` |
+| [USERS-23](#users-23) | basse | accessibilite | S | Boutons à icône seule sans libellé accessible | `client/src/pages/Users.tsx:779` |
+| [USERS-24](#users-24) | basse | coherence-design | S | Chargement affiché par un spinner central au lieu d'un squelette de la liste | `client/src/pages/Users.tsx:642` |
+
+### GROUPS-01
+
+**Un manager qui modifie un magasin efface sa configuration (NocoDB, SMTP, coordonnées, logo)** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/Groups.tsx:348`
+- **Constat :** Groups.tsx:348 `const canManage = user?.role === 'admin' || user?.role === 'manager';` affiche les boutons Modifier. Pour un non-admin, GET /api/groups renvoie `user.userGroups.map(ug => ug.group)` (routes.ts:982-983), objets réduits à `{id, name, color, createdAt, updatedAt}` (storage.ts:393-399). handleEdit remplit alors le formulaire avec des valeurs vides (`nocodbTableName: group.nocodbTableName || ""`, `address: (group as any).address || ""`, `smtpEnabled: Boolean(undefined)`, l.268-292), et handleSubmit envoie tous ces champs (l.326-330). PUT /api/groups/:id accepte tout manager, sur n'importe quel id (routes.ts:1070), et écrit ces valeurs vides.
+- **Impact :** Il suffit qu'un manager (qui peut ouvrir /groups par l'URL, même si le menu le réserve à l'admin, Sidebar.tsx:349) enregistre la fiche pour supprimer la configuration NocoDB, le webhook, l'adresse, le téléphone, le logo et désactiver le SMTP du magasin : perte de données silencieuse. Il peut aussi modifier ou supprimer des magasins qui ne sont pas les siens.
+- **Recommandation :** Aligner les droits : `canManage = user?.role === 'admin'` (comme le menu), et utiliser `requireAdmin` (server/permissions.ts:79) sur POST, PUT et DELETE /api/groups. Côté client, n'envoyer que les champs modifiés (comparer avec les valeurs initiales). Si les managers doivent garder un accès, vérifier côté serveur que l'id fait partie de leurs magasins.
+
+### GROUPS-02
+
+**GET /api/groups renvoie les logos base64 et toute la configuration à chaque page de l'application** — perf-api, sévérité haute, effort M
+
+- **Fichier :** `server/storage.ts:432`
+- **Constat :** storage.ts:432-434 `return await db.select().from(groups).orderBy(groups.name);` → inclut `logo: text("logo") // Logo en data URI` (schema.ts:65), ainsi que les colonnes SMTP et NocoDB. Groups.tsx:39 autorise jusqu'à `MAX_LOGO_KB = 200` (environ 270 Ko une fois encodé en base64). Cette requête est faite par Layout.tsx:49 sur toutes les pages et par une vingtaine de composants (Orders, Deliveries, modales…), qui n'utilisent que id, name et color. Aucune compression gzip n'est active (`setupCompression` dans server/cache.ts:93 n'est jamais appelé, et le paquet `compression` est absent de package.json).
+- **Impact :** Avec 10 magasins ayant un logo, environ 2,7 Mo de JSON non compressé sont téléchargés au chargement de l'app, puis à chaque invalidation (création ou modification de magasin, affectation d'utilisateur, USERS-06). Le premier affichage est nettement plus lent, surtout en 4G sur mobile.
+- **Recommandation :** Comme proposé : projection légère sans `logo` ni `smtpPassword` (en gardant webhookUrl, nocodb*, smtpEnabled, address, phone, avec `hasLogo` et `smtpPasswordSet` calculés), et GET /api/groups/:id complet chargé à l'ouverture de la modale de Groups.tsx. Étendre la même projection aux jointures `group: groups` de storage.ts (commandes, livraisons, publicités). Ajouter `compression()` après vérification du proxy.
+
+### GROUPS-05
+
+**Fenêtre de création/modification surchargée (environ 25 champs) et pleine de jargon technique** — ux-simplicite, sévérité haute, effort M
+
+- **Fichier :** `client/src/pages/Groups.tsx:508`
+- **Constat :** Groups.tsx:508 `<DialogContent className="sm:max-w-4xl max-h-[90vh] overflow-y-auto">` avec deux colonnes (l.519). On y trouve : nom, couleur (sélecteur natif + 10 pastilles + code hex, l.536-563), « Configuration NocoDB (Optionnel) » (l.571), « Mapping des colonnes » avec 6 noms de colonnes (l.611-677), « URL Webhook » (l.683), adresse, téléphone, logo, « Envoi de mails (SMTP) » (l.803), « Serveur SMTP », « Port », « Connexion SSL/TLS directe (port 465). Décoché = STARTTLS (port 587). » (l.851), identifiant, mot de passe, adresse et nom de l'expéditeur.
+- **Impact :** Pour créer un magasin, l'utilisateur fait face à un formulaire d'intégrateur. Les champs essentiels (nom, adresse, téléphone) sont noyés parmi des réglages techniques, ce qui cause des erreurs de saisie et décourage l'utilisation.
+- **Recommandation :** Découper en onglets ou sections repliables : « Informations » (nom, couleur en pastilles seules, adresse, téléphone, logo), ouvert par défaut ; « Envoi des e-mails » (avec préréglages Office 365 / Gmail qui remplissent serveur, port et sécurité) ; « Avancé : vérification des factures (NocoDB) et webhook », replié. Reformuler en langage courant (« Colonne n° de facture » plutôt que « Mapping des colonnes », « Sécurité : SSL / STARTTLS » avec une aide). À la création, ne demander que le nom et proposer de compléter ensuite.
+
+### GROUPS-14
+
+**POST /api/groups écrit le mot de passe SMTP en clair et le logo base64 dans les logs** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/routes.ts:1038`
+- **Constat :** routes.ts:1038 `console.log('✅ Group data validation passed:', data);`, où `data = insertGroupSchema.parse(req.body)` n'est pas masqué et contient `smtpPassword`. routes.ts:1001 `console.log('📋 POST /api/groups - Request body:', JSON.stringify(redactBody(req.body), null, 2))` : redactBody (l.9-16) masque le mot de passe mais pas `logo`, d'où jusqu'à environ 270 Ko de base64 par appel. Le handler contient une dizaine d'autres console.log (l.994-1042).
+- **Impact :** Le mot de passe de la boîte mail du magasin se retrouve en clair dans les logs serveur et Docker. Les logs grossissent fortement à chaque création.
+- **Recommandation :** Supprimer tous les console.log de debug du handler et garder un seul `console.error` en cas d'erreur, avec `redactBody` étendu à `logo` (remplacé par `[logo N Ko]`).
+
+### USERS-01
+
+**N+1 sur GET /api/users : 1 + 2N requêtes SQL à chaque chargement** — perf-serveur, sévérité haute, effort S
+
+- **Fichier :** `server/routes.ts:4280`
+- **Constat :** routes.ts:4276-4282 : `const baseUsers = await storage.getUsers(); const usersWithData = await Promise.all(baseUsers.map(async (baseUser) => { const userWithGroups = await storage.getUserWithGroups(baseUser.id);` ; storage.ts:371-373 : `async getUserWithGroups(id) { const user = await this.getUser(id); ... db.execute(sql`SELECT ... FROM user_groups ug INNER JOIN groups g ... WHERE ug.user_id = ${id}`)` → un SELECT users redondant (l'utilisateur est déjà dans baseUsers) + une jointure, par utilisateur. Il faut y ajouter getUserWithGroups pour l'appelant (l.4270) et le deserializeUser de passport (2 requêtes).
+- **Impact :** Pour 60 comptes : environ 125 requêtes SQL et autant d'allers-retours vers le pool à chaque affichage de la page Utilisateurs, à chaque mutation (invalidateQueries) et à chaque ouverture de la page Tâches (Tasks.tsx:386 appelle le même endpoint). Le temps de réponse croît linéairement avec le nombre d'utilisateurs.
+- **Recommandation :** Ajouter `getUsersWithGroups()` à IStorage, DatabaseStorage et MemStorage (2 requêtes : projection des users sans `password`, puis user_groups JOIN groups, regroupés dans une Map). Garder la forme `{...user, userGroups:[{userId, groupId, group:{id,name,color}}], userRoles:[]}`. Pas de changement côté client.
+
+### USERS-02
+
+**Hash des mots de passe renvoyé au navigateur (GET/POST/PUT /api/users), y compris aux managers** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:409`
+- **Constat :** storage.ts:409-411 : `async getUsers() { return await db.select().from(users); }` (la colonne `password` est définie en shared/schema.ts:40), puis routes.ts:4283 `return { ...baseUser, userGroups: ... }` → res.json(usersWithData). routes.ts:4356 `res.json(newUser)` et l.4431 `res.json(updatedUser)` renvoient aussi le hash. Seul le mot de passe SMTP est filtré (sanitize.ts:36). L'accès est ouvert à `['admin', 'directeur', 'manager']` (routes.ts:4271).
+- **Impact :** N'importe quel manager ou directeur peut lire dans l'onglet Réseau les hashs scrypt de tous les comptes, administrateurs compris, et tenter de les casser hors ligne. Le payload est aussi alourdi inutilement.
+- **Recommandation :** Correction mécanique et locale : ne plus renvoyer `password` dans les 3 routes, via la projection de USERS-01 pour GET et `const { password, ...safeUser } = newUser; res.json(safeUser)` (idem pour updatedUser) pour POST et PUT. Ne pas toucher au type de retour de storage.createUser/updateUser. Restreindre GET /api/users aux admins ou renvoyer une version réduite aux managers est une décision séparée (à traiter avec PERM-01). Tasks.tsx:385 peut aussi être supprimé, puisqu'il n'est pas utilisé.
+
+### USERS-03
+
+**Modale de modification : le bouton Assigner/Retirer ne se met pas à jour, ce qui crée des affectations en double** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:898`
+- **Constat :** Users.tsx:898 `const isAssigned = selectedUser?.userGroups?.some(ug => ug.groupId === group.id)`. `selectedUser` est un état copié à l'ouverture (l.450 `setSelectedUser(userWithNames)`) et n'est jamais remis à jour après assignGroupMutation, qui ne fait que `invalidateQueries(['/api/users'])` (l.243). Côté serveur, storage.ts:1210-1212 fait un INSERT simple, et la table n'a ni clé primaire ni contrainte d'unicité (shared/schema.ts:82-86 : `userGroups = pgTable("user_groups", { userId, groupId, createdAt })`).
+- **Impact :** Après un clic sur « Assigner », le bouton reste sur « Assigner ». L'utilisateur clique à nouveau et une 2e ligne identique est insérée. Le tableau affiche alors deux badges identiques (et React signale une clé dupliquée `key={userGroup.groupId}`, l.733). Pour retirer l'affectation, il faut fermer puis rouvrir la modale.
+- **Recommandation :** Ne stocker que `selectedUserId` et dériver l'utilisateur depuis la requête : `const selectedUser = users.find(u => u.id === selectedUserId)`. Côté BD, ajouter `primaryKey({ columns: [t.userId, t.groupId] })` (après dédoublonnage des lignes existantes) et utiliser `.onConflictDoNothing()` dans assignUserToGroup.
+
+### GROUPS-03
+
+**La réponse de /api/groups change selon le rôle : les non-admins reçoivent des magasins tronqués** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:982`
+- **Constat :** routes.ts:978-984 : l'admin reçoit `storage.getGroups()` (toutes les colonnes), les autres rôles `(user as any).userGroups?.map((ug: any) => ug.group)`, construit dans storage.ts:393-399 avec seulement id, name, color, createdAt et updatedAt. Or Avoirs.tsx:776-779 fait `const groups = await queryClient.fetchQuery({ queryKey: ['/api/groups'] }); … if (!group?.webhookUrl) { toast({ description: "Aucun webhook configuré pour ce magasin" })`.
+- **Impact :** Un directeur, qui a accès aux avoirs, voit « Aucun webhook configuré pour ce magasin » même si le webhook existe. C'est aussi la cause de la perte de données décrite en GROUPS-01.
+- **Recommandation :** Pour les non-admins, faire `db.select(<projection légère de GROUPS-02>).from(groups).where(inArray(groups.id, userGroupIds))` afin que tous les rôles reçoivent la même forme de données.
+
+### GROUPS-04
+
+**Chaque handler recharge l'utilisateur et ses magasins, déjà chargés par passport** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:972`
+- **Constat :** localAuth.production.ts:193-196 : `passport.deserializeUser(async (id) => { const user = await storage.getUserWithGroups(id); done(null, user); })` (2 requêtes à chaque appel API). Puis routes.ts:972 (GET /api/groups), 1487 (/api/stats/by-group), 4270 (GET /api/users), 4312, 4394, 4499, 5092 (/api/nocodb-config) refont `await storage.getUserWithGroups(...)` (2 requêtes de plus) juste pour lire `user.role`. Les middlewares `requireAdmin` et `requireModulePermission` de server/permissions.ts, qui lisent `req.user.role` sans requête, sont importés (routes.ts:5) mais jamais utilisés.
+- **Impact :** 4 requêtes SQL au lieu de 2 par appel API. Rien qu'à l'ouverture de la page Magasins, 3 appels donnent 12 requêtes, dont 6 inutiles.
+- **Recommandation :** Correction automatique limitée à remplacer `await storage.getUserWithGroups(req.user.claims ? req.user.claims.sub : req.user.id)` par `req.user` dans ces handlers, en gardant les tests `if (!user || ...)`. La réécriture de getUserWithGroups en LEFT JOIN + json_agg se fait séparément, en conservant exactement la forme `userGroups[{userId, groupId, group:{id,name,color,createdAt,updatedAt}}]`.
+
+### GROUPS-06
+
+**Le bouton « 🔍 Tester la configuration NocoDB » ne fait rien (TODO)** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Groups.tsx:704`
+- **Constat :** Groups.tsx:703-709 : `onClick={() => { // TODO: Implémenter le test de configuration\n toast({ title: "Test de configuration", description: "Fonctionnalité à implémenter" }); }}` avec l'aide « Vérifie que la table et les colonnes existent » (l.714).
+- **Impact :** L'interface promet une vérification qui n'existe pas. L'utilisateur croit que sa configuration est validée, ou perd confiance dans l'outil.
+- **Recommandation :** Retirer le bouton et son texte d'aide. Le branchement sur un vrai endpoint NocoDB est une évolution séparée, non automatique.
+
+### GROUPS-07
+
+**Le champ Webhook n'apparaît que si une configuration NocoDB est choisie** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Groups.tsx:680`
+- **Constat :** Groups.tsx:594 `{formData.nocodbConfigId && (<> … ` contient le bloc « Notifications / URL Webhook » (l.680-695). Le webhook est pourtant utilisé seul : BLReconciliation.tsx:564 `if (!selectedDeliveryForInvoice.group?.webhookUrl)` et Avoirs.tsx:779.
+- **Impact :** Un magasin sans NocoDB ne peut pas recevoir de webhook depuis l'interface (envoi de factures depuis le rapprochement ou les avoirs impossible). Si l'on retire la config NocoDB, l'URL reste enregistrée mais n'est plus visible ni modifiable.
+- **Recommandation :** Sortir le bloc Webhook de la condition `formData.nocodbConfigId` à sa position actuelle. Le déplacement vers une section « Avancé » dépend de GROUPS-05.
+
+### GROUPS-08
+
+**Test SMTP : erreur affichée en JSON brut, et test fait sur les valeurs enregistrées et non sur la saisie** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Groups.tsx:181`
+- **Constat :** Groups.tsx:178-182 `description: error?.message || "Impossible de joindre le serveur SMTP"`. apiRequest lève `Error(`${res.status}: ${text}`)` (queryClient.ts:6), d'où un toast « 400: {"success":false,"message":"Configuration incomplète : …"} ». Le test lit `storage.getGroup(id)` (routes.ts:1100), c'est-à-dire la configuration enregistrée et non les champs modifiés, et il n'est proposé qu'en modification (l.904).
+- **Impact :** Un message illisible pour un non-technicien. Après avoir corrigé le mot de passe, l'utilisateur relance le test, qui échoue encore puisqu'il porte sur l'ancienne configuration.
+- **Recommandation :** Analyser le message JSON (voir le helper ApiError de USERS-04). Accepter les champs du formulaire dans le corps de POST /test-smtp (en reprenant le mot de passe enregistré si le champ est vide), ou au minimum enregistrer puis tester, avec un libellé explicite « Enregistrer et tester ».
+
+### GROUPS-09
+
+**Suppression d'un magasin : contrôle fait seulement côté client, données orphelines** — bug, sévérité moyenne, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:1131`
+- **Constat :** Groups.tsx:299 `if (stats.orders > 0 || stats.deliveries > 0)` ne regarde que les commandes et livraisons, et seulement dans le navigateur. Le serveur, routes.ts:1131-1132 `await storage.deleteGroup(id);` puis storage.ts:462-463 `await db.delete(groups).where(eq(groups.id, id))`, ne vérifie rien. Aucune clé étrangère n'existe (init.sql : `"group_id" integer NOT NULL` sans REFERENCES), donc user_groups, DLC, tâches, avoirs, commandes client et SAV ne sont pas nettoyés.
+- **Impact :** Un magasin qui n'a que des DLC, tâches ou avoirs peut être supprimé, ce qui laisse des enregistrements orphelins (affichés sans magasin ou en erreur). Un appel API direct contourne le contrôle.
+- **Recommandation :** Côté serveur : dans une transaction, supprimer les lignes user_groups du magasin, puis le magasin. Intercepter l'erreur `23503` pour renvoyer un 409 avec un message clair (« Ce magasin a encore des commandes, livraisons, DLC, tâches ou avoirs »), avec éventuellement un comptage préalable pour détailler. Côté client : afficher ce message (helper de USERS-04).
+
+### GROUPS-11
+
+**La page Magasins parle de « Groupes »** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Groups.tsx:358`
+- **Constat :** Sidebar.tsx:347 `label: "Magasins"`, mais Groups.tsx:358 « Gestion des Groupes/Magasins », l.361 « N groupes », l.370 « Nouveau Groupe », l.381 « Rechercher un groupe... », l.399 « Aucun groupe », l.107 « Groupe créé avec succès », l.523 « Nom du groupe * », l.511 « Modifier Groupe ».
+- **Impact :** Deux mots pour la même chose dans le même écran, alors que les utilisateurs pensent en « magasins ».
+- **Recommandation :** Remplacer partout dans l'interface par « Magasin » : « Magasins », « Nouveau magasin », « Rechercher un magasin… », « Magasin créé », « Nom du magasin ».
+
+### GROUPS-13
+
+**Un clic hors de la fenêtre ou la touche Échap efface toute la saisie sans avertir** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Groups.tsx:502`
+- **Constat :** Groups.tsx:502-507 : `onOpenChange={() => { setShowCreateModal(false); setShowEditModal(false); setSelectedGroup(null); setFormData({ ...EMPTY_GROUP_FORM, invoiceColumnName: "Ref Facture" }); }}`. Le formulaire est réinitialisé (avec une valeur par défaut « Ref Facture » qui diffère de celle du bouton Annuler, l.937).
+- **Impact :** Après avoir rempli 20 champs, un clic à côté de la fenêtre fait tout perdre.
+- **Recommandation :** Si le formulaire a été modifié, demander « Abandonner les modifications ? » avant de fermer (ou bloquer la fermeture par clic extérieur avec `onInteractOutside={e => isDirty && e.preventDefault()}`). Utiliser une seule fonction de réinitialisation.
+
+### PERF-BUNDLE-01
+
+**Pages d'administration (Utilisateurs, Magasins…) chargées par tous les utilisateurs** — perf-bundle, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:12`
+- **Constat :** RouterProduction.tsx:7-30 : `import Groups from "@/pages/Groups"; import Users from "@/pages/Users"; import NocoDBConfig …; import DatabaseDebug …; import BackupManager …` en imports statiques. Aucun `lazy(` dans client/src (grep). vite.config.ts:41-46 ne sépare que les dépendances (vendor-*).
+- **Impact :** Un employé en magasin télécharge et analyse le code des pages d'administration (plus de 2 100 lignes pour Users et Groups seulement, plus DatabaseDebug, SQLExecutor, etc.) qu'il n'ouvrira jamais, ce qui ralentit le premier affichage, surtout sur mobile.
+- **Recommandation :** Supprimer les imports inutilisés NocoDBConfig, DatabaseDebug, BackupManager et WeatherSettings de RouterProduction.tsx. Passer en `lazy(() => import(...))` Users, Groups, Utilities, Analytics et PaymentSchedulePage. Entourer les deux `<Switch>` (mobile et desktop) d'un `<Suspense>` placé à l'intérieur de Layout/MobileApp, avec un fallback simple construit à partir de `ui/skeleton`.
+
+### PERM-01
+
+**Deux matrices de permissions divergentes (client et shared), sans module Utilisateurs ni Magasins** — dette-code, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/lib/permissions.ts:42`
+- **Constat :** client/src/lib/permissions.ts:42 `orders: { … employee: ['view'] }` contre shared/permissions.ts:41 `employee: []`. Livraisons : client l.50 `employee: ['view']`, sans 'validate', contre shared l.49 `employee: []` avec 'validate'. Tâches : client l.89 `manager: ['view', 'validate']` contre shared l.88 `manager: ['view', 'create', 'edit', 'validate']`. Calendar.tsx:267, QuickCreateMenu.tsx:22 et OrderDetailModal.tsx:165 utilisent la version client, alors que Orders.tsx, Deliveries.tsx et le serveur (routes.ts:147) utilisent shared. Les droits Utilisateurs et Magasins sont codés en dur et diffèrent : Users.tsx:568 (admin), Groups.tsx:348 (admin|manager), Sidebar.tsx:337/349 (admin), routes.ts:4271 (admin|directeur|manager), routes.ts:1027/1070 (admin|manager).
+- **Impact :** Des boutons visibles mènent à des 403 (un employé voit des actions de commande dans le calendrier que le serveur refuse) et les règles d'accès aux pages d'administration sont contradictoires (voir GROUPS-01).
+- **Recommandation :** Avant de supprimer client/src/lib/permissions.ts, ajouter dans shared/permissions.ts les modules `backups` (action `manage`), `admin`, `users` et `stores`. Valider avec le produit les divergences (employé : vue commandes/livraisons ; manager : tâches create/edit). Ensuite seulement, réexporter shared côté client et brancher `requireModulePermission` côté serveur.
+
+### USERS-04
+
+**Les messages d'erreur précis du serveur ne sont jamais affichés** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:216`
+- **Constat :** Users.tsx:178, 216, 262, 307 : `const errorMessage = error?.response?.data?.message || "Impossible de créer l'utilisateur"`. Or apiRequest (queryClient.ts:3-7) lève `new Error(`${res.status}: ${text}`)`, qui n'a aucune propriété `response`. Le serveur renvoie pourtant des messages clairs : routes.ts:4372 « Un utilisateur avec ce nom d'utilisateur existe déjà. Veuillez choisir un autre nom d'utilisateur. »
+- **Impact :** Si l'identifiant ou l'e-mail existe déjà, l'administrateur ne voit que « Impossible de créer l'utilisateur » et ne sait pas quoi corriger.
+- **Recommandation :** Sans changer le format de l'erreur levée, ajouter dans queryClient.ts un helper `getApiErrorMessage(error, fallback)` : il extrait le texte après `^\d{3}: `, tente `JSON.parse(...).message` et renvoie fallback en cas d'échec. L'utiliser dans les 4 onError de Users.tsx (et dans le test SMTP de Groups.tsx, cf. GROUPS-08). Une éventuelle classe ApiError avec `status` devra garder `message` au format `${status}: ${text}` ou s'accompagner d'une migration de queryClient.ts:81, useAuthUnified.ts:32, useAuth.ts:8 et authUtils.ts vers `error.status === 401`.
+
+### USERS-05
+
+**Création avec magasins : N appels séparés, N toasts, 2N rechargements et opération non atomique** — perf-api, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Users.tsx:411`
+- **Constat :** Users.tsx:407-415 : `const createdUser = await createUserMutation.mutateAsync(newUser); ... await Promise.all(userGroups.map(groupId => assignGroupMutation.mutateAsync({ userId: createdUser.id, groupId })))`. Chaque assignGroupMutation.onSuccess (l.236-246) affiche un toast « Utilisateur assigné au groupe avec succès » et invalide ['/api/users'] et ['/api/groups'], puis l.418 un toast final et l.426 une nouvelle invalidation.
+- **Impact :** Pour 3 magasins : 4 POST, 4 toasts superposés et jusqu'à 7 rechargements de /api/users (chacun en N+1, voir USERS-01) et de /api/groups (avec les logos). Si une affectation échoue, le compte est créé mais la modale reste ouverte. Un nouveau clic sur « Créer » renvoie alors 409 (identifiant déjà pris) avec un message générique.
+- **Recommandation :** Accepter `groupIds: number[]` dans POST /api/users et faire l'insertion user + user_groups dans une transaction `db.transaction`. Côté client : un seul appel, un seul toast, une seule invalidation de ['/api/users'].
+
+### USERS-06
+
+**Invalidation inutile de /api/groups après chaque affectation** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:245`
+- **Constat :** Users.tsx:243-245 et 288-290 : `queryClient.invalidateQueries({ queryKey: ['/api/users'] }); queryClient.invalidateQueries({ queryKey: ['/api/groups'] });`. Pour un admin, /api/groups renvoie tous les magasins (routes.ts:978-980), donc la liste ne dépend pas des affectations. Le changement de rôle (l.96) recharge aussi toute la liste.
+- **Impact :** Chaque clic Assigner/Retirer recharge la liste des magasins avec tous les logos base64 (voir GROUPS-02), utilisée par Layout, en plus du N+1 de /api/users.
+- **Recommandation :** Supprimer seulement `queryClient.invalidateQueries({ queryKey: ['/api/groups'] })` dans assignGroupMutation et removeGroupMutation. Garder l'invalidation de ['/api/users'], qui devient peu coûteuse après USERS-01. La mise à jour optimiste par setQueryData est à traiter à part.
+
+### USERS-07
+
+**Magasins enregistrés tout de suite dans la modale, contrairement aux autres champs (« Annuler » ne les annule pas)** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Users.tsx:893`
+- **Constat :** Users.tsx:908-916 : le bouton `onClick={() => handleToggleGroupInEdit(group.id, isAssigned)}` appelle l'API immédiatement (l.465-477), alors que nom, e-mail, rôle et mot de passe ne partent qu'au clic « Mettre à jour » (l.479-500). Le bouton « Annuler » (l.927-936) ferme sans revenir en arrière. La création utilise des cases à cocher (l.1052) : deux interfaces différentes pour la même donnée. La liste est limitée à `max-h-32` (128 px, environ 3 magasins visibles).
+- **Impact :** Un utilisateur non technicien pense que « Annuler » annule tout, alors que les magasins ont déjà été modifiés. Une même action se fait de deux façons différentes selon qu'on crée ou qu'on modifie.
+- **Recommandation :** Utiliser les mêmes cases à cocher qu'à la création, garder la sélection dans l'état du formulaire et l'envoyer avec « Enregistrer » (PUT /api/users/:id avec `groupIds`, différence calculée côté serveur dans une transaction). Agrandir la liste (max-h-60).
+
+### USERS-08
+
+**Le rôle « Directeur » manque dans le filtre et dans le formulaire de création** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:631`
+- **Constat :** Filtre, Users.tsx:631-634 : `<SelectItem value="all">…<SelectItem value="admin">…<SelectItem value="manager">…<SelectItem value="employee">` (pas de directeur). Création, l.1040-1042 : uniquement employee/manager/admin. Le sélecteur rapide (l.763) et la modale de modification (l.886) proposent pourtant « Directeur », et le serveur l'accepte (routes.ts:4325).
+- **Impact :** Impossible de lister les directeurs. Pour créer un directeur, il faut créer un compte avec un autre rôle puis le modifier, ce qui déclenche une 2e confirmation.
+- **Recommandation :** Ajouter dans roleUtils.ts un tableau ordonné `ROLE_OPTIONS = ['admin','directeur','manager','employee'].map(v => ({ value: v, label: ROLE_DISPLAY_NAMES[v] }))` et l'utiliser pour le filtre, la création, la modification et le sélecteur rapide. Élargir le type du onValueChange de création à `'directeur'`.
+
+### USERS-09
+
+**Le tableau affiche un ID technique au lieu de l'identifiant de connexion, qui n'est pas non plus cherchable** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:712`
+- **Constat :** Users.tsx:711-713 : `<div className="text-sm text-gray-500">ID: {userData.id}</div>` (valeurs du type `manual_1712345678_k3j2h1g0f` ou `jdupont_1712345678`, routes.ts:4343). La recherche (l.348-350) ne porte que sur firstName, lastName et email, pas sur `username`, alors que c'est le seul champ obligatoire et celui utilisé pour se connecter.
+- **Impact :** L'administrateur ne voit pas l'identifiant qu'il doit donner à l'employé et ne peut pas retrouver « ff0292 ». Les comptes sans prénom ni nom (champs facultatifs) apparaissent comme « Nom non renseigné » sans autre repère lisible.
+- **Recommandation :** Remplacer « ID: … » par « Identifiant : {username} ». Ajouter `u.username` à la recherche (placeholder « Nom, identifiant ou e-mail… »). Calculer `searchTerm.toLowerCase()` une seule fois dans un useMemo.
+
+### USERS-10
+
+**La confirmation de changement de rôle affiche le code anglais et ne dit pas de qui il s'agit** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:516`
+- **Constat :** Users.tsx:513-517 : `setPendingRoleChange({ userId, newRoleName, newRoleDisplay: newRoleName })`, puis l.1124 `vers <span>{pendingRoleChange.newRoleDisplay}</span>` → « …changer le rôle de cet utilisateur vers employee ». l.529 : la modale se ferme dès le `mutate`, donc le libellé « Modification... » (l.1147) n'est jamais visible.
+- **Impact :** Le texte mélange anglais et français et ne nomme ni l'utilisateur ni l'ancien rôle. Le risque d'erreur augmente sur une action sensible.
+- **Recommandation :** `newRoleDisplay: getRoleDisplayName(newRoleName)`. Ajouter l'utilisateur (`users.find(u => u.id === userId)`) et l'ancien rôle dans l'état et le texte. Fermer la modale via `updateUserRoleMutation.mutate(vars, { onSuccess: () => { setShowRoleConfirmModal(false); setPendingRoleChange(null); } })` et la laisser ouverte en cas d'erreur (le toast d'erreur existe déjà).
+
+### USERS-11
+
+**Deux réglages du rôle avec des règles différentes : la modale permet de modifier son propre rôle sans confirmation** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:877`
+- **Constat :** Le sélecteur rapide bloque son propre compte (Users.tsx:503 `if (userId === user?.id)` et l.752 `userData.id !== user?.id`) et demande une confirmation. La modale de modification (l.877-890) envoie `role: editForm.role` (l.488) sans confirmation ni contrôle. Côté serveur, PUT /api/users/:id (routes.ts:4392-4431) ne bloque ni l'auto-rétrogradation ni le retrait du dernier administrateur.
+- **Impact :** Un admin peut se retirer ses propres droits par erreur depuis sa fiche et perdre l'accès à l'administration. La même donnée s'affiche 3 fois par ligne ou modale (badge, sélecteur rapide, sélecteur de la modale).
+- **Recommandation :** Garder un seul point d'édition du rôle (la modale, avec la même confirmation), retirer le sélecteur rapide de la colonne Actions, et ajouter côté serveur : refus si `req.params.id === user.id && role !== user.role`, et refus si cela retire le dernier admin.
+
+### USERS-14
+
+**Mobile : tableau coupé, la colonne Actions devient inaccessible** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:658`
+- **Constat :** La route /users est servie telle quelle dans MobileApp (RouterProduction.tsx:120). Users.tsx:658 `<div className="bg-white border … overflow-hidden">` contient un `<table className="w-full">` de 5 colonnes en `whitespace-nowrap` (l.683, 717, 720, 726, 749). Le contenu qui dépasse est masqué au lieu de défiler.
+- **Impact :** Sur téléphone, les boutons Modifier et Supprimer ainsi que le sélecteur de rôle sont hors de l'écran et inutilisables.
+- **Recommandation :** Correction automatique limitée à remplacer `overflow-hidden` par `overflow-x-auto` (Users.tsx:658). La version en cartes sous `md` est une évolution d'interface à faire séparément (non automatique).
+
+### USERS-17
+
+**Vocabulaire incohérent « Groupes » / « Magasins » sur la page Utilisateurs** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:673`
+- **Constat :** Users.tsx:673 en-tête de colonne « Groupes », l.729 « Aucun groupe », l.895 « Magasins/Groupes », l.1048 « Magasins assignés », l.240 toast « assigné au groupe », l.420 « assigné à N magasin(s) », l.921 « Aucun groupe disponible ». Le menu dit « Magasins » (Sidebar.tsx:347).
+- **Impact :** L'utilisateur final ne sait pas si un « groupe » et un « magasin » sont la même chose.
+- **Recommandation :** Utiliser « Magasin(s) » partout dans l'interface (« Magasins », « Aucun magasin », « Affecté au magasin X »). Garder « group » uniquement dans le code.
+
+### GROUPS-10
+
+**Cartes magasin : informations techniques inutiles, état de configuration absent** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Groups.tsx:433`
+- **Constat :** Groups.tsx:433 `<p className="text-sm text-gray-500">#{group.id}</p>` et l.457-466, une ligne entière avec l'icône Palette et le code `{group.color}` (« #1976D2 »), la couleur étant déjà visible dans le carré d'en-tête (l.425-430). L'icône `Users` (personnes) sert à représenter un magasin (l.357, 429).
+- **Impact :** Du bruit visuel sans valeur pour un employé ou un manager. On ne voit pas les informations utiles : nombre d'utilisateurs, envoi de mails configuré ou non, factures reliées ou non.
+- **Recommandation :** Supprimer l'id et la ligne couleur/hex. Utiliser l'icône `Store` de lucide. Ajouter des badges d'état (« Mails : configurés / à configurer », « Factures NocoDB : reliées », « 3 utilisateurs ») à partir des champs légers de GROUPS-02.
+
+### GROUPS-12
+
+**Configs NocoDB chargées au montage sans condition (403 relancé 2 fois pour un manager)** — perf-client, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Groups.tsx:84`
+- **Constat :** Groups.tsx:84-86 `useQuery<NocodbConfig[]>({ queryKey: ['/api/nocodb-config'] })` sans `enabled`. Le serveur répond 403 aux non-admins (routes.ts:5093-5094), et la politique `retry: failureCount < 2` (queryClient.ts:84) relance la requête 2 fois.
+- **Impact :** Une requête (avec déchiffrement des jetons côté serveur, storage.ts:1657) à chaque ouverture de la page, même si la modale n'est jamais ouverte, et 3 requêtes en erreur pour un manager.
+- **Recommandation :** `enabled: user?.role === 'admin', staleTime: 5 * 60 * 1000`. La condition sur l'ouverture de la modale est facultative.
+
+### GROUPS-15
+
+**Composants natifs et emojis mélangés aux composants shadcn et aux icônes lucide** — coherence-design, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Groups.tsx:579`
+- **Constat :** Groups.tsx:579 `<select id="nocodbConfig" … className="w-full mt-1 p-2 border …">` natif, alors que Users.tsx utilise `Select` shadcn. Groups.tsx:806 et 845 : `<input type="checkbox">` natifs, alors que Users.tsx:1052 utilise `Checkbox`. Emojis dans les boutons : l.711 « 🔍 Tester… », l.915 « ✉️ Tester la connexion SMTP ». Triple sélecteur de couleur (carré + `<Input type="color">` + code hex + 10 pastilles, l.536-563).
+- **Impact :** Rendu et comportement clavier différents d'une page à l'autre (et en mode sombre). L'interface paraît moins soignée et la page est plus chargée.
+- **Recommandation :** Utiliser `Select`, `Switch` (pour « Activé ») et `Checkbox` de shadcn, des icônes lucide (`Search`, `Mail`) à la place des emojis, et ne garder que les 10 pastilles pour la couleur.
+
+### GROUPS-16
+
+**Grilles du formulaire non adaptées au mobile** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Groups.tsx:616`
+- **Constat :** Groups.tsx:616 `<div className="grid grid-cols-2 gap-4">` (6 champs de colonnes NocoDB), l.822 `grid grid-cols-3 gap-3` (serveur/port), l.854 et 882 `grid grid-cols-2`. La route /groups est servie telle quelle sur mobile (RouterProduction.tsx:119). L'en-tête (l.354) `flex items-center justify-between` ne passe pas à la ligne alors qu'il contient un titre en text-2xl et un bouton.
+- **Impact :** Sur téléphone, champs très étroits et libellés tronqués (« Colonne Montant TTC », « Adresse expéditeur * »), titre et bouton serrés.
+- **Recommandation :** `grid-cols-1 sm:grid-cols-2` (l.616, 854, 882), `grid-cols-1 sm:grid-cols-3` avec `sm:col-span-2` (l.822-823), et `flex flex-wrap gap-3` sur les en-têtes Groups.tsx:354 et Users.tsx:590.
+
+### PERM-02
+
+**Middleware global qui recopie récursivement toutes les réponses JSON pour masquer smtpPassword** — perf-serveur, sévérité basse, effort M
+
+- **Fichier :** `server/routes.ts:168`
+- **Constat :** routes.ts:166-170 : `app.use('/api', (req, res, next) => { … res.json = (body) => originalJson(stripSmtpPassword(body)); })`. sanitize.ts:13-43 parcourt chaque objet jusqu'à 8 niveaux et recrée un nouvel objet pour chacun (`const result = {}; for (const [key, entry] of Object.entries(value))`), sur toutes les réponses API (livraisons, commandes, etc.), même sans aucun magasin.
+- **Impact :** Coût CPU et mémoire proportionnel à la taille de chaque réponse, sur toutes les routes, pour protéger un seul champ.
+- **Recommandation :** D'abord remplacer `group: groups` dans toutes les jointures de storage.ts, ainsi que getGroups/getGroup, par une projection sans `smtpPassword` (ni `logo`), avec `smtpPasswordSet`. Réserver la lecture du mot de passe à emailService via une méthode dédiée (ex. `getGroupSmtpCredentials`). Ne supprimer le middleware qu'ensuite, et ne jamais le restreindre à /api/groups tant qu'une jointure peut encore renvoyer le champ.
+
+### USERS-12
+
+**Délai artificiel de 1 seconde avant la fermeture de la modale après enregistrement** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:159`
+- **Constat :** Users.tsx:158-162 : `// Delay modal close to show the updated data\n setTimeout(() => { setShowEditModal(false); setSelectedUser(null); }, 1000);`
+- **Impact :** La modale reste ouverte une seconde de plus à chaque modification. Le bouton « Mettre à jour » redevient cliquable pendant ce temps, ce qui permet un double envoi.
+- **Recommandation :** Fermer la modale immédiatement dans onSuccess : le toast suffit à confirmer l'enregistrement. Supprimer le setEditForm de la réponse (l.143-150), qui ne sert plus.
+
+### USERS-13
+
+**Confirmations incohérentes : window.confirm natif pour supprimer, Dialog pour le rôle, AlertDialog ailleurs** — coherence-design, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:558`
+- **Constat :** Users.tsx:558 `if (window.confirm(`Êtes-vous sûr de vouloir supprimer l'utilisateur ${userToDelete.firstName} ${userToDelete.lastName} ?…`))`, Groups.tsx:308 `window.confirm(...)`, contre un Dialog personnalisé pour le rôle (Users.tsx:1104) et un AlertDialog shadcn dans Avoirs.tsx:1603 et DlcPage.tsx:1139.
+- **Impact :** La boîte native du navigateur casse l'identité visuelle. Pour un compte sans prénom ni nom (champs facultatifs), le message devient « supprimer l'utilisateur   ? ».
+- **Recommandation :** Créer un composant `ConfirmDialog` (AlertDialog shadcn, bouton rouge « Supprimer ») et l'utiliser pour toutes les suppressions, avec le nom affiché ou à défaut l'identifiant (`username`).
+
+### USERS-15
+
+**console.log de debug dans les mutations des deux pages** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:227`
+- **Constat :** Users.tsx:227 `console.log('📤 Assigning group:', data)`, l.233, 237, 248, 273, 278, 282, 293 ; Groups.tsx:99 `console.log('🏪 Frontend: Creating group with data:', data)`, qui affiche le mot de passe SMTP saisi et le logo base64, et l.101.
+- **Impact :** Console polluée en production. Le mot de passe SMTP en clair est visible dans la console du navigateur.
+- **Recommandation :** Supprimer ces console.log, ou les placer derrière `if (import.meta.env.DEV)` comme dans apiRequest.
+
+### USERS-16
+
+**Code mort : gestion 401 jamais déclenchée (répétée 8 fois), états et fonctions inutilisés** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:100`
+- **Constat :** isUnauthorizedError teste `/^401: .*Unauthorized/` (authUtils.ts:2) alors que le serveur répond « Authentification requise » (localAuth.ts:252). Le bloc ne se déclenche donc jamais et redirigerait vers `/api/login` en GET, route qui n'existe pas (seul POST, localAuth.production.ts:203). Il est copié dans 5 mutations de Users.tsx (l.100, 165, 203, 249, 294) et 3 de Groups.tsx (l.114, 148, 226). Inutilisés : `usePermissions` (Users.tsx:15), `showRoleModal`/`selectedUserForRole` (l.42-43), `safeUsers` (l.84), `handleToggleGroup` (l.540-546), commentaire obsolète « Gestion des Rôles » (l.538).
+- **Impact :** Environ 120 lignes sans effet qui rendent les pages difficiles à maintenir. Le 401 est déjà géré globalement (queryClient.ts:57-62).
+- **Recommandation :** Supprimer ces blocs et créer un helper `onApiError(toast, fallback)` partagé. Supprimer les états, imports et fonctions inutilisés.
+
+### USERS-18
+
+**Le texte d'aide « Minimum 6 caractères » n'est vérifié nulle part** — bug, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:870`
+- **Constat :** Users.tsx:869-871 : « Minimum 6 caractères. Laissez vide pour conserver le mot de passe actuel. » Côté client, handleSubmitEdit ne vérifie rien (l.492). Côté serveur : création `password: z.string().min(1, …)` (routes.ts:4323), modification `password: z.string().optional()` (l.4405).
+- **Impact :** Un mot de passe d'un seul caractère est accepté alors que l'interface annonce le contraire.
+- **Recommandation :** Choisir une règle unique (par exemple 6 caractères minimum), l'appliquer dans les deux schémas zod côté serveur et vérifier côté client avec un message sous le champ, dans la création comme dans la modification.
+
+### USERS-19
+
+**La clé primaire est générée côté client à partir de l'e-mail (« _1712… » si e-mail vide)** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:191`
+- **Constat :** Users.tsx:189-192 : `id: userData.email.split('@')[0] + '_' + Date.now(), // Simple ID generation`, alors que le serveur sait déjà générer un id (routes.ts:4343 `userData.id || `manual_${Date.now()}_…``). Les lignes 195-197 sont aussi redondantes (`payload.password` est déjà dans `...userData`).
+- **Impact :** Identifiants techniques peu lisibles (`_1712345678901` quand l'e-mail est vide), affichés dans le tableau (voir USERS-09). Le client choisit la clé primaire.
+- **Recommandation :** Ne plus envoyer `id` depuis le client, retirer `id` du createUserSchema côté serveur et laisser le serveur générer un UUID (`crypto.randomUUID()`).
+
+### USERS-20
+
+**Aucune explication de ce que permet chaque rôle** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:1029`
+- **Constat :** Les sélecteurs de rôle (Users.tsx:1029-1044, 875-891, 753-767) ne montrent que les libellés « Administrateur / Directeur / Manager / Employé ». Les droits réels sont dans shared/permissions.ts (par ex. rapprochement : directeur oui, manager non, l.53-58 ; avoirs : manager création seule, l.94-99).
+- **Impact :** Un administrateur non technicien choisit un rôle sans savoir ce que la personne pourra faire, d'où des erreurs d'attribution et des demandes de support.
+- **Recommandation :** Ajouter sous chaque option une ligne de description (« Manager : commandes, livraisons, DLC ; pas de rapprochement ni de suppression »), générée depuis shared/permissions.ts ou écrite dans roleUtils.ts.
+
+### USERS-21
+
+**Suppression d'un utilisateur : boucle d'await séquentielle sans transaction** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:4514`
+- **Constat :** routes.ts:4512-4521 : `const userWithGroups = await storage.getUserWithGroups(userToDelete); if (userWithGroups) { for (const userGroup of userWithGroups.userGroups) { await storage.removeUserFromGroup(userToDelete, userGroup.groupId); } } await storage.deleteUser(userToDelete);`
+- **Impact :** 2 + N + 1 requêtes à la suite. En cas d'erreur au milieu, l'utilisateur reste en base mais n'est plus dans certains magasins.
+- **Recommandation :** `await db.transaction(async tx => { await tx.delete(userGroups).where(eq(userGroups.userId, id)); await tx.delete(users).where(eq(users.id, id)); })`, à encapsuler dans storage.deleteUser.
+
+### USERS-22
+
+**Routes en double pour l'affectation utilisateur ↔ magasin (la 2e n'est jamais atteinte)** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:4461`
+- **Constat :** routes.ts:4228 `app.post('/api/users/:userId/groups', …)` et routes.ts:4461 `app.post('/api/users/:id/groups', …)`. Même chose pour DELETE en l.4249 et l.4481. Express exécute la première route enregistrée, qui envoie la réponse : les secondes sont du code mort.
+- **Impact :** Confusion à la maintenance : une correction faite dans la 2e version n'aurait aucun effet.
+- **Recommandation :** Supprimer les routes des lignes 4461-4495.
+
+### USERS-23
+
+**Boutons à icône seule sans libellé accessible** — accessibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:779`
+- **Constat :** Users.tsx:779-787 : bouton Supprimer `<Button …><Trash2 className="w-4 h-4" /></Button>` sans `title` ni `aria-label` (Modifier a un `title`, l.773). Le sélecteur rapide de rôle (l.758) n'a pas d'aria-label. Groups.tsx:438-452 : boutons Modifier et Supprimer des cartes sans libellé. Groups.tsx:552-561 : pastilles de couleur avec seulement `title`, sans `aria-pressed` pour la couleur choisie.
+- **Impact :** Les lecteurs d'écran annoncent « bouton » sans contexte, et rien au survol ne dit ce que fait la poubelle.
+- **Recommandation :** Ajouter `aria-label="Supprimer {nom}"` / `aria-label="Modifier {nom}"` et un `title` équivalent, plus `aria-pressed={formData.color === option.value}` sur les pastilles.
+
+### USERS-24
+
+**Chargement affiché par un spinner central au lieu d'un squelette de la liste** — coherence-design, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Users.tsx:642`
+- **Constat :** Users.tsx:642-645 et Groups.tsx:391-394 : `<div className="animate-spin rounded-full h-12 w-12 border-b-2 border-primary"></div>` dans un bloc `h-64`.
+- **Impact :** La page change de forme à l'arrivée des données et le chargement semble plus long, surtout que /api/users est lent (USERS-01).
+- **Recommandation :** Afficher 5 lignes `Skeleton` (shadcn) avec la même structure que le tableau ou les cartes.

docs/audit-webui/11-suppliers-contacts-analytics.md

@@ -0,0 +1,690 @@
+# Fournisseurs, Contacts, Statistiques
+
+_56 constats vérifiés — 11 haute, 24 moyenne, 21 basse._
+
+## Pages analysées
+
+### `/suppliers`
+
+**Rôle :** Référentiel des fournisseurs (nom, contact, téléphone, email, code ffnancy, mode de paiement, options DLC / rapprochement auto / contrôle) avec un compteur de commandes et livraisons par fournisseur. Menu visible uniquement pour l'admin.
+
+**Tâches principales de l'utilisateur :**
+- Rechercher un fournisseur par nom
+- Consulter ses coordonnées et options
+- Créer / modifier un fournisseur (admin)
+- Supprimer un fournisseur (admin)
+- Voir le volume de commandes/livraisons d'un fournisseur
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/suppliers | au montage (queryKey ['/api/suppliers'], queryFn par défaut, staleTime global 30 s) | server/routes.ts:1141 -> storage.getSuppliers() server/storage.ts:467 | Re-lit l'utilisateur en base (storage.getUser, routes.ts:1143) alors que deserializeUser l'a déjà chargé ; filtre ?dlc fait en JS (routes.ts:1151). Liste complète sans pagination (acceptable, table petite). |
+| GET /api/stats/by-supplier | au montage, en parallèle | server/routes.ts:1504 -> storage.getOrderDeliveryStatsBySupplier() server/storage.ts:1842 | Agrégat SQL GROUP BY déjà optimisé (Promise.all) ; n'envoie pas storeId : ignore le magasin sélectionné dans l'en-tête ; totaux « depuis toujours ». |
+| POST /api/suppliers | clic « Créer » dans la modale | server/routes.ts:1165 -> storage.createSupplier() server/storage.ts:471 | ~12 console.log dont JSON.stringify du body à chaque création (logs serveur non retirés en prod). Erreur Zod 400 non exploitée côté client. |
+| PUT /api/suppliers/:id | clic « Modifier » (mise à jour optimiste) | server/routes.ts:1239 -> storage.updateSupplier() server/storage.ts:476 | Autorise admin+manager+directeur alors que l'UI réserve à l'admin ; ZodError renvoyée en 500. Double invalidation onSuccess+onSettled. |
+| DELETE /api/suppliers/:id | clic corbeille + confirm() natif | server/routes.ts:1256 -> storage.deleteSupplier() server/storage.ts:485 | Échoue (FK orders/deliveries ON DELETE NO ACTION, init.sql:446-455) dès qu'il existe une commande : message générique « Impossible de supprimer ». |
+
+**Lisibilité / simplicité :** Grille de cartes très « lourdes » (shadow-lg, icône, #id technique) peu adaptée à 100+ fournisseurs : pas de tri, pas de filtre par option (DLC, contrôle), recherche sur le nom seulement. Le code ffnancy est saisi mais jamais affiché, libellé jargon « Code fournisseur API (liaison ffnancy) ». Bon skeleton de chargement mais aucun état d'erreur (une panne affiche « Commencez par créer votre premier fournisseur »). Doublon fonctionnel avec la colonne Fournisseurs de la page Contacts (mêmes coordonnées, édition possible aux deux endroits avec des droits différents). Suppression impossible dès qu'il y a de l'historique, sans explication. Boutons icône sans libellé accessible. Page rendue sans MobileLayout sur mobile.
+
+### `/contacts`
+
+**Rôle :** Annuaire téléphonique : coordonnées des fournisseurs (globales) et contacts libres rattachés à un magasin (dépanneurs, commerciaux, etc.), avec liens tel:/mailto:.
+
+**Tâches principales de l'utilisateur :**
+- Trouver rapidement le téléphone/email d'un fournisseur
+- Trouver un contact du magasin
+- Ajouter / modifier / supprimer un contact (admin, directeur, manager)
+- Mettre à jour les coordonnées d'un fournisseur (admin, directeur)
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/suppliers | au montage (même clé que les autres pages, cache partagé) | server/routes.ts:1141 -> storage.getSuppliers() server/storage.ts:467 | Liste globale complète affichée en premier ; aucun état de chargement. |
+| GET /api/contacts?groupId=X (ou /api/contacts) | au montage et à chaque changement de magasin ; queryFn manuelle via apiRequest, sans enabled | server/routes.ts:1273 -> storage.getContacts(groupIds) server/storage.ts:490 | Pour un non-admin le paramètre groupId est ignoré (tous ses magasins) ; si l'utilisateur n'a aucun magasin, groupIds=[] et getContacts renvoie TOUS les contacts. Clé de cache '/api/contacts?groupId=X' non invalidée par les mutations. |
+| POST /api/contacts | clic « Créer » | server/routes.ts:1293 -> storage.createContact() server/storage.ts:497 | Aucun contrôle que groupId appartient aux magasins de l'utilisateur. |
+| PUT /api/contacts/:id | clic « Modifier » | server/routes.ts:1311 -> storage.updateContact() server/storage.ts:502 | Aucun contrôle d'appartenance du contact ; ZodError -> 500 ; le client écrase groupId par le magasin sélectionné. |
+| DELETE /api/contacts/:id | clic corbeille + confirm() | server/routes.ts:1327 -> storage.deleteContact() server/storage.ts:511 | Aucun contrôle d'appartenance : un manager peut supprimer le contact d'un autre magasin par son id. |
+| PUT /api/suppliers/:id | modale « Coordonnées — fournisseur » | server/routes.ts:1239 -> storage.updateSupplier() server/storage.ts:476 | Envoie {contact, phone, email} ; invalide ['/api/suppliers'] correctement. |
+| GET /api/groups | via Layout/StoreContext (déjà en cache) | server/routes.ts:970 -> storage.getGroups() server/storage.ts:432 (admin) / userGroups (autres) | Pour l'admin renvoie toutes les colonnes de groups dont le logo en data URI base64 et la config SMTP. |
+
+**Lisibilité / simplicité :** Deux colonnes (Fournisseurs / Autres contacts) claires sur desktop mais, sur mobile, la liste complète des fournisseurs passe avant les contacts du magasin (long défilement). Pas d'état de chargement (les états vides « Aucun contact » s'affichent pendant le chargement) ni d'erreur. Sélecteur de magasin admin propre à la page, en doublon du sélecteur global de l'en-tête. Le bouton « Nouveau contact » disparaît en vue « Tous les magasins » sans explication et le sélecteur « Magasin * » de la modale est ignoré. Les employés (pas de sélecteur dans l'en-tête, pas d'auto-sélection) restent bloqués sur « Sélectionnez un magasin ». Après création/modification/suppression, la liste ne se rafraîchit pas (clé de cache non invalidée). Notes saisies sur une ligne. Page très utile sur téléphone (liens tel:) mais absente du menu mobile et rendue sans MobileLayout.
+
+### `/analytics`
+
+**Rôle :** Tableau de bord statistiques (menu « Statistiques ») : KPI commandes/livraisons/taux de rapprochement/montant, courbe temporelle, camembert fournisseurs, barres par magasin, top 5 fournisseurs, exports CSV.
+
+**Tâches principales de l'utilisateur :**
+- Choisir une période (raccourcis ou dates)
+- Filtrer par fournisseur / magasin
+- Lire les KPI et graphiques
+- Exporter les données en CSV
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/analytics/summary | au montage + à chaque changement de filtre (fetch manuel) ; polling 30 s si « Temps réel » | server/routes.ts:6218 -> storage.getAnalyticsSummary() server/storage.ts:3166 | 4 requêtes SQL séquentielles ; la 4e (topStores) fait groups LEFT JOIN orders LEFT JOIN deliveries sans filtre de date (produit cartésien) et son résultat n'est jamais affiché ; totalAmount additionne BL + facture (double comptage). |
+| GET /api/analytics/timeseries | au montage + filtres + granularité | server/routes.ts:6250 -> storage.getAnalyticsTimeseries() server/storage.ts:3285 | 2 requêtes séquentielles en SQL brut concaténé (sql.raw) ; format semaine 'YYYY-IW' erroné ; pas de remplissage des trous. |
+| GET /api/analytics/by-supplier | au montage + filtres | server/routes.ts:6281 -> storage.getAnalyticsBySupplier() server/storage.ts:3361 | Ignore le filtre fournisseur ; pas de LIMIT alors que le client n'affiche que 5 lignes ; doublonne summary.topSuppliers. |
+| GET /api/analytics/by-store | au montage + filtres | server/routes.ts:6310 -> storage.getAnalyticsByStore() server/storage.ts:3400 | AUCUN filtrage par rôle ni par groupIds : tout utilisateur voit l'activité de tous les magasins ; erreurs avalées (return []). |
+| GET /api/suppliers | au montage | server/routes.ts:1141 -> storage.getSuppliers() server/storage.ts:467 | Pour la liste déroulante fournisseurs. |
+| GET /api/groups | au montage (cache partagé avec Layout) | server/routes.ts:970 -> storage.getGroups() server/storage.ts:432 | Seuls id/name sont utilisés ; l'admin reçoit logo base64 + config SMTP de chaque magasin. |
+| GET /api/analytics/export?type=summary\|timeseries\|suppliers\|stores | clic sur un bouton d'export | server/routes.ts:6331 -> getAnalyticsSummary/Timeseries/BySupplier/ByStore | CSV non échappé, séparateur ',' sans BOM, en-têtes anglais ; échec silencieux côté client. |
+
+**Lisibilité / simplicité :** Page la plus problématique du périmètre. Chaque changement de filtre remplace toute la page par un spinner plein écran (perte du contexte). Les filtres « Fournisseurs »/« Magasins » prétendent être multi-sélection mais ne le sont pas, n'agissent pas sur tous les graphiques, et ignorent le magasin choisi dans l'en-tête. Libellés jargon/anglicismes (« Tableau de bord Analytics » alors que le menu dit « Statistiques », « Granularité », « Taux de réconciliation », bouton « Temps réel/Actualisé »), montants non formatés à la française et sans HT/TTC, calendriers en anglais. Par défaut 365 points journaliers illisibles, axe X brut (« 2026-45 »), camembert dont l'infobulle affiche 0,1,2… au lieu du nom. KPI « Montant total » faux (BL + facture). Exports en double, CSV cassé dans Excel FR, échecs silencieux. États vides affichés pendant le chargement. recharts (410 Ko) chargé pour tous les utilisateurs au démarrage car la page n'est pas lazy.
+
+### `(non routée) SalesAnalysisPage`
+
+**Rôle :** Afficher dans une iframe un outil externe d'analyse des ventes dont l'URL est configurée dans les utilitaires.
+
+**Tâches principales de l'utilisateur :**
+- Consulter l'outil d'analyse des ventes
+- Recharger l'iframe
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/utilities | au montage | server/routes.ts:333 -> storage.getUtilities() server/storage.ts:3015 | Réservé admin/directeur (403 sinon) ; la page interpréterait le 403 comme « URL non configurée ». |
+
+**Lisibilité / simplicité :** Code mort : le composant n'est importé nulle part, aucune route ni entrée de menu « Analyse Vente » n'existe. S'il était branché : message trompeur pour manager/employé (403 affiché comme « URL non configurée » avec un bouton vers /utilities réservé admin), iframe en h-screen dans le Layout (double barre de défilement).
+
+### `(non routée) SalesAnalysisConfig`
+
+**Rôle :** Formulaire de saisie de l'URL de l'outil d'analyse des ventes.
+
+**Tâches principales de l'utilisateur :**
+- Saisir/enregistrer l'URL de l'outil d'analyse
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/utilities | au montage | server/routes.ts:333 -> storage.getUtilities() server/storage.ts:3015 | Même clé de cache que BackupManager. |
+| POST /api/utilities | clic « Sauvegarder » | server/routes.ts:354 -> storage.updateUtilities()/createUtilities() | Aucune validation de format d'URL côté client ou serveur. |
+
+**Lisibilité / simplicité :** Composant jamais importé (ni dans Utilities.tsx ni dans le routeur) : l'admin ne peut pas configurer l'URL depuis l'interface. Le texte renvoie à un menu « Analyse Vente » inexistant. Impossible d'effacer l'URL proprement (le champ n'est pas resynchronisé si config devient null).
+
+### `/bl-reconciliation (partie « relances fournisseurs » uniquement : /api/supplier-mail-logs + shared/supplierMail.ts)`
+
+**Rôle :** Afficher sur l'icône mail de chaque livraison la date de la dernière relance fournisseur envoyée, et construire le contenu du mail de relance (objet, texte, HTML).
+
+**Tâches principales de l'utilisateur :**
+- Voir si une livraison a déjà fait l'objet d'une relance
+- Envoyer une relance fournisseur
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/supplier-mail-logs?storeId=X | au montage de BLReconciliation (enabled: !!user) | server/routes.ts:2439 -> storage.getSupplierMailLogs() server/storage.ts:2974 | SELECT * jusqu'à 500 lignes alors que le client ne garde que le dernier envoi 'sent' par livraison ; storeId ignoré pour un directeur. |
+| POST /api/deliveries/:id/send-supplier-mail | clic sur l'icône mail | server/routes.ts:2330 -> emailService.sendSupplierDocumentRequest + storage.createSupplierMailLog() server/storage.ts:2969 | Invalide ['/api/supplier-mail-logs'] (préfixe correct). |
+
+**Lisibilité / simplicité :** Fonctionnellement correct ; le contenu du mail est clair et en français. Points faibles : montant du BL au format « 1234.50 € » au lieu de « 1 234,50 € » dans un mail adressé aux fournisseurs, et indicateur de dernière relance pouvant disparaître pour les livraisons anciennes à cause de la limite de 500 lignes.
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [ANA-01](#ana-01) | haute | perf-client | S | Spinner plein écran à chaque changement de filtre : toute la page disparaît | `client/src/pages/Analytics.tsx:140` |
+| [ANA-02](#ana-02) | haute | perf-bundle | S | recharts (410 Ko) téléchargé au démarrage par tous les utilisateurs | `client/src/components/RouterProduction.tsx:28` |
+| [ANA-03](#ana-03) | haute | perf-serveur | S | Requête topStores en produit cartésien, sans filtre de date, dont le résultat n'est jamais affiché | `server/storage.ts:3242` |
+| [ANA-04](#ana-04) | haute | bug | S | KPI « Montant total » faux : BL et facture additionnés | `server/storage.ts:3218` |
+| [ANA-05](#ana-05) | haute | bug | S | /api/analytics/by-store sans filtrage par rôle ni par magasin | `server/routes.ts:6310` |
+| [ANA-06](#ana-06) | haute | bug | S | Contournement du filtrage par magasin quand la liste filtrée devient vide | `server/routes.ts:6235` |
+| [API-01](#api-01) | haute | perf-serveur | M | L'utilisateur est relu en base 2 fois par requête (3 à 4 requêtes SQL d'authentification par appel) | `server/routes.ts:1143` |
+| [CONT-01](#cont-01) | haute | bug | S | La liste des contacts ne se rafraîchit pas après création / modification / suppression | `client/src/pages/Contacts.tsx:72` |
+| [CONT-02](#cont-02) | haute | bug | S | Un utilisateur sans magasin reçoit les contacts de TOUS les magasins | `server/storage.ts:490` |
+| [CONT-03](#cont-03) | haute | bug | S | Création / modification / suppression de contacts sans contrôle du magasin | `server/routes.ts:1311` |
+| [CONT-04](#cont-04) | haute | ux-simplicite | S | Les employés restent bloqués sur « Sélectionnez un magasin » sans aucun moyen de choisir | `client/src/components/Layout.tsx:131` |
+| [ANA-07](#ana-07) | moyenne | perf-serveur | S | Requêtes SQL indépendantes exécutées en séquence | `server/storage.ts:3211` |
+| [ANA-08](#ana-08) | moyenne | perf-api | M | 4 appels analytics séparés avec calculs en double | `client/src/pages/Analytics.tsx:56` |
+| [ANA-09](#ana-09) | moyenne | bug | S | Décalage d'un jour sur les périodes (fuseau horaire) et cache jamais réutilisé | `client/src/pages/Analytics.tsx:47` |
+| [ANA-10](#ana-10) | moyenne | bug | S | Format de semaine ISO erroné ('YYYY-IW' au lieu de 'IYYY-IW') | `server/storage.ts:3294` |
+| [ANA-11](#ana-11) | moyenne | lisibilite | M | Courbe illisible par défaut : 365 points journaliers, dates brutes, trous non comblés | `client/src/pages/Analytics.tsx:31` |
+| [ANA-12](#ana-12) | moyenne | bug | S | Camembert : l'infobulle affiche 0, 1, 2… au lieu du nom du fournisseur | `client/src/pages/Analytics.tsx:444` |
+| [ANA-13](#ana-13) | moyenne | ux-simplicite | M | Filtres trompeurs : fausse multi-sélection et graphiques qui ignorent certains filtres | `client/src/pages/Analytics.tsx:265` |
+| [ANA-14](#ana-14) | moyenne | coherence-design | S | Le magasin choisi dans l'en-tête est ignoré par les Statistiques | `client/src/pages/Analytics.tsx:21` |
+| [ANA-15](#ana-15) | moyenne | lisibilite | S | Jargon, anglicismes et montants non formatés à la française | `client/src/pages/Analytics.tsx:159` |
+| [ANA-17](#ana-17) | moyenne | ux-simplicite | M | Exports CSV : échec silencieux, boutons en double, fichier inexploitable dans Excel FR | `client/src/pages/Analytics.tsx:123` |
+| [ANA-18](#ana-18) | moyenne | ux-simplicite | S | États vides affichés pendant le chargement, aucun état d'erreur | `client/src/pages/Analytics.tsx:407` |
+| [API-02](#api-02) | moyenne | perf-api | S | Données de référence (fournisseurs, magasins) refetchées toutes les 30 s / à chaque page ; cache serveur inutilisé | `client/src/lib/queryClient.ts:77` |
+| [API-03](#api-03) | moyenne | perf-api | S | /api/groups renvoie à l'admin le logo base64 et la configuration SMTP de chaque magasin | `server/storage.ts:432` |
+| [CONT-05](#cont-05) | moyenne | bug | S | Le magasin du contact est écrasé silencieusement à l'enregistrement | `client/src/pages/Contacts.tsx:169` |
+| [CONT-06](#cont-06) | moyenne | coherence-design | S | Second sélecteur de magasin propre à la page, en doublon du sélecteur global | `client/src/pages/Contacts.tsx:229` |
+| [CONT-07](#cont-07) | moyenne | ux-simplicite | S | Aucun état de chargement ni d'erreur : « Aucun contact » s'affiche pendant le chargement | `client/src/pages/Contacts.tsx:68` |
+| [CONT-08](#cont-08) | moyenne | ux-simplicite | M | La liste complète des fournisseurs passe avant les contacts du magasin (mobile) | `client/src/pages/Contacts.tsx:254` |
+| [CONT-09](#cont-09) | moyenne | ux-simplicite | S | Contacts, Fournisseurs et Statistiques sur mobile : sans MobileLayout et absents du menu mobile | `client/src/components/RouterProduction.tsx:116` |
+| [MAIL-01](#mail-01) | moyenne | perf-api | M | Historique des relances : 500 lignes complètes chargées pour n'utiliser que la dernière par livraison | `server/storage.ts:2974` |
+| [SUPP-01](#supp-01) | moyenne | ux-simplicite | M | Fonctionnalité dupliquée avec la colonne Fournisseurs de la page Contacts | `client/src/pages/Suppliers.tsx:369` |
+| [SUPP-02](#supp-02) | moyenne | coherence-design | M | Droits fournisseurs incohérents entre UI et serveur | `server/routes.ts:1239` |
+| [SUPP-03](#supp-03) | moyenne | ux-simplicite | M | Suppression impossible dès qu'il y a un historique, avec un message générique | `client/src/pages/Suppliers.tsx:262` |
+| [SUPP-04](#supp-04) | moyenne | ux-simplicite | S | Erreurs de validation non expliquées à l'utilisateur | `client/src/pages/Suppliers.tsx:93` |
+| [SUPP-05](#supp-05) | moyenne | ux-simplicite | M | Grille de cartes lourde, recherche limitée au nom, ni tri ni filtres | `client/src/pages/Suppliers.tsx:276` |
+| [ANA-16](#ana-16) | basse | lisibilite | S | Calendriers en anglais, popover qui ne se ferme pas, pas de contrôle début ≤ fin | `client/src/pages/Analytics.tsx:221` |
+| [ANA-19](#ana-19) | basse | ux-simplicite | S | Bouton « Temps réel » confus et partiel | `client/src/pages/Analytics.tsx:71` |
+| [ANA-20](#ana-20) | basse | dette-code | S | fetch() manuels, logs de debug et variables mortes | `client/src/pages/Analytics.tsx:58` |
+| [ANA-21](#ana-21) | basse | dette-code | M | SQL brut concaténé et erreurs avalées dans timeseries / by-store | `server/storage.ts:3297` |
+| [ANA-22](#ana-22) | basse | ux-simplicite | S | En-tête non responsive et rendu sans navigation sur mobile | `client/src/pages/Analytics.tsx:154` |
+| [ANA-23](#ana-23) | basse | bug | S | Taux de rapprochement calculé sur toutes les livraisons, y compris planifiées | `server/storage.ts:3260` |
+| [API-04](#api-04) | basse | dette-code | S | Logs serveur verbeux à chaque création de fournisseur | `server/routes.ts:1167` |
+| [API-05](#api-05) | basse | bug | S | Erreurs de validation renvoyées en 500 sur PUT fournisseur / contact ; filtre DLC en JS | `server/routes.ts:1250` |
+| [CONT-10](#cont-10) | basse | perf-client | S | Requête contacts non conditionnée et queryFn redondante | `client/src/pages/Contacts.tsx:76` |
+| [CONT-11](#cont-11) | basse | ux-simplicite | S | Champ « Notes » sur une seule ligne | `client/src/pages/Contacts.tsx:536` |
+| [MAIL-02](#mail-02) | basse | lisibilite | S | Montant du BL au format anglo-saxon dans le mail envoyé au fournisseur | `shared/supplierMail.ts:85` |
+| [SALES-01](#sales-01) | basse | dette-code | S | Pages Analyse des ventes jamais branchées (code mort) et texte trompeur | `client/src/pages/SalesAnalysisConfig.tsx:75` |
+| [SALES-02](#sales-02) | basse | ux-simplicite | S | Si branchée : 403 présenté comme « URL non configurée », iframe en h-screen, URL non validée | `client/src/pages/SalesAnalysisPage.tsx:39` |
+| [SUPP-06](#supp-06) | basse | lisibilite | S | ID technique affiché, code ffnancy caché, libellés jargon | `client/src/pages/Suppliers.tsx:380` |
+| [SUPP-07](#supp-07) | basse | ux-simplicite | S | Une erreur réseau s'affiche comme « Aucun fournisseur – créez votre premier fournisseur » | `client/src/pages/Suppliers.tsx:344` |
+| [SUPP-08](#supp-08) | basse | perf-client | S | Recherche de stats en O(n×m) à chaque frappe, filtres non mémoïsés | `client/src/pages/Suppliers.tsx:280` |
+| [SUPP-09](#supp-09) | basse | perf-api | S | Double invalidation après modification d'un fournisseur | `client/src/pages/Suppliers.tsx:156` |
+| [SUPP-10](#supp-10) | basse | dette-code | S | Logs de debug et branche 401 morte dans les mutations | `client/src/pages/Suppliers.tsx:67` |
+| [SUPP-11](#supp-11) | basse | coherence-design | S | Compteurs Commandes/Livraisons ambigus et indépendants du magasin sélectionné | `client/src/pages/Suppliers.tsx:61` |
+| [SUPP-12](#supp-12) | basse | accessibilite | S | Boutons icône sans libellé ni infobulle, petits textes à faible contraste | `client/src/pages/Suppliers.tsx:385` |
+| [SUPP-13](#supp-13) | basse | dette-code | S | Casts `as any` inutiles sur email/codefou | `client/src/pages/Suppliers.tsx:242` |
+
+### ANA-01
+
+**Spinner plein écran à chaque changement de filtre : toute la page disparaît** — perf-client, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/Analytics.tsx:140`
+- **Constat :** Analytics.tsx:57 `queryKey: ['/api/analytics/summary', queryParams]` sans placeholderData ; l.140-149 `if (summaryLoading) { return (<div className="flex items-center justify-center min-h-screen">...Chargement des statistiques...` — chaque nouvelle clé (nouvelle période, fournisseur, magasin) repasse isLoading à true.
+- **Impact :** Au moindre clic sur « Ce mois » ou un fournisseur, filtres, KPI et graphiques sont remplacés par un spinner sur toute la hauteur : effet de clignotement, perte de repère, popovers fermés.
+- **Recommandation :** Ajouter `placeholderData: keepPreviousData` à toutes les requêtes analytics, n'afficher le spinner plein écran qu'au premier chargement (`isLoading && !summary`) et utiliser `isFetching` pour une opacité réduite / skeleton par carte.
+
+### ANA-02
+
+**recharts (410 Ko) téléchargé au démarrage par tous les utilisateurs** — perf-bundle, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:28`
+- **Constat :** RouterProduction.tsx:28 `import Analytics from "@/pages/Analytics";` (import statique, aucun React.lazy dans le routeur) ; Analytics.tsx:14 est le seul import de recharts ; vite.config.ts manualChunks `"vendor-charts": ["recharts"]` ; dist/public/index.html contient `modulepreload ... /assets/vendor-charts-gtSIDI7m.js` (410 243 octets).
+- **Impact :** Même un employé qui n'a pas accès aux Statistiques télécharge et parse ~410 Ko de JS au premier chargement (et l'index fait 1,08 Mo) : démarrage plus lent, surtout sur mobile.
+- **Recommandation :** `const Analytics = lazy(() => import("@/pages/Analytics"))` + <Suspense> (desktop et mobile) ET corriger vite.config.ts : retirer l'entrée "vendor-charts" de manualChunks (ou ajouter "clsx"/"tailwind-merge" dans un chunk vendor chargé par l'entrée). Vérifier après `vite build` que dist/public/index.html ne contient plus de modulepreload vers le chunk recharts. Généraliser aux autres pages dans un second temps.
+
+### ANA-03
+
+**Requête topStores en produit cartésien, sans filtre de date, dont le résultat n'est jamais affiché** — perf-serveur, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:3242`
+- **Constat :** storage.ts:3242-3258 `db.select({... COUNT(DISTINCT orders.id), COUNT(DISTINCT deliveries.id)}).from(groups).leftJoin(orders, eq(groups.id, orders.groupId)).leftJoin(deliveries, eq(groups.id, deliveries.groupId))` : pour chaque magasin, nb_commandes × nb_livraisons lignes, sans les conditions de date/fournisseur. `grep topStores client/src` : aucune utilisation ; avgDeliveryDelay (l.3220) non affiché non plus.
+- **Impact :** C'est la requête la plus coûteuse de la page (millions de lignes intermédiaires dès quelques milliers de commandes par magasin), exécutée à chaque filtre et toutes les 30 s en mode « Temps réel », pour un résultat jeté.
+- **Recommandation :** Supprimer topStores (seule requête coûteuse) de getAnalyticsSummary dans IStorage, DatabaseStorage et MemStorage, en acceptant/annonçant la disparition de cette colonne JSON de l'export Résumé (cf. ANA-17) ; ou, si l'export doit la garder, la calculer via des sous-requêtes agrégées filtrées comme getAnalyticsByStore. avgDeliveryDelay peut rester.
+
+### ANA-04
+
+**KPI « Montant total » faux : BL et facture additionnés** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:3218`
+- **Constat :** storage.ts:3218 `totalAmount: sql`COALESCE(SUM(CAST(bl_amount AS NUMERIC)), 0) + COALESCE(SUM(CAST(invoice_amount AS NUMERIC)), 0)`` alors que le top fournisseurs (l.3230) n'utilise que `SUM(blAmount)`. Affiché tel quel Analytics.tsx:387.
+- **Impact :** Pour une livraison rapprochée (BL ≈ facture), le montant est compté deux fois : le KPI est environ le double de la réalité et incohérent avec la somme du top fournisseurs. Décisions prises sur un chiffre faux.
+- **Recommandation :** Définir le montant de référence (ex. COALESCE(invoice_amount, bl_amount) par ligne) et l'appliquer partout ; indiquer HT/TTC dans le libellé.
+
+### ANA-05
+
+**/api/analytics/by-store sans filtrage par rôle ni par magasin** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/routes.ts:6310`
+- **Constat :** routes.ts:6317-6323 `const filters = { startDate, endDate, supplierIds }; const byStore = await storage.getAnalyticsByStore(filters);` — aucun bloc « Apply role-based filtering », groupIds non lu ; storage.ts:3400-3455 interroge `FROM groups g` sans WHERE sur g.id.
+- **Impact :** Un manager voit le nom et l'activité de tous les magasins de l'enseigne ; le filtre « Magasins » de la page n'a aucun effet sur le graphique « Performance par magasin ».
+- **Recommandation :** Appliquer le même filtrage par rôle que les autres routes, ajouter `groupIds` à getAnalyticsByStore (`WHERE g.id = ANY(...)`).
+
+### ANA-06
+
+**Contournement du filtrage par magasin quand la liste filtrée devient vide** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/routes.ts:6235`
+- **Constat :** routes.ts:6235-6240 `filters.groupIds = filters.groupIds ? filters.groupIds.filter((id) => userGroupIds.includes(id)) : userGroupIds;` puis storage.ts:3200 `if (filters.groupIds?.length) { ...inArray(...) }`. Si l'utilisateur passe `groupIds=999` (magasin qui n'est pas le sien) ou n'a aucun magasin, le tableau devient [] et AUCUN filtre n'est appliqué. Même motif l.6266 (timeseries), l.6295 (by-supplier), et dans /export. Le directeur est en outre exempté de tout filtrage (l.6235) alors que /api/groups le limite à ses magasins (l.976-985).
+- **Impact :** Fuite de données : un manager obtient les statistiques de toute l'enseigne avec un simple paramètre d'URL ; incohérence de périmètre pour les directeurs.
+- **Recommandation :** Si la liste filtrée est vide pour un non-admin, renvoyer immédiatement un résultat vide (ou 403) ; factoriser via `resolveStatsGroupIds` (routes.ts:1469) déjà utilisé par /api/stats/* ; décider explicitement du périmètre du directeur.
+
+### API-01
+
+**L'utilisateur est relu en base 2 fois par requête (3 à 4 requêtes SQL d'authentification par appel)** — perf-serveur, sévérité haute, effort M
+
+- **Fichier :** `server/routes.ts:1143`
+- **Constat :** localAuth.ts:141-143 `passport.deserializeUser(async (id) => { const user = await storage.getUserWithGroups(id); ...})` charge déjà l'utilisateur + groupes à chaque requête ; puis chaque handler recommence : routes.ts:1143 `storage.getUser(...)`, 1275, 1506, 6220, 6252, 6283, 6312 `storage.getUserWithGroups(...)`. storage.ts:371-373 getUserWithGroups fait 2 requêtes séquentielles (`await this.getUser(id)` puis le SELECT user_groups JOIN groups).
+- **Impact :** La page Statistiques déclenche 6 appels -> ~22 requêtes SQL rien que pour l'authentification avant tout calcul métier ; latence ajoutée sur chaque appel API de l'application.
+- **Recommandation :** Remplacer, en tête de handler uniquement, `await storage.getUser(...)` / `await storage.getUserWithGroups(...)` par `req.user` (garder les relectures faites APRÈS une mise à jour de l'utilisateur) ; fusionner getUserWithGroups en une seule requête LEFT JOIN. Ne PAS ajouter de cache mémoire par userId.
+
+### CONT-01
+
+**La liste des contacts ne se rafraîchit pas après création / modification / suppression** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/Contacts.tsx:72`
+- **Constat :** Contacts.tsx:72-74 `const contactsQueryKey = effectiveGroupId ? [`/api/contacts?groupId=${effectiveGroupId}`] : ["/api/contacts"];` alors que les mutations font (l.90, 102, 114) `queryClient.invalidateQueries({ queryKey: ["/api/contacts"] });`. TanStack compare élément par élément : '/api/contacts?groupId=3' !== '/api/contacts', donc la requête n'est jamais invalidée dès qu'un magasin est sélectionné (cas de tous les non-admins).
+- **Impact :** L'utilisateur crée un contact, voit le toast « Contact créé avec succès » mais le contact n'apparaît pas ; il recrée souvent un doublon ou pense que l'enregistrement a échoué. Idem pour une suppression : la carte reste affichée.
+- **Recommandation :** Utiliser une clé structurée `['/api/contacts', { groupId: effectiveGroupId }]` (queryFn construisant l'URL) et garder `invalidateQueries({ queryKey: ['/api/contacts'] })`, qui matchera alors par préfixe. Idéalement mettre aussi à jour le cache via setQueryData dans onSuccess.
+
+### CONT-02
+
+**Un utilisateur sans magasin reçoit les contacts de TOUS les magasins** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:490`
+- **Constat :** routes.ts:1279-1281 `if (user.role !== 'admin') { groupIds = (user.userGroups || []).map((ug: any) => ug.groupId); }` puis storage.ts:490-494 `if (groupIds && groupIds.length > 0) { ...where(inArray(contacts.groupId, groupIds)) } return await db.select().from(contacts).orderBy(contacts.name);` — un tableau vide fait tomber dans la branche « tout renvoyer ».
+- **Impact :** Fuite de données : un employé/manager non encore rattaché à un magasin voit l'annuaire complet de toute l'enseigne.
+- **Recommandation :** Dans la route, `if (user.role !== 'admin' && groupIds.length === 0) return res.json([])` ; dans les DEUX implémentations de getContacts (DatabaseStorage l.490 et MemStorage l.3719), traiter `groupIds !== undefined && groupIds.length === 0` comme « aucun contact ».
+
+### CONT-03
+
+**Création / modification / suppression de contacts sans contrôle du magasin** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/routes.ts:1311`
+- **Constat :** routes.ts:1293-1338 : POST, PUT et DELETE vérifient seulement le rôle `['admin', 'directeur', 'manager'].includes(user.role)` puis appellent `storage.createContact(data)` / `updateContact(id, data)` / `deleteContact(id)` sans vérifier que `data.groupId` ou le contact ciblé appartient aux magasins de l'utilisateur.
+- **Impact :** Un manager du magasin A peut créer, modifier ou supprimer les contacts du magasin B (simple appel avec un id). Risque de perte de données entre magasins.
+- **Recommandation :** Charger le contact (getContact(id)) et vérifier `userGroupIds.includes(contact.groupId)` pour PUT/DELETE ; vérifier `data.groupId` pour POST et PUT (sauf admin). Renvoyer 403 sinon.
+
+### CONT-04
+
+**Les employés restent bloqués sur « Sélectionnez un magasin » sans aucun moyen de choisir** — ux-simplicite, sévérité haute, effort S
+
+- **Fichier :** `client/src/components/Layout.tsx:131`
+- **Constat :** Layout.tsx:131 le sélecteur n'existe que pour `user.role === 'admin' || 'directeur' || 'manager'` ; Layout.tsx:70 l'auto-sélection ne concerne que `directeur`/`manager`. Contacts.tsx:41 `effectiveGroupId = isAdmin ? adminGroupId : selectedStoreId` et l.355-359 affichent « Sélectionnez un magasin pour voir les contacts ». Or Sidebar.tsx:323-326 donne l'accès Contacts au rôle `employee`.
+- **Impact :** Sur desktop, un employé dont le magasin n'est pas déjà mémorisé dans localStorage ne voit jamais les contacts de son magasin, alors que la page lui est proposée dans le menu.
+- **Recommandation :** Auto-sélectionner le magasin pour tout rôle n'ayant qu'un magasin (y compris employee) dans Layout.tsx et MobileApp.tsx ; à défaut, afficher directement les contacts de tous les magasins de l'utilisateur (ce que renvoie déjà le serveur) au lieu du message bloquant.
+
+### ANA-07
+
+**Requêtes SQL indépendantes exécutées en séquence** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:3211`
+- **Constat :** getAnalyticsSummary : storage.ts:3213 `await orderQuery`, 3223 `await deliveryQuery`, 3236 `await supplierQuery`, 3255 `await storeQuery` ; getAnalyticsTimeseries : 3333 `await db.execute(sql.raw(ordersSql))` puis 3344 `await db.execute(sql.raw(deliveriesSql))`.
+- **Impact :** Le temps de réponse est la somme des requêtes au lieu du maximum.
+- **Recommandation :** `const [[orderCount], [deliveryStats], topSuppliers] = await Promise.all([...])` ; idem pour les deux requêtes de timeseries (pattern déjà utilisé dans getOrderDeliveryStatsBySupplier l.1861).
+
+### ANA-08
+
+**4 appels analytics séparés avec calculs en double** — perf-api, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Analytics.tsx:56`
+- **Constat :** Analytics.tsx:56-112 : summary, timeseries, by-supplier, by-store, chacun avec fetch manuel ; summary.topSuppliers (storage.ts:3226-3239) et by-supplier (storage.ts:3361-3397) exécutent la même agrégation deliveries JOIN suppliers ; by-supplier n'a pas de LIMIT alors que le client fait `bySupplier.slice(0, 5)` (l.445).
+- **Impact :** 4 allers-retours + 4 ré-authentifications (API-01) et une agrégation calculée deux fois à chaque filtre.
+- **Recommandation :** Créer un endpoint unique GET /api/analytics/overview qui exécute les agrégats en Promise.all et renvoie {kpis, timeseries, bySupplier(top 5), byStore} ; supprimer topSuppliers du summary ou by-supplier.
+
+### ANA-09
+
+**Décalage d'un jour sur les périodes (fuseau horaire) et cache jamais réutilisé** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Analytics.tsx:47`
+- **Constat :** Analytics.tsx:38 `startOfMonth(new Date())` (minuit heure locale) puis l.47 `params.append('startDate', dateRange.from.toISOString())` ; serveur storage.ts:3188 `filters.startDate.toISOString().split('T')[0]`. À Paris (UTC+2), le 01/10 00:00 devient '2026-09-30'. « Aujourd'hui » entre 0 h et 2 h interroge la veille. Les raccourcis utilisent `new Date()` avec millisecondes : la clé de cache change à chaque clic.
+- **Impact :** « Ce mois » inclut le dernier jour du mois précédent, « Cette semaine » le dimanche précédent ; chiffres légèrement faux et refetch systématique même en recliquant sur la même période.
+- **Recommandation :** Envoyer des dates calendaires `format(date, 'yyyy-MM-dd')` (clé de cache stable) et les utiliser telles quelles côté serveur (sans toISOString).
+
+### ANA-10
+
+**Format de semaine ISO erroné ('YYYY-IW' au lieu de 'IYYY-IW')** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:3294`
+- **Constat :** storage.ts:3293-3294 `const dateFormat = granularity === 'day' ? 'YYYY-MM-DD' : granularity === 'week' ? 'YYYY-IW' : 'YYYY-MM';` — en PostgreSQL TO_CHAR('2024-12-30','YYYY-IW') donne '2024-01'.
+- **Impact :** Les jours de fin décembre sont agrégés dans la « semaine 01 » de la mauvaise année et fusionnés avec début janvier : pic faux sur la courbe.
+- **Recommandation :** Utiliser 'IYYY-IW' (et un libellé lisible « Sem. 45 – 2026 » côté client).
+
+### ANA-11
+
+**Courbe illisible par défaut : 365 points journaliers, dates brutes, trous non comblés** — lisibilite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Analytics.tsx:31`
+- **Constat :** Analytics.tsx:25 période par défaut `addDays(new Date(), -365)` et l.31 `granularity` = 'day' ; l.411 `<XAxis dataKey="date" />` affiche '2026-03-14' ou '2026-45' ; storage.ts:3347-3357 ne renvoie que les dates ayant des données (pas de zéros), la ligne relie des jours non consécutifs.
+- **Impact :** Graphique en « peigne » impossible à lire, axe X technique, tendances trompeuses.
+- **Recommandation :** Granularité automatique selon la durée (≤31 j : jour, ≤6 mois : semaine, sinon mois), tickFormatter en français (« 14 mars », « sept. 2026 »), remplissage des périodes vides à 0 (generate_series côté SQL).
+
+### ANA-12
+
+**Camembert : l'infobulle affiche 0, 1, 2… au lieu du nom du fournisseur** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Analytics.tsx:444`
+- **Constat :** Analytics.tsx:444-453 `<Pie data={bySupplier.slice(0, 5)} ... label={(entry) => entry.supplierName} outerRadius={80} dataKey="deliveries">` sans `nameKey` ; recharts 2.15.4 Pie.js:520 `var name = getValueByDataKey(entry, nameKey, i)` avec nameKey par défaut 'name' -> l'index. Les labels de noms longs débordent d'une carte de 300 px.
+- **Impact :** Au survol l'utilisateur lit « 0 : 34 » : impossible de savoir de quel fournisseur il s'agit ; labels qui se chevauchent.
+- **Recommandation :** Auto-implémenter uniquement `nameKey="supplierName"` sur le <Pie> ; la légende, le retrait des labels et le diagramme en barres relèvent de la refonte visuelle.
+
+### ANA-13
+
+**Filtres trompeurs : fausse multi-sélection et graphiques qui ignorent certains filtres** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Analytics.tsx:265`
+- **Constat :** Analytics.tsx:266-277 le Select est mono-valeur ; cliquer un autre fournisseur fait `setSelectedSuppliers([supplierId])` (remplacement), la valeur "multiple" n'a aucun SelectItem. l.30 `selectedStatus` n'est jamais modifié. routes.ts:6288-6292 by-supplier ne lit pas supplierIds ; routes.ts:6317-6321 by-store ne lit pas groupIds.
+- **Impact :** Le « ✓ » laisse croire à une sélection multiple qui n'existe pas ; en filtrant sur un fournisseur, le camembert continue d'afficher les 5 fournisseurs, en filtrant sur un magasin, le graphique magasins reste inchangé : résultats contradictoires à l'écran.
+- **Recommandation :** Soit un vrai multi-select (Popover + Checkbox), soit un Select simple sans « ✓ » ; appliquer tous les filtres à tous les endpoints (ou masquer/griser le graphique non concerné) ; supprimer selectedStatus.
+
+### ANA-14
+
+**Le magasin choisi dans l'en-tête est ignoré par les Statistiques** — coherence-design, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Analytics.tsx:21`
+- **Constat :** Analytics.tsx:21 `const { selectedStoreId } = useStore();` n'est jamais utilisé ; l.29 `selectedStores` démarre vide et l.296-327 propose un troisième sélecteur « Magasins ».
+- **Impact :** Un manager qui travaille sur « Magasin A » (en-tête) voit des statistiques multi-magasins sans s'en rendre compte.
+- **Recommandation :** Initialiser/synchroniser le filtre magasin avec selectedStoreId (ou supprimer le filtre local et utiliser uniquement le sélecteur global, comme les autres pages).
+
+### ANA-15
+
+**Jargon, anglicismes et montants non formatés à la française** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Analytics.tsx:159`
+- **Constat :** Analytics.tsx:159 « Tableau de bord Analytics » alors que le menu dit « Statistiques » (Sidebar.tsx:283) ; l.250 « Granularité » ; l.365 « Taux de réconciliation » (le reste de l'app dit « Rapprochement ») ; l.171 bouton « Temps réel » qui devient « Actualisé » ; l.387 `${summary.totalAmount.toFixed(2)}€` et l.534 `{supplier.amount.toFixed(2)}€` -> « 123456.70€ » ; aucune mention HT/TTC.
+- **Impact :** Termes techniques ou anglais, chiffres difficiles à lire pour un employé/manager ; incohérence de vocabulaire entre menu et page.
+- **Recommandation :** Titre « Statistiques », « Regrouper par : jour/semaine/mois », « Livraisons rapprochées (%) » ; formater avec `new Intl.NumberFormat('fr-FR', { style: 'currency', currency: 'EUR' })` et préciser HT ; ajouter une courte aide (icône i) sous chaque KPI.
+
+### ANA-17
+
+**Exports CSV : échec silencieux, boutons en double, fichier inexploitable dans Excel FR** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Analytics.tsx:123`
+- **Constat :** Analytics.tsx:123-138 `if (response.ok) {...}` sans else ni toast ; l.173-180 « Export CSV » et l.566 « Export Résumé » appellent tous deux handleExport('summary'). routes.ts:6375-6381 `Object.keys(data[0]).join(',')` / `Object.values(item).map(val => typeof val === 'object' ? JSON.stringify(val) : val).join(',')` : pas d'échappement, séparateur ',' sans BOM UTF-8, en-têtes anglais (totalOrders...), tableau topSuppliers en JSON dans une cellule ; l'export « timeseries » force `granularity: 'day'` (l.6366) quelle que soit l'option choisie.
+- **Impact :** Clic sans effet si pas de données (404), accents cassés et colonnes décalées à l'ouverture dans Excel français (séparateur ';'), noms de fournisseurs contenant une virgule qui cassent le fichier.
+- **Recommandation :** Un seul menu « Exporter ▾ » ; côté serveur, CSV avec ';', BOM '', guillemets échappés et en-têtes français (ou XLSX) ; respecter la granularité ; toast d'erreur/« aucune donnée » côté client.
+
+### ANA-18
+
+**États vides affichés pendant le chargement, aucun état d'erreur** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Analytics.tsx:407`
+- **Constat :** Analytics.tsx:74-112 timeseries/bySupplier/byStore sans isLoading ni isError ; l.407-427 `Array.isArray(timeseries) && timeseries.length > 0 ? ... : « Aucune donnée temporelle – Vérifiez la période sélectionnée »` (idem l.441-469, 483-509). Une erreur summary laisse les KPI à 0 (l.342 `summary?.totalOrders || 0`).
+- **Impact :** L'utilisateur lit « Aucune donnée » et change de période alors que les données arrivent ; une panne est présentée comme « 0 commande ».
+- **Recommandation :** Skeleton dans chaque carte pendant le chargement, message d'erreur explicite avec « Réessayer », et n'afficher l'état vide qu'une fois la requête réussie.
+
+### API-02
+
+**Données de référence (fournisseurs, magasins) refetchées toutes les 30 s / à chaque page ; cache serveur inutilisé** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/lib/queryClient.ts:77`
+- **Constat :** queryClient.ts:77 `staleTime: 30 * 1000` global avec `refetchOnMount: true` ; ['/api/suppliers'] est utilisé par ~14 composants (Avoirs, SavTickets, BLReconciliation, modales commande/livraison...). server/cache.ts:53 `export function cacheMiddleware(...)` n'est importé nulle part (grep vide dans server/).
+- **Impact :** Chaque navigation après 30 s relance /api/suppliers et /api/groups (avec ré-authentification, cf. API-01) pour des données qui changent quelques fois par mois.
+- **Recommandation :** Définir `staleTime: 10 * 60 * 1000` sur les clés ['/api/suppliers'] et ['/api/groups'] (via queryClient.setQueryDefaults), les mutations invalidant déjà ces clés ; côté serveur, mettre en cache mémoire getSuppliers() (invalidé sur POST/PUT/DELETE) ou supprimer server/cache.ts s'il n'est pas utilisé.
+
+### API-03
+
+**/api/groups renvoie à l'admin le logo base64 et la configuration SMTP de chaque magasin** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:432`
+- **Constat :** storage.ts:432-434 `return await db.select().from(groups).orderBy(groups.name);` (toutes colonnes) ; schema.ts:67 `logo: text("logo"), // Logo en data URI (data:image/png;base64,...)` + colonnes smtp*. routes.ts:979-981 renvoie ce résultat tel quel à l'admin ; Analytics.tsx:118-120 et Layout.tsx:47-50 n'utilisent que id/name/color.
+- **Impact :** Pour l'admin, chaque chargement de l'application télécharge les logos de tous les magasins (souvent plusieurs dizaines de Ko chacun) ; forme de réponse différente entre admin et non-admin.
+- **Recommandation :** Projeter les colonnes nécessaires à la liste (id, name, color) et exposer le détail (logo, SMTP) via GET /api/groups/:id uniquement sur la page Magasins.
+
+### CONT-05
+
+**Le magasin du contact est écrasé silencieusement à l'enregistrement** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Contacts.tsx:169`
+- **Constat :** Contacts.tsx:169 `const payload = { ...formData, groupId: effectiveGroupId ?? formData.groupId };`. Côté serveur routes.ts:1278-1281 le paramètre groupId est ignoré pour un non-admin, qui reçoit les contacts de tous ses magasins. Pour l'admin, le sélecteur « Magasin * » de la modale (l.461-481) n'est jamais pris en compte puisque le bouton « Nouveau contact » n'est visible que si effectiveGroupId est défini (l.220).
+- **Impact :** Un manager multi-magasins voit un contact du magasin B en ayant sélectionné A ; s'il le modifie (même juste le téléphone), le contact est déplacé vers A. Pour l'admin, le choix « Magasin » de la modale est un faux choix.
+- **Recommandation :** En édition, conserver `selectedContact.groupId` (ne pas l'écraser). Côté serveur, honorer `groupId` pour les non-admins s'il appartient à leurs magasins. Supprimer le sélecteur de magasin de la modale ou l'utiliser réellement (et autoriser la création en vue « Tous les magasins »).
+
+### CONT-06
+
+**Second sélecteur de magasin propre à la page, en doublon du sélecteur global** — coherence-design, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Contacts.tsx:229`
+- **Constat :** Contacts.tsx:40-41 `const [adminGroupId, setAdminGroupId] = useState<number | null>(null); const effectiveGroupId = isAdmin ? adminGroupId : selectedStoreId;` et l.229-251 un bloc bleu « Magasin affiché (admin) ». Le sélecteur global de l'en-tête (Layout.tsx:131-155) est ignoré pour l'admin sur cette page.
+- **Impact :** L'admin choisit « Magasin A » dans l'en-tête mais la page Contacts affiche « Tous les magasins » : deux sélecteurs contradictoires, source de confusion.
+- **Recommandation :** Supprimer adminGroupId et utiliser `selectedStoreId` du StoreContext pour tous les rôles (null = tous les magasins pour l'admin).
+
+### CONT-07
+
+**Aucun état de chargement ni d'erreur : « Aucun contact » s'affiche pendant le chargement** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/Contacts.tsx:68`
+- **Constat :** Contacts.tsx:68-84 `const { data: suppliers = [] } = useQuery(...)` / `const { data: contacts = [] } = useQuery(...)` sans lecture de isLoading/isError ; l.275-279 « Aucun fournisseur trouvé » et l.364-367 « Aucun contact » s'affichent tant que les données ne sont pas arrivées ou en cas d'erreur.
+- **Impact :** L'utilisateur croit que l'annuaire est vide (ou que ses contacts ont disparu) pendant le chargement ou lors d'une panne réseau.
+- **Recommandation :** Afficher des skeletons de cartes pendant isLoading (comme Suppliers.tsx:292-305) et un encart d'erreur avec bouton « Réessayer » sur isError.
+
+### CONT-08
+
+**La liste complète des fournisseurs passe avant les contacts du magasin (mobile)** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Contacts.tsx:254`
+- **Constat :** Contacts.tsx:254 `grid grid-cols-1 lg:grid-cols-2` : sous 1024 px la colonne Fournisseurs (tous les fournisseurs de l'enseigne, l.281 `filteredSuppliers.map(...)`, sans pagination) est rendue entièrement avant « Autres contacts ».
+- **Impact :** Sur téléphone/tablette il faut faire défiler des dizaines de cartes fournisseurs pour atteindre le contact du dépanneur du magasin.
+- **Recommandation :** Remplacer les deux colonnes par des onglets « Fournisseurs » / « Contacts du magasin » (ou une seule recherche unifiée), afficher une liste compacte (nom + boutons Appeler / Email) et limiter l'affichage initial.
+
+### CONT-09
+
+**Contacts, Fournisseurs et Statistiques sur mobile : sans MobileLayout et absents du menu mobile** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:116`
+- **Constat :** RouterProduction.tsx:116-128 `{/* Pages sans version mobile - utiliser version desktop pour l'instant */} <Route path="/contacts" component={Contacts} />` (idem /suppliers, /analytics) rendus directement dans MobileApp, alors que les pages mobiles s'enveloppent dans MobileLayout (DashboardPage.tsx:136). MobileBottomNav.tsx:30-42 ne liste ni /contacts ni /analytics.
+- **Impact :** La page la plus utile sur téléphone (liens tel: et mailto:) est inaccessible depuis le menu mobile ; si on y arrive par URL, il n'y a ni en-tête ni navigation pour revenir.
+- **Recommandation :** Envelopper ces pages dans MobileLayout sur mobile et ajouter « Contacts » au menu « Plus » de MobileBottomNav.
+
+### MAIL-01
+
+**Historique des relances : 500 lignes complètes chargées pour n'utiliser que la dernière par livraison** — perf-api, sévérité moyenne, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:2974`
+- **Constat :** storage.ts:2984-2990 `db.select().from(supplierMailLogs)...orderBy(desc(supplierMailLogs.createdAt)).limit(500)` (toutes colonnes : subject, errorMessage, messageId...) ; BLReconciliation.tsx:100-108 ne garde que `log.status === 'sent' && !map.has(log.deliveryId)`. Index existants : group_id et delivery_id seuls (migrations.ts:106-107). routes.ts:2448-2455 n'honore storeId que pour l'admin alors que le client l'envoie aussi pour le directeur (BLReconciliation.tsx:87).
+- **Impact :** Payload inutilement gros à chaque ouverture du rapprochement ; au-delà de 500 envois, l'indicateur « déjà relancé » disparaît pour les livraisons plus anciennes (risque de relancer deux fois le même fournisseur).
+- **Recommandation :** Endpoint dédié `SELECT DISTINCT ON (delivery_id) delivery_id, created_at, sent_by, sent_by_name, sent_to FROM supplier_mail_logs WHERE status = 'sent' AND group_id = ANY($1) ORDER BY delivery_id, created_at DESC` (champs renvoyés en camelCase comme aujourd'hui : deliveryId, createdAt, sentBy, sentByName), index (group_id, delivery_id, created_at DESC), et prise en compte de storeId pour le directeur s'il appartient à ses magasins.
+
+### SUPP-01
+
+**Fonctionnalité dupliquée avec la colonne Fournisseurs de la page Contacts** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Suppliers.tsx:369`
+- **Constat :** Suppliers.tsx:405-422 affiche contact/téléphone/email et permet l'édition (modale l.494-640) ; Contacts.tsx:281-330 affiche les mêmes coordonnées et ouvre sa propre modale d'édition (l.566-613) via PUT /api/suppliers/:id.
+- **Impact :** Deux écrans pour la même information, avec des droits différents : l'utilisateur ne sait pas où mettre à jour un numéro.
+- **Recommandation :** Garder la fiche complète (options, mode de paiement, code ffnancy) dans Fournisseurs (admin) et faire de Contacts un annuaire en lecture + lien « Modifier la fiche » vers Fournisseurs, ou l'inverse ; une seule modale de coordonnées partagée.
+
+### SUPP-02
+
+**Droits fournisseurs incohérents entre UI et serveur** — coherence-design, sévérité moyenne, effort M
+
+- **Fichier :** `server/routes.ts:1239`
+- **Constat :** Suppliers.tsx:216/229/253/320 : création, modification, suppression réservées à `user?.role === 'admin'` ; Contacts.tsx:27 `CAN_EDIT_SUPPLIER = ["admin", "directeur"]` ; routes.ts:1201 POST autorise admin/manager/directeur, routes.ts:1242 PUT admin/manager/directeur, routes.ts:1259 DELETE admin/directeur.
+- **Impact :** Un directeur peut modifier un fournisseur depuis Contacts mais pas depuis Fournisseurs ; un manager peut créer/modifier via l'API sans que l'UI le permette. Matrice de droits impossible à expliquer aux utilisateurs.
+- **Recommandation :** Définir une seule règle (ex. hasPermission(role,'suppliers','edit') dans server/permissions) et l'utiliser côté serveur et client (hook usePermission).
+
+### SUPP-03
+
+**Suppression impossible dès qu'il y a un historique, avec un message générique** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Suppliers.tsx:262`
+- **Constat :** Suppliers.tsx:262 `if (confirm(...)) deleteMutation.mutate(supplier.id)` puis l.189-193 toast « Impossible de supprimer le fournisseur ». init.sql:446-455 : `FOREIGN KEY ("supplier_id") REFERENCES "suppliers"("id") ON DELETE NO ACTION` sur deliveries et orders ; routes.ts:1265-1268 renvoie 500 « Failed to delete supplier ».
+- **Impact :** L'admin confirme la suppression puis reçoit une erreur incompréhensible, alors que la carte affiche déjà le nombre de commandes (stats.orders).
+- **Recommandation :** Désactiver le bouton (avec infobulle « X commandes liées ») quand stats.orders + stats.deliveries > 0, renvoyer côté serveur un 409 explicite sur violation FK (code 23503), et proposer un statut « Archivé/inactif ».
+
+### SUPP-04
+
+**Erreurs de validation non expliquées à l'utilisateur** — ux-simplicite, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Suppliers.tsx:93`
+- **Constat :** routes.ts:1223-1228 renvoie `{ message: "Validation failed", errors: error.errors }` en 400, mais Suppliers.tsx:93-97 affiche toujours « Impossible de créer le fournisseur » (idem modification l.145-149).
+- **Impact :** L'utilisateur ne sait pas quel champ corriger.
+- **Recommandation :** Extraire le message serveur de l'erreur (`apiRequest` lève `${status}: ${body}`) et l'afficher dans le toast (403 = droits insuffisants, 409/FK = fournisseur utilisé, etc.) ; la validation Zod côté client n'est pas prioritaire.
+
+### SUPP-05
+
+**Grille de cartes lourde, recherche limitée au nom, ni tri ni filtres** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Suppliers.tsx:276`
+- **Constat :** Suppliers.tsx:276-278 `suppliers.filter(supplier => supplier.name.toLowerCase().includes(searchTerm.toLowerCase()))` ; l.368-372 cartes `shadow-lg hover:shadow-xl ... p-6` en grille de 3 ; aucun filtre sur hasDlc / requiresControl / automaticReconciliation.
+- **Impact :** Avec des dizaines de fournisseurs, long défilement et densité faible ; impossible de lister « les fournisseurs à contrôler » ou « avec DLC ».
+- **Recommandation :** Passer en tableau compact (Nom, Contact, Téléphone, Email, Options en badges, Commandes) avec tri, recherche sur nom/contact/email/code, et filtres rapides par option.
+
+### ANA-16
+
+**Calendriers en anglais, popover qui ne se ferme pas, pas de contrôle début ≤ fin** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Analytics.tsx:221`
+- **Constat :** Analytics.tsx:221-226 et 238-243 `<Calendar mode="single" selected={dateRange.from} onSelect={...} initialFocus />` sans `locale={fr}` ni `weekStartsOn` (calendar.tsx ne définit aucune locale) ; Popover non contrôlé ; aucune validation from <= to.
+- **Impact :** Mois et jours affichés en anglais, semaine commençant le dimanche ; l'utilisateur doit cliquer à côté pour fermer ; une période inversée renvoie des graphiques vides sans explication.
+- **Recommandation :** Auto-implémenter uniquement `locale={fr}` sur les deux <Calendar> ; fermeture contrôlée du Popover, validation début ≤ fin et mode="range" à traiter avec la refonte des filtres.
+
+### ANA-19
+
+**Bouton « Temps réel » confus et partiel** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Analytics.tsx:71`
+- **Constat :** Analytics.tsx:71 `refetchInterval: isRefreshing ? 30000 : false` uniquement sur summary ; l.164-172 le bouton passe en `animate-pulse` permanent et son libellé devient « Actualisé ».
+- **Impact :** Les graphiques ne se mettent pas à jour en « temps réel » (seuls les KPI) ; le libellé suggère une action terminée ; animation clignotante fatigante ; relance aussi la requête coûteuse ANA-03.
+- **Recommandation :** Remplacer par un bouton « Actualiser » ponctuel (refetch de toutes les requêtes) avec l'heure de dernière mise à jour ; supprimer le polling.
+
+### ANA-20
+
+**fetch() manuels, logs de debug et variables mortes** — dette-code, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Analytics.tsx:58`
+- **Constat :** Analytics.tsx:58-112 quatre queryFn avec `fetch(...)` dupliquant la queryFn par défaut et `console.log('📊 [ANALYTICS] Fetching summary...')`, `console.log('✅ [ANALYTICS] Summary data received:', data)` ; `console.error` (l.64, 83) conservés en prod (vite.config.ts ne retire que log/debug) ; `user` (l.20), `selectedStoreId` (l.21), `selectedStatus` (l.30) inutilisés.
+- **Impact :** Code verbeux et difficile à maintenir ; la gestion 401 centralisée de queryClient.ts est contournée.
+- **Recommandation :** Factoriser une seule queryFn `({ queryKey: [url, params] }) => fetch(`${url}?${params}`)` partagée par les 4 requêtes, supprimer les console.log, la variable `user` (et l'import useAuthUnified) ainsi que selectedStatus/setSelectedStatus (jamais modifiés) ; conserver selectedStoreId pour ANA-14.
+
+### ANA-21
+
+**SQL brut concaténé et erreurs avalées dans timeseries / by-store** — dette-code, sévérité basse, effort M
+
+- **Fichier :** `server/storage.ts:3297`
+- **Constat :** storage.ts:3297-3341 conditions construites en chaînes `orderConditions.push(`supplier_id IN (${supplierIds})`)` puis `db.execute(sql.raw(ordersSql))` ; storage.ts:3414-3439 idem avec `${sql.raw(orderDateFilter)}` ; storage.ts:3458-3461 `catch (error) { console.error(...); return []; }`. Un `supplierIds=abc` donne `IN (NaN)` -> erreur SQL 500.
+- **Impact :** Fragile (aujourd'hui protégé seulement par Number()/toISOString), les erreurs de by-store sont masquées en « Aucune donnée magasin ».
+- **Recommandation :** Réécrire avec les helpers Drizzle (gte, inArray, sql`...` paramétré) comme getAnalyticsBySupplier, valider les paramètres avec Zod dans la route, laisser remonter les erreurs.
+
+### ANA-22
+
+**En-tête non responsive et rendu sans navigation sur mobile** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Analytics.tsx:154`
+- **Constat :** Analytics.tsx:154-155 `<div className="bg-white border-b p-6 -m-6 mb-6"><div className="flex items-center justify-between">` titre long + deux boutons sans flex-wrap ; la route mobile (RouterProduction.tsx:128) rend la page hors MobileLayout.
+- **Impact :** Sur téléphone, titre et boutons se compressent/débordent ; aucune navigation pour revenir.
+- **Recommandation :** `flex-col sm:flex-row gap-2`, supprimer le hack de marges négatives, envelopper dans MobileLayout sur mobile (cf. CONT-09).
+
+### ANA-23
+
+**Taux de rapprochement calculé sur toutes les livraisons, y compris planifiées** — bug, sévérité basse, effort S
+
+- **Fichier :** `server/storage.ts:3260`
+- **Constat :** storage.ts:3219 `reconciled: COUNT(CASE WHEN reconciled = true THEN 1 END)` et l.3260 `reconciliationRate: deliveryStats.count ? (reconciled / count) * 100 : 0` où count inclut les livraisons au statut 'planned' (pas encore livrables donc pas rapprochables).
+- **Impact :** Le taux est mécaniquement sous-estimé dès qu'il y a des livraisons futures dans la période.
+- **Recommandation :** Calculer sur les livraisons au statut 'delivered' (`COUNT(*) FILTER (WHERE status = 'delivered')`) et l'indiquer dans le libellé.
+
+### API-04
+
+**Logs serveur verbeux à chaque création de fournisseur** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:1167`
+- **Constat :** routes.ts:1167-1213 une douzaine de `console.log` dont `console.log('📋 POST /api/suppliers - Request body:', JSON.stringify(redactBody(req.body), null, 2));` et `console.log('✅ Supplier data validation passed:', data);`. Le serveur est compilé par `tsc` (package.json:8) : rien n'est retiré en production.
+- **Impact :** Pollution des logs de production, données métier écrites en clair.
+- **Recommandation :** Supprimer ces logs ou les conditionner à `process.env.NODE_ENV !== 'production'`.
+
+### API-05
+
+**Erreurs de validation renvoyées en 500 sur PUT fournisseur / contact ; filtre DLC en JS** — bug, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:1250`
+- **Constat :** routes.ts:1246 `insertSupplierSchema.partial().parse(req.body)` et l.1250-1253 `catch (error) { res.status(500).json({ message: "Failed to update supplier" }) }` ; idem routes.ts:1318-1324 pour les contacts. routes.ts:1151 `suppliers.filter(supplier => supplier.hasDlc === true)` après un SELECT complet.
+- **Impact :** Une saisie invalide apparaît comme une panne serveur ; filtrage côté Node au lieu d'un WHERE.
+- **Recommandation :** Auto-implémenter uniquement le `if (error.name === 'ZodError') return res.status(400).json({ message: 'Validation failed', errors: error.errors })` dans PUT /api/suppliers/:id et PUT /api/contacts/:id ; le paramètre dlcOnly est optionnel et non prioritaire.
+
+### CONT-10
+
+**Requête contacts non conditionnée et queryFn redondante** — perf-client, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Contacts.tsx:76`
+- **Constat :** Contacts.tsx:76-84 `useQuery({ queryKey: contactsQueryKey, queryFn: async () => { const url = effectiveGroupId ? ... ; return await apiRequest(url, "GET"); } })` : pas de `enabled`, alors que l.355-360 n'affiche rien si `!effectiveGroupId && !isAdmin`. La queryFn reconstruit l'URL que la queryFn par défaut gère déjà.
+- **Impact :** Requête et transfert inutiles quand le résultat n'est pas affiché ; code dupliqué.
+- **Recommandation :** Ajouter `enabled: isAdmin || !!effectiveGroupId` et laisser la queryFn par défaut (ou une queryFn unique construisant l'URL depuis la clé structurée de CONT-01).
+
+### CONT-11
+
+**Champ « Notes » sur une seule ligne** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Contacts.tsx:536`
+- **Constat :** Contacts.tsx:535-542 `<Label htmlFor="c-notes">Notes</Label><Input id="c-notes" ... placeholder="Notes libres..." />` alors que la colonne est un `text` (schema.ts:115).
+- **Impact :** Saisie d'horaires, consignes ou remarques longues peu lisible ; le texte déborde.
+- **Recommandation :** Utiliser le composant Textarea (rows=3).
+
+### MAIL-02
+
+**Montant du BL au format anglo-saxon dans le mail envoyé au fournisseur** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `shared/supplierMail.ts:85`
+- **Constat :** supplierMail.ts:84-86 `details.push(`Montant du BL : ${blAmount.toFixed(2)} €`);` -> « Montant du BL : 12345.50 € ».
+- **Impact :** Mail professionnel en français avec un montant au mauvais format (point décimal, pas de séparateur de milliers).
+- **Recommandation :** `new Intl.NumberFormat('fr-FR', { style: 'currency', currency: 'EUR' }).format(blAmount)` -> « 12 345,50 € ».
+
+### SALES-01
+
+**Pages Analyse des ventes jamais branchées (code mort) et texte trompeur** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/SalesAnalysisConfig.tsx:75`
+- **Constat :** `grep -rn "SalesAnalysis" client/src` : aucun import hors des deux fichiers ; RouterProduction.tsx ne déclare aucune route ; SalesAnalysisConfig.tsx:75 « Cette page sera accessible via le menu "Analyse Vente" » alors que Sidebar.tsx n'a pas cette entrée ; Utilities.tsx n'inclut pas le formulaire.
+- **Impact :** L'admin ne peut ni configurer ni consulter l'outil d'analyse ; code à maintenir pour rien.
+- **Recommandation :** Décision produit : soit ajouter la route /sales-analysis + entrée de menu « Analyse des ventes » et intégrer SalesAnalysisConfig dans Utilitaires, soit supprimer les deux fichiers et la colonne utilities.sales_analysis_url.
+
+### SALES-02
+
+**Si branchée : 403 présenté comme « URL non configurée », iframe en h-screen, URL non validée** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/SalesAnalysisPage.tsx:39`
+- **Constat :** routes.ts:340-343 /api/utilities réservé admin/directeur ; SalesAnalysisPage.tsx:20-22 ne lit pas isError, l.39-60 affiche « URL non configurée » + bouton vers /utilities (admin seulement) ; l.64 `<div className="w-full h-screen relative">` dans le Layout ; SalesAnalysisConfig.tsx:56-58 accepte n'importe quelle chaîne ; l.29-31 le champ n'est pas vidé si l'URL est supprimée.
+- **Impact :** Un manager/employé recevrait un message faux et un bouton menant à une page interdite ; double barre de défilement.
+- **Recommandation :** Exposer l'URL via un endpoint lisible par tous les rôles autorisés, gérer isError, hauteur `h-[calc(100vh-header)]`, valider l'URL (z.string().url()).
+
+### SUPP-06
+
+**ID technique affiché, code ffnancy caché, libellés jargon** — lisibilite, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Suppliers.tsx:380`
+- **Constat :** Suppliers.tsx:380 `<p className="text-sm text-gray-500">#{supplier.id}</p>` ; le champ codefou est saisi (l.543-549 « Code fournisseur API (liaison ffnancy) ») mais jamais affiché sur la carte ; les options n'ont aucune aide (« Fournisseur à contrôler », « Rapprochement automatique BL/Factures »).
+- **Impact :** Information inutile pour l'utilisateur, information utile absente, sens des options obscur pour un non-technicien.
+- **Recommandation :** Afficher « Code : FOU01 » à la place de #id ; renommer le champ en « Code fournisseur (catalogue articles ffnancy) » ou un libellé validé par le métier, et ajouter une phrase d'aide sous chaque option.
+
+### SUPP-07
+
+**Une erreur réseau s'affiche comme « Aucun fournisseur – créez votre premier fournisseur »** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Suppliers.tsx:344`
+- **Constat :** Suppliers.tsx:55-57 `const { data: suppliers = [], isLoading } = useQuery(...)` (isError non lu) ; l.344-355 `filteredSuppliers.length === 0` -> « Commencez par créer votre premier fournisseur ».
+- **Impact :** En cas de panne, l'admin peut croire que le référentiel a été effacé et recréer des fournisseurs.
+- **Recommandation :** Gérer isError avec un encart d'erreur et un bouton « Réessayer » (refetch).
+
+### SUPP-08
+
+**Recherche de stats en O(n×m) à chaque frappe, filtres non mémoïsés** — perf-client, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Suppliers.tsx:280`
+- **Constat :** Suppliers.tsx:280-283 `supplierStats.find(s => s.id === supplierId)` appelé pour chaque carte (l.370) ; l.276-278 filtre recalculé et `searchTerm.toLowerCase()` réévalué pour chaque fournisseur à chaque rendu.
+- **Impact :** Re-rendus plus lents à chaque caractère tapé quand la liste grossit.
+- **Recommandation :** `const statsById = useMemo(() => new Map(supplierStats.map(s => [s.id, s])), [supplierStats])` et `useMemo` pour filteredSuppliers avec le terme normalisé une fois.
+
+### SUPP-09
+
+**Double invalidation après modification d'un fournisseur** — perf-api, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Suppliers.tsx:156`
+- **Constat :** Suppliers.tsx:156 `queryClient.invalidateQueries({ queryKey: ['/api/suppliers'] });` dans onSuccess puis l.161-163 à nouveau dans onSettled.
+- **Impact :** Deux refetchs successifs de /api/suppliers (le premier annulé, souvent déjà parti au serveur) après chaque modification.
+- **Recommandation :** Ne garder l'invalidation que dans onSettled.
+
+### SUPP-10
+
+**Logs de debug et branche 401 morte dans les mutations** — dette-code, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Suppliers.tsx:67`
+- **Constat :** Suppliers.tsx:67-69, 103-106, 110, 122, 129 `console.log('🚚 Frontend: Creating supplier...')` ; l.82-91 `if (isUnauthorizedError(error)) { ... window.location.href = "/api/login"; }` alors que authUtils.ts:2 teste `/^401: .*Unauthorized/` et que requireAuth renvoie « Authentification requise » (localAuth.ts:252) : la branche ne s'exécute jamais, et GET /api/login n'existe pas (seul POST).
+- **Impact :** Bruit dans le code ; si la branche s'exécutait, l'utilisateur atterrirait sur « Cannot GET /api/login ».
+- **Recommandation :** Dans Suppliers.tsx uniquement : supprimer les console.log et les trois blocs `if (isUnauthorizedError(error)) {...}` (comportement inchangé, la redirection 401 est déjà assurée par queryClient pour les requêtes). La correction globale de isUnauthorizedError (regex /^401:/) et la redirection vers /auth relèvent d'un chantier séparé.
+
+### SUPP-11
+
+**Compteurs Commandes/Livraisons ambigus et indépendants du magasin sélectionné** — coherence-design, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Suppliers.tsx:61`
+- **Constat :** Suppliers.tsx:61-63 `useQuery({ queryKey: ['/api/stats/by-supplier'] })` sans storeId ; routes.ts:1511 `resolveStatsGroupIds(user, req.query.storeId)` -> tous les magasins ; l.465-474 libellés « Commandes » / « Livraisons » sans période.
+- **Impact :** L'admin qui a sélectionné un magasin voit des totaux enseigne « depuis toujours » sans le savoir.
+- **Recommandation :** Passer `storeId=selectedStoreId` (clé ['/api/stats/by-supplier', selectedStoreId]) et préciser le libellé (« Commandes (total) » ou « 12 derniers mois »).
+
+### SUPP-12
+
+**Boutons icône sans libellé ni infobulle, petits textes à faible contraste** — accessibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Suppliers.tsx:385`
+- **Constat :** Suppliers.tsx:385-399 `<Button variant="ghost" size="sm" onClick={() => handleEdit(supplier)}><Edit className="w-4 h-4" /></Button>` (idem corbeille) ; Contacts.tsx:302-304 et 403-413 identiques. Textes `text-xs text-gray-400` (Suppliers.tsx:543, Contacts.tsx:327) et `text-xs text-blue-500` (Contacts.tsx:397) sous le ratio 4,5:1.
+- **Impact :** Lecteurs d'écran annoncent « bouton » sans action ; utilisateurs peu à l'aise ne savent pas ce que fait l'icône ; textes difficiles à lire.
+- **Recommandation :** Ajouter `aria-label` et `title` (« Modifier », « Supprimer ») ; passer les textes secondaires en text-gray-500/600 et text-blue-700.
+
+### SUPP-13
+
+**Casts `as any` inutiles sur email/codefou** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Suppliers.tsx:242`
+- **Constat :** Suppliers.tsx:242-243 `codefou: (supplier as any).codefou`, `email: (supplier as any).email`, l.417-420 ; Contacts.tsx:188, 317-323, 390-391 ; alors que shared/schema.ts:95-97 déclare `codefou`, `email` et contacts.company (l.111).
+- **Impact :** Perte du typage : une faute de frappe ou un renommage de colonne ne sera pas détecté à la compilation.
+- **Recommandation :** Supprimer les `as any` (le type Supplier/Contact inféré contient déjà ces champs) et typer les mutationFn (InsertSupplier, InsertContact).

docs/audit-webui/12-admin-utilities-auth.md

@@ -0,0 +1,666 @@
+# Administration, Utilitaires & Connexion
+
+_48 constats vérifiés — 4 haute, 25 moyenne, 19 basse._
+
+## Pages analysées
+
+### `/utilities (+ routes de compatibilité /backup, /nocodb-config, /database-debug, /weather-settings ; aussi exposée sur mobile)`
+
+**Rôle :** Conteneur d'administration (admin uniquement) qui regroupe en 6 onglets : sauvegardes, configuration NocoDB, debug base de données, météo, webhook BAP, exécution SQL.
+
+**Tâches principales de l'utilisateur :**
+- Choisir un outil d'administration via les onglets
+- Accéder directement à un onglet via une ancienne URL (/backup, /nocodb-config...)
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/user | au montage (useAuthUnified : état local par instance, fetch cache:'no-cache') | server/localAuth.ts:204 → storage.getUserWithGroups (server/storage.ts:371) ; + passport.deserializeUser localAuth.ts:141 → getUserWithGroups | Refait aussi par RouterProduction, Layout, Sidebar (useAuthSimple) et chaque onglet monté : ≥5 appels par affichage, 4 requêtes SQL chacun. Tant qu'il n'a pas répondu, user=null → carte « Accès refusé » affichée. |
+
+**Lisibilité / simplicité :** Six onglets plats (grid-cols-6 fixe) mélangent outils quotidiens (sauvegardes, météo) et outils dangereux pour développeur (SQL brut, scan de schéma), avec des libellés jargon (NocoDB, BAP, Debug). Inutilisable sur téléphone (6 colonnes forcées). Double en-tête de page (Utilitaires + titre de chaque onglet), largeurs/titres/états de chargement différents d'un onglet à l'autre, onglet actif non reflété dans l'URL. Flash « Accès refusé » à chaque ouverture à cause du hook d'auth non partagé. Tous les onglets sont importés statiquement dans le bundle principal téléchargé par tous les employés.
+
+### `/utilities › onglet Sauvegardes`
+
+**Rôle :** Voir les sauvegardes de la base, en créer une manuellement, les télécharger ou les supprimer, activer/désactiver la sauvegarde automatique nocturne.
+
+**Tâches principales de l'utilisateur :**
+- Vérifier que la dernière sauvegarde est récente et réussie
+- Lancer une sauvegarde manuelle
+- Télécharger une sauvegarde
+- Supprimer une sauvegarde
+- Activer/désactiver la sauvegarde automatique
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/backups | au montage (enabled après le /api/user propre au composant) + polling toutes les 30 s | server/routes.ts:5173 → backupService.getBackupList (server/backupService.ts:159, ORDER BY created_at DESC LIMIT 10) | Requête légère mais précédée de getUserWithGroups (2 requêtes) en plus de la désérialisation ; polling inconditionnel. |
+| GET /api/utilities | au montage | server/routes.ts:333 → storage.getUser + storage.getUtilities (server/storage.ts:3015) | Lu pour l'interrupteur et la carte « Statut Système ». |
+| POST /api/utilities | clic sur l'interrupteur sauvegarde automatique | server/routes.ts:354 → getUtilities puis updateUtilities/createUtilities (server/storage.ts:3020-3031) | La réponse (config à jour) n'est pas réutilisée : invalidation + refetch ; toast calculé sur l'ancienne valeur. |
+| POST /api/backups | clic « Sauvegarde Manuelle » | server/routes.ts:5188 → backupService.createBackup (server/backupService.ts:98) | Requête HTTP ouverte pendant tout le pg_dump ; lecture synchrone du dump complet (readFileSync) pour compter les tables ; un échec laisse le statut « creating ». |
+| GET /api/backups/:filename/download | clic « Télécharger » (lien <a> créé dynamiquement) | server/routes.ts:5203 → backupService.downloadBackup (server/backupService.ts:202) | Nom de fichier non validé (path.join avec le paramètre). |
+| DELETE /api/backups/:filename | clic sur l'icône corbeille (sans confirmation) | server/routes.ts:5225 → backupService.deleteBackup (server/backupService.ts:173) | Suppression physique immédiate du fichier + enregistrement. |
+| GET /api/user | au montage (useAuthUnified) | server/localAuth.ts:204 | Bloque les deux requêtes ci-dessus (enabled: canManageBackups) → cascade. |
+
+**Lisibilité / simplicité :** Information répétée trois fois (sous-titre, carte interrupteur, carte « Statut Système »), nom de fichier technique en titre de chaque ligne, unités anglaises (Bytes), description serveur franglaise (« Manuel backup du… »). Suppression en un clic sans confirmation via un bouton icône sans libellé. Ligne de liste non responsive (pas de flex-wrap ni troncature) coupée par l'overflow-x-hidden du Layout. Bouton principal orange alors que les autres onglets utilisent le bleu. Sauvegardes ratées affichées « En cours » à vie et comptées comme « Dernière sauvegarde ». Pas de restauration proposée (à décider côté produit).
+
+### `/utilities › onglet Configuration NocoDB`
+
+**Rôle :** Gérer les connexions à la base NocoDB externe utilisée pour vérifier les factures lors du rapprochement BL/factures.
+
+**Tâches principales de l'utilisateur :**
+- Créer une configuration NocoDB
+- Modifier une configuration (URL, jeton, projet, actif)
+- Supprimer une configuration
+- Afficher le jeton API
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/nocodb-config | au montage (enabled: user?.role === 'admin', donc après le /api/user propre au composant) | server/routes.ts:5090 → storage.getUserWithGroups + storage.getNocodbConfigs (server/storage.ts:1655) | Renvoie le jeton API déchiffré au navigateur. Même queryKey réutilisée par Groups.tsx:85. |
+| POST /api/nocodb-config | soumission de la modale de création | server/routes.ts:5105 → storage.createNocodbConfig (server/storage.ts:1682) | Aucune contrainte « une seule config active ». |
+| PUT /api/nocodb-config/:id | soumission de la modale d'édition | server/routes.ts:5124 → storage.updateNocodbConfig (server/storage.ts:1688) | Le jeton en clair est renvoyé dans le formulaire puis ré-envoyé. |
+| DELETE /api/nocodb-config/:id | confirmation dans la modale de suppression | server/routes.ts:5141 → storage.deleteNocodbConfig (server/storage.ts:1701) | Pas de vérification des magasins (groups.nocodb_config_id) qui l'utilisent. |
+| GET /api/user | au montage (useAuthUnified) | server/localAuth.ts:204 | Flash « Accès restreint » tant qu'il n'a pas répondu. |
+
+**Lisibilité / simplicité :** Libellés anglais/jargon (« Personal API Token », placeholders xc-token / your-nocodb-instance), pas d'aide ni de bouton « Tester la connexion » (présent sur Météo et BAP). Jeton visible en clair avec un bouton œil. Plusieurs configurations peuvent être « Actif » sans indiquer laquelle sert réellement. Boutons Modifier/Supprimer icône seule, sans libellé ni style destructif ; suppression sans avertissement sur les magasins liés. Spinner géant (128 px) au chargement, h1 text-3xl dans un conteneur différent des autres onglets. Formulaire de création non réinitialisé, formulaires création/édition dupliqués, console.log de debug à chaque rendu.
+
+### `/utilities › onglet Debug Base de Données`
+
+**Rôle :** Outil développeur : scanner le schéma de la base de production, l'écrire dans les logs serveur et télécharger un rapport texte.
+
+**Tâches principales de l'utilisateur :**
+- Lancer le scan du schéma
+- Télécharger le rapport
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/debug/log-schema | clic « Démarrer le Scan du Schéma » (fetch manuel) | server/routes.ts:4776 → pool.query en boucle (colonnes + COUNT(*) par table, l.4813-4846) | N+1 séquentiel, COUNT(*) en scan complet, centaines de lignes console ; refuse de fonctionner hors production. |
+| GET /api/debug/download-schema | clic « Télécharger » (window.open dans un nouvel onglet) | server/routes.ts:4904 → même balayage complet (l.4971, 4984) | Refait intégralement le travail du scan précédent. |
+| GET /api/user | au montage (useAuthUnified) | server/localAuth.ts:204 | Flash « Accès refusé » tant qu'il n'a pas répondu. |
+
+**Lisibilité / simplicité :** Page entièrement orientée développeur (« logs de votre application Node.js », « Relations FK », marqueur de log à chercher), émojis dans les textes, fonctionne uniquement en production, parcours en deux temps (scan puis téléchargement qui relance le scan). N'a pas sa place au même niveau que les Sauvegardes pour un admin non technicien.
+
+### `/utilities › onglet Météo`
+
+**Rôle :** Configurer la clé API Visual Crossing et la ville du widget météo affiché dans l'en-tête de toutes les pages.
+
+**Tâches principales de l'utilisateur :**
+- Saisir la clé API et la ville
+- Détecter la ville par géolocalisation
+- Tester la connexion
+- Activer/désactiver le widget
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/weather/settings | au montage | server/routes.ts:5596 → storage.getWeatherSettings (server/storage.ts:2891) | Renvoie la clé API en clair (mise en defaultValue d'un champ password). |
+| PUT /api/weather/settings/:id (POST si aucun réglage) | soumission du formulaire (fetch manuel) | server/routes.ts:5630 / 5611 → storage.updateWeatherSettings (server/storage.ts:2901) / createWeatherSettings (2896) | Ne vide pas le cache météo même si la ville change ; le client n'invalide pas /api/weather/current. |
+| POST /api/weather/test-connection | clic « Tester la connexion » (fetch manuel) | server/routes.ts:5650 → weatherService.testApiConnection (server/weatherService.ts:220) | Messages serveur en français ; erreur client en anglais « Test connection failed ». |
+| POST /api/weather/geolocation | clic sur le bouton localisation | server/routes.ts:6094 → weatherService.getCityFromCoordinates + storage.updateWeatherSettings + storage.clearWeatherCache | Aucun contrôle de rôle admin ; le client met à jour l'input par manipulation DOM. |
+| GET /api/weather/current | WeatherWidget du Layout : montage + toutes les 30 min (non rafraîchi par cette page) | server/routes.ts:5671 → getWeatherSettings + getWeatherData×2 séquentiels (server/storage.ts:2910) + getNearestWeatherData (2930) + API externe si absent | Cache BD indexé par date seulement (pas par ville) ; pas de cache mémoire ; console.log à chaque appel. |
+
+**Lisibilité / simplicité :** Formulaire simple et plutôt clair, mais : après changement manuel de ville le widget continue d'afficher l'ancienne ville jusqu'au lendemain (cache non vidé), messages d'erreur en anglais, champs non contrôlés manipulés via document.getElementById / querySelector('form'), largeur max-w-2xl incohérente avec les autres onglets, texte « À propos » inexact (le widget est à gauche, le sélecteur de magasin à droite).
+
+### `/utilities › onglet Configuration BAP`
+
+**Rôle :** Configurer l'URL du webhook n8n qui reçoit les PDF « BAP » envoyés depuis le bouton BAP de la barre latérale.
+
+**Tâches principales de l'utilisateur :**
+- Saisir/modifier l'URL du webhook
+- Tester le webhook
+- Activer/désactiver l'envoi
+- Sauvegarder
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/webhook-bap-config | au montage | server/routes.ts:186 → storage.getUser + storage.getWebhookBapConfig (server/storage.ts:2992) | Si la table manque, renvoie une config factice avec l'URL de production codée en dur. |
+| POST /api/webhook-bap-config | clic « Sauvegarder » | server/routes.ts:222 → getWebhookBapConfig puis updateWebhookBapConfig/createWebhookBapConfig (server/storage.ts:2997-3012) | Erreur de validation Zod renvoyée en 500. |
+| POST /api/webhook-bap-config/test | clic « Tester le Webhook » (fetch manuel) | server/routes.ts:264 → fetch POST vers l'URL saisie (timeout 10 s) | Teste l'URL saisie, pas celle enregistrée. |
+
+**Lisibilité / simplicité :** Jargon (webhook, n8n, BAP non expliqué) et prénoms codés en dur (« Laurie et Jeremy ») ; interrupteur « Configuration active » sans explication de l'effet. Bouton Sauvegarder isolé en bas après la carte de test, statut « Connexion réussie » qui reste affiché après modification de l'URL, pas d'indication de modifications non enregistrées. Bouton copier icône seule. Pas de titre de section cohérent avec les autres onglets.
+
+### `/utilities › onglet Exécution SQL`
+
+**Rôle :** Exécuter du SQL brut sur la base de production (collage ou fichier .sql).
+
+**Tâches principales de l'utilisateur :**
+- Coller ou charger un script SQL
+- Exécuter
+- Lire les résultats/logs
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| POST /api/admin/execute-sql | clic « Exécuter SQL » (fetch manuel dans useMutation) | server/routes.ts:6151 → storage.getUser + db.execute(sql.raw(sqlQuery)) (l.6178) | Aucune transaction ni mode lecture seule ; renvoie toutes les lignes (results: result.rows) + un échantillon dupliqué dans logs. |
+
+**Lisibilité / simplicité :** Outil extrêmement dangereux exposé à un clic, sans confirmation ni sauvegarde préalable. Résultats non bornés rendus comme un bloc JSON géant sans retour à la ligne (whitespace non préservé) dans une zone sans hauteur max. Bouton obsolète « SQL Webhook BAP » qui écrase l'éditeur et contient une URL de production. Message « Début de l'exécution » effacé aussitôt.
+
+### `/auth (et toute URL quand l'utilisateur n'est pas connecté)`
+
+**Rôle :** Écran de connexion (identifiant + mot de passe) avec visuel de présentation sur grand écran.
+
+**Tâches principales de l'utilisateur :**
+- Se connecter
+- Voir les identifiants par défaut lors de la première installation
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/user | au montage, deux fois (RouterProduction puis AuthPage, chacun via useAuthUnified) | server/localAuth.ts:204 → storage.getUserWithGroups (server/storage.ts:371) | Renvoie 401 pour un visiteur ; provoque deux spinners plein écran successifs. |
+| GET /api/default-credentials-check | au montage | server/localAuth.ts:234 → storage.getUserByUsername('admin') (server/storage.ts:351) | Endpoint public ; carte admin/admin affichée par défaut avant la réponse. |
+| POST /api/login | soumission du formulaire (fetch manuel en « production », useMutation sinon) | server/localAuth.ts:153 → LocalStrategy (getUserByUsername + scrypt) puis await backupService.checkAndPerformDailyBackup (server/backupService.ts:240) | Peut attendre un pg_dump complet avant de répondre ; puis côté client attente artificielle de 500 ms + rechargement complet. |
+
+**Lisibilité / simplicité :** Formulaire simple et lisible, mais : deux spinners avant l'affichage, chargement initial lourd (~1,7 Mo JS non compressé + script tiers replit.com bloquant, lang=en déclenchant la traduction Chrome, zoom mobile désactivé), champs sans autoComplete/autoCapitalize (majuscule automatique sur mobile → échec de connexion, comparaison sensible à la casse), identifiants admin/admin affichés par défaut, messages d'erreur trompeurs en cas de blocage (rate-limit) ou de CSRF, anglicisme « across tous vos magasins », 500 ms d'attente + rechargement complet après connexion, sessions en mémoire perdues à chaque redémarrage.
+
+### `(aucune — page non routée) Landing`
+
+**Rôle :** Ancienne page d'accueil marketing (héritage Replit Auth), jamais importée.
+
+**Tâches principales de l'utilisateur :**
+- Aucune (code mort)
+
+**Lisibilité / simplicité :** Code mort : non importée par le routeur, ses boutons redirigent vers GET /api/login qui n'existe pas (seul POST existe). Branding « La Foir'Fouille » codé en dur, classes Tailwind personnalisées. À supprimer.
+
+### `* (404, desktop dans Layout et mobile dans MobileApp)`
+
+**Rôle :** Page affichée pour une URL inconnue quand l'utilisateur est connecté.
+
+**Tâches principales de l'utilisateur :**
+- Comprendre que la page n'existe pas et revenir à l'application
+
+**Lisibilité / simplicité :** Message de développeur en anglais (« 404 Page Not Found », « Did you forget to add the page to the router? »), aucun bouton de retour, min-h-screen à l'intérieur du Layout (double hauteur d'écran).
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [ADMIN-01](#admin-01) | haute | bug | M | Hook d'auth non partagé : flash « Accès refusé » et cascade de /api/user à chaque onglet | `client/src/hooks/useAuthUnified.ts:23` |
+| [AUTH-01](#auth-01) | haute | perf-bundle | S | Script tiers replit.com bloquant en production, lang="en" et zoom désactivé | `client/index.html:19` |
+| [BACKUP-01](#backup-01) | haute | ux-simplicite | S | Suppression d'une sauvegarde en un clic, sans confirmation | `client/src/pages/BackupManager.tsx:142` |
+| [SQL-01](#sql-01) | haute | ux-simplicite | M | Exécution de SQL brut en production sans confirmation ni filet de sécurité | `client/src/pages/SQLExecutor.tsx:97` |
+| [ADMIN-02](#admin-02) | moyenne | perf-api | S | /api/user exécute 4 requêtes SQL alors que req.user est déjà chargé | `server/localAuth.ts:210` |
+| [AUTH-02](#auth-02) | moyenne | perf-serveur | S | Fichiers statiques servis sans compression ni cache long | `server/index.production.ts:143` |
+| [AUTH-03](#auth-03) | moyenne | perf-client | M | Double vérification d'auth, double spinner, puis 500 ms d'attente et rechargement complet | `client/src/pages/AuthPage.tsx:69` |
+| [AUTH-04](#auth-04) | moyenne | bug | S | Identifiants admin/admin affichés par défaut avant (et sans) vérification | `client/src/pages/AuthPage.tsx:25` |
+| [AUTH-05](#auth-05) | moyenne | accessibilite | S | Champs de connexion sans autoComplete/autoCapitalize (échecs sur mobile) | `client/src/pages/AuthPage.tsx:224` |
+| [AUTH-06](#auth-06) | moyenne | bug | S | Sessions stockées en mémoire en production (fichier d'auth PostgreSQL jamais utilisé) | `server/routes.ts:119` |
+| [AUTH-07](#auth-07) | moyenne | bug | S | CSRF activé en production (npm start) mais jamais envoyé par le client | `server/index.ts:40` |
+| [BACKUP-02](#backup-02) | moyenne | bug | S | Une sauvegarde ratée reste « En cours » indéfiniment | `server/backupService.ts:153` |
+| [BACKUP-03](#backup-03) | moyenne | perf-serveur | S | Le dump complet est relu en mémoire de façon synchrone pour compter les tables | `server/backupService.ts:134` |
+| [BACKUP-04](#backup-04) | moyenne | perf-api | S | La connexion attend la vérification (voire l'exécution) de la sauvegarde quotidienne | `server/localAuth.ts:165` |
+| [BACKUP-06](#backup-06) | moyenne | lisibilite | S | Informations répétées trois fois et libellés techniques | `client/src/pages/BackupManager.tsx:205` |
+| [BACKUP-07](#backup-07) | moyenne | accessibilite | S | Ligne de sauvegarde non responsive et bouton supprimer sans nom accessible | `client/src/pages/BackupManager.tsx:366` |
+| [BACKUP-09](#backup-09) | moyenne | bug | S | Téléchargement de sauvegarde vulnérable au path traversal | `server/backupService.ts:203` |
+| [BAP-01](#bap-01) | moyenne | lisibilite | S | Jargon technique et prénoms codés en dur | `client/src/pages/WebhookBAPConfig.tsx:166` |
+| [DEBUG-01](#debug-01) | moyenne | perf-serveur | S | Scan de schéma en N+1 avec COUNT(*) complet, refait pour le téléchargement | `server/routes.ts:4831` |
+| [DEBUG-02](#debug-02) | moyenne | ux-simplicite | S | Outil développeur incompréhensible pour un admin non technicien | `client/src/pages/DatabaseDebug.tsx:73` |
+| [ERR-01](#err-01) | moyenne | lisibilite | M | Messages d'erreur bruts (code HTTP + JSON, en anglais) affichés dans les toasts | `client/src/lib/queryClient.ts:6` |
+| [NF-01](#nf-01) | moyenne | lisibilite | S | Page 404 en anglais avec message de développeur et sans retour | `client/src/pages/not-found.tsx:11` |
+| [NOCO-01](#noco-01) | moyenne | bug | S | Jeton API NocoDB déchiffré envoyé au navigateur et affiché en clair | `server/storage.ts:1657` |
+| [NOCO-03](#noco-03) | moyenne | ux-simplicite | M | Plusieurs configurations « Actif » possibles, une seule utilisée au hasard | `server/storage.ts:1665` |
+| [SQL-02](#sql-02) | moyenne | perf-api | S | Résultats SQL non bornés, dupliqués et rendus en un bloc illisible | `server/routes.ts:6197` |
+| [UTIL-01](#util-01) | moyenne | ux-simplicite | M | Six onglets plats mêlant outils quotidiens et outils dangereux, inutilisables sur mobile | `client/src/pages/Utilities.tsx:81` |
+| [UTIL-03](#util-03) | moyenne | perf-bundle | M | Pages admin importées statiquement dans le bundle principal de tous les utilisateurs | `client/src/components/RouterProduction.tsx:17` |
+| [WEATHER-01](#weather-01) | moyenne | bug | S | Changer la ville ne met pas à jour le widget météo (cache non vidé, requête non invalidée) | `server/routes.ts:5639` |
+| [WEATHER-02](#weather-02) | moyenne | bug | S | Géolocalisation météo modifiable par n'importe quel utilisateur connecté | `server/routes.ts:6096` |
+| [ADMIN-03](#admin-03) | basse | perf-serveur | S | Chaque handler admin relit l'utilisateur en BD pour vérifier le rôle | `server/routes.ts:5175` |
+| [AUTH-08](#auth-08) | basse | bug | S | Limite de 5 connexions/15 min par IP et message d'erreur trompeur | `client/src/pages/AuthPage.tsx:76` |
+| [AUTH-09](#auth-09) | basse | dette-code | S | Deux implémentations de connexion, hook appelé hors rendu, double soumission | `client/src/pages/AuthPage.tsx:171` |
+| [BACKUP-05](#backup-05) | basse | perf-client | S | Polling 30 s inconditionnel de la liste des sauvegardes | `client/src/pages/BackupManager.tsx:61` |
+| [BACKUP-08](#backup-08) | basse | bug | S | Toast de l'interrupteur calculé sur l'ancienne valeur et bascule différée | `client/src/pages/BackupManager.tsx:78` |
+| [BACKUP-10](#backup-10) | basse | coherence-design | S | Double en-tête de page et bouton principal orange | `client/src/pages/BackupManager.tsx:196` |
+| [BAP-02](#bap-02) | basse | ux-simplicite | S | Bouton Sauvegarder isolé et statut de test périmé | `client/src/pages/WebhookBAPConfig.tsx:251` |
+| [BAP-03](#bap-03) | basse | bug | S | Validation renvoyée en 500 et configuration factice avec URL de production | `server/routes.ts:236` |
+| [LAND-01](#land-01) | basse | dette-code | S | Page Landing morte qui pointe vers une route inexistante | `client/src/pages/Landing.tsx:7` |
+| [NOCO-02](#noco-02) | basse | dette-code | S | Log de debug à chaque rendu et code défensif opaque | `client/src/pages/NocoDBConfig.tsx:66` |
+| [NOCO-04](#noco-04) | basse | accessibilite | S | Boutons Modifier/Supprimer icône seule et suppression sans avertissement d'impact | `client/src/pages/NocoDBConfig.tsx:300` |
+| [NOCO-05](#noco-05) | basse | bug | S | Formulaire de création non réinitialisé après succès | `client/src/pages/NocoDBConfig.tsx:84` |
+| [NOCO-06](#noco-06) | basse | dette-code | S | Formulaires de création et d'édition dupliqués | `client/src/pages/NocoDBConfig.tsx:371` |
+| [NOCO-07](#noco-07) | basse | lisibilite | M | Libellés anglais/jargon et aucun test de connexion | `client/src/pages/NocoDBConfig.tsx:406` |
+| [SQL-03](#sql-03) | basse | dette-code | S | Bouton « SQL Webhook BAP » obsolète, état dupliqué et log de démarrage effacé | `client/src/pages/SQLExecutor.tsx:100` |
+| [UTIL-02](#util-02) | basse | ux-simplicite | S | Onglet actif non reflété dans l'URL | `client/src/pages/Utilities.tsx:28` |
+| [UTIL-04](#util-04) | basse | coherence-design | M | Conteneurs, titres et états de chargement différents dans chaque onglet | `client/src/pages/NocoDBConfig.tsx:231` |
+| [WEATHER-03](#weather-03) | basse | dette-code | S | Formulaire non contrôlé manipulé via le DOM, fetch manuels et erreurs en anglais | `client/src/pages/WeatherSettings.tsx:318` |
+| [WEATHER-04](#weather-04) | basse | perf-serveur | S | /api/weather/current recalculé à chaque appel sans cache mémoire | `server/routes.ts:5683` |
+
+### ADMIN-01
+
+**Hook d'auth non partagé : flash « Accès refusé » et cascade de /api/user à chaque onglet** — bug, sévérité haute, effort M
+
+- **Fichier :** `client/src/hooks/useAuthUnified.ts:23`
+- **Constat :** useAuthUnified.ts:23-24 `const [productionUser, setProductionUser] = useState<any>(null); const [productionLoading, setProductionLoading] = useState(true);` + useEffect l.148-167 `fetch('/api/user', { credentials: 'include', cache: 'no-cache' ...})` : état local par instance. Utilities.tsx:26 `const { user } = useAuthUnified();` puis l.45 `if (!canManageBackups && !canManageNocoDB && ...) return (... Accès refusé ...)` sans tenir compte d'isLoading ; même schéma BackupManager.tsx:48/54/177, NocoDBConfig.tsx:45/211 (« Accès restreint »), DatabaseDebug.tsx:8/41. Les requêtes attendent ce second appel : BackupManager.tsx:60 `enabled: canManageBackups`, NocoDBConfig.tsx:58 `enabled: user?.role === 'admin'`.
+- **Impact :** À l'ouverture de /utilities, l'admin voit une carte « Accès refusé » (Utilities), puis une seconde (onglet), puis un spinner : 3 allers-retours séquentiels (/api/user → /api/user → /api/backups) avant la liste. /api/user est appelé ≥5 fois par affichage (RouterProduction, Layout, Sidebar via useAuthSimple, Utilities, onglet) et de nouveau à chaque changement d'onglet.
+- **Recommandation :** Source unique : `useQuery({ queryKey: ['/api/user'], queryFn: getQueryFn({ on401: 'returnNull' }) sans redirection, staleTime: 5*60_000, retry: false })`. Attention : le queryFn par défaut (queryClient.ts:56-61) fait `window.location.href = '/auth'` sur un 401, ce qui changerait le comportement de RouterProduction (il affiche aujourd'hui AuthPage directement sur '/'). Il faut donc un queryFn dédié qui renvoie null sans rediriger. Garder la même forme de retour { user, isLoading, isAuthenticated, refreshAuth, forceAuthRefresh } pour les ~15 appelants, et faire de useAuthSimple un alias. Dans Utilities, afficher un skeleton tant que isLoading. Les contrôles de rôle dans les onglets peuvent ensuite être retirés (Utilities est le seul point d'entrée de ces pages).
+
+### AUTH-01
+
+**Script tiers replit.com bloquant en production, lang="en" et zoom désactivé** — perf-bundle, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/index.html:19`
+- **Constat :** client/index.html:18-19 `<script type="text/javascript" src="https://replit.com/public/js/replit-dev-banner.js"></script>` (classique, sans async/defer) présent aussi dans dist/public/index.html ; l.2 `<html lang="en">` ; l.5 `content="width=device-width, initial-scale=1.0, maximum-scale=1"`.
+- **Impact :** Le module de l'application (différé) ne s'exécute qu'après le téléchargement de ce script tiers : si replit.com est lent ou filtré par le réseau du magasin, l'écran reste blanc jusqu'au timeout. Chrome propose de « traduire depuis l'anglais » une interface française ; zoom bloqué sur mobile (malvoyants).
+- **Recommandation :** Partie mécanique : supprimer la balise replit (l.18-19) et passer `lang="fr"`. Le retrait de `maximum-scale=1` est souhaitable pour l'accessibilité, mais il faut d'abord vérifier que les champs natifs ont une police d'au moins 16px sur mobile. À traiter séparément.
+
+### BACKUP-01
+
+**Suppression d'une sauvegarde en un clic, sans confirmation** — ux-simplicite, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/BackupManager.tsx:142`
+- **Constat :** l.142-145 `const handleDelete = (filename: string) => { setDeletingBackup(filename); deleteBackupMutation.mutate(filename); };` appelé directement par l.388-391 `<Button variant="outline" size="sm" onClick={() => handleDelete(backup.filename)} ... className="text-red-600 hover:text-red-700">` (icône Trash2 seule). Côté serveur backupService.ts:186-193 `fs.unlinkSync(filepath)` puis suppression de l'enregistrement.
+- **Impact :** Un clic accidentel (bouton sans libellé collé à « Télécharger ») détruit définitivement une sauvegarde, potentiellement la seule récente. Incohérent avec NocoDBConfig qui demande confirmation (l.631-662).
+- **Recommandation :** AlertDialog « Supprimer la sauvegarde du 02/10/2026 à 02:00 ? Cette action est définitive. » avec bouton destructif « Supprimer » ; aria-label/title « Supprimer » sur l'icône ; interdire la suppression de la dernière sauvegarde terminée.
+
+### SQL-01
+
+**Exécution de SQL brut en production sans confirmation ni filet de sécurité** — ux-simplicite, sévérité haute, effort M
+
+- **Fichier :** `client/src/pages/SQLExecutor.tsx:97`
+- **Constat :** SQLExecutor.tsx:86-97 `handleExecuteSQL` → `executeMutation.mutate(sqlContent);` sans confirmation ; serveur routes.ts:6178 `const result = await db.execute(sql.raw(sqlQuery));` hors transaction, sans mode lecture seule ; seul garde-fou : le texte d'avertissement l.144-155.
+- **Impact :** Un clic sur « Exécuter SQL » applique immédiatement un DROP/DELETE/UPDATE sur la base de production, sans retour arrière ni sauvegarde préalable ; risque majeur de perte de données (script collé par erreur, admin non technicien).
+- **Recommandation :** Masquer l'onglet par défaut (variable d'env `ENABLE_SQL_EXECUTOR`) ; sinon détecter les mots-clés destructifs (DROP, DELETE, UPDATE, TRUNCATE, ALTER) → AlertDialog exigeant de taper « EXÉCUTER », sauvegarde automatique avant exécution, option « lecture seule » exécutée dans `BEGIN TRANSACTION READ ONLY`.
+
+### ADMIN-02
+
+**/api/user exécute 4 requêtes SQL alors que req.user est déjà chargé** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `server/localAuth.ts:210`
+- **Constat :** localAuth.ts:141-143 `passport.deserializeUser(async (id) => { const user = await storage.getUserWithGroups(id); done(null, user); })` puis dans GET /api/user l.210-211 `const userId = (req.user as SelectUser).id; const userWithGroups = await storage.getUserWithGroups(userId);`. storage.ts:371-388 : `const user = await this.getUser(id);` puis un second `db.execute(sql`SELECT ... FROM user_groups ug INNER JOIN groups g ...`)` en série.
+- **Impact :** Chaque /api/user = 2 requêtes (désérialisation) + 2 requêtes (handler) séquentielles ; multiplié par ≥5 appels par navigation (ADMIN-01) ≈ 20 allers-retours BD rien que pour l'authentification à chaque page.
+- **Recommandation :** Seule la partie 1 est mécanique : dans GET /api/user, construire la réponse à partir de `req.user` (déjà un UserWithGroups fourni par deserializeUser) avec exactement les mêmes champs, `userGroups: req.user.userGroups || []`. La branche 404 disparaît : un utilisateur supprimé donne alors 401 via isAuthenticated(), ce qui reste acceptable. La réécriture de getUserWithGroups en json_agg (partie 2) est à traiter à part. La fonction est appelée ~106 fois dans routes.ts, et json_agg renvoie createdAt/updatedAt en chaînes au lieu d'objets Date. MemStorage (storage.ts:3606) doit aussi garder la même forme.
+
+### AUTH-02
+
+**Fichiers statiques servis sans compression ni cache long** — perf-serveur, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/index.production.ts:143`
+- **Constat :** index.production.ts:143-144 `app.use('/assets', express.static(join(publicPath, 'assets'))); app.use('/', express.static(publicPath));` sans maxAge/immutable ni compression ; server/vite.ts:79 `app.use(express.static(distPath));` idem ; `setupCompression` (server/cache.ts:93-100) n'est appelé nulle part et ne ferait que poser `Content-Encoding: gzip` sans compresser.
+- **Impact :** ~1,7 Mo de JS + 120 Ko de CSS transférés non compressés au premier affichage de /auth (≈ 4-5× plus qu'en gzip), puis revalidés à chaque ouverture alors que les noms de fichiers sont hachés.
+- **Recommandation :** Partie sûre : `app.use('/assets', express.static(assetsPath, { maxAge: '1y', immutable: true }))` dans index.production.ts et dans serveStatic (vite.ts), et `Cache-Control: no-cache` sur l'envoi d'index.html. Pour la compression : d'abord vérifier la configuration nginx. Sinon, ajouter la dépendance `compression`, la déclarer `--external:compression` dans le Dockerfile et l'installer en production. Supprimer setupCompression.
+
+### AUTH-03
+
+**Double vérification d'auth, double spinner, puis 500 ms d'attente et rechargement complet** — perf-client, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/AuthPage.tsx:69`
+- **Constat :** RouterProduction.tsx:56 appelle useAuthUnified (fetch /api/user) et affiche un spinner l.79-88 ; AuthPage.tsx:23 rappelle useAuthUnified (nouveau fetch, état local) et affiche un second spinner plein écran l.180-189 ; après succès l.68-71 `setTimeout(() => { window.location.href = "/"; }, 500);` alors que POST /api/login renvoie déjà l'utilisateur (localAuth.ts:174-182).
+- **Impact :** Deux spinners successifs avant le formulaire ; après validation, 500 ms d'attente artificielle + rechargement complet de l'application (revalidation des 1,7 Mo, nouvelle cascade de /api/user) avant le tableau de bord.
+- **Recommandation :** Lire l'état d'auth depuis la source partagée (ADMIN-01) sans nouveau fetch ; après login : `queryClient.setQueryData(['/api/user'], user)` puis `setLocation('/')`, sans reload ni délai.
+
+### AUTH-04
+
+**Identifiants admin/admin affichés par défaut avant (et sans) vérification** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/AuthPage.tsx:25`
+- **Constat :** l.25 `const [showDefaultCredentials, setShowDefaultCredentials] = useState(true);` ; l.41-45 en cas d'erreur `return { showDefault: true };` ; l.256-273 « Identifiant : admin / Mot de passe : admin » ; endpoint public localAuth.ts:234-241 `res.json({ showDefault: !!showDefault })` sans authentification.
+- **Impact :** Les identifiants par défaut s'affichent à chaque ouverture de l'écran de connexion le temps de la requête (en permanence si elle échoue), même après changement du mot de passe ; un visiteur peut savoir si le compte admin a toujours son mot de passe d'origine.
+- **Recommandation :** Valeur initiale `false`, afficher seulement si la réponse vaut `true`, `false` en cas d'erreur ; à terme limiter l'endpoint au premier démarrage.
+
+### AUTH-05
+
+**Champs de connexion sans autoComplete/autoCapitalize (échecs sur mobile)** — accessibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/AuthPage.tsx:224`
+- **Constat :** l.224-231 `<Input id="login-username" type="text" value={loginData.username} ... required placeholder="Votre identifiant" />` et l.234-242 champ mot de passe, sans autoComplete, autoCapitalize, autoCorrect ni spellCheck ; serveur storage.ts:351-353 `db.select().from(users).where(eq(users.username, username))` : comparaison sensible à la casse, sans trim.
+- **Impact :** Sur téléphone/tablette, le clavier met une majuscule (« Admin ») ou un espace final → « Identifiant ou mot de passe incorrect » alors que l'utilisateur a bien tapé ; gestionnaires de mots de passe mal détectés.
+- **Recommandation :** Partie automatisable : `autoComplete="username" autoCapitalize="none" autoCorrect="off" spellCheck={false}` sur l'identifiant, `autoComplete="current-password"` sur le mot de passe, et `username.trim()` avant envoi. La comparaison `lower(username)` côté serveur est une décision séparée (risque de doublons de casse existants en base).
+
+### AUTH-06
+
+**Sessions stockées en mémoire en production (fichier d'auth PostgreSQL jamais utilisé)** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:119`
+- **Constat :** routes.ts:4 `import { setupLocalAuth, requireAuth } from "./localAuth";`, l.119 `const setupAuth = setupLocalAuth;`, l.183 `await setupAuth(app);` → localAuth.ts:96-110 `console.log('🔧 Using memory session store for development'); ... app.use(session(sessionSettings));` sans `store`, cookie `maxAge: 24 * 60 * 60 * 1000` (l.106). index.production.ts:8 importe localAuth.production.js (store PostgreSQL l.142-147) mais n'appelle jamais son setupLocalAuth.
+- **Impact :** Chaque redémarrage/déploiement déconnecte tous les magasins ; MemoryStore fuit en mémoire ; reconnexion obligatoire chaque jour.
+- **Recommandation :** Utiliser connect-pg-simple (déjà importé à localAuth.ts:9) quand DATABASE_URL est défini. Pour `secure: true` derrière le proxy nginx, ajouter aussi `app.set('trust proxy', 1)` (présent seulement dans localAuth.production.ts:161), sinon le cookie n'est pas émis et la connexion casse. Supprimer localAuth.production.ts seulement après avoir retiré l'import à index.production.ts:8.
+
+### AUTH-07
+
+**CSRF activé en production (npm start) mais jamais envoyé par le client** — bug, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/index.ts:40`
+- **Constat :** index.ts:39-42 `if (process.env.NODE_ENV === 'production') { setupCsrfProtection(app); }` ; security.ts:59-70 rejette tout POST/PUT/DELETE dont l'en-tête `x-csrf-token` ne correspond pas au cookie ; aucune occurrence de « csrf » dans client/src (AuthPage.tsx:53-60 `fetch('/api/login', { method: 'POST', headers: { 'Content-Type': 'application/json' }, ...})`). L'exemption security.ts:50-53 `'/api/webhook'` testée par `startsWith` exempte aussi `/api/webhook-bap-config`.
+- **Impact :** Avec le script `start` de package.json (`node dist/server/index.js`), la connexion échoue en 403 avec le message anglais « Request rejected due to security validation failure », ainsi que toutes les mutations des autres pages.
+- **Recommandation :** Centraliser l'envoi de `x-csrf-token` (lu dans le cookie `csrf_token`) dans apiRequest, et faire passer par lui les fetch d'écriture (AuthPage, WeatherSettings, SQLExecutor, WebhookBAPConfig…). Corriger l'exemption en `/api/webhook/`. Décider ensuite si index.production.ts doit appliquer les mêmes middlewares de sécurité qu'index.ts.
+
+### BACKUP-02
+
+**Une sauvegarde ratée reste « En cours » indéfiniment** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/backupService.ts:153`
+- **Constat :** backupService.ts:106-115 insère d'abord `status: 'creating'` ; en cas d'échec de pg_dump, l.153-156 `} catch (error) { console.error('❌ Backup failed:', error); throw new Error(`Backup failed: ...`) }` sans mise à jour du statut. BackupManager.tsx:170-171 prévoit `case 'failed': return <Badge variant="destructive">Échec</Badge>;` jamais atteint ; l.286-294 « Dernière Sauvegarde » affiche `backups[0]` quel que soit son statut.
+- **Impact :** Une sauvegarde échouée est affichée « En cours » pour toujours, présentée comme « Dernière sauvegarde » et occupe une des 10 places : l'admin croit la base protégée alors qu'elle ne l'est pas.
+- **Recommandation :** Sortir `id` et `filepath` du try (ils sont déclarés dedans, donc inaccessibles dans le catch). Dans le catch : `await db.update(databaseBackups).set({ status: 'failed' }).where(eq(databaseBackups.id, id))` et supprimer le fichier partiel s'il existe. Dans les deux vérifications quotidiennes, ne considérer que `status = 'completed'`, pour qu'un échec soit retenté. Côté client : « Dernière sauvegarde » = premier élément `completed`, et un bandeau si la dernière tentative a échoué.
+
+### BACKUP-03
+
+**Le dump complet est relu en mémoire de façon synchrone pour compter les tables** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/backupService.ts:134`
+- **Constat :** backupService.ts:131 `await execAsync(command, { env });` puis l.133-135 `const stats = fs.statSync(filepath); const sqlContent = fs.readFileSync(filepath, 'utf8'); const tablesCount = (sqlContent.match(/CREATE TABLE/g) || []).length;`. routes.ts:5195-5196 `const backup = await backupService.createBackup('manual', user.id); res.json(backup);`.
+- **Impact :** Le fichier de dump (dizaines/centaines de Mo si la base contient logos/PDF en base64) est chargé en mémoire et parcouru par regex sur le thread principal : toutes les requêtes API des magasins sont gelées pendant ce temps (sauvegarde nocturne, manuelle ou déclenchée au login) ; pic mémoire du process.
+- **Recommandation :** Remplacer par `const stats = await fs.promises.stat(filepath)` et un comptage SQL qui reste proche de ce que pg_dump inclut (toutes les tables utilisateur, pas seulement public) : `SELECT count(*) FROM information_schema.tables WHERE table_type = 'BASE TABLE' AND table_schema NOT IN ('pg_catalog','information_schema')`. Ainsi le nombre de tables affiché ne change pas sensiblement.
+
+### BACKUP-04
+
+**La connexion attend la vérification (voire l'exécution) de la sauvegarde quotidienne** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `server/localAuth.ts:165`
+- **Constat :** localAuth.ts:160-172 `req.login(user, async (err) => { ... const backupResult = await backupService.checkAndPerformDailyBackup(user.id); ... res.json({...})`. backupService.ts:240-285 : 2 requêtes (utilities, database_backups) puis, si aucune sauvegarde automatique n'existe pour la date UTC du jour, `await this.createBackup('automatic', resolvedUserId);` (pg_dump complet), sans verrou.
+- **Impact :** Chaque connexion paie 2 requêtes supplémentaires ; la première connexion du jour sans sauvegarde (serveur redémarré, avant 2h, échec nocturne) reste bloquée sur « Connexion... » pendant tout le pg_dump ; deux connexions simultanées peuvent lancer deux dumps.
+- **Recommandation :** Ne plus attendre : `setImmediate(() => backupService.checkAndPerformDailyBackup(user.id).catch(console.error))`, puis `res.json(...)` immédiatement (même corps de réponse). Ajouter dans BackupService une promesse « en cours » (`if (this.running) return this.running`) partagée par checkAndPerformDailyBackup et scheduleAutomaticBackup. Supprimer l'appel au login est une décision produit séparée.
+
+### BACKUP-06
+
+**Informations répétées trois fois et libellés techniques** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/BackupManager.tsx:205`
+- **Constat :** Même état répété : en-tête l.205 « Sauvegarde automatique quotidienne à 2h00 - Maximum 10 fichiers conservés », carte l.232-247 « Configuration des Sauvegardes Automatiques… Les sauvegardes automatiques sont actives », carte l.302-317 « Statut Système… Actif / Sauvegarde automatique 2h00 ». Titre de ligne = nom de fichier l.360-361 `{backup.filename}` (ex. backup_automatic_2026-10-02T00-00-01-123Z.sql), « PostgreSQL » l.328, unités anglaises l.148 `['Bytes', 'KB', 'MB', 'GB']`, description serveur franglaise backupService.ts:108 `${type === 'manual' ? 'Manuel' : 'Automatique'} backup du ...`.
+- **Impact :** Page dense et technique ; l'information utile (« ma dernière sauvegarde est-elle récente et réussie ? ») est noyée pour un admin non informaticien.
+- **Recommandation :** Fusionner interrupteur + statut en une carte (« Sauvegarde automatique chaque nuit : Activée — dernière réussie cette nuit à 02:00 »). Ligne : titre « Sauvegarde automatique — jeu. 2 oct. 2026, 02:00 », sous-titre « 12,4 Mo », nom de fichier en infobulle. Unités o/Ko/Mo/Go ; description « Sauvegarde manuelle du … ».
+
+### BACKUP-07
+
+**Ligne de sauvegarde non responsive et bouton supprimer sans nom accessible** — accessibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/BackupManager.tsx:366`
+- **Constat :** l.349-353 `<div className="flex items-center justify-between p-4 border rounded-lg"><div className="flex items-center space-x-4">` et l.366 `<div className="text-sm text-gray-500 flex items-center space-x-4 mt-1">` (date + taille + tables + 2 badges) sans flex-wrap ; nom de fichier l.360 sans truncate ; bouton l.388-400 icône seule sans aria-label. Conteneur parent Layout.tsx:211 `overflow-x-hidden` ; route /utilities exposée sur mobile (RouterProduction.tsx:125).
+- **Impact :** Sur tablette, sidebar ouverte ou téléphone, la ligne déborde et les boutons Télécharger/Supprimer sont coupés ; lecteur d'écran : bouton « sans nom ».
+- **Recommandation :** Remplacer `space-x-4` par `flex-wrap gap-x-4 gap-y-1`, ajouter `min-w-0 truncate` sur le nom, `flex-col sm:flex-row` pour empiler les actions, `aria-label="Supprimer la sauvegarde"` + `title`.
+
+### BACKUP-09
+
+**Téléchargement de sauvegarde vulnérable au path traversal** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/backupService.ts:203`
+- **Constat :** backupService.ts:202-209 `async downloadBackup(filename: string) { const filepath = path.join(this.backupDir, filename); if (!fs.existsSync(filepath)) throw ...; return filepath; }` appelé par routes.ts:5210-5213 `const { filename } = req.params; const filepath = await backupService.downloadBackup(filename); res.download(filepath, filename, ...)` sans vérifier l'existence en BD (contrairement à deleteBackup l.175-183).
+- **Impact :** `/api/backups/..%2F..%2F.env/download` (paramètre décodé par Express) permet de lire des fichiers hors du dossier de sauvegarde (.env avec DATABASE_URL, SESSION_SECRET) depuis une session admin.
+- **Recommandation :** Dans downloadBackup (et deleteBackup) : rejeter si `!/^backup_(manual|automatic)_[\w-]+\.sql$/.test(filename)`, puis vérifier `path.resolve(filepath).startsWith(path.resolve(this.backupDir) + path.sep)`. Le format actuel `backup_${type}_${ISO avec : et . remplacés par -}.sql` passe la regex.
+
+### BAP-01
+
+**Jargon technique et prénoms codés en dur** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/WebhookBAPConfig.tsx:166`
+- **Constat :** l.163 « Configuration Webhook BAP », l.166 « Configurez l'URL du webhook n8n pour l'envoi des fichiers BAP vers Laurie et Jeremy », l.181 « URL du Webhook n8n * », l.195 « URL complète du webhook n8n qui recevra les fichiers PDF BAP », l.246 « Tester le Webhook », l.216 interrupteur « Configuration active » sans explication.
+- **Impact :** Jargon (webhook, n8n) et sigle BAP non expliqué ; prénoms qui deviendront faux au prochain changement d'équipe ; l'admin ne sait pas ce que fait l'interrupteur.
+- **Recommandation :** Titre « Envoi automatique des BAP (bons à payer) », champ « Adresse de réception (fournie par votre informaticien) », description sans prénoms (ou destinataires configurables), aide sous l'interrupteur : « Désactivé : le bouton BAP n'enverra plus de fichiers ».
+
+### DEBUG-01
+
+**Scan de schéma en N+1 avec COUNT(*) complet, refait pour le téléchargement** — perf-serveur, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:4831`
+- **Constat :** routes.ts:4813-4846 `for (const tableRow of tablesResult.rows) { ... const columnsResult = await pool.query(columnsQuery, [tableName]); ... const countQuery = `SELECT COUNT(*) as total FROM "${tableName}"`; await pool.query(countQuery); }` ; /api/debug/download-schema refait le même balayage (l.4971 et 4984) ; DatabaseDebug.tsx:104-113 n'affiche « Télécharger » qu'après le scan.
+- **Impact :** ≈ 2 requêtes séquentielles par table (dont un COUNT(*) en scan complet sur les grosses tables), exécutées deux fois pour obtenir le fichier, plus des centaines de lignes de log.
+- **Recommandation :** Priorité basse. Une seule requête information_schema.columns regroupée en JS, des comptes exacts en Promise.all (ou n_live_tup en l'indiquant « ≈ » dans le rapport), et un endpoint unique qui renvoie directement le fichier.
+
+### DEBUG-02
+
+**Outil développeur incompréhensible pour un admin non technicien** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/DatabaseDebug.tsx:73`
+- **Constat :** l.73-75 « scanner votre base de données de production et logger toutes les tables, colonnes et relations dans les logs du serveur », l.80-81 « ne marche qu'en production sur votre serveur privé », l.129 « Relations FK », l.155-157 « logs de votre application Node.js… "🔍 ===== DÉBUT SCAN SCHÉMA BASE DE DONNÉES =====" », émojis l.80/126/132/135 ; parcours en 2 temps puis `window.open('/api/debug/download-schema', '_blank')` l.106.
+- **Impact :** Onglet inutilisable sans accès aux logs Docker ; sa présence au même niveau que « Sauvegardes » alourdit la page et inquiète l'utilisateur.
+- **Recommandation :** Retirer de l'interface standard ou le placer dans « Outils avancés » sous forme d'un bouton unique « Télécharger le rapport technique » (lien `<a href download>` au lieu de window.open).
+
+### ERR-01
+
+**Messages d'erreur bruts (code HTTP + JSON, en anglais) affichés dans les toasts** — lisibilite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/lib/queryClient.ts:6`
+- **Constat :** queryClient.ts:3-7 `const text = (await res.text()) || res.statusText; throw new Error(`${res.status}: ${text}`);` affiché tel quel par BackupManager.tsx:86/105/125 `description: error.message || ...`, NocoDBConfig.tsx:95/116/137, WebhookBAPConfig.tsx:86 ; messages serveur en anglais routes.ts:5177 `{ message: "Access denied" }`, 5199 `"Failed to create backup"`, 5120 `'Failed to create configuration'`.
+- **Impact :** L'utilisateur voit par ex. « 500: {"message":"Failed to create backup"} » : JSON brut, code HTTP et anglais, incompréhensible pour un non-technicien.
+- **Recommandation :** Si on lève `Object.assign(new Error(body.message || body.error || défaut), { status })`, il faut adapter TOUTES les détections de 401 basées sur le texte, pas seulement queryClient.ts:81. Sont aussi concernés useAuthUnified.ts:32 et useAuth.ts:8 (`error?.message?.includes('401')`). Utiliser `error.status === 401` partout, et garder `${status}` dans le message en transition. Le changement touche toute l'application et doit être testé.
+
+### NF-01
+
+**Page 404 en anglais avec message de développeur et sans retour** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/not-found.tsx:11`
+- **Constat :** l.11 `<h1 className="text-2xl font-bold text-gray-900">404 Page Not Found</h1>`, l.15 « Did you forget to add the page to the router? », aucun lien ; l.6 `min-h-screen` alors que la page est rendue dans Layout (RouterProduction.tsx:192) et MobileApp (l.142).
+- **Impact :** Un employé qui suit un ancien lien ou fait une faute de frappe voit un message technique en anglais sans moyen évident de revenir ; hauteur d'écran doublée sous l'en-tête.
+- **Recommandation :** « Page introuvable — Cette page n'existe pas ou a été déplacée. » + bouton « Retour au tableau de bord » (`<Link href="/">`) ; remplacer `min-h-screen` par `py-16`.
+
+### NOCO-01
+
+**Jeton API NocoDB déchiffré envoyé au navigateur et affiché en clair** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:1657`
+- **Constat :** storage.ts:1655-1658 `getNocodbConfigs() { const configs = await db.select()...; return configs.map((c) => this.decryptNocodbConfig(c)); }` → routes.ts:5097-5098 `res.json(configs)`. NocoDBConfig.tsx:340 `{formatToken(config.apiToken, showTokens[config.id])}` + bouton œil l.342-352 ; l.183 réinjecte le jeton dans le formulaire d'édition ; l.66-78 `console.log('🔍 NocoDBConfig Debug:', { rawConfigs, ... })` à chaque rendu (non conditionné à DEV dans le source).
+- **Impact :** Le chiffrement au repos est contourné : le jeton d'accès aux factures de tous les magasins transite, reste dans le cache React Query et la console, et s'affiche d'un clic (également chargé par Groups.tsx:85).
+- **Recommandation :** En plus de la recommandation (renvoyer `apiToken` masqué + `apiTokenSet: true`, champ vide en édition = conserver le jeton, ce qui implique de ne pas passer apiToken à updateNocodbConfig s'il est vide) : restreindre ou supprimer GET /api/nocodb-config/active. Le client ne l'appelle pas (aucune occurrence dans client/src), et invoiceVerification passe par storage directement. Vérifier Groups.tsx:84-86, qui lit la même queryKey mais n'utilise pas apiToken.
+
+### NOCO-03
+
+**Plusieurs configurations « Actif » possibles, une seule utilisée au hasard** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `server/storage.ts:1665`
+- **Constat :** storage.ts:1665-1671 `db.select().from(nocodbConfig).where(eq(nocodbConfig.isActive, true)).limit(1)` sans ORDER BY, utilisé par invoiceVerification.ts:360 et 734 ; createNocodbConfig (storage.ts:1682-1686) et l'interrupteur « Configuration active » (NocoDBConfig.tsx:454-473) n'empêchent pas plusieurs actives ; badge « Actif » sur chaque carte (l.284-290).
+- **Impact :** Avec deux configurations actives, la vérification des factures utilise l'une ou l'autre de façon non déterministe ; l'admin ne sait pas laquelle sert ni quels magasins (groups.nocodb_config_id) en dépendent.
+- **Recommandation :** Garantir une seule config active (activer l'une désactive les autres dans une transaction) ou utiliser `groups.nocodbConfigId` par magasin ; afficher sur chaque carte « Utilisée par : Magasin A, Magasin B » et un badge « Utilisée pour la vérification des factures ».
+
+### SQL-02
+
+**Résultats SQL non bornés, dupliqués et rendus en un bloc illisible** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:6197`
+- **Constat :** routes.ts:6185-6189 place déjà un échantillon JSON de 10 lignes dans `logs`, puis l.6194-6198 `res.json({ success: true, logs, results: result.rows, rowCount })` renvoie toutes les lignes ; client SQLExecutor.tsx:42 `setLogs(prev => [...prev, `📊 Résultats: ${JSON.stringify(result.results, null, 2)}`])`, rendu l.224-228 `<div key={index} className="mb-1">{log}</div>` sans whitespace-pre (indentation perdue) dans un conteneur l.220 `min-h-[300px] ... overflow-auto` sans hauteur max.
+- **Impact :** Un `SELECT * FROM deliveries` renvoie des milliers de lignes sérialisées deux fois puis rendues comme un texte géant sur une seule ligne logique : navigateur figé, résultat illisible, page qui s'allonge indéfiniment.
+- **Recommandation :** Serveur : `results: rows.slice(0, 200), truncated: rows.length > 200` et ne plus dupliquer l'échantillon dans logs. Client : tableau (colonnes = clés) dans `max-h-[60vh] overflow-auto`, logs en `whitespace-pre-wrap`.
+
+### UTIL-01
+
+**Six onglets plats mêlant outils quotidiens et outils dangereux, inutilisables sur mobile** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/Utilities.tsx:81`
+- **Constat :** l.81 `<TabsList className="grid w-full grid-cols-6 mb-6">` avec « Sauvegardes », « Configuration NocoDB », « Debug Base de Données », « Météo », « Configuration BAP », « Exécution SQL » (l.83-116) au même niveau ; la page est servie telle quelle sur mobile (RouterProduction.tsx:125 `<Route path="/utilities" component={Utilities} />`).
+- **Impact :** Outils de tous les jours (sauvegardes, météo) côte à côte avec SQL brut et scan de schéma ; libellés jargon (NocoDB, BAP, Debug) ; sur téléphone, 6 colonnes forcées ≈ 55 px chacune : libellés tronqués/superposés.
+- **Recommandation :** Regrouper : « Sauvegardes », « Météo », « Connexions externes » (NocoDB + envoi BAP) et « Outils avancés » (Debug + SQL) replié derrière un avertissement ; libellés en français simple ; `TabsList` en `flex overflow-x-auto` (ou Select sur mobile).
+
+### UTIL-03
+
+**Pages admin importées statiquement dans le bundle principal de tous les utilisateurs** — perf-bundle, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:17`
+- **Constat :** RouterProduction.tsx:5-44 importe statiquement toutes les pages (dont NocoDBConfig, DatabaseDebug, BackupManager, Utilities l.17-23) ; Utilities.tsx:18-23 importe les 6 onglets ; aucun `lazy(`/`Suspense` dans client/src. Build : dist/public/assets/index-CCl1yENM.js = 1 081 745 octets, vendor-charts-gtSIDI7m.js = 410 243 octets préchargé par `<link rel="modulepreload" ... vendor-charts-gtSIDI7m.js>` dans dist/public/index.html dès la page de connexion.
+- **Impact :** Les employés (qui n'accèdent jamais aux utilitaires) et l'écran de connexion téléchargent et parsent ~1,7 Mo de JS (non compressé, cf. AUTH-02) avant le premier affichage : démarrage lent sur PC de caisse et mobiles.
+- **Recommandation :** Commencer par `lazy()` sur Analytics (gain recharts) et Utilities (admin), avec `<Suspense fallback={<PageSkeleton/>}>` autour du Switch desktop et mobile. Supprimer les imports statiques inutilisés de RouterProduction.tsx:17-27. Généraliser ensuite par route, en ajoutant une gestion des erreurs de chargement de chunk : après un déploiement, `emptyOutDir` supprime les anciens chunks, et un onglet resté ouvert planterait à la navigation. Il faut un error boundary qui recharge la page. Ce n'est pas purement mécanique, d'où auto=false.
+
+### WEATHER-01
+
+**Changer la ville ne met pas à jour le widget météo (cache non vidé, requête non invalidée)** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:5639`
+- **Constat :** PUT routes.ts:5637-5640 `const settings = await storage.updateWeatherSettings(id, data); res.json(settings);` sans `clearWeatherCache()` (contrairement à la géolocalisation l.6130) ; storage.ts:2910-2918 `getWeatherData` filtre `eq(weatherData.date, date), eq(weatherData.isCurrentYear, isCurrentYear)` sans la ville ; client WeatherSettings.tsx:54 et 94 n'invalident que `['/api/weather/settings']` alors que le widget lit `['/api/weather/current']` (WeatherWidget.tsx:121-123, refetch 30 min).
+- **Impact :** Après avoir remplacé « Nancy » par « Metz » et sauvegardé, l'en-tête affiche la météo de l'ancienne ville jusqu'au lendemain (et jusqu'à 30 min après une géolocalisation) : l'admin pense que le réglage n'a pas fonctionné.
+- **Recommandation :** Serveur : lire l'ancienne config (`getWeatherSettings()`) avant la mise à jour, et appeler `storage.clearWeatherCache()` seulement si `data.location` est défini et différent. Attention : clearWeatherCache supprime aussi l'historique N-1, comme le fait déjà la géolocalisation. Client : ajouter `queryClient.invalidateQueries({ queryKey: ['/api/weather/current'] })` dans les deux onSuccess.
+
+### WEATHER-02
+
+**Géolocalisation météo modifiable par n'importe quel utilisateur connecté** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:6096`
+- **Constat :** routes.ts:6094-6099 `app.post('/api/weather/geolocation', isAuthenticated, ...) { const user = await storage.getUserWithGroups(...); if (!user) return res.status(404)...` sans contrôle de rôle, alors que GET/POST/PUT /api/weather/settings exigent `user.role !== 'admin'` (l.5599, 5614, 5633) ; le handler modifie la config globale l.6125-6127 et purge le cache l.6130.
+- **Impact :** Un employé peut changer la ville météo affichée dans tous les magasins et vider le cache (nouveaux appels facturés à l'API Visual Crossing).
+- **Recommandation :** Ajouter `requireAdmin` (server/permissions.ts:78) sur la route.
+
+### ADMIN-03
+
+**Chaque handler admin relit l'utilisateur en BD pour vérifier le rôle** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:5175`
+- **Constat :** routes.ts:5175 `const user = await storage.getUserWithGroups(req.user.claims ? req.user.claims.sub : req.user.id); if (!user || user.role !== 'admin')` répété l.4778, 4906, 5092, 5107, 5126, 5143, 5190, 5205, 5227, 5598, 5613, 5632, 5652 ; routes.ts:194, 215, 251, 340, 361, 6159 `await storage.getUser(userId)`. Or server/permissions.ts:78-94 `requireAdmin` lit déjà `req.user?.role` sans requête.
+- **Impact :** +1 à 2 requêtes SQL séquentielles avant chaque réponse admin (dont le polling /api/backups toutes les 30 s) et ~20 blocs de code dupliqués.
+- **Recommandation :** Remplacer route par route : requireAdmin seulement là où le contrôle actuel est `role !== 'admin'`, et requireAdminOrDirecteur (permissions.ts:97) pour /api/utilities et /api/payment-schedule. Remplacer chaque usage ultérieur de `user` par `req.user` (id, username). Vérifier que le client n'affiche pas `error.error` sur ces 403. À faire handler par handler, avec relecture.
+
+### AUTH-08
+
+**Limite de 5 connexions/15 min par IP et message d'erreur trompeur** — bug, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/AuthPage.tsx:76`
+- **Constat :** security.ts:153-161 `const authLimiter = rateLimit({ windowMs: 15 * 60 * 1000, max: 5, message: { error: 'Trop de tentatives de connexion...' } })` appliqué l.185 à `/api/login`, sans `skipSuccessfulRequests` ; AuthPage.tsx:73-77 n'affiche que `errorData.message || "Identifiant ou mot de passe incorrect"`.
+- **Impact :** (server/index.ts) Dans un magasin où tous les postes sortent par la même IP, la 6e connexion en 15 min — même si les précédentes ont réussi — est refusée et l'employé lit « Identifiant ou mot de passe incorrect » ; il réessaie et prolonge le blocage.
+- **Recommandation :** Côté client (valable partout) : `errorData.message || errorData.error`, et un message dédié pour le statut 429. Côté serveur : `skipSuccessfulRequests: true` et un `max` adapté aux magasins derrière une IP partagée. À coordonner avec la décision d'activer ou non security.ts dans index.production.ts (voir AUTH-07).
+
+### AUTH-09
+
+**Deux implémentations de connexion, hook appelé hors rendu, double soumission** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/AuthPage.tsx:171`
+- **Constat :** AuthPage.tsx:15-19 `getEnvironment()` (hostname seul) choisit l.171-177 entre `handleProductionLogin` (fetch, l.50-89) et `loginMutation` (l.92-139), alors que useAuthUnified.ts:8-11 combine hostname et `import.meta.env.DEV` ; useAuthUnified.ts:129 `const queryClient = useQueryClient();` dans une fonction async (violation des règles des hooks) ; l.86-88 `finally { setIsSubmitting(false); }` réactive le bouton pendant les 500 ms avant redirection ; l.287 « … across tous vos magasins ».
+- **Impact :** Comportement de connexion différent selon l'URL (un build de prod servi sur localhost prend le chemin « dev » qui plante sur le hook) ; double soumission possible ; anglicisme visible sur l'écran d'accueil.
+- **Recommandation :** Une seule implémentation (useMutation + apiRequest), bouton désactivé jusqu'à la navigation, supprimer getEnvironment et l'appel de hook hors rendu ; corriger « dans tous vos magasins ».
+
+### BACKUP-05
+
+**Polling 30 s inconditionnel de la liste des sauvegardes** — perf-client, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/BackupManager.tsx:61`
+- **Constat :** l.57-62 `useQuery({ queryKey: ['/api/backups'], queryFn: () => apiRequest('/api/backups'), enabled: canManageBackups, refetchInterval: 30000 })` alors que la liste ne change qu'à la sauvegarde nocturne ou après une action déjà suivie d'un `invalidateQueries` (l.100, 119).
+- **Impact :** Tant que l'onglet est ouvert : une requête toutes les 30 s (~5 requêtes SQL côté serveur) inutile ; inversement l'état « En cours » d'une sauvegarde n'est rafraîchi qu'au mieux toutes les 30 s.
+- **Recommandation :** Supprimer le polling (`refetchInterval` absent) et le queryFn explicite. Les invalidations après action et refetchOnMount suffisent. Le polling conditionnel sur 'creating' ne doit être ajouté qu'après BACKUP-02, avec une durée maximale.
+
+### BACKUP-08
+
+**Toast de l'interrupteur calculé sur l'ancienne valeur et bascule différée** — bug, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/BackupManager.tsx:78`
+- **Constat :** l.74-81 `onSuccess: () => { queryClient.invalidateQueries({ queryKey: ['/api/utilities'] }); toast({ ..., description: config?.automaticBackupsEnabled ? "Sauvegardes automatiques désactivées" : "Sauvegardes automatiques activées" })` alors que l'interrupteur l.252 affiche `checked={config?.automaticBackupsEnabled !== false}`. POST /api/utilities renvoie déjà la config (routes.ts:381 `res.json(config)`).
+- **Impact :** Si aucune ligne utilities n'existe (config null), l'interrupteur paraît activé ; le désactiver affiche « Sauvegardes automatiques activées » (l'inverse). L'interrupteur ne bascule qu'après un refetch supplémentaire.
+- **Recommandation :** `onSuccess: (data, enabled) => { queryClient.setQueryData(['/api/utilities'], data); toast({ title: 'Configuration mise à jour', description: enabled ? 'Sauvegardes automatiques activées' : 'Sauvegardes automatiques désactivées' }); }`
+
+### BACKUP-10
+
+**Double en-tête de page et bouton principal orange** — coherence-design, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/BackupManager.tsx:196`
+- **Constat :** Utilities.tsx:64-76 en-tête « Utilitaires d'Administration » (icône w-8 h-8, h2 text-2xl), puis BackupManager.tsx:196-223 second en-tête blanc « Gestion des Sauvegardes » (icône w-8 h-8, h2 text-2xl) ; bouton l.213 `className="bg-accent hover:bg-orange-600 text-white"` alors que NocoDBConfig.tsx:250 utilise la variante par défaut (bleue) pour l'action principale.
+- **Impact :** ~200 px perdus avant le contenu, deux titres de même niveau empilés + onglet qui répète le nom ; couleur d'action principale différente selon l'onglet.
+- **Recommandation :** Un seul en-tête (Utilities) ; dans l'onglet, une ligne titre + action ; bouton principal en variante par défaut, libellé « Créer une sauvegarde maintenant ».
+
+### BAP-02
+
+**Bouton Sauvegarder isolé et statut de test périmé** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/WebhookBAPConfig.tsx:251`
+- **Constat :** Bouton « Sauvegarder » seul en bas de page l.268-286, après la carte de test ; l.251-263 `{testMutation.isSuccess && (... Connexion réussie ...)}` reste affiché après modification de l'URL (aucun `testMutation.reset()` dans le onChange l.186) ; aucune indication de modifications non enregistrées.
+- **Impact :** L'admin peut tester une URL, voir « Connexion réussie », la modifier et quitter sans sauvegarder en pensant que tout est en ordre.
+- **Recommandation :** Regrouper Tester + Sauvegarder dans le pied d'une même carte, `testMutation.reset()` à chaque changement d'URL, désactiver « Sauvegarder » si rien n'a changé et afficher « Modifications non enregistrées ».
+
+### BAP-03
+
+**Validation renvoyée en 500 et configuration factice avec URL de production** — bug, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:236`
+- **Constat :** routes.ts:236 `const validatedData = insertWebhookBapConfigSchema.parse(req.body);` dans un try dont le catch l.258-261 renvoie toujours `res.status(500).json({ error: 'Erreur serveur', details: error.message })` ; GET l.206-215 renvoie, si la table manque, `{ id: 1, ..., webhookUrl: "https://workflow.ffnancy.fr/webhook/a3d03176-...", needsTableCreation: true }` (needsTableCreation non exploité par l'UI).
+- **Impact :** Une saisie invalide s'affiche comme « 500: {"error":"Erreur serveur","details":"[...zod...]"} » ; le formulaire peut être pré-rempli avec une URL que l'admin n'a jamais saisie.
+- **Recommandation :** `if (error instanceof z.ZodError) return res.status(400).json({ message: 'URL ou champs invalides' })` ; supprimer la configuration factice (renvoyer null).
+
+### LAND-01
+
+**Page Landing morte qui pointe vers une route inexistante** — dette-code, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Landing.tsx:7`
+- **Constat :** Aucun import de Landing dans client/src ; l.6-8 `const handleLogin = () => { window.location.href = "/api/login"; };` alors que /api/login n'existe qu'en POST (localAuth.ts:153) ; classes `bg-surface`, `bg-delivered` et branding « La Foir'Fouille » codé en dur.
+- **Impact :** Code mort qui entretient la confusion (deux écrans d'accueil) ; réactivée, ses trois boutons mèneraient à une erreur.
+- **Recommandation :** Supprimer client/src/pages/Landing.tsx. Pour localAuth.production.ts : retirer d'abord l'import inutilisé à server/index.production.ts:8, puis supprimer le fichier, en le traitant avec AUTH-06 car il contient la configuration PG store et trust proxy à reprendre.
+
+### NOCO-02
+
+**Log de debug à chaque rendu et code défensif opaque** — dette-code, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/NocoDBConfig.tsx:66`
+- **Constat :** l.61-78 `// Protection quadruple couche pour éviter les erreurs TypeError  const configs = rawConfigs || []; const safeConfigs = Array.isArray(configs) ? configs : []; console.log('🔍 NocoDBConfig Debug:', { rawConfigs, ..., environment: window.location.hostname });` ; la variable `error` (l.56) n'est jamais rendue.
+- **Impact :** Bruit console en dev (retiré au build prod par esbuild.pure, vite.config.ts:31) ; si l'API renvoie une erreur, la page affiche « Aucune configuration » au lieu d'un message d'erreur.
+- **Recommandation :** Supprimer le console.log. Typer `useQuery<NocodbConfig[] | null>` et écrire `const configs = rawConfigs ?? []`, pas une valeur par défaut de déstructuration. Puis remplacer safeConfigs par configs.
+
+### NOCO-04
+
+**Boutons Modifier/Supprimer icône seule et suppression sans avertissement d'impact** — accessibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/NocoDBConfig.tsx:300`
+- **Constat :** l.300-313 deux `<Button variant="outline" size="sm">` avec seulement `<Edit />` / `<Trash2 />`, sans aria-label ni title, même style ; modale l.640-643 « Cette action est irréversible » sans mentionner les magasins liés ; storage.ts:1701-1703 `await db.delete(nocodbConfig).where(eq(nocodbConfig.id, id));` sans vérifier groups.nocodb_config_id.
+- **Impact :** Boutons ambigus (lecteurs d'écran, utilisateurs) ; suppression possible d'une configuration encore utilisée → vérification des factures cassée sans prévenir.
+- **Recommandation :** aria-label/title « Modifier » / « Supprimer », style destructif sur Supprimer ; avant suppression, compter les magasins liés et bloquer ou avertir (« 3 magasins utilisent cette configuration »).
+
+### NOCO-05
+
+**Formulaire de création non réinitialisé après succès** — bug, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/NocoDBConfig.tsx:84`
+- **Constat :** l.84-86 `onSuccess: () => { queryClient.invalidateQueries({ queryKey: ['/api/nocodb-config'] }); setShowCreateModal(false); ...` sans `createForm.reset()` ; `createForm` (l.144-154) conserve les valeurs, jeton compris.
+- **Impact :** En rouvrant « Nouvelle Configuration », la configuration précédente est pré-remplie : risque de créer un doublon par erreur.
+- **Recommandation :** Appeler `createForm.reset()` dans onSuccess uniquement. Réinitialiser aussi à la fermeture (Annuler) ferait perdre une saisie fermée par erreur, c'est un choix produit.
+
+### NOCO-06
+
+**Formulaires de création et d'édition dupliqués** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/NocoDBConfig.tsx:371`
+- **Constat :** Création l.371-492 et édition l.505-626 : les 6 FormField sont copiés à l'identique (~120 lignes chacun), ex. `<FormLabel>Personal API Token</FormLabel>` l.406 et l.540.
+- **Impact :** Toute correction de libellé ou de validation doit être faite deux fois ; risque de divergence.
+- **Recommandation :** Extraire `<NocodbConfigFormFields control={form.control} />` réutilisé par les deux modales.
+
+### NOCO-07
+
+**Libellés anglais/jargon et aucun test de connexion** — lisibilite, sévérité basse, effort M
+
+- **Fichier :** `client/src/pages/NocoDBConfig.tsx:406`
+- **Constat :** l.406 `<FormLabel>Personal API Token</FormLabel>`, placeholders l.394 `https://your-nocodb-instance.com`, l.410 `xc-token-xxxxxxxxxxxxxx`, l.427 `p_xxxxxxxxxxxxxx` ; sous-titre l.247 « connexions aux bases de données NocoDB externes » ; aucun bouton « Tester la connexion » alors que WeatherSettings.tsx:334 et WebhookBAPConfig.tsx:246 en proposent un.
+- **Impact :** Un admin non développeur ne sait ni quoi saisir ni si la configuration fonctionne avant de l'utiliser dans le rapprochement.
+- **Recommandation :** Libellés FR (« Adresse du serveur NocoDB », « Jeton d'accès personnel », « Identifiant de la base (commence par p_) ») avec texte d'aide ; ajouter un bouton « Tester la connexion ».
+
+### SQL-03
+
+**Bouton « SQL Webhook BAP » obsolète, état dupliqué et log de démarrage effacé** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/SQLExecutor.tsx:100`
+- **Constat :** l.100-135 `handleCopyWebhookSQL` écrase l'éditeur sans confirmation, contient l'URL de production l.116 `'https://workflow.ffnancy.fr/webhook/a3d03176-...'` alors que la table est créée par init.sql, migrations/20250903141000_create_webhook_bap_config.sql et server/createWebhookTable.ts ; l.129 `navigator.clipboard.writeText(webhookSQL);` sans try/catch. l.14 `isExecuting` duplique `executeMutation.isPending` ; l.19 `setLogs([])` dans mutationFn efface le message posé l.96 `setLogs([`🔄 Début de l'exécution SQL...`])`.
+- **Impact :** Bouton obscur qui peut écraser un script en cours ; en HTTP non sécurisé, navigator.clipboard est indéfini → exception, aucun retour ; message « Début de l'exécution » jamais visible.
+- **Recommandation :** Supprimer le bouton et le script embarqué ; utiliser `executeMutation.isPending` ; retirer `setLogs([])` du mutationFn.
+
+### UTIL-02
+
+**Onglet actif non reflété dans l'URL** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/Utilities.tsx:28`
+- **Constat :** l.28-35 `useState(() => { const path = window.location.pathname; if (path === '/backup') return 'backups'; ... return 'backups'; })` et l.80 `onValueChange={setActiveTab}` ne touche pas l'URL ; aucune route pour 'webhookbap' ni 'sql' (RouterProduction.tsx:173-176).
+- **Impact :** F5 ou lien partagé ramène toujours sur « Sauvegardes » ; bouton Précédent inopérant entre onglets.
+- **Recommandation :** Stocker l'onglet dans l'URL (`/utilities?tab=meteo` via `useSearch`/`setLocation` de wouter) et rediriger les anciennes routes vers ce format.
+
+### UTIL-04
+
+**Conteneurs, titres et états de chargement différents dans chaque onglet** — coherence-design, sévérité basse, effort M
+
+- **Fichier :** `client/src/pages/NocoDBConfig.tsx:231`
+- **Constat :** NocoDBConfig.tsx:238-242 `container mx-auto px-4 py-8` + `<h1 className="text-3xl ...">` ; WeatherSettings.tsx:220-223 `container mx-auto p-6 max-w-2xl` + h1 text-2xl ; DatabaseDebug.tsx:56-60 `p-6` + h1 ; SQLExecutor.tsx:141 h1 sans padding ; WebhookBAPConfig.tsx:158-167 aucun titre de page. Chargement : NocoDBConfig.tsx:231 spinner `h-32 w-32`, WeatherSettings.tsx:205-213 skeleton, WebhookBAPConfig.tsx:150-153 texte « Chargement de la configuration... », BackupManager.tsx:333-334 Loader2 dans la carte.
+- **Impact :** Impression d'outils assemblés ; h1 imbriqués sous le h2 de Utilities (hiérarchie inversée pour lecteurs d'écran) ; le contenu change de largeur et de style à chaque onglet.
+- **Recommandation :** Composant commun `<AdminSection title description actions>` (titre h3 text-lg, sans container/max-w propre) et `<SectionSkeleton />` partagé ; supprimer les grands titres redondants avec le libellé d'onglet.
+
+### WEATHER-03
+
+**Formulaire non contrôlé manipulé via le DOM, fetch manuels et erreurs en anglais** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/WeatherSettings.tsx:318`
+- **Constat :** l.318 `new FormData(document.querySelector('form') as HTMLFormElement)` (premier formulaire du document), l.97-100 `const locationInput = document.getElementById('location') as HTMLInputElement; locationInput.value = data.location.fullLocation;`, champs `defaultValue` l.245/268/297, trois `fetch` manuels l.39, 72, 161 au lieu d'apiRequest, messages anglais l.48 `throw new Error('Failed to save settings')` et l.170 `throw new Error('Test connection failed')` affichés à l'utilisateur.
+- **Impact :** Fragile (un autre formulaire dans le Layout ferait tester les mauvais champs), état hors React, messages d'erreur en anglais.
+- **Recommandation :** Champs contrôlés (useState ou react-hook-form comme NocoDBConfig), lecture via `e.currentTarget.form`, apiRequest et messages FR (« Impossible d'enregistrer les réglages météo »).
+
+### WEATHER-04
+
+**/api/weather/current recalculé à chaque appel sans cache mémoire** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:5683`
+- **Constat :** routes.ts:5673 `await storage.getWeatherSettings()`, l.5683-5684 `let currentYearData = await storage.getWeatherData(today, true); let previousYearData = await storage.getWeatherData(previousYearDate, false);` séquentiels, l.5755 `console.log('🌤️ [RESPONSE] Weather data prepared:', ...)` à chaque appel ; appelé par WeatherWidget (Layout, toutes les pages) avec `refetchInterval: 30 * 60 * 1000`.
+- **Impact :** Pour une donnée qui change une fois par jour, chaque ouverture de l'application par chaque employé coûte 3 requêtes métier + 2 de désérialisation et une ligne de log.
+- **Recommandation :** Se limiter à `Promise.all` pour les deux lectures et à la suppression du log de réponse. Le cache mémoire n'est utile qu'après avoir corrigé WEATHER-01, et doit alors être invalidé explicitement dans POST/PUT settings et géolocalisation.

docs/audit-webui/13-app-shell.md

@@ -0,0 +1,381 @@
+# Shell applicatif (navigation, layout, auth, design system)
+
+_30 constats vérifiés — 5 haute, 18 moyenne, 7 basse._
+
+## Pages analysées
+
+### `* (shell desktop ≥768px : Layout + Sidebar, entoure toutes les routes desktop)`
+
+**Rôle :** Cadre commun desktop : menu latéral filtré par rôle, en-tête (météo, date, sélecteur de magasin), zone de contenu des pages, déconnexion, envoi BAP.
+
+**Tâches principales de l'utilisateur :**
+- Naviguer entre les modules (19 entrées pour un admin, 8 pour un employé)
+- Choisir le magasin actif (admin/directeur/manager)
+- Réduire/étendre le menu
+- Envoyer un BAP (admin)
+- Se déconnecter
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/user | au montage de RouterProduction, puis à nouveau au montage de Layout (useAuthUnified), de Sidebar (useAuthSimple) et de chaque page/modale qui appelle useAuthUnified | server/localAuth.ts:204 (handler) + passport.deserializeUser server/localAuth.ts:141 -> storage.getUserWithGroups (server/storage.ts:371) appelé 2 fois = 4 requêtes SQL par appel | fetch manuel cache:'no-cache' sans cache partagé en production : 5 appels au premier affichage du tableau de bord |
+| GET /api/groups | au montage de Layout, mais seulement après la résolution du /api/user propre à Layout (enabled: !!user) — cascade | server/routes.ts:970 -> storage.getUserWithGroups (redondant avec req.user) + storage.getGroups (admin) | alimente le sélecteur de magasin et StoreContext.stores |
+| GET /api/weather/current | au montage de Layout + polling toutes les 30 min (refetchInterval), retry:1 | server/routes.ts:5671 -> storage.getWeatherSettings, storage.getWeatherData x2, weatherService.fetchCurrentWeather (API externe) si absent du cache | 404 si météo non configurée -> réessayé une fois à chaque chargement |
+| POST /api/logout | au clic sur Déconnexion (Sidebar) | server/localAuth.ts:200 logoutHandler (req.logout + session.destroy + redirect /auth) | suivi de window.location.href='/auth' (rechargement complet) |
+| GET /api/webhook-bap-config puis POST vers webhook externe | au clic Envoyer BAP | server/routes.ts:186 (config) ; envoi direct navigateur -> https://workflow.ffnancy.fr/... (Sidebar.tsx:121,143) | bloqué par CSP connect-src 'self' quand servi par server/index.ts |
+
+**Lisibilité / simplicité :** Menu dense (19 entrées / 5 sections pour un admin) avec sections déséquilibrées (« ANALYSES » = 1 entrée), libellés ambigus (Commandes vs Commandes Client, Échéance, Rapprochement, BAP), icônes dupliquées (BarChart3 pour Tableau de bord et Statistiques). L'accueil « / » n'active aucune entrée. L'en-tête est occupé par la météo et la date (widgets plus hauts que l'en-tête) au lieu du titre de page ; un employé ne voit jamais son magasin. Chargement en 3 temps (spinner plein écran, puis spinner du menu, puis sélecteur qui apparaît). Deux bleus concurrents, contraste du bouton primaire insuffisant, survol des boutons primaires inopérant, coins carrés dans les composants de base mais arrondis dans les pages, 62 !important dans index.css.
+
+### `* (shell mobile <768px : MobileApp + MobileLayout + MobileBottomNav)`
+
+**Rôle :** Cadre mobile : en-tête compact avec magasin, barre de navigation basse (4 onglets + Plus), panneau latéral profil/magasin/déconnexion.
+
+**Tâches principales de l'utilisateur :**
+- Accéder rapidement à Accueil, Commandes, Livraisons, Tâches
+- Ouvrir « Plus » pour Calendrier, Publicités, Cmd Client, DLC, SAV, Avoirs
+- Changer de magasin et se déconnecter via le menu hamburger
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/user | au montage de RouterProduction, MobileApp, MobileLayout, MobileBottomNav et de la page (5 appels) | server/localAuth.ts:204 + deserializeUser server/localAuth.ts:141 -> storage.getUserWithGroups x2 | MobileBottomNav récupère user sans jamais l'utiliser |
+| GET /api/groups | au montage de MobileApp après son propre /api/user | server/routes.ts:970 -> storage.getUserWithGroups + storage.getGroups | pas d'invalidation au changement de magasin (contrairement au desktop) |
+| POST /api/logout | au clic Déconnexion dans le Sheet | server/localAuth.ts:200 logoutHandler | suivi de window.location.href='/auth' |
+
+**Lisibilité / simplicité :** Navigation mobile incomplète : Contacts, Rapprochement, Échéance, Statistiques et toute l'administration sont inaccessibles ; si on y arrive par URL, la page desktop s'affiche sans en-tête ni barre de navigation (impasse). Le bouton hamburger n'ouvre pas de menu de navigation mais seulement profil/magasin/déconnexion. Les onglets Commandes/Livraisons/Avoirs sont montrés à tous les rôles alors que le desktop les cache aux employés. Libellés de 10 px, rôle affiché en anglais (« Employee »), libellés différents du desktop (Accueil/Tableau de bord, Cmd Client/Commandes Client). Une rotation du téléphone en paysage (≥768px) bascule toute l'application en interface desktop.
+
+### `/auth (et premier chargement : index.html, bundle, bootstrap)`
+
+**Rôle :** Connexion et démarrage de l'application : téléchargement du bundle, vérification de session, redirection vers l'accueil.
+
+**Tâches principales de l'utilisateur :**
+- Se connecter
+- Arriver sur le tableau de bord (ou la page demandée)
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /api/user | au montage de RouterProduction puis de AuthPage (2 appels 401 pour un visiteur non connecté) | server/localAuth.ts:204 | spinner plein écran bloquant pendant le premier appel |
+| GET /api/default-credentials-check | au montage de AuthPage | server/localAuth.ts:234 -> storage.getUserByUsername('admin') | la carte « admin / admin » est affichée par défaut avant la réponse |
+| POST /api/login | au clic Se connecter | server/localAuth.ts:153 (passport local) | en production : setTimeout 500 ms puis window.location.href='/' (rechargement complet, URL d'origine perdue) |
+| GET /assets/*.js (5 fichiers, 1,72 Mo brut / ~436 Ko gzip) + https://replit.com/public/js/replit-dev-banner.js | chargement initial de la page | server/index.production.ts:143-144 express.static sans maxAge ni compression | toutes les pages et recharts sont téléchargées avant même l'écran de connexion |
+
+**Lisibilité / simplicité :** Premier affichage lent : 1,08 Mo de code applicatif + 410 Ko de recharts préchargés avant l'écran de connexion, script tiers replit.com synchrone qui retarde le démarrage, pas de cache long ni de compression côté Node. Après connexion : attente artificielle de 500 ms puis rechargement complet, la page demandée initialement est perdue. Les identifiants par défaut « admin / admin » clignotent à l'écran pour tout visiteur. Langue du document déclarée en anglais et zoom bloqué.
+
+### `(toute URL inconnue) — page 404`
+
+**Rôle :** Page affichée quand l'URL ne correspond à aucune route.
+
+**Tâches principales de l'utilisateur :**
+- Comprendre que la page n'existe pas
+- Revenir à l'accueil
+
+**Lisibilité / simplicité :** Message en anglais destiné aux développeurs (« 404 Page Not Found / Did you forget to add the page to the router? »), aucun bouton de retour ; min-h-screen alors que la page est rendue dans la zone de contenu du Layout.
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [SHELL-01](#shell-01) | haute | perf-api | M | Chaque composant refait son propre GET /api/user en production (aucun cache partagé) | `client/src/hooks/useAuthUnified.ts:148` |
+| [SHELL-02](#shell-02) | haute | bug | S | Le tableau de bord lance ses requêtes avant de connaître le rôle : doublons et données non filtrées en cache | `client/src/pages/Dashboard.tsx:79` |
+| [SHELL-03](#shell-03) | haute | perf-bundle | M | Toutes les pages importées statiquement : 1,72 Mo de JS avant l'écran de connexion | `client/src/components/RouterProduction.tsx:7` |
+| [SHELL-04](#shell-04) | haute | perf-client | S | Script tiers replit.com synchrone livré en production : retarde le démarrage de l'app | `client/index.html:19` |
+| [SHELL-10](#shell-10) | haute | ux-simplicite | M | Mobile : 8 modules inaccessibles et pages desktop affichées sans aucune navigation | `client/src/components/RouterProduction.tsx:117` |
+| [SHELL-05](#shell-05) | moyenne | perf-serveur | S | Fichiers statiques servis sans compression ni cache long (le middleware « compression » est factice) | `server/index.production.ts:143` |
+| [SHELL-06](#shell-06) | moyenne | perf-client | S | Valeur de StoreContext recréée à chaque rendu + re-rendu global à chaque pixel de redimensionnement | `client/src/components/Layout.tsx:86` |
+| [SHELL-07](#shell-07) | moyenne | perf-api | S | Changement de magasin : invalidation par prédicat qui double les requêtes | `client/src/components/Layout.tsx:138` |
+| [SHELL-08](#shell-08) | moyenne | perf-api | S | Retry systématique sur 403/404/500 et redirections 401 par rechargement complet | `client/src/lib/queryClient.ts:79` |
+| [SHELL-09](#shell-09) | moyenne | ux-simplicite | S | Connexion = attente artificielle de 500 ms + rechargement complet, et la page demandée est perdue | `client/src/pages/AuthPage.tsx:68` |
+| [SHELL-11](#shell-11) | moyenne | coherence-design | M | Trois sources de vérité différentes pour « qui voit quel module » | `client/src/components/Sidebar.tsx:247` |
+| [SHELL-12](#shell-12) | moyenne | lisibilite | S | Menu : sections déséquilibrées, libellés ambigus, icônes dupliquées, libellés différents du mobile | `client/src/components/Sidebar.tsx:225` |
+| [SHELL-14](#shell-14) | moyenne | ux-simplicite | M | En-tête occupé par la météo et la date (qui débordent) au lieu du titre de page et du magasin | `client/src/components/Layout.tsx:106` |
+| [SHELL-15](#shell-15) | moyenne | ux-simplicite | S | Directeur/manager multi-magasins : alerte rouge bloquante au lieu d'une présélection ; pastilles couleur invalides | `client/src/components/Layout.tsx:195` |
+| [SHELL-16](#shell-16) | moyenne | accessibilite | M | Deux bleus concurrents et bouton primaire au contraste insuffisant (3,1:1) | `client/src/index.css:16` |
+| [SHELL-17](#shell-17) | moyenne | bug | S | Les modificateurs d'opacité (hover:bg-primary/90...) ne génèrent aucun CSS : pas de retour visuel au survol | `tailwind.config.ts:44` |
+| [SHELL-18](#shell-18) | moyenne | coherence-design | M | Coins incohérents : composants de base carrés, pages et mobile arrondis | `client/src/components/ui/button.tsx:8` |
+| [SHELL-19](#shell-19) | moyenne | dette-code | M | index.css : 62 !important et règles globales qui écrasent bordures, focus et couleurs d'anneau | `client/src/index.css:280` |
+| [SHELL-20](#shell-20) | moyenne | accessibilite | S | Langue déclarée en anglais et zoom bloqué sur mobile | `client/index.html:2` |
+| [SHELL-21](#shell-21) | moyenne | accessibilite | S | Boutons icône sans nom accessible et éléments cliquables non focusables | `client/src/pages/mobile/MobileBottomNav.tsx:86` |
+| [SHELL-22](#shell-22) | moyenne | lisibilite | S | Tailles de texte trop petites dans la navigation (10-11 px) | `client/src/pages/mobile/MobileBottomNav.tsx:76` |
+| [SHELL-25](#shell-25) | moyenne | ux-simplicite | M | Rotation ou redimensionnement : toute l'application est démontée et remontée ; branches mobiles mortes dans Layout/Sidebar | `client/src/components/RouterProduction.tsx:106` |
+| [SHELL-28](#shell-28) | moyenne | bug | S | Les identifiants par défaut « admin / admin » s'affichent par défaut sur l'écran de connexion | `client/src/pages/AuthPage.tsx:25` |
+| [SHELL-13](#shell-13) | basse | ux-simplicite | S | Sur l'accueil « / » (page d'arrivée après connexion) aucune entrée du menu n'est active | `client/src/components/Sidebar.tsx:219` |
+| [SHELL-23](#shell-23) | basse | lisibilite | S | Page 404 en anglais avec message destiné aux développeurs | `client/src/pages/not-found.tsx:11` |
+| [SHELL-24](#shell-24) | basse | lisibilite | S | Rôle affiché en anglais sur mobile, libellé recalculé à la main sur desktop | `client/src/pages/mobile/MobileLayout.tsx:136` |
+| [SHELL-26](#shell-26) | basse | dette-code | S | Code mort et dupliqué dans le shell (hooks, nav, fichiers .tmp, scripts publics) | `client/src/components/Sidebar.tsx:394` |
+| [SHELL-27](#shell-27) | basse | bug | S | Appel de hook dans une fonction asynchrone (forceAuthRefresh) et comportement dev/prod divergent | `client/src/hooks/useAuthUnified.ts:129` |
+| [SHELL-29](#shell-29) | basse | dette-code | M | Fonction métier BAP (≈300 lignes) logée dans le menu, avec destinataires et URL codés en dur | `client/src/components/Sidebar.tsx:794` |
+| [SHELL-30](#shell-30) | basse | ux-simplicite | S | Un seul ErrorBoundary global : une erreur dans une page efface aussi le menu | `client/src/App.tsx:10` |
+
+### SHELL-01
+
+**Chaque composant refait son propre GET /api/user en production (aucun cache partagé)** — perf-api, sévérité haute, effort M
+
+- **Fichier :** `client/src/hooks/useAuthUnified.ts:148`
+- **Constat :** useAuthUnified.ts:8-11 `const isDevelopment = ... (hostname === 'localhost' || ...replit.dev) && import.meta.env.DEV === true;` -> en prod la branche React Query est désactivée (`enabled: isDevelopment`, l.43) et chaque instance exécute son propre `useEffect(() => { ... fetch('/api/user', { credentials: 'include', cache: 'no-cache' ...` (l.148-167) avec un état local `useState(true)` (l.24). 48 fichiers appellent useAuthUnified() (RouterProduction:56, Layout:22, Dashboard:16, AnnouncementCard:101, MobileApp:16, MobileLayout:22, MobileBottomNav:47, toutes les modales...), et Sidebar.tsx:44 utilise en plus useAuthSimple qui refait le même fetch (useAuthSimple.ts:15). Côté serveur, chaque appel coûte 4 requêtes SQL : deserializeUser server/localAuth.ts:141-143 `storage.getUserWithGroups(id)` puis le handler server/localAuth.ts:211 rappelle `storage.getUserWithGroups(userId)` (getUser + jointure, storage.ts:371-388). Conséquence visible : spinner plein écran (RouterProduction.tsx:79-88), puis spinner du menu (Sidebar.tsx:392-445), puis /api/groups qui attend le /api/user propre au Layout (Layout.tsx:48-51 `enabled: !!user`).
+- **Impact :** Premier affichage du tableau de bord desktop = 5 appels /api/user (RouterProduction, Layout, Sidebar, Dashboard, AnnouncementCard) = 20 requêtes SQL rien que pour l'authentification ; mobile = 5 appels ; +1 à chaque changement de page et à chaque ouverture de modale. Cascade de 3 états de chargement successifs et sauts de mise en page.
+- **Recommandation :** Hook unique basé sur React Query : `useQuery({ queryKey: ['/api/user'], queryFn: fetchUser /* dédié : 401 → return null, SANS redirection */, staleTime: Infinity, retry: false })`, réexporté par useAuthUnified, useAuthSimple, useAuthProduction, useAuth ; supprimer isDevelopment. Après login : `await queryClient.invalidateQueries({ queryKey: ['/api/user'] })` (ou faire renvoyer `userGroups` par /api/login avant d'utiliser setQueryData). Côté serveur : /api/user et /api/groups utilisent `req.user` (déjà chargé par deserializeUser avec userGroups) au lieu de rappeler getUserWithGroups.
+
+### SHELL-02
+
+**Le tableau de bord lance ses requêtes avant de connaître le rôle : doublons et données non filtrées en cache** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:79`
+- **Constat :** Dashboard.tsx:16 `const { user } = useAuthUnified();` vaut null au montage en production (état local du hook). Pourtant les requêtes partent tout de suite sans `enabled` : l.79 `const ordersUrl = `/api/orders${selectedStoreId && user?.role === 'admin' ? `?storeId=${selectedStoreId}` : ''}`` (idem l.80-81) -> la clé change quand user arrive => 2 requêtes, la première sans storeId (tous magasins = la plus lourde). Pour /api/stats/monthly (l.29 clé `['/api/stats/monthly', selectedStoreId]`, filtre l.37 `if (selectedStoreId && user?.role === 'admin')`), /api/stats/yearly (l.62) et /api/tasks (l.285) la clé ne contient pas le rôle : la réponse non filtrée est mise en cache sous la clé du magasin sélectionné.
+- **Impact :** Pour un admin avec un magasin sélectionné : statistiques et tâches de TOUS les magasins affichées comme si c'étaient celles du magasin (jusqu'au prochain refetch), et 3 grosses requêtes doublées à chaque arrivée sur le tableau de bord.
+- **Recommandation :** Ajouter `enabled: !!user` aux useQuery de Dashboard.tsx (stats/monthly l.29, stats/yearly l.55, orders/deliveries/customer-orders l.84-94, announcements/recent, tasks l.282). L'ajout de `user?.role` dans les queryKey est optionnel. Correction définitive via SHELL-01.
+
+### SHELL-03
+
+**Toutes les pages importées statiquement : 1,72 Mo de JS avant l'écran de connexion** — perf-bundle, sévérité haute, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:7`
+- **Constat :** RouterProduction.tsx:5-44 : 24 pages desktop + 11 pages mobiles en `import X from "@/pages/..."` ; aucun `lazy(`/`<Suspense` dans client/src. Build actuel (dist/public, construit avec la config vite courante) : index-CCl1yENM.js 1 081 745 o (258 Ko gzip), vendor-charts 410 243 o (110 Ko gzip), vendor-react 146 Ko, vendor-icons 44 Ko, vendor-query 40 Ko, et dist/public/index.html précharge tout : `<link rel="modulepreload" ... href="/assets/vendor-charts-gtSIDI7m.js">`. recharts n'est importé que par pages/Analytics.tsx:14 ; jsbarcode que par pages/CustomerOrders.tsx:33. De plus NocoDBConfig, DatabaseDebug, BackupManager, WeatherSettings sont importés (l.17-18, 22, 27) mais jamais utilisés comme composant de route. (framer-motion, react-icons et xlsx ne sont importés nulle part côté client : pas d'impact bundle.)
+- **Impact :** Un employé sur le PC du magasin ou en 4G télécharge et parse ~436 Ko gzip (1,72 Mo brut) — dont les graphiques et le code admin qu'il n'utilisera jamais — avant de voir l'écran de connexion.
+- **Recommandation :** 1) Corriger manualChunks pour que vendor-charts ne contienne que recharts/d3/victory (forme fonction : `id.includes('node_modules/recharts') || id.includes('victory-vendor') || id.includes('d3-')`), ou retirer l'entrée vendor-charts, et vérifier dans dist/public/index.html que vendor-charts n'est plus en modulepreload. 2) Puis `lazy(() => import(...))` pour toutes les routes sauf AuthPage/Dashboard (et équivalents mobiles), `<Suspense fallback={<PageSkeleton/>}>` dans la zone de contenu du Layout/MobileLayout. 3) Supprimer les 4 imports inutilisés (sans gain de taille tant qu'Utilities les importe).
+
+### SHELL-04
+
+**Script tiers replit.com synchrone livré en production : retarde le démarrage de l'app** — perf-client, sévérité haute, effort S
+
+- **Fichier :** `client/index.html:19`
+- **Constat :** client/index.html:19 `<script type="text/javascript" src="https://replit.com/public/js/replit-dev-banner.js"></script>` est recopié tel quel dans dist/public/index.html. Le bundle est un `<script type="module">` (différé) : il ne s'exécute qu'une fois le parsing terminé, donc après téléchargement + exécution de ce script classique bloquant. L'image Docker lance server/index.production.ts qui n'applique pas setupSecurityHeaders (aucun import, l.1-9) : le script est donc réellement téléchargé depuis replit.com. Avec server/index.ts, la CSP `script-src 'self'` (server/security.ts:115) le bloque et génère une erreur console.
+- **Impact :** Chaque chargement dépend d'un serveur tiers : si replit.com est lent ou filtré par le pare-feu du magasin, l'application reste blanche jusqu'au timeout réseau. Fuite de l'IP/URL des utilisateurs vers un tiers.
+- **Recommandation :** Supprimer les lignes 18-19 de client/index.html (bannière de dev Replit inutile en production).
+
+### SHELL-10
+
+**Mobile : 8 modules inaccessibles et pages desktop affichées sans aucune navigation** — ux-simplicite, sévérité haute, effort M
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:117`
+- **Constat :** RouterProduction.tsx:117-129 monte Contacts, Suppliers, Groups, Users, BLReconciliation, Utilities, Analytics, PaymentSchedulePage directement (« Pages sans version mobile - utiliser version desktop ») : ces pages n'utilisent pas MobileLayout (seules les 11 pages de pages/mobile l'importent) -> ni en-tête, ni barre basse. MobileBottomNav.tsx:29-43 ne propose que Accueil, Commandes, Livraisons, Tâches + Calendrier, Publicités, Cmd Client, DLC, SAV, Avoirs. Le bouton hamburger (MobileLayout.tsx:72 `onClick={() => setMenuOpen(true)}`) ouvre un Sheet qui ne contient que profil, sélecteur de magasin et déconnexion (MobileLayout.tsx:129-185), aucun lien.
+- **Impact :** Sur téléphone, un directeur ne peut pas atteindre Rapprochement, Échéance, Statistiques ni Contacts ; s'il y arrive par un lien, il reste bloqué sans menu (seul le bouton retour du navigateur fonctionne). L'icône « menu » trompe l'utilisateur.
+- **Recommandation :** Mettre dans le Sheet du hamburger la liste complète des modules filtrée par rôle (même configuration que la Sidebar, cf. SHELL-11) et envelopper les pages desktop rendues sur mobile dans `<MobileLayout title=...>` (ou un wrapper générique dans RouterProduction).
+
+### SHELL-05
+
+**Fichiers statiques servis sans compression ni cache long (le middleware « compression » est factice)** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/index.production.ts:143`
+- **Constat :** server/index.production.ts:143-144 `app.use('/assets', express.static(join(publicPath, 'assets'))); app.use('/', express.static(publicPath));` -> maxAge par défaut 0 (revalidation des 6 fichiers à chaque visite / rechargement), aucun middleware de compression (le paquet `compression` n'est pas dans package.json). server/cache.ts:92-100 `setupCompression` pose `Content-Encoding: gzip` sans compresser (et n'est appelé nulle part). La compression dépend donc d'un nginx externe (réseau `nginx_default` dans docker-compose.yml:66) dont la config n'est pas versionnée.
+- **Impact :** Sans nginx compressant, 1,72 Mo transférés au lieu de ~436 Ko ; dans tous les cas, 6 allers-retours 304 à chaque rechargement complet (et l'app en fait beaucoup, cf. SHELL-09).
+- **Recommandation :** Partie automatisable : `/assets` servi avec `express.static(..., { maxAge: '1y', immutable: true })` ; index.html (express.static racine et les deux res.sendFile l.147-169) avec `Cache-Control: no-cache` ; supprimer setupCompression (code mort). Ajout de `compression()` : à décider séparément (nouvelle dépendance, vérifier d'abord si nginx compresse déjà).
+
+### SHELL-06
+
+**Valeur de StoreContext recréée à chaque rendu + re-rendu global à chaque pixel de redimensionnement** — perf-client, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/Layout.tsx:86`
+- **Constat :** Layout.tsx:86 `<StoreProvider value={{ selectedStoreId, setSelectedStoreId, stores, sidebarCollapsed, ... }}>` (objet littéral) ; MobileApp.tsx:55-64 `const storeContextValue = { ... }` sans useMemo. 35 composants consomment useStore(). use-screen-size.ts:35 `setDimensions({ width, height })` sur chaque événement resize (l.43) et le hook est utilisé par RouterProduction:57, Layout:26 et Sidebar:48 ; Layout et Sidebar ajoutent useIsMobile (matchMedia). Tout changement d'état UI (repli du menu, ouverture du menu mobile) re-rend aussi tous les consommateurs du magasin.
+- **Impact :** Redimensionner la fenêtre, replier le menu ou ouvrir un menu re-rend l'arbre complet (Layout + page + toutes les cartes), ce qui rend l'interface saccadée sur les PC de caisse peu puissants.
+- **Recommandation :** Automatisable : useMemo sur la valeur du contexte dans Layout et MobileApp avec une constante module `EMPTY_STORES: Group[] = []` comme défaut ; useScreenSize réécrit pour ne stocker que le palier, initialisé de façon synchrone depuis window.innerWidth, avec mise à jour seulement si le palier change ; supprimer use-phone-mode.ts dans le même changement (ou conserver un `dimensions` non stocké en state). Hors auto : séparation du contexte UI.
+
+### SHELL-07
+
+**Changement de magasin : invalidation par prédicat qui double les requêtes** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/Layout.tsx:138`
+- **Constat :** Layout.tsx:138-146 `queryClient.invalidateQueries({ predicate: (query) => ... includes('/api/orders') || includes('/api/deliveries') || includes('/api/stats/monthly') || includes('/api/tasks') })` est appelé AVANT `setSelectedStoreId(newStoreId)` (l.154). Les requêtes actives portent encore l'ancien storeId (ex. Dashboard.tsx:85 `queryKey: [ordersUrl, selectedStoreId]`) : elles sont refetchées pour l'ancien magasin, puis les nouvelles clés (qui contiennent déjà selectedStoreId) sont chargées. Dashboard.tsx:23-26 invalide aussi `/api/dlc-products` et `/api/dlc-products/stats` à chaque montage. Le mobile (MobileLayout.tsx:40-48) n'invalide rien : comportements divergents.
+- **Impact :** Chaque changement de magasin déclenche 2 vagues de requêtes (ancienne + nouvelle), dont une inutile ; chaque retour sur le tableau de bord recharge les DLC même si les données ont 2 secondes.
+- **Recommandation :** Automatisable : supprimer l'invalidation par prédicat de Layout.tsx:138-146 et le useEffect Dashboard.tsx:23-26. Hors auto : centraliser `changeStore()` dans StoreContext (desktop et mobile), qui est un refactor.
+
+### SHELL-08
+
+**Retry systématique sur 403/404/500 et redirections 401 par rechargement complet** — perf-api, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/lib/queryClient.ts:79`
+- **Constat :** queryClient.ts:79-89 `retry: (failureCount, error) => { if (...'401'...) { window.location.href = '/auth'; return false; } return failureCount < 2; }` -> toute erreur non-401 (403 droit refusé, 404, 500) est retentée 2 fois avec backoff (1 s puis 2 s). getQueryFn l.58-61 fait aussi `window.location.href = '/auth'` sur 401 : avec 10 requêtes actives, 10 redirections concurrentes. WeatherWidget.tsx:121-125 force `retry: 1` sur un endpoint qui répond 404 quand la météo n'est pas configurée (routes.ts:5675-5677).
+- **Impact :** Une erreur met ~3 s à s'afficher et coûte 3 requêtes au serveur ; un manager sans droit sur une ressource voit un chargement prolongé au lieu d'un message clair ; une session expirée provoque un rechargement brutal de la page.
+- **Recommandation :** Automatisable : `retry: (n, err) => { if (/^401\b/.test(err?.message) || err?.message?.includes('Unauthorized')) { /* conserver la redirection existante */ return false; } if (/^4\d\d\b/.test(err?.message)) return false; return n < 1; }` et `retry: false` dans WeatherWidget. La gestion unifiée du 401 (setQueryData + navigation wouter unique) est à faire avec SHELL-01.
+
+### SHELL-09
+
+**Connexion = attente artificielle de 500 ms + rechargement complet, et la page demandée est perdue** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/AuthPage.tsx:68`
+- **Constat :** AuthPage.tsx:68-71 `setTimeout(() => { window.location.href = "/"; }, 500);` après un login réussi. RouterProduction.tsx:47-53 `RedirectToAuth` envoie toute URL vers /auth sans mémoriser l'URL d'origine. RouterProduction.tsx:135 (`window.location.href = '/dashboard'`) et l.185 (`window.location.href = '/'`) déclenchent un rechargement complet pendant le rendu. Layout.tsx:81-83 `handleLogout` (GET /api/logout) n'est jamais utilisé.
+- **Impact :** Un employé qui ouvre un lien (ex. /dlc reçu par message) doit se connecter puis renaviguer manuellement ; chaque connexion recharge tout le bundle et relance les 5 appels /api/user (SHELL-01).
+- **Recommandation :** Après SHELL-01 : RedirectToAuth ajoute `?next=` (encodeURIComponent du chemin courant) ; après login : `await queryClient.invalidateQueries({ queryKey: ['/api/user'] })` puis `setLocation(next)` seulement si `next` commence par '/' et pas par '//' (sinon '/'). Remplacer les `window.location.href` du rendu par `<Redirect to="/" />`. Supprimer Layout.handleLogout.
+
+### SHELL-11
+
+**Trois sources de vérité différentes pour « qui voit quel module »** — coherence-design, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/Sidebar.tsx:247`
+- **Constat :** Sidebar.tsx:247-256 Commandes/Livraisons `roles: ["admin", "directeur", "manager"]` (rôles codés en dur) ; MobileBottomNav.tsx:29-43 montre Commandes, Livraisons et Avoirs à tout le monde (`const { user } = useAuthUnified();` l.47 n'est jamais utilisé) ; lib/permissions.ts:38-51 déclare `employee: ['view']` pour orders et deliveries, mais n'est pas utilisé par la navigation. Aucune route n'est protégée : RouterProduction.tsx:158-159 rend /users et /groups pour tout rôle authentifié (seules certaines actions sont désactivées dans les pages, ex. Users.tsx:71 `enabled: user?.role === 'admin'`).
+- **Impact :** Un employé voit « Commandes » sur son téléphone mais pas sur le PC ; il peut ouvrir /users par URL et tomber sur une page vide ou partielle. Toute évolution de droits doit être faite à 3 endroits.
+- **Recommandation :** Créer NAV_ITEMS unique (path, label, icon, module) partagé par Sidebar, MobileBottomNav et le Sheet mobile, filtré par hasModuleAccess après avoir étendu le type Module et la table PERMISSIONS aux modules manquants ; ajouter `<ProtectedRoute module=...>` avec un message « Accès non autorisé ». Décision produit préalable : l'employé voit-il Commandes/Livraisons/Avoirs ?
+
+### SHELL-12
+
+**Menu : sections déséquilibrées, libellés ambigus, icônes dupliquées, libellés différents du mobile** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/Sidebar.tsx:225`
+- **Constat :** Sidebar.tsx:225-364 : 19 entrées en 5 sections pour un admin (« GESTION PRINCIPALE » 2 entrées, « ANALYSES » 1 seule entrée l.279-287). Libellés : « Commandes » (l.248) vs « Commandes Client » (l.300), « Échéance » (l.266), « Rapprochement » (l.260), « BAP » (l.359). Même icône BarChart3 pour Tableau de bord (l.232) et Statistiques (l.284) ; « Magasins » avec l'icône Users (l.348) alors que Store sert de logo. Mobile (MobileBottomNav.tsx:30-42) : « Accueil », « Cmd Client », « DLC », icône CheckSquare pour Tâches vs ListTodo sur desktop (l.312).
+- **Impact :** Un employé non technicien ne distingue pas commandes fournisseurs et commandes clients ; « Échéance » et « BAP » sont du jargon comptable ; deux icônes identiques ralentissent le repérage ; changer d'appareil oblige à réapprendre les noms.
+- **Recommandation :** Regrouper en 3-4 sections métier : « Au quotidien » (Accueil, Tâches, DLC, Commandes clients, SAV), « Fournisseurs » (Commandes fournisseurs, Livraisons, Rapprochement BL / Factures, Avoirs, Échéancier), « Magasin » (Calendrier, Publicités, Contacts, Statistiques), « Administration ». Icônes uniques (LayoutDashboard, LineChart, Store). Mêmes libellés sur mobile via la config partagée de SHELL-11.
+
+### SHELL-14
+
+**En-tête occupé par la météo et la date (qui débordent) au lieu du titre de page et du magasin** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/Layout.tsx:106`
+- **Constat :** Layout.tsx:106 `<header className={`h-16 ...`}>` (64 px) contient WeatherWidget et DateWidget (l.123-127). WeatherWidget.tsx:157 `<CardContent className="p-4 min-h-[80px]">` : 80 px minimum dans un en-tête de 64 px -> débordement. DateWidget.tsx:19 et WeatherWidget.tsx:156 `shadow-lg hover:shadow-xl transition-all` sur des éléments non cliquables. Le sélecteur de magasin n'est rendu que pour admin/directeur/manager (l.131) : un employé ne voit son magasin nulle part. Aucun titre de page dans l'en-tête ; les pages utilisent des h2 (Orders.tsx:236, Dashboard.tsx:395) et le titre d'onglet ne change jamais.
+- **Impact :** La zone la plus visible de l'écran n'indique ni la page courante ni le magasin ; le widget météo (3 colonnes de températures) chevauche le contenu ; l'ombre au survol fait croire à un bouton.
+- **Recommandation :** En-tête = titre de la page courante (h1, dérivé de la config de navigation) + badge du magasin (lecture seule pour les employés) + météo compacte (icône + température, détail en infobulle). Retirer les ombres hover des widgets. Mettre à jour document.title par route.
+
+### SHELL-15
+
+**Directeur/manager multi-magasins : alerte rouge bloquante au lieu d'une présélection ; pastilles couleur invalides** — ux-simplicite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/components/Layout.tsx:195`
+- **Constat :** Layout.tsx:70-74 ne présélectionne un magasin que si `stores.length === 1` ; sinon l.195-208 affiche un bandeau rouge « Action requise : Veuillez sélectionner un magasin pour afficher les données. Vos permissions ne permettent pas... » pendant que le sélecteur affiche juste « Magasin » (l.161). Pastille : `style={{ backgroundColor: store.color || '#gray-400' }}` (l.180) et `'#gray'` (MobileLayout.tsx:166) sont des couleurs CSS invalides. Noms tronqués à `max-w-[120px]` (l.182) dans un sélecteur de 256 px (`w-64`, l.159).
+- **Impact :** À chaque nouvelle session sur un poste partagé, le directeur tombe sur un écran d'erreur rouge et des pages vides ; les magasins sans couleur n'ont pas de pastille ; les noms longs sont coupés sans raison.
+- **Recommandation :** Présélectionner le dernier magasin utilisé ou le premier magasin assigné pour directeur/manager et supprimer le bandeau. Remplacer les fallbacks par `'#9ca3af'`. Retirer `max-w-[120px]` sur desktop.
+
+### SHELL-16
+
+**Deux bleus concurrents et bouton primaire au contraste insuffisant (3,1:1)** — accessibilite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/index.css:16`
+- **Constat :** index.css:16 `--primary: hsl(207, 90%, 54%);` (= #2094F3) utilisé par le bouton shadcn par défaut (button.tsx:12 `bg-primary text-primary-foreground`), alors que le reste de l'interface code en dur blue-600 #2563eb : 26 `bg-blue-600`, 124 `text-blue-600/700` contre 30 `bg-primary` et 11 `text-primary` ; index.html:13 et manifest.json `theme-color #2563EB` ; focus forcé `#2563eb !important` (index.css:321, 342). Contrastes calculés (WCAG) : texte blanc sur --primary = 3,1:1 ; --destructive hsl(0,84%,60%) = 3,6:1 ; --accent = 2,5:1 (minimum AA texte 14 px : 4,5:1). blue-600 sur blanc = 5,17:1.
+- **Impact :** Les boutons d'action principaux (« Enregistrer », « Créer ») sont peu lisibles, surtout sur les écrans de magasin en plein jour ; deux bleus différents côte à côte donnent une impression de désordre.
+- **Recommandation :** Aligner le token sur blue-600 : `--primary: hsl(221, 83%, 53%)` (contraste 5,17:1) et assombrir --destructive (ex. red-600 hsl(0,72%,51%)). Remplacer progressivement les `bg-blue-600`/`text-blue-600` en dur par `bg-primary`/`text-primary`.
+
+### SHELL-17
+
+**Les modificateurs d'opacité (hover:bg-primary/90...) ne génèrent aucun CSS : pas de retour visuel au survol** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `tailwind.config.ts:44`
+- **Constat :** tailwind.config.ts:43-46 `primary: { DEFAULT: "var(--primary)", ... }` sans `<alpha-value>`, et index.css:16 définit le token comme couleur complète `hsl(207, 90%, 54%)`. Tailwind 3.4.17 ne peut alors pas appliquer d'opacité : vérifié en compilant `bg-primary/90 hover:bg-primary/90` -> seule `.bg-primary{background-color:var(--primary)}` est émise ; le CSS de production dist/public/assets/index-8CW9ARss.css ne contient aucune règle `bg-primary\/90` ni `bg-destructive\/90`. Utilisé par button.tsx:12 (`hover:bg-primary/90`) et l.14 (`hover:bg-destructive/90`), toast.tsx:78 (`text-foreground/50`).
+- **Impact :** Les boutons principaux et de suppression ne réagissent pas au survol : l'utilisateur n'a aucun indice qu'ils sont cliquables.
+- **Recommandation :** Passer les tokens au format canaux (`--primary: 221 83% 53%;`) et `hsl(var(--primary) / <alpha-value>)` dans tailwind.config.ts pour tous les tokens ; dans le même changement, supprimer ou convertir en `hsl(var(--x))` toutes les utilisations directes de `var(--primary|secondary|accent|...)` (index.css:112-221 notamment), puis vérifier visuellement boutons, toasts et dialogues.
+
+### SHELL-18
+
+**Coins incohérents : composants de base carrés, pages et mobile arrondis** — coherence-design, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/ui/button.tsx:8`
+- **Constat :** Les primitives shadcn ont perdu leur arrondi : button.tsx:8 (aucun `rounded-md`), card.tsx:12 `"border bg-white text-card-foreground shadow-sm"`, input.tsx:10 (pas de rounded), dialog.tsx:41 `... rounded-none`, alors que index.css:25 définit `--radius: 0.5rem` et que les pages utilisent `rounded-lg` 101 fois et `rounded-xl/2xl` 10 fois. Dans le shell : avatar carré (Sidebar.tsx:875 `h-8 w-8 bg-gray-100`) vs entrées de menu `rounded-md` (Sidebar.tsx:595) ; pastille magasin carrée sur desktop (Layout.tsx:178 `w-3 h-3`) mais ronde sur mobile (MobileLayout.tsx:165 `rounded-full`).
+- **Impact :** L'interface paraît assemblée de pièces disparates, ce qui nuit à la lisibilité et à la confiance des utilisateurs.
+- **Recommandation :** Choisir une règle (recommandé : `rounded-md` partout, `rounded-full` pour pastilles/avatars) ; la rétablir dans button, card, input, select, dialog, puis retirer les arrondis ad hoc des pages.
+
+### SHELL-19
+
+**index.css : 62 !important et règles globales qui écrasent bordures, focus et couleurs d'anneau** — dette-code, sévérité moyenne, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/index.css:280`
+- **Constat :** index.css:280-286 `.bg-blue-600 { border: none !important; outline: none !important; box-shadow: none !important; --tw-ring-color: transparent !important; ... }` supprime bordure et anneau de focus de tout élément bleu ; l.341-343 `* { --tw-ring-color: #2563eb !important; }` force tous les anneaux en bleu (ex. `focus:ring-red-400` de toast.tsx:78 ignoré) ; l.156-164 `html, body { overflow: hidden !important; } #root { overflow: hidden !important; }` ; propriété inexistante `ring: 0 !important;` (l.233, 246, 258) ; ~120 lignes (l.224-349) de surcharges répétées du calendrier ; `.layout-container { transition: all 0.3s }` (l.439-441) ; bloc `.phone-mode` (l.411-498) jamais utilisé (0 occurrence de `phone-mode` dans les .tsx).
+- **Impact :** Les navigations au clavier perdent des repères de focus, les états d'erreur rouges deviennent bleus, et chaque correction visuelle future nécessite un nouvel !important.
+- **Recommandation :** Supprimer d'abord le code mort sans effet visible (bloc .phone-mode, `ring: 0`) ; puis, avec vérification visuelle (calendrier, boutons bleus, toasts), retirer `.bg-blue-600 {...}` et `* { --tw-ring-color }` au profit du token `--ring` et de la prop `classNames` de components/ui/calendar.tsx.
+
+### SHELL-20
+
+**Langue déclarée en anglais et zoom bloqué sur mobile** — accessibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/index.html:2`
+- **Constat :** client/index.html:2 `<html lang="en">` alors que toute l'interface est en français ; l.5 `<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1" />` empêche le zoom par pincement (WCAG 1.4.4).
+- **Impact :** Les lecteurs d'écran prononcent le français avec une voix anglaise ; un employé qui a du mal à lire les textes de 10-12 px sur téléphone ne peut pas zoomer.
+- **Recommandation :** Automatisable : `<html lang="fr">` uniquement. Retirer `maximum-scale=1` seulement après avoir mis tous les champs saisissables mobiles à au moins 16 px (TasksPage.tsx:392, TaskFormUltraSimple.tsx).
+
+### SHELL-21
+
+**Boutons icône sans nom accessible et éléments cliquables non focusables** — accessibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/MobileBottomNav.tsx:86`
+- **Constat :** MobileBottomNav.tsx:86-97 le bouton « Plus » est un `<div ... onClick={() => setMoreOpen(true)}>` (non atteignable au clavier, pas de rôle bouton) ; Sidebar.tsx:652-664 l'entrée BAP est un `<div ... onClick={() => { setShowBapModal(true); ...}}>` ; boutons icône seule sans aria-label ni title : repli du menu Sidebar.tsx:544-555 (Chevron seul), hamburger Layout.tsx:111-119, hamburger MobileLayout.tsx:69-76.
+- **Impact :** Navigation clavier et lecteur d'écran impossibles sur ces commandes ; au survol, le bouton de repli ne dit pas ce qu'il fait.
+- **Recommandation :** Remplacer les div cliquables par `<button type="button">` (ajouter `w-full text-left` sur l'entrée BAP de la Sidebar) ; ajouter `aria-label` + `title` (« Réduire le menu »/« Déplier le menu » selon l'état, « Ouvrir le menu », « Plus de pages », « Envoyer un BAP »).
+
+### SHELL-22
+
+**Tailles de texte trop petites dans la navigation (10-11 px)** — lisibilite, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/mobile/MobileBottomNav.tsx:76`
+- **Constat :** MobileBottomNav.tsx:76 et 93 `text-[10px]` pour les libellés de la barre basse ; Sidebar.tsx:572 et 637 `text-[11px] font-bold text-gray-500 uppercase tracking-widest` pour les titres de section ; MobileLayout.tsx:89 nom du magasin en `text-xs` tronqué à `max-w-[80px]` ; `text-xs` (12 px) utilisé 301 fois dans client/src.
+- **Impact :** Public non technicien, souvent debout en magasin : libellés difficiles à lire, nom du magasin actif illisible sur mobile.
+- **Recommandation :** Minimum 12 px (`text-xs`) pour les libellés de la barre basse, titres de section en `text-xs font-semibold` sans majuscules forcées, nom du magasin en `text-sm` avec `max-w-[140px]`. Fixer 14 px comme taille de corps minimale pour les données.
+
+### SHELL-25
+
+**Rotation ou redimensionnement : toute l'application est démontée et remontée ; branches mobiles mortes dans Layout/Sidebar** — ux-simplicite, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:106`
+- **Constat :** RouterProduction.tsx:57 `const { isMobile } = useScreenSize();` puis l.106 `if (isMobile) return <MobileApp>...` sinon `<Layout>` : passer le seuil de 768 px (téléphone en paysage ≈ 844 px, fenêtre réduite) remplace un arbre par l'autre (perte des formulaires en cours, 5 nouveaux /api/user, rechargement des données). use-screen-size.ts:18 `useState<ScreenSize>('desktop')` : premier rendu toujours « desktop » avant correction (saut de mise en page sur tablette). Trois systèmes de points de rupture : useIsMobile (<768, matchMedia), useScreenSize (768/1024), use-phone-mode (<400, inutilisé). Layout n'étant rendu que si !isMobile, les branches mobiles de Layout (overlay l.89-94, hamburger l.110-120, init repliée l.40) et de Sidebar (tiroir l.374-377) sont inatteignables.
+- **Impact :** Un employé qui tourne son téléphone en saisissant une DLC perd sa saisie et voit l'interface changer complètement (menu latéral desktop sur petit écran).
+- **Recommandation :** Décider desktop/mobile une seule fois au démarrage (largeur + `matchMedia('(pointer: coarse)')`) ou au minimum avec hystérésis ; initialiser l'état de façon synchrone depuis window.innerWidth ; supprimer useIsMobile du shell et les branches mobiles mortes de Layout/Sidebar.
+
+### SHELL-28
+
+**Les identifiants par défaut « admin / admin » s'affichent par défaut sur l'écran de connexion** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `client/src/pages/AuthPage.tsx:25`
+- **Constat :** AuthPage.tsx:25 `const [showDefaultCredentials, setShowDefaultCredentials] = useState(true);` ; la carte l.256-271 affiche « Identifiant : admin / Mot de passe : admin » tant que /api/default-credentials-check n'a pas répondu, et l.38-41 renvoie `{ showDefault: true }` en cas d'erreur réseau.
+- **Impact :** Tout visiteur voit brièvement (ou durablement si l'appel échoue) des identifiants administrateur, ce qui est déroutant pour les employés et constitue un risque si le mot de passe n'a pas été changé.
+- **Recommandation :** Initialiser à `false` et ne montrer la carte que si la réponse vaut explicitement `showDefault === true` ; en cas d'erreur, ne rien afficher.
+
+### SHELL-13
+
+**Sur l'accueil « / » (page d'arrivée après connexion) aucune entrée du menu n'est active** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/Sidebar.tsx:219`
+- **Constat :** Sidebar.tsx:219-223 `const isActive = (path) => { if (path === "/" && location === "/") return true; if (path !== "/" && location.startsWith(path)) return true; ... }` mais aucune entrée n'a le chemin « / » : « Tableau de bord » pointe vers /dashboard (l.230). La connexion redirige vers « / » (AuthPage.tsx:70) et RouterProduction.tsx:153 et 191 servent la même page sous deux URLs. Le mobile gère le cas (MobileBottomNav.tsx:51 `if (path === "/dashboard" && (location === "/" || location === "/dashboard"))`).
+- **Impact :** Juste après la connexion, l'utilisateur ne sait pas où il se trouve dans le menu.
+- **Recommandation :** Dans Sidebar.isActive, ajouter `if (path === "/dashboard" && (location === "/" || location === "/dashboard")) return true;` (même logique que le mobile) ; ne pas changer les URLs.
+
+### SHELL-23
+
+**Page 404 en anglais avec message destiné aux développeurs** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/not-found.tsx:11`
+- **Constat :** not-found.tsx:11 `<h1 ...>404 Page Not Found</h1>` et l.14-15 `Did you forget to add the page to the router?` ; aucun bouton de retour ; `min-h-screen` (l.6) alors que la page est rendue dans la zone de contenu du Layout (RouterProduction.tsx:192).
+- **Impact :** Un employé qui suit un ancien lien voit un message incompréhensible et ne sait pas comment revenir.
+- **Recommandation :** « Page introuvable — Cette page n'existe pas ou a été déplacée » + bouton « Retour à l'accueil » (`<Link href="/">`) ; remplacer `min-h-screen` par `py-16`.
+
+### SHELL-24
+
+**Rôle affiché en anglais sur mobile, libellé recalculé à la main sur desktop** — lisibilite, sévérité basse, effort S
+
+- **Fichier :** `client/src/pages/mobile/MobileLayout.tsx:136`
+- **Constat :** MobileLayout.tsx:136 `<p className="text-sm text-gray-500 capitalize">{user.role}</p>` affiche « Employee », « Admin » ; Sidebar.tsx:885-887 recalcule en ternaires `user?.role === 'admin' ? 'Administrateur' : ...` alors que lib/roleUtils.ts:24 fournit `getRoleDisplayName()`.
+- **Impact :** Incohérence de langue et de libellé entre PC et téléphone.
+- **Recommandation :** Utiliser `getRoleDisplayName(user.role ?? 'employee')` dans MobileLayout.tsx:136 (retirer `capitalize`) et Sidebar.tsx:885-887.
+
+### SHELL-26
+
+**Code mort et dupliqué dans le shell (hooks, nav, fichiers .tmp, scripts publics)** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `client/src/components/Sidebar.tsx:394`
+- **Constat :** Jamais importés : hooks/useAuth.ts, hooks/useAuthProduction.ts, hooks/use-phone-mode.ts, components/PhoneBottomNav.tsx, components/ToasterRobust.tsx + hooks/use-toast-robust.ts, components/Responsive{Dashboard,Orders,Deliveries,Tasks,Calendar}.tsx (≈578 lignes au total). 36 fichiers `*.tsx.tmp` versionnés dans components/ui. client/public/nocodb-protection-patch.js et nocodb-urgent-fix.js ne sont référencés nulle part mais copiés dans dist/public et servis publiquement (ils remplacent console.error pour masquer les erreurs). En-tête de la Sidebar dupliqué 3 fois (Sidebar.tsx:394-443, 450-501, 514-558).
+- **Impact :** Maintenance plus lente et risques de corriger le mauvais fichier ; les scripts publics peuvent masquer des erreurs si quelqu'un les rebranche.
+- **Recommandation :** Supprimer ces fichiers ; extraire l'en-tête de la Sidebar dans un composant `SidebarHeader` réutilisé par les 3 états.
+
+### SHELL-27
+
+**Appel de hook dans une fonction asynchrone (forceAuthRefresh) et comportement dev/prod divergent** — bug, sévérité basse, effort S
+
+- **Fichier :** `client/src/hooks/useAuthUnified.ts:129`
+- **Constat :** useAuthUnified.ts:124-130 dans `forceAuthRefresh` (fonction async appelée depuis AuthPage.tsx:112 après login) : `const queryClient = useQueryClient(); queryClient.invalidateQueries(...)` -> violation des règles des hooks (« Invalid hook call » hors rendu). Par ailleurs l.8-11 la détection `isDevelopment` fait tourner React Query en dev (1 seul appel partagé) et des fetch indépendants en prod : les bugs SHELL-01/02 sont invisibles en local.
+- **Impact :** Connexion potentiellement cassée en développement ; les problèmes de performance et de données non filtrées ne sont reproductibles qu'en production.
+- **Recommandation :** Importer `queryClient` depuis @/lib/queryClient au lieu d'appeler le hook ; à terme, une seule implémentation identique dev/prod (SHELL-01).
+
+### SHELL-29
+
+**Fonction métier BAP (≈300 lignes) logée dans le menu, avec destinataires et URL codés en dur** — dette-code, sévérité basse, effort M
+
+- **Fichier :** `client/src/components/Sidebar.tsx:794`
+- **Constat :** Sidebar.tsx:49-187 et 712-868 : état, upload et deux modales BAP dans le composant de navigation ; destinataires figés `<SelectItem value="Laurie">` (l.794) et `<SelectItem value="Jeremy">` (l.802) ; URL de secours codée en dur l.121 `https://workflow.ffnancy.fr/webhook/...` ; envoi direct navigateur -> webhook externe (l.143), bloqué par la CSP `connect-src 'self'` (server/security.ts:117) quand l'app est servie par server/index.ts ; texte « Ou glissez-déposez votre fichier » (l.740) sans aucun gestionnaire onDrop.
+- **Impact :** Le menu devient lourd à maintenir ; ajouter un destinataire nécessite un déploiement ; le glisser-déposer annoncé ne fonctionne pas.
+- **Recommandation :** Extraire dans components/modals/BapSendModal.tsx chargé à la demande ; faire passer l'envoi par une route serveur (proxy vers le webhook) ; ajouter un champ destinataires à la config webhook BAP (migration de schéma) avant de retirer Laurie et Jeremy du code ; ajouter onDrop/onDragOver ou retirer la mention glisser-déposer.
+
+### SHELL-30
+
+**Un seul ErrorBoundary global : une erreur dans une page efface aussi le menu** — ux-simplicite, sévérité basse, effort S
+
+- **Fichier :** `client/src/App.tsx:10`
+- **Constat :** App.tsx:10-17 `<ErrorBoundary>` enveloppe tout l'arbre (QueryClientProvider, RouterProduction, Layout). ErrorBoundary.tsx:39 affiche un écran plein (`min-h-screen`) avec un bouton « Réessayer » qui ne fait que `setState({ hasError: false })` (l.27-29) — la même erreur se reproduit immédiatement ; aucun lien vers l'accueil.
+- **Impact :** Une erreur dans une seule carte du tableau de bord bloque toute l'application ; l'utilisateur doit recharger la page à la main.
+- **Recommandation :** Ajouter un ErrorBoundary par route à l'intérieur de la zone de contenu du Layout/MobileLayout (réinitialisé au changement d'URL via `key={location}`), avec boutons « Réessayer » et « Retour à l'accueil » ; garder le global en dernier recours.

docs/audit-webui/14-server-infra.md

@@ -0,0 +1,257 @@
+# Infrastructure serveur
+
+_19 constats vérifiés — 6 haute, 6 moyenne, 7 basse._
+
+## Pages analysées
+
+### `/* (index.html, /assets/*, fallback SPA)`
+
+**Rôle :** Livrer l'application (HTML, JS, CSS, favicon, manifest) aux navigateurs des PC et mobiles des magasins. C'est le premier contact de l'utilisateur avec LogiFlow, et le temps avant le premier écran en dépend.
+
+**Tâches principales de l'utilisateur :**
+- Ouvrir LogiFlow le matin (premier chargement)
+- Recharger une page ou ouvrir un nouvel onglet
+- Ouvrir un lien direct (ex. /deliveries) via le fallback SPA
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| GET /assets/index-*.js, vendor-*.js, index-*.css | au chargement initial et à chaque rechargement | server/index.production.ts:143-144 express.static (enregistré après registerRoutes, donc après session et passport) | 1 842 832 octets bruts, sans compression. Cache-Control: public, max-age=0 par défaut, donc revalidation à chaque rechargement. Chaque requête déclenche passport.deserializeUser, soit 2 requêtes SQL. |
+| GET /* (fallback SPA vers index.html) | navigation directe ou rechargement sur une route client | server/index.production.ts:158-169 app.get('*') avec res.sendFile et console.log à chaque appel | Passe par la session et passport (2 requêtes SQL). Pas de Cache-Control: no-cache explicite. |
+| GET https://replit.com/public/js/replit-dev-banner.js | au parsing de index.html (script synchrone) | tiers (client/index.html:19, recopié dans dist/public/index.html:24) | Bloque la fin du parsing, donc le démarrage du module principal de l'application. |
+
+**Lisibilité / simplicité :** Le premier écran est lent à apparaître : environ 1,8 Mo de JS/CSS non compressé, toutes les pages et recharts préchargés dès l'écran de connexion, et un script tiers replit.com bloquant. Sans cache long, chaque rechargement relance 6 à 9 requêtes réseau, et chacune réveille la session et la base de données. Si le pare-feu du magasin filtre replit.com, l'écran peut rester blanc jusqu'au timeout réseau.
+
+### `/api/* (chaîne de middlewares transversale à toutes les requêtes API)`
+
+**Rôle :** Servir toutes les données métier (commandes, livraisons, rapprochement, avoirs, DLC, tâches...). La latence de base de ces middlewares s'ajoute à chaque appel de chaque page.
+
+**Tâches principales de l'utilisateur :**
+- Afficher n'importe quelle liste (commandes, livraisons, DLC, tâches...)
+- Créer ou modifier un enregistrement
+- Changer de magasin (relance de toutes les requêtes)
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| (toute requête authentifiée) désérialisation de session | à chaque requête HTTP portant le cookie de session, assets compris | server/localAuth.ts:141-148 passport.deserializeUser, puis storage.getUserWithGroups (server/storage.ts:371-406) : SELECT users, puis SELECT user_groups JOIN groups | 2 requêtes SQL séquentielles à chaque requête. Sessions en MemoryStore (localAuth.ts:98-108). |
+| GET /api/orders, /api/deliveries, /api/contacts, etc. (130 handlers) | au montage des pages et au changement de magasin | server/routes.ts:1345, 1754, 1275... : await storage.getUserWithGroups(req.user...) (106 occurrences) ou storage.getUser (24 occurrences) | L'utilisateur, déjà chargé dans req.user, est rechargé : 4 requêtes SQL d'identité avant la requête métier. |
+| wrapper res.json sur /api | chaque réponse JSON | server/routes.ts:165-171 qui appelle stripSmtpPassword (server/sanitize.ts:13-42) | Clone profond de chaque réponse : +11,7 ms mesurés pour 2000 livraisons (1,6 Mo). |
+| logger de requêtes | chaque requête /api | server/index.production.ts:30-39 | console.log synchrone vers le pipe Docker, en plus des 266 console.log de routes.ts. |
+
+**Lisibilité / simplicité :** Chaque appel API paie un surcoût fixe : 4 allers-retours SQL d'identité, un clonage complet de la réponse, des logs synchrones et une réponse non compressée. En production Docker, les index de performance ne sont probablement pas créés, et la purge du cache factures ne tourne pas. Les deux points d'entrée (index.ts et index.production.ts) divergent fortement, si bien que le comportement observé en dev n'est pas celui de la production.
+
+### `/auth (connexion), soit POST /api/login et GET /api/user`
+
+**Rôle :** Connecter l'employé ou le manager, puis charger son profil et ses magasins.
+
+**Tâches principales de l'utilisateur :**
+- Se connecter le matin
+- Rester connecté entre deux redéploiements
+- Obtenir son rôle et ses magasins (sélecteur de magasin)
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| POST /api/login | au clic sur Se connecter | server/localAuth.ts:152-185 : LocalStrategy (getUserByUsername + scrypt), puis await backupService.checkAndPerformDailyBackup (backupService.ts:240-300), qui lance un pg_dump complet à la première connexion du jour | La réponse attend la fin de la sauvegarde. Ensuite, fs.readFileSync sur le dump bloque l'event loop (backupService.ts:133-135). |
+| GET /api/user | au montage de l'app (hooks useAuth*) | server/localAuth.ts:204-230 : getUserWithGroups recalculé alors que deserializeUser vient de le faire | 4 requêtes SQL pour renvoyer un profil déjà en mémoire. |
+
+**Lisibilité / simplicité :** Le premier employé du jour attend la fin d'un pg_dump complet avant d'entrer dans l'application. Chaque redéploiement déconnecte tout le monde, car les sessions sont gardées en mémoire, et il faut ressaisir ses identifiants.
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [INFRA-01](#infra-01) | haute | perf-serveur | M | Les index de performance ne sont jamais appliqués en production Docker | `Dockerfile:119` |
+| [INFRA-02](#infra-02) | haute | perf-api | M | L'utilisateur et ses magasins sont rechargés 2 fois par requête (4 requêtes SQL d'identité) | `server/routes.ts:1345` |
+| [INFRA-03](#infra-03) | haute | perf-serveur | S | Les fichiers statiques passent par la session et passport (2 requêtes SQL par asset) | `server/index.production.ts:129` |
+| [INFRA-04](#infra-04) | haute | perf-client | S | Aucune compression HTTP (gzip/brotli) des assets ni du JSON | `server/index.production.ts:27` |
+| [INFRA-05](#infra-05) | haute | perf-client | S | Les assets hashés sont servis sans cache long (revalidation à chaque rechargement) | `server/index.production.ts:143` |
+| [INFRA-06](#infra-06) | haute | perf-client | S | Le script tiers replit-dev-banner.js bloque le démarrage de l'application en production | `client/index.html:19` |
+| [INFRA-07](#infra-07) | moyenne | perf-api | S | La connexion attend un pg_dump complet et bloque l'event loop (première connexion du jour) | `server/localAuth.ts:165` |
+| [INFRA-08](#infra-08) | moyenne | bug | S | Sessions en MemoryStore en production : déconnexion de tous les utilisateurs à chaque redéploiement | `server/localAuth.ts:98` |
+| [INFRA-09](#infra-09) | moyenne | perf-serveur | S | La purge du cache de vérification des factures ne tourne pas en production | `server/index.production.ts:129` |
+| [INFRA-10](#infra-10) | moyenne | dette-code | M | Deux points d'entrée serveur divergents (middlewares, CSRF, rate limit différents entre dev et prod) | `server/index.production.ts:25` |
+| [INFRA-11](#infra-11) | moyenne | bug | S | La sanitisation globale échappe le HTML en entrée et corrompt apostrophes, dates et URLs | `server/security.ts:202` |
+| [INFRA-12](#infra-12) | moyenne | perf-bundle | M | Toutes les pages et recharts sont téléchargés dès l'écran de connexion (pas de code splitting) | `client/src/components/RouterProduction.tsx:1` |
+| [INFRA-13](#infra-13) | basse | perf-api | M | stripSmtpPassword clone en profondeur chaque réponse JSON /api | `server/routes.ts:168` |
+| [INFRA-14](#infra-14) | basse | perf-serveur | M | Logs console verbeux et synchrones sur les chemins chauds, sans rotation | `server/routes.ts:1353` |
+| [INFRA-15](#infra-15) | basse | bug | S | Le gestionnaire d'erreurs relance l'exception après avoir répondu (connexion coupée) | `server/index.production.ts:136` |
+| [INFRA-16](#infra-16) | basse | perf-api | S | Aucun en-tête Cache-Control sur les réponses /api | `server/routes.ts:165` |
+| [INFRA-17](#infra-17) | basse | bug | S | NODE_ENV forcé trop tard (imports ESM hissés) et absent du Dockerfile | `server/index.production.ts:18` |
+| [INFRA-18](#infra-18) | basse | perf-serveur | S | Driver BD choisi par heuristique sur le nom d'hôte, pool sans statement_timeout | `server/db.ts:17` |
+| [INFRA-19](#infra-19) | basse | dette-code | S | Code d'infrastructure mort ou trompeur (cache, compression, monitoring, auth/db « production ») | `server/cache.ts:93` |
+
+### INFRA-01
+
+**Les index de performance ne sont jamais appliqués en production Docker** — perf-serveur, sévérité haute, effort M
+
+- **Fichier :** `Dockerfile:119`
+- **Constat :** Dockerfile:119 `CMD ["sh", "-c", "... psql \"$DATABASE_URL\" -c 'ALTER TABLE dlc_products ADD COLUMN IF NOT EXISTS stock_epuise ...' ...; node dist/index.js"]`. Le Dockerfile n'a pas d'ENTRYPOINT et docker-compose.yml n'a ni entrypoint ni command. Seul scripts/docker-entrypoint.sh (l.53-59) appelle scripts/auto-migrate-production.sh, qui contient la création des index (l.125-150 : `CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_user_groups_user_id ON user_groups (user_id); ... idx_deliveries_order_id ...`). Ce script n'est donc jamais lancé. De plus, les deux scripts commencent par `#!/bin/bash` alors que l'image node:20-alpine n'installe que `wget postgresql-client` (Dockerfile:105). migrations/migrate.js, que cite migrations/20260814_add_performance_indexes.sql, utilise `const { Pool } = require('pg')` dans un package `"type": "module"` et n'est référencé nulle part. server/migrations.ts runMigrations() n'est jamais appelé. runProductionMigrations ne crée que idx_sav_tickets_priority et idx_supplier_mail_logs_* (migrations.production.ts:44, 98-99).
+- **Impact :** Sauf création manuelle, orders, deliveries, user_groups, dlc_products, etc. sont lues par scan séquentiel. user_groups est lue à chaque requête authentifiée. Les listes et le calendrier filtrés par magasin ou par date ralentissent à mesure que les tables grossissent. Gain estimé : x10 à x100 sur les requêtes filtrées dès quelques milliers de lignes, souvent plusieurs centaines de ms par page.
+- **Recommandation :** 1) Vérifier l'état réel en prod avec pg_indexes. 2) Option à privilégier : créer les index dans Node. Point important : pg exécute une chaîne de plusieurs statements dans une transaction implicite, et CREATE INDEX CONCURRENTLY y échoue (`cannot run inside a transaction block`). Il faut donc envoyer chaque `CREATE INDEX CONCURRENTLY IF NOT EXISTS` dans un `client.query()` séparé, après avoir purgé les index invalides (bloc DO de auto-migrate-production.sh:131-145). Il vaut mieux lancer cette création en tâche de fond après `server.listen`, pour ne pas retarder le démarrage ni le healthcheck. 3) Option ENTRYPOINT : elle est déconseillée sans tests, car ces scripts bash n'ont jamais tourné dans l'image, utilisent `set -e` et des bashismes, et il faudrait aussi conserver l'ALTER TABLE dlc_products du CMD actuel.
+
+### INFRA-02
+
+**L'utilisateur et ses magasins sont rechargés 2 fois par requête (4 requêtes SQL d'identité)** — perf-api, sévérité haute, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:1345`
+- **Constat :** server/localAuth.ts:141-143 `passport.deserializeUser(async (id) => { const user = await storage.getUserWithGroups(id); ...` s'exécute à chaque requête. storage.ts:372 `const user = await this.getUser(id);` puis l.376-386 `SELECT ... FROM user_groups ug INNER JOIN groups g ... WHERE ug.user_id = ${id}`, soit 2 allers-retours séquentiels. Les handlers rechargent ensuite le même utilisateur : 106 occurrences de `await storage.getUserWithGroups(req.user.claims ? req.user.claims.sub : req.user.id)` (ex. routes.ts:1345 /api/orders, 1754 /api/deliveries, 1275 /api/contacts) et 24 de `storage.getUser(`. /api/user fait de même (localAuth.ts:211).
+- **Impact :** Chaque appel API enchaîne 4 requêtes SQL séquentielles avant la requête métier. Une page qui lance environ 10 appels au montage produit environ 40 requêtes d'identité qui se disputent le pool de 25 connexions. Gain estimé : passer de 4 à 1 requête (voire 0 avec un cache), soit -2 à -8 ms par appel en local et davantage sous charge, et -75 % de requêtes SQL d'identité.
+- **Recommandation :** Ne remplacer par `const user = req.user` QUE les appels dont l'argument est l'identifiant de l'utilisateur courant (`req.user.claims ? req.user.claims.sub : req.user.id`, ou une variable userId dérivée de req.user). Exclure explicitement routes.ts:4282 (que l'on corrigera plutôt par une seule requête groupée pour tous les utilisateurs) et 4512. Le mieux est d'introduire un helper `getCurrentUser(req)` qui renvoie req.user. Réécrire getUserWithGroups en une seule requête (LEFT JOIN + json_agg) est sans risque. En revanche, le cache mémoire avec TTL retarde la révocation des rôles et des magasins : c'est une décision produit.
+
+### INFRA-03
+
+**Les fichiers statiques passent par la session et passport (2 requêtes SQL par asset)** — perf-serveur, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/index.production.ts:129`
+- **Constat :** index.production.ts:129 `await registerProductionRoutes(app);` appelle registerRoutes, puis routes.ts:183 `await setupAuth(app);`, puis localAuth.ts:110-112 `app.use(session(sessionSettings)); app.use(passport.initialize()); app.use(passport.session());`. Tout cela est enregistré AVANT index.production.ts:143-144 `app.use('/assets', express.static(...)); app.use('/', express.static(publicPath));`. Chaque requête d'asset portant le cookie déclenche deserializeUser, donc getUserWithGroups (2 requêtes SQL), puis parcourt les 134 routes de routes.ts avant d'atteindre express.static. Le fallback SPA (l.158-169) subit le même chemin.
+- **Impact :** Un chargement complet (index.html, 6 assets, favicon.svg/ico, manifest.json) fait environ 9 à 10 requêtes, soit environ 20 requêtes SQL inutiles en concurrence avec les vrais appels API du montage. Gain estimé : -20 requêtes SQL par chargement et -2 à -10 ms par asset.
+- **Recommandation :** Dans index.production.ts uniquement, déclarer avant `await registerProductionRoutes(app)` : `app.use('/assets', express.static(join(publicPath,'assets'), { maxAge:'1y', immutable:true, index:false, fallthrough:true }))` et `app.use(express.static(publicPath, { index:false }))`. Déclarer aussi le fallback SPA filtré `app.get(/^\/(?!api\/).*/, (req,res)=>{ res.set('Cache-Control','no-cache'); res.sendFile(join(publicPath,'index.html')); })`, puis supprimer les l.143-169. Ne pas toucher à index.ts/vite.ts, ou alors seulement après avoir fait exclure /api au catch-all de serveStatic.
+
+### INFRA-04
+
+**Aucune compression HTTP (gzip/brotli) des assets ni du JSON** — perf-client, sévérité haute, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/index.production.ts:27`
+- **Constat :** package.json ne contient pas `compression`, et aucune occurrence dans package-lock.json. Aucun app.use(compression()) dans index.ts ni index.production.ts. Le seul code de compression, server/cache.ts:93-100 `if (req.accepts('gzip') && ...) res.setHeader('Content-Encoding', 'gzip');`, ne compresse rien et n'est jamais importé. Mesures sur dist/public/assets : 1 842 832 octets bruts, contre 454 684 en gzip -9 (-75 %) et environ 357 Ko en brotli. index-CCl1yENM.js passe de 1 081 745 à 257 997 octets en gzip. Un JSON de 2000 livraisons passe de 762 Ko à 35 Ko en gzip (5,7 ms). Le nginx externe (réseau nginx_default) n'est pas versionné, et par défaut nginx ne compresse que text/html (gzip_types).
+- **Impact :** Premier chargement d'environ 1,8 Mo au lieu d'environ 0,45 Mo : sur une ligne magasin à 5 Mbit/s, environ 2,9 s de transfert contre environ 0,7 s. Les grosses listes JSON (livraisons, commandes, DLC) pèsent 5 à 20 fois plus que nécessaire. Gain estimé : -75 % sur les assets et -85 à -95 % sur le JSON.
+- **Recommandation :** `npm i compression` (dans les dependencies), puis `app.use(compression({ threshold: 1024 }))` en tout premier middleware dans index.production.ts et index.ts. Ajouter OBLIGATOIREMENT `--external:compression` à la commande esbuild du Dockerfile (l.41-65), sinon le serveur plante au démarrage. Précompresser au build reste une option. Supprimer server/cache.ts, qui est du code mort et un no-op.
+
+### INFRA-05
+
+**Les assets hashés sont servis sans cache long (revalidation à chaque rechargement)** — perf-client, sévérité haute, effort S
+
+- **Fichier :** `server/index.production.ts:143`
+- **Constat :** index.production.ts:143-144 `app.use('/assets', express.static(join(publicPath, 'assets'))); app.use('/', express.static(publicPath));` sans option maxAge, donc serve-static envoie `Cache-Control: public, max-age=0`. Même chose dans server/vite.ts:79 `app.use(express.static(distPath));`. Les noms sont pourtant hashés (index-CCl1yENM.js, vendor-react-DogKF7zp.js...). L'index.html et le fallback SPA (l.147-169) n'ont pas non plus de `Cache-Control: no-cache` explicite.
+- **Impact :** À chaque rechargement ou nouvel onglet, le navigateur renvoie 6 requêtes conditionnelles (304) pour JS/CSS, plus favicon et manifest. Chacune passe par la session et la base (INFRA-03). Gain estimé : 0 requête réseau pour les assets après la première visite, soit -100 à -400 ms par rechargement selon la latence.
+- **Recommandation :** `/assets` : `{ maxAge:'1y', immutable:true, index:false }`. Racine : `express.static(publicPath, { index:false, maxAge:'1d' })`, ou `setHeaders` qui force `no-cache` sur les .html. Pour index.html, la route `/` et le fallback SPA, faire `res.set('Cache-Control','no-cache')` avant sendFile. À regrouper avec INFRA-03 dans index.production.ts.
+
+### INFRA-06
+
+**Le script tiers replit-dev-banner.js bloque le démarrage de l'application en production** — perf-client, sévérité haute, effort S
+
+- **Fichier :** `client/index.html:19`
+- **Constat :** client/index.html:18-19 `<!-- This is a replit script ... --> <script type="text/javascript" src="https://replit.com/public/js/replit-dev-banner.js"></script>` est recopié tel quel dans le build : dist/public/index.html:24. Le script est synchrone (ni async ni defer). Le bundle principal est `type="module"` (différé, l.14) et ne s'exécute qu'une fois le parsing terminé, donc après le téléchargement et l'exécution de ce script tiers. index.production.ts n'envoie pas de CSP : la requête vers replit.com part donc réellement en production.
+- **Impact :** Il faut une résolution DNS, une poignée de main TLS et un téléchargement vers replit.com (environ 100 à 500 ms) avant que React ne démarre. Si le pare-feu du magasin ignore les paquets vers replit.com, l'écran reste blanc jusqu'au timeout réseau. Gain : -100 à -500 ms au premier rendu, et une dépendance externe inutile en moins.
+- **Recommandation :** Supprimer les lignes 18-19 de client/index.html, puis rebuild.
+
+### INFRA-07
+
+**La connexion attend un pg_dump complet et bloque l'event loop (première connexion du jour)** — perf-api, sévérité moyenne, effort S
+
+- **Fichier :** `server/localAuth.ts:165`
+- **Constat :** localAuth.ts:160-171 `req.login(user, async (err) => { ... const backupResult = await backupService.checkAndPerformDailyBackup(user.id); ... res.json({...})`. backupService.ts:130 `await execAsync(command, { env });` lance pg_dump. Ensuite l.133-135 `fs.statSync(filepath); const sqlContent = fs.readFileSync(filepath, 'utf8'); ... sqlContent.match(/CREATE TABLE/g)` lit tout le dump de façon synchrone. Toutes les autres connexions font au moins 2 requêtes SQL (utilities, database_backups, l.243-263) avant de répondre. Un planificateur quotidien à 2h existe déjà (backupService.ts:303 scheduleAutomaticBackup).
+- **Impact :** Le premier employé connecté chaque jour attend la durée complète du pg_dump (plusieurs secondes selon la taille de la base) sur l'écran de connexion. Pendant le readFileSync et la regex sur le dump, toutes les requêtes du serveur sont gelées. Gain : connexion toujours sous 200 ms, et plus aucun gel global.
+- **Recommandation :** Dans localAuth.ts : `res.json({...}); setImmediate(() => backupService.checkAndPerformDailyBackup(user.id).catch(err => console.error(err)));`. Dans createBackup, remplacer statSync/readFileSync par `await fs.promises.stat(filepath)` et compter les tables autrement, par exemple en lisant le fichier en flux ou via information_schema.
+
+### INFRA-08
+
+**Sessions en MemoryStore en production : déconnexion de tous les utilisateurs à chaque redéploiement** — bug, sévérité moyenne, effort S
+
+- **Fichier :** `server/localAuth.ts:98`
+- **Constat :** routes.ts:4 `import { setupLocalAuth, requireAuth } from "./localAuth";`, qui est la version dev intégrée au bundle Docker (Dockerfile:41 esbuild server/index.production.ts). localAuth.ts:96-108 `console.log('🔧 Using memory session store for development'); const sessionSettings = { ... // Using default memory store`. index.production.ts:8 importe `setupLocalAuth` de localAuth.production.js (store connect-pg-simple + `app.set("trust proxy", 1)`, l.142-161) sans jamais l'appeler. express-session 1.18.2 l'avertit lui-même (node_modules/express-session/index.js:153-154 : `if (env === 'production' && store instanceof MemoryStore) console.warn(warning)`).
+- **Impact :** Chaque redémarrage du conteneur (déploiement, crash, mise à jour) déconnecte tout le monde, et chaque employé doit se reconnecter. Les sessions expirées ne sont jamais purgées (fuite mémoire lente). Sans `trust proxy` derrière nginx, req.ip est l'IP du proxy et les cookies secure sont impossibles.
+- **Recommandation :** Décision produit : faut-il que les sessions survivent aux redéploiements ? Si oui, utiliser connect-pg-simple, déjà installé et déjà externalisé. Sinon, utiliser memorystore avec checkPeriod 24h, en ajoutant `--external:memorystore` à la commande esbuild du Dockerfile. Dans les deux cas, ajouter `app.set('trust proxy', 1)` et ne garder qu'une seule implémentation d'auth.
+
+### INFRA-09
+
+**La purge du cache de vérification des factures ne tourne pas en production** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/index.production.ts:129`
+- **Constat :** server/index.ts:63-64 `const { startMaintenanceJobs } = await import('./maintenance.js'); startMaintenanceJobs();`. Cet appel n'existe pas dans server/index.production.ts, seul point d'entrée Docker (Dockerfile:41). maintenance.ts:4-8 le rappelle : « les entrées expirées s'accumulaient indéfiniment et alourdissaient chaque lecture du cache ». clearExpiredCache n'est appelé nulle part ailleurs.
+- **Impact :** En production, la table invoice_verification_cache grossit sans fin, et les lectures du cache de rapprochement ralentissent progressivement. Gain : la table reste à sa taille utile.
+- **Recommandation :** Ajouter `const { startMaintenanceJobs } = await import('./maintenance.js'); startMaintenanceJobs();` après `await registerProductionRoutes(app);` dans index.production.ts.
+
+### INFRA-10
+
+**Deux points d'entrée serveur divergents (middlewares, CSRF, rate limit différents entre dev et prod)** — dette-code, sévérité moyenne, effort M
+
+- **Fichier :** `server/index.production.ts:25`
+- **Constat :** index.ts:28-46 : `app.use(cookieParser()); setupSecurityHeaders(app); setupRateLimiting(app); setupInputSanitization(app); if (NODE_ENV==='production') setupCsrfProtection(app);`. index.production.ts:25-39 n'a rien de tout cela. package.json `"start": "NODE_ENV=production node dist/server/index.js"` lance index.ts avec le CSRF actif, alors que le client n'envoie jamais `x-csrf-token` (0 occurrence de « csrf » dans client/src) : toute mutation y renverrait 403. security.ts:139-185 applique 1000 req/15 min et 300 req/min par IP sans `trust proxy` : derrière nginx, tous les magasins partagent le même compteur.
+- **Impact :** Ce qui est testé en dev (sanitisation, CSRF, rate limit, purge) n'est pas ce qui tourne en prod, et l'inverse. Les régressions et les écarts de performance n'apparaissent qu'en production.
+- **Recommandation :** Extraire un `createApp()` commun (parsers, sécurité, statiques, routes, maintenance, gestion d'erreurs) appelé par les deux points d'entrée, avec des options explicites. Décider des middlewares de sécurité à garder en prod, et ajouter le header CSRF dans apiRequest si le CSRF est conservé. Supprimer ou aligner le script `start`.
+
+### INFRA-11
+
+**La sanitisation globale échappe le HTML en entrée et corrompt apostrophes, dates et URLs** — bug, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/security.ts:202`
+- **Constat :** security.ts:202 `sanitized = validator.escape(sanitized);` est appliqué récursivement à req.body et req.query (l.308-315), branché par index.ts:37. Vérifié : `validator.escape("L'Oréal 12/03/2025 https://x.fr/a")` donne `L&#x27;Oréal 12&#x2F;03&#x2F;2025 https:&#x2F;&#x2F;x.fr&#x2F;a`. detectSqlInjection (l.278-283) contient `/(--|\#|\/\*|\*\/)/` : chaque « Commande #123 » ou couleur « #2563EB » déclenche un console.warn. Le corps entier (jusqu'à 10 Mo) est aussi recopié à chaque requête.
+- **Impact :** Dans tout environnement lancé via index.ts, les noms avec apostrophe (très fréquents en français), les dates JJ/MM/AAAA, les URLs de webhook/NocoDB et les mots de passe contenant « / » ou « ' » sont stockés échappés. L'utilisateur voit alors « &#x27; » à l'écran. Les logs sont pollués de fausses alertes.
+- **Recommandation :** Retirer validator.escape de sanitizeString, sauf pour le champ password, ou prévoir une migration des mots de passe. Garder le filtrage des octets nuls et de __proto__/constructor. Réserver detectSqlInjection à un mode debug. Prévoir un script pour décoder les entités dans les données créées via index.ts si une base de dev ou de `npm start` doit être conservée. À coordonner avec INFRA-10 : si ce middleware est ajouté à la prod lors de l'unification, il faut d'abord retirer l'escape.
+
+### INFRA-12
+
+**Toutes les pages et recharts sont téléchargés dès l'écran de connexion (pas de code splitting)** — perf-bundle, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/RouterProduction.tsx:1`
+- **Constat :** RouterProduction.tsx : 40 imports statiques, dont 35 de pages, et 0 `lazy(`. Le build en témoigne : dist/public/index.html:14-19 `<script type="module" src="/assets/index-CCl1yENM.js">` (1 081 745 o) + `<link rel="modulepreload" href="/assets/vendor-charts-gtSIDI7m.js">` (410 243 o, recharts, utilisé par exemple dans pages/Analytics.tsx:14), vendor-react, vendor-query et vendor-icons.
+- **Impact :** L'écran de connexion télécharge et compile environ 1,8 Mo de JS/CSS (environ 450 Ko gzip). Le parse et la compilation prennent environ 300 à 800 ms sur PC de caisse ou mobile d'entrée de gamme. Gain estimé : -60 à -70 % de JS initial avec un découpage par route.
+- **Recommandation :** `const Deliveries = lazy(() => import('@/pages/Deliveries'))` pour chaque page, avec `<Suspense fallback={<Spinner/>}>` autour du Switch wouter. Retirer `vendor-charts` des manualChunks forcés (vite.config.ts:44) pour que recharts ne soit chargé que par les pages qui l'utilisent.
+
+### INFRA-13
+
+**stripSmtpPassword clone en profondeur chaque réponse JSON /api** — perf-api, sévérité basse, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:168`
+- **Constat :** routes.ts:165-171 `app.use('/api', (req, res, next) => { const originalJson = res.json.bind(res); res.json = (body: any) => originalJson(stripSmtpPassword(body)); ...`. sanitize.ts:25-42 reconstruit chaque tableau et chaque objet (`value.map(...)`, `for (const [key, entry] of Object.entries(value)) result[key] = stripSmtpPassword(...)`). Mesure Node sur 2000 livraisons avec supplier, group et order imbriqués (1,6 Mo) : 11,7 ms de clonage en plus des 18 ms de JSON.stringify. Sur 5000 éléments : 33,6 ms de clonage pour 47,5 ms de stringify.
+- **Impact :** Les grosses listes coûtent +40 à +65 % de CPU de sérialisation, le pic mémoire double, et l'event loop est bloquée d'autant pour les autres utilisateurs. Gain estimé : 5 à 30 ms par grosse liste.
+- **Recommandation :** Remplacer d'abord, dans toutes les jointures `group: groups` de storage.ts, la sélection complète par une liste explicite de colonnes sans smtpPassword. Ensuite seulement, restreindre stripSmtpPassword aux routes /api/groups* en y conservant le calcul de smtpPasswordSet. Alternative sans refonte : `app.set('json replacer', (k, v) => v && typeof v === 'object' && !Array.isArray(v) && 'smtpPassword' in v ? (({smtpPassword, ...r}) => ({...r, smtpPasswordSet: !!smtpPassword}))(v) : v)`. Il faudra alors mesurer le gain, car le replacer est appelé pour chaque propriété.
+
+### INFRA-14
+
+**Logs console verbeux et synchrones sur les chemins chauds, sans rotation** — perf-serveur, sévérité basse, effort M
+
+- **Fichier :** `server/routes.ts:1353`
+- **Constat :** routes.ts contient 266 console.log, par exemple l.1353 `console.log('Orders API called with:', {...})`, l.1762 `'Deliveries API called with:'`, l.1868 `'Deliveries returned:'`, l.3507, l.3782/3791/3874/3885 `JSON.stringify(req.body, null, 2)` (avoirs). storage.ts:935 `getDeliveries() récupéré ...` et l.2303 `getTasks - Raw results`. index.production.ts:30-39 journalise chaque requête /api et l.162 chaque navigation SPA. Sous Linux, stdout vers un pipe (cas de Docker) est synchrone dans Node. docker-compose.yml n'a aucune clé `logging:`.
+- **Impact :** Chaque requête écrit 3 à 6 lignes de façon bloquante (environ 0,1 à 0,5 ms par requête, davantage avec JSON.stringify indenté). Le fichier de log json-file du conteneur grossit sans limite et peut remplir le disque du serveur.
+- **Recommandation :** Se limiter à supprimer, ou passer derrière un `if (process.env.LOG_LEVEL === 'debug')`, les logs des handlers GET chauds et les JSON.stringify(req.body / validatedData / dataForDb) cités, ainsi que le log SPA de index.production.ts:162. Garder les console.error et console.warn. La rotation dans docker-compose.yml (`logging: { driver: json-file, options: { max-size: "10m", max-file: "3" } }`) est indépendante et sans risque.
+
+### INFRA-15
+
+**Le gestionnaire d'erreurs relance l'exception après avoir répondu (connexion coupée)** — bug, sévérité basse, effort S
+
+- **Fichier :** `server/index.production.ts:136`
+- **Constat :** index.production.ts:131-137 `app.use((err, _req, res, _next) => { ... res.status(status).json({ message }); throw err; });` (idem index.ts:66-71). Express transmet l'exception à finalhandler 1.3.1, qui voit headersSent et exécute `req.socket.destroy()` (node_modules/finalhandler/index.js:126-129).
+- **Impact :** Chaque erreur transmise via next(err) (JSON invalide, corps de plus de 10 Mo...) détruit la connexion keep-alive. La réponse d'erreur peut arriver tronquée, et le navigateur affiche une erreur réseau générique au lieu du message. Il doit aussi rouvrir une connexion TCP.
+- **Recommandation :** `if (res.headersSent) return _next(err); console.error(err); res.status(status).json({ message });`, sans `throw`.
+
+### INFRA-16
+
+**Aucun en-tête Cache-Control sur les réponses /api** — perf-api, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:165`
+- **Constat :** `grep -n "Cache-Control" server/*.ts` ne renvoie aucune occurrence. Les réponses /api reposent sur l'ETag faible par défaut d'Express (SHA1 du corps) sans directive de cache, et contiennent des données privées par magasin.
+- **Impact :** Le comportement de cache dépend des heuristiques du navigateur et d'un éventuel proxy (nginx externe non versionné). Rien n'empêche un cache partagé de stocker des données d'un magasin. Les référentiels quasi statiques (/api/suppliers, /api/groups) sont rechargés intégralement à chaque montage.
+- **Recommandation :** Ajouter seulement `res.set('Cache-Control', 'private, no-cache')` dans le middleware /api de routes.ts:165. Les 304 via ETag sont conservés. Ne pas mettre de max-age sur des endpoints invalidés par des mutations côté client.
+
+### INFRA-17
+
+**NODE_ENV forcé trop tard (imports ESM hissés) et absent du Dockerfile** — bug, sévérité basse, effort S
+
+- **Fichier :** `server/index.production.ts:18`
+- **Constat :** index.production.ts:7-9 `import { storage } from "./storage.js"; ...` : les modules importés (storage puis db) s'évaluent avant la ligne 18 `process.env.NODE_ENV = 'production';`. Or db.ts:4 `const isProduction = process.env.NODE_ENV === 'production';` est calculé à l'import. Le Dockerfile ne déclare que `ENV PORT=3000` (l.101). Seul docker-compose.yml (`NODE_ENV: production`) rend la configuration correcte.
+- **Impact :** Un `docker run` sans compose ou un orchestrateur qui oublie la variable bascule db.ts sur le driver Neon WebSocket (db.ts:44-56) face à un Postgres classique : échec de connexion ou latence. Le forçage à la ligne 18 donne une fausse impression de sécurité.
+- **Recommandation :** Ajouter `ENV NODE_ENV=production` dans le stage production du Dockerfile, par exemple à côté de `ENV PORT=3000`. On peut conserver la ligne 18, inoffensive, comme filet de sécurité, ou la supprimer : ce n'est pas nécessaire.
+
+### INFRA-18
+
+**Driver BD choisi par heuristique sur le nom d'hôte, pool sans statement_timeout** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/db.ts:17`
+- **Constat :** db.ts:17 `if (isProduction && dbUrl && (dbUrl.includes('logiflow-db') || dbUrl.includes('localhost') || dbUrl.includes('127.0.0.1')))` choisit pg. Tout autre hôte tombe sur `@neondatabase/serverless` (WebSocket, l.44-56). Le pool pg (l.23-29) a `max: 25, idleTimeoutMillis: 30000, connectionTimeoutMillis: 15000`, sans statement_timeout ni application_name.
+- **Impact :** Renommer le service Postgres ou passer par une IP change silencieusement de driver. Une requête lente (vérification de factures, export) peut monopoliser des connexions, et les autres requêtes attendent alors jusqu'à 15 s avant d'échouer.
+- **Recommandation :** Choisir Neon seulement si l'URL contient `neon.tech` (ou via une variable DB_DRIVER), et pg sinon. Ajouter au pool `statement_timeout: 30000` et `application_name: 'logiflow'`, en surchargeant le timeout pour les opérations longues connues.
+
+### INFRA-19
+
+**Code d'infrastructure mort ou trompeur (cache, compression, monitoring, auth/db « production »)** — dette-code, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/cache.ts:93`
+- **Constat :** server/cache.ts n'est jamais importé. Son setupCompression (l.93-100) pose `Content-Encoding: gzip` sans compresser, et cacheMiddleware (l.53) comme createOptimizedQuery sont inutilisés. server/monitoring.ts n'est jamais importé, et getStats (l.85) trie responseTime en place. server/db.production.ts n'est jamais importé. server/localAuth.production.ts est importé (index.production.ts:8) mais jamais appelé. server/migrations.ts runMigrations() n'est jamais appelé. /api/health est défini 3 fois (routes.ts:174, localAuth.ts:245, index.production.ts:66), et seul le premier répond.
+- **Impact :** Les mainteneurs croient à tort que la compression, le cache API, le monitoring et les sessions PG sont actifs. Brancher setupCompression casserait toutes les réponses (ERR_CONTENT_DECODING_FAILED), et le temps de diagnostic des lenteurs s'allonge.
+- **Recommandation :** Corrections sans risque : supprimer server/cache.ts et server/db.production.ts, ainsi que les /api/health en double de localAuth.ts:244-247 et index.production.ts:65-75 (le HEALTHCHECK Docker reste servi par routes.ts:174). Conserver server/migrations.ts, utilisé par scripts/create-migration.js, ou au moins sa fonction createMigration. Traiter la suppression de localAuth.production.ts avec INFRA-08, qui pourrait réutiliser son store pg. Le branchement de monitoring.ts (avec tri sur une copie et /api/metrics derrière requireAdmin) est un chantier à part, à ne pas automatiser.

docs/audit-webui/15-database.md

@@ -0,0 +1,655 @@
+# Base de données
+
+_36 constats vérifiés — 8 haute, 13 moyenne, 15 basse._
+
+## Pages analysées
+
+### `transverse : authentification (chaque appel /api/*)`
+
+**Rôle :** Identifier l'utilisateur et ses magasins avant de servir n'importe quelle donnée.
+
+**Tâches principales de l'utilisateur :**
+- Se connecter
+- Naviguer entre les pages (chaque page déclenche 3 à 10 appels API)
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| (middleware) session + deserializeUser | chaque requête API | server/localAuth.production.ts:193 passport.deserializeUser -> storage.getUserWithGroups (server/storage.ts:371) | SELECT session + UPDATE session (touch) + getUser + jointure user_groups/groups = 4 allers-retours avant la route. |
+| (dans 91 routes) storage.getUserWithGroups(req.user.id) | chaque requête API | server/routes.ts (106 appels, ex. 1345, 1754, 2799, 3195) | Recharge exactement ce que deserializeUser vient de charger : +2 requêtes séquentielles par appel. |
+
+**Lisibilité / simplicité :** Invisible pour l'utilisateur mais coûte ~6 requêtes BD par appel API avant toute donnée métier ; le tableau de bord (~10 appels) génère ~60 requêtes d'authentification. C'est une latence fixe ajoutée à chaque écran.
+
+### `/ et /dashboard (desktop)`
+
+**Rôle :** Vue d'ensemble du magasin : commandes, livraisons, commandes clients, stats du mois/de l'année, DLC, tâches, annonce récente, publicités à venir.
+
+**Tâches principales de l'utilisateur :**
+- Voir les compteurs du jour/mois
+- Voir les commandes récentes et livraisons à venir
+- Lire l'annonce récente
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/orders[?storeId] | au montage | server/routes.ts:1343 -> storage.getOrders (server/storage.ts:678) | Aucune borne de date (commentaire Dashboard.tsx:78) : tout l'historique + livraisons imbriquées + groupe complet (logo) par ligne, juste pour compter par statut. |
+| /api/deliveries[?storeId] | au montage | server/routes.ts:1752 -> storage.getDeliveries (server/storage.ts:885) | Tout l'historique pour calculer 'livrées ce mois' et palettes côté client. |
+| /api/customer-orders[?storeId] | au montage | server/routes.ts:3486 -> storage.getCustomerOrders (server/storage.ts:1868) | Tout l'historique pour 6 compteurs par statut. |
+| /api/stats/monthly et /api/stats/yearly | au montage | server/routes.ts:4155/4192 -> getMonthlyStats (storage.ts:1222) / getYearlyStats (storage.ts:1364) | 4 requêtes séquentielles chacune ; filtre delivered_date non indexé. |
+| /api/announcements?recent=true | au montage | server/routes.ts:5770 (requête inline + N+1) | Paramètre recent ignoré côté serveur, filtre 2 jours fait côté client ; 1 + 2×5 requêtes. |
+| /api/ad-campaigns?year=N (×3) | au montage, 3 appels séquentiels (Dashboard.tsx:205) | server/routes.ts:4595 -> storage.getPublicities (server/storage.ts:1502) | Participations avec groupe complet (logo) ; groupIds ignoré. |
+| /api/dlc-products/stats | au montage | server/routes.ts:2831 -> getDlcStats (storage.ts:2224) | Agrégat en base : correct. |
+| /api/tasks | au montage | server/routes.ts:3193 -> getTasks (storage.ts:2267) | Liste non bornée. |
+
+**Lisibilité / simplicité :** Page d'accueil la plus lente : elle télécharge l'historique complet de 3 tables (avec relations et logos magasin répétés) pour n'afficher que des compteurs et 5 lignes récentes. Le temps d'affichage croît avec l'ancienneté du magasin.
+
+### `/ et /dashboard (mobile)`
+
+**Rôle :** Résumé du jour sur téléphone : commandes, livraisons et tâches du jour.
+
+**Tâches principales de l'utilisateur :**
+- Voir combien de commandes/livraisons sont prévues aujourd'hui
+- Voir les tâches en cours
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/stats/dashboard | au montage | aucune route serveur (grep négatif dans server/routes.ts) | Appel vers un endpoint inexistant. |
+| /api/orders?storeId&date=AAAA-MM-JJ | au montage | server/routes.ts:1343 (lit seulement startDate/endDate/storeId, l.1350) -> storage.getOrders | date ignoré : historique complet chargé, compteur 'Commandes' = total historique. |
+| /api/deliveries?storeId&date=AAAA-MM-JJ | au montage | server/routes.ts:1752 -> storage.getDeliveries | Même problème. |
+| /api/tasks | au montage | server/routes.ts:3193 -> getTasks | Liste non bornée. |
+
+**Lisibilité / simplicité :** Sur réseau mobile, l'écran d'accueil télécharge tout l'historique pour afficher deux nombres, et ces nombres sont faux (total historique au lieu du jour).
+
+### `/orders`
+
+**Rôle :** Lister et gérer les commandes fournisseurs du magasin.
+
+**Tâches principales de l'utilisateur :**
+- Rechercher une commande
+- Créer/modifier/supprimer une commande
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/orders?storeId | au montage | server/routes.ts:1343 -> storage.getOrders (storage.ts:678, loadDeliveriesByOrderIds storage.ts:522) | 3 requêtes (N+1 déjà corrigé) mais sans LIMIT ; inArray de tous les ids de commandes ; groupe complet ×2 par commande. |
+| /api/groups | au montage | server/routes.ts:970 -> storage.getGroups (storage.ts:432) pour admin | Admin : lignes complètes avec logo et config SMTP/NocoDB. |
+
+**Lisibilité / simplicité :** Liste sans pagination : chargement de plus en plus long au fil des mois, poids JSON gonflé par le logo du magasin répété dans chaque commande et chaque livraison imbriquée.
+
+### `/deliveries (+ modales Créer/Modifier livraison)`
+
+**Rôle :** Lister les livraisons, les valider, les lier à une commande.
+
+**Tâches principales de l'utilisateur :**
+- Valider une livraison avec son BL
+- Créer une livraison liée à une commande
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/deliveries?storeId | au montage | server/routes.ts:1752 -> storage.getDeliveries (storage.ts:885) + attachOrdersAndCommentCounts (storage.ts:643) | Historique complet, sans LIMIT. |
+| /api/orders (sans paramètre) | à l'ouverture des modales | server/routes.ts:1343 -> storage.getOrders() tous magasins (admin) / [] (employé, l.1442) | Toutes les commandes de tous les magasins pour filtrer côté client fournisseur+magasin+non livrée ; employé : liste vide. |
+| /api/deliveries/:id | au clic | server/routes.ts:1877 -> storage.getDelivery (storage.ts:1004) | 5 requêtes séquentielles. |
+
+**Lisibilité / simplicité :** Ouvrir la modale de création de livraison télécharge tout l'historique des commandes (admin) ou rien du tout (employé : impossible de lier une commande).
+
+### `/calendar`
+
+**Rôle :** Calendrier mensuel des commandes et livraisons.
+
+**Tâches principales de l'utilisateur :**
+- Voir les livraisons du mois
+- Naviguer de mois en mois
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/orders?startDate&endDate&storeId | au montage / changement de mois | server/routes.ts:1343 -> storage.getOrdersByDateRange (storage.ts:725) | Bonne borne de date ; s'appuie sur idx_orders_group_planned_date (si appliqué). |
+| /api/deliveries?startDate&endDate&storeId | au montage / changement de mois | server/routes.ts:1752 -> storage.getDeliveriesByDateRange (storage.ts:939) | Idem, idx_deliveries_group_scheduled_date ; groupe complet (logo) par ligne. |
+
+**Lisibilité / simplicité :** Seule vue correctement bornée par date ; reste alourdie par les objets magasin complets et par l'absence probable des index en production.
+
+### `/bl-reconciliation`
+
+**Rôle :** Rapprocher BL et factures fournisseurs, commenter, relancer les fournisseurs.
+
+**Tâches principales de l'utilisateur :**
+- Voir les livraisons livrées à rapprocher
+- Vérifier une facture dans NocoDB
+- Commenter / envoyer un mail fournisseur
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/deliveries?storeId | au montage, staleTime 0 | server/routes.ts:1752 -> storage.getDeliveries | Tous statuts, tout l'historique ; filtre status==='delivered' côté client (BLReconciliation.tsx:371). |
+| /api/deliveries/:id/verify-invoice | automatique, file de 3 en parallèle | server/routes.ts (~2470) -> storage.getDelivery + invoiceVerificationService.verifyInvoice (getGroup complet à chaque appel) | getDelivery 5 requêtes + relecture du groupe (logo) par vérification. |
+| /api/deliveries/:id/reconciliation-comments | à l'ouverture des commentaires | server/routes.ts:2175 -> getDelivery + getReconciliationComments (storage.ts:3035) | author: users complet (hash du mot de passe). |
+| /api/supplier-mail-logs | au montage | server/routes.ts:2439 -> getSupplierMailLogs (storage.ts:2974) | LIMIT 500, OK ; index composite manquant pour le tri. |
+
+**Lisibilité / simplicité :** La page charge tout l'historique des livraisons, puis déclenche des vérifications en rafale qui relisent chacune la fiche magasin complète : temps de chargement long et sensation de page qui 'mouline'.
+
+### `/payment-schedule`
+
+**Rôle :** Échéancier des paiements fournisseurs d'un magasin (admin/directeur) et export Excel.
+
+**Tâches principales de l'utilisateur :**
+- Voir les échéances du mois
+- Exporter l'échéancier
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/payment-schedule?groupId | au montage / changement de magasin | server/routes.ts:390 -> storage.getDeliveries() SANS filtre (l.430) puis boucles verifyInvoice/updateDelivery séquentielles (l.444, 491) | Toutes les livraisons de tous les magasins chargées puis filtrées en JS. |
+| POST /api/payment-schedule/export | au clic Exporter | server/routes.ts:548 -> storage.getDeliveries() sans filtre (l.596) | Même chargement complet. |
+
+**Lisibilité / simplicité :** Page potentiellement la plus lente de l'application : temps proportionnel à la taille de toute la base (tous magasins) plus un appel NocoDB séquentiel par facture sans échéance.
+
+### `/users`
+
+**Rôle :** Gérer les utilisateurs, leurs rôles et leurs magasins.
+
+**Tâches principales de l'utilisateur :**
+- Créer/modifier un utilisateur
+- Affecter un utilisateur à un magasin
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/users | au montage (aussi utilisé par la page Tâches) | server/routes.ts:4268 -> storage.getUsers + Promise.all(getUserWithGroups) (l.4279-4282) | 2N+1 requêtes ; renvoie le champ password (hash) de chaque utilisateur. |
+| /api/groups | au montage | server/routes.ts:970 -> getGroups | Lignes complètes avec logo. |
+
+**Lisibilité / simplicité :** Chargement qui croît avec le nombre d'utilisateurs ; données sensibles inutiles dans la réponse.
+
+### `/sav`
+
+**Rôle :** Suivi des tickets SAV.
+
+**Tâches principales de l'utilisateur :**
+- Créer un ticket
+- Suivre le statut des tickets
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/sav/tickets | au montage / filtre | server/routes.ts:5242 -> storage.getSavTickets (storage.ts:2656) | creator: users complet (hash), group complet (logo), Promise.all d'historique vide, sans LIMIT. |
+| /api/sav/stats | au montage | server/routes.ts:5524 -> getSavTicketStats (storage.ts:2818) | 3 requêtes séquentielles remplaçables par une seule. |
+
+**Lisibilité / simplicité :** Liste lourde (objets utilisateur et magasin complets par ticket), compteurs en 3 allers-retours.
+
+### `/publicities`
+
+**Rôle :** Planning des publicités et participation des magasins.
+
+**Tâches principales de l'utilisateur :**
+- Voir les publicités de l'année
+- Cocher la participation d'un magasin
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/ad-campaigns?year&storeId | au montage / changement d'année | server/routes.ts:4595 -> storage.getPublicities (storage.ts:1502) | groupIds ignoré ; chaque participation embarque la ligne groups complète (logo) alors que seul group.name est lu. |
+
+**Lisibilité / simplicité :** Le poids de la réponse explose dès que les magasins ont un logo (publicités × magasins participants × logo).
+
+### `/tasks`
+
+**Rôle :** Tâches du magasin.
+
+**Tâches principales de l'utilisateur :**
+- Voir les tâches à faire
+- Marquer une tâche terminée
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/tasks?storeId | au montage | server/routes.ts:3193 -> getTasks (storage.ts:2267) | Toutes les tâches y compris terminées depuis toujours, group complet. |
+| /api/users | au montage | server/routes.ts:4268 | N+1 et hash de mot de passe. |
+
+**Lisibilité / simplicité :** Liste qui grossit indéfiniment avec les tâches terminées.
+
+### `/dlc`
+
+**Rôle :** Suivi des dates limites de consommation.
+
+**Tâches principales de l'utilisateur :**
+- Voir les produits qui expirent bientôt
+- Rechercher un produit
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/dlc-products?storeId&status&supplierId&search | au montage / filtre / recherche (debounce) | server/routes.ts:2797 -> getDlcProducts (storage.ts:1976) | Filtres poussés en SQL (bien) ; LIKE '%..%' non indexable ; pas de LIMIT ; group complet. |
+| /api/dlc-products/stats | au montage | server/routes.ts:2831 -> getDlcStats (storage.ts:2224) | Une requête agrégée : bon modèle. |
+
+**Lisibilité / simplicité :** Page plutôt bien conçue côté requêtes ; la recherche texte et l'absence d'index composite (group_id, expiry_date) la ralentiront avec le volume.
+
+### `/customer-orders`
+
+**Rôle :** Commandes clients et appels à passer.
+
+**Tâches principales de l'utilisateur :**
+- Saisir une commande client
+- Voir les clients à appeler
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/customer-orders[?storeId] | au montage | server/routes.ts:3486 -> getCustomerOrders (storage.ts:1868) | Historique complet, group complet. |
+| /api/customer-orders/pending-calls | au montage | server/routes.ts:3638 -> getPendingClientCalls (storage.ts:1931) | Filtre customer_notified=false non indexé. |
+
+**Lisibilité / simplicité :** Liste non paginée ; reste acceptable tant que le volume est faible.
+
+### `/avoirs`
+
+**Rôle :** Suivi des avoirs fournisseurs.
+
+**Tâches principales de l'utilisateur :**
+- Créer un avoir
+- Suivre son statut
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/avoirs[?storeId] | au montage | server/routes.ts:3711 -> getAvoirs (storage.ts:2528) | Une requête avec JOIN (bien) ; group complet (logo) ; sans LIMIT. |
+
+**Lisibilité / simplicité :** Requête correcte, poids gonflé par l'objet magasin complet.
+
+### `/analytics`
+
+**Rôle :** Statistiques commandes/livraisons par période, fournisseur et magasin.
+
+**Tâches principales de l'utilisateur :**
+- Choisir une période
+- Comparer fournisseurs et magasins
+
+**Appels API :**
+
+| Endpoint | Déclencheur | Handler serveur | Notes |
+|---|---|---|---|
+| /api/analytics/summary | au montage / changement de filtres | server/routes.ts:6218 -> getAnalyticsSummary (storage.ts:3166) | 4 requêtes séquentielles ; top magasins = produit cartésien orders×deliveries. |
+| /api/analytics/timeseries | idem | server/routes.ts:6250 -> getAnalyticsTimeseries (storage.ts:3285) | 2 requêtes séquentielles. |
+| /api/analytics/by-supplier | idem | server/routes.ts:6281 -> getAnalyticsBySupplier (storage.ts:3361) | Une requête agrégée. |
+| /api/analytics/by-store | idem | server/routes.ts:6310 -> getAnalyticsByStore (storage.ts:3400) | Sous-requêtes agrégées : bon modèle à réutiliser. |
+
+**Lisibilité / simplicité :** Le bloc 'top magasins' devient très lent avec le volume (jointure multiplicative) et ne respecte pas la période choisie.
+
+## Constats
+
+| ID | Sév. | Catégorie | Effort | Titre | Fichier |
+|---|---|---|---|---|---|
+| [DB-01](#db-01) | haute | perf-serveur | S | Les index de performance ne sont jamais créés automatiquement en production | `Dockerfile:119` |
+| [DB-03](#db-03) | haute | perf-api | S | Le logo base64 du magasin et sa config SMTP/NocoDB sont recopiés dans chaque ligne de chaque liste | `server/storage.ts:553` |
+| [DB-04](#db-04) | haute | bug | S | La ligne users complète, hash du mot de passe compris, est renvoyée au navigateur | `server/storage.ts:2669` |
+| [DB-06](#db-06) | haute | perf-serveur | M | L'utilisateur et ses magasins sont rechargés deux fois à chaque appel API (6 allers-retours BD avant les données) | `server/routes.ts:1345` |
+| [DB-07](#db-07) | haute | perf-serveur | M | L'échéancier charge toutes les livraisons de tous les magasins puis filtre en JavaScript | `server/routes.ts:430` |
+| [DB-08](#db-08) | haute | perf-api | M | Le tableau de bord télécharge l'historique complet de 3 tables pour afficher des compteurs | `client/src/pages/Dashboard.tsx:78` |
+| [DB-09](#db-09) | haute | bug | S | Le paramètre `date=` du tableau de bord mobile est ignoré : tout l'historique est chargé et les compteurs sont faux | `client/src/pages/mobile/DashboardPage.tsx:101` |
+| [DB-16](#db-16) | haute | perf-serveur | S | Top magasins d'Analytics : jointure multiplicative orders × deliveries par magasin | `server/storage.ts:3242` |
+| [DB-02](#db-02) | moyenne | dette-code | M | Index absents du schéma Drizzle : `npm run db:push` les supprimerait, et l'auto-migration ne crée jamais un nouvel index | `shared/schema.ts:28` |
+| [DB-05](#db-05) | moyenne | perf-serveur | S | N+1 sur /api/users : 2 requêtes par utilisateur lancées toutes en même temps | `server/routes.ts:4279` |
+| [DB-10](#db-10) | moyenne | perf-api | M | Le rapprochement charge toutes les livraisons (tous statuts, tout l'historique) puis filtre côté client | `client/src/pages/BLReconciliation.tsx:357` |
+| [DB-11](#db-11) | moyenne | perf-api | M | Les modales de livraison téléchargent toutes les commandes pour en garder quelques-unes (et rien pour un employé) | `client/src/components/modals/CreateDeliveryModal.tsx:61` |
+| [DB-12](#db-12) | moyenne | perf-serveur | S | getDelivery enchaîne 5 requêtes séquentielles et sert surtout à des contrôles d'accès | `server/storage.ts:1041` |
+| [DB-13](#db-13) | moyenne | perf-serveur | S | Statistiques mensuelles et annuelles : 4 requêtes indépendantes exécutées l'une après l'autre | `server/storage.ts:1270` |
+| [DB-14](#db-14) | moyenne | perf-serveur | S | Aucun index sur deliveries.delivered_date alors que les stats filtrent dessus | `server/storage.ts:1295` |
+| [DB-18](#db-18) | moyenne | perf-serveur | S | Annonces : N+1 (auteur + magasin par message) alors qu'une version avec JOIN existe déjà | `server/routes.ts:5815` |
+| [DB-19](#db-19) | moyenne | perf-serveur | S | updateExistingReconciledCaches : chargement de toutes les livraisons puis 2 à 4 requêtes par livraison | `server/invoiceVerification.ts:216` |
+| [DB-21](#db-21) | moyenne | perf-serveur | S | La purge périodique du cache de vérification des factures ne tourne pas en production | `server/index.production.ts:62` |
+| [DB-24](#db-24) | moyenne | perf-api | L | Aucune liste n'est paginée ; les relations sont ensuite chargées via des IN de milliers d'identifiants | `server/storage.ts:711` |
+| [DB-36](#db-36) | moyenne | perf-api | M | /api/groups renvoie à l'admin la ligne magasin complète (logo, SMTP, NocoDB) à 24 composants | `server/routes.ts:979` |
+| [DB-37](#db-37) | moyenne | perf-serveur | S | Synthèse de la couverture d'index par table (colonnes lues dans storage.ts) | `migrations/20260814_add_performance_indexes.sql:15` |
+| [DB-15](#db-15) | basse | perf-serveur | S | Index (group_id, status) absent sur orders et deliveries, alors qu'il existe pour les autres tables | `server/storage.ts:1282` |
+| [DB-17](#db-17) | basse | perf-serveur | S | Série temporelle Analytics : 2 requêtes indépendantes séquentielles | `server/storage.ts:3333` |
+| [DB-20](#db-20) | basse | bug | S | Diagnostic du cache : toutes les livraisons chargées pour compter, et clé de cache erronée | `server/routes.ts:2735` |
+| [DB-23](#db-23) | basse | dette-code | S | user_groups n'a ni clé primaire ni contrainte d'unicité (user_id, group_id) | `shared/schema.ts:82` |
+| [DB-25](#db-25) | basse | perf-serveur | S | Statistiques SAV : 3 requêtes séquentielles, plus une requête morte | `server/storage.ts:2832` |
+| [DB-26](#db-26) | basse | dette-code | S | getSavTickets attend un historique par ticket qui renvoie toujours un tableau vide | `server/storage.ts:2704` |
+| [DB-27](#db-27) | basse | perf-serveur | S | Numérotation des tickets SAV : filtre non indexable et risque de doublon | `server/storage.ts:2753` |
+| [DB-28](#db-28) | basse | perf-serveur | S | La synchronisation des statuts charge toutes les commandes et livraisons, puis met à jour une par une | `server/routes.ts:1700` |
+| [DB-29](#db-29) | basse | perf-api | S | getPublicities ignore groupIds, groupe les participations en O(P×N) et trie deux fois ; le tableau de bord l'appelle 3 fois de suite | `server/storage.ts:1502` |
+| [DB-30](#db-30) | basse | perf-serveur | S | Météo : deux lectures indépendantes séquentielles et recherche « date la plus proche » non indexable | `server/routes.ts:5683` |
+| [DB-31](#db-31) | basse | perf-serveur | S | Chaque vérification de facture relit la fiche magasin complète (logo) et la configuration NocoDB | `server/invoiceVerification.ts:285` |
+| [DB-32](#db-32) | basse | dette-code | S | server/cache.ts n'est importé nulle part et son middleware de compression est piégeux | `server/cache.ts:96` |
+| [DB-33](#db-33) | basse | perf-serveur | S | Suppression d'utilisateur : un DELETE par magasin dans une boucle | `server/routes.ts:4514` |
+| [DB-34](#db-34) | basse | perf-serveur | S | DLC : pas d'index composite magasin+date, recherche texte non indexable | `server/storage.ts:2052` |
+| [DB-35](#db-35) | basse | perf-serveur | S | Index complémentaires : appels clients en attente et historique des mails fournisseurs | `server/storage.ts:1933` |
+
+### DB-01
+
+**Les index de performance ne sont jamais créés automatiquement en production** — perf-serveur, sévérité haute, effort S
+
+- **Fichier :** `Dockerfile:119`
+- **Constat :** Dockerfile:119 `CMD ["sh", "-c", "... CREATE INDEX IF NOT EXISTS idx_dlc_products_stock_epuise ...; node dist/index.js"]` et aucun ENTRYPOINT : scripts/docker-entrypoint.sh:53-60 (seul appelant de scripts/auto-migrate-production.sh, où sont les CREATE INDEX CONCURRENTLY) n'est jamais exécuté. server/migrations.ts:112-114 `// Ignorer les fichiers de migrations ... const allMigrations = hardcodedMigrations;` ignore migrations/20260814_add_performance_indexes.sql. server/migrations.production.ts (seul code lancé au démarrage, index.production.ts:53) ne crée aucun de ces index. init.sql (index group_id partiels, l.511-546) n'est joué par l'image postgres que si le volume postgres_data est vide (docker-compose.yml:50). docker-compose.override.yml cible un service `app` qui n'existe pas (le service s'appelle `logiflow`).
+- **Impact :** Sauf application manuelle, orders/deliveries/user_groups/tasks/... n'ont que leurs clés primaires : chaque liste filtrée par magasin, chaque jointure deliveries.order_id et le chargement de l'utilisateur à chaque requête font un parcours séquentiel complet. C'est la dégradation progressive décrite dans le commit 753b301, toujours active.
+- **Recommandation :** Dans server/migrations.production.ts, ajouter une fonction ensurePerformanceIndexes(client). 1) Purger les index invalides, comme le DO $$ de auto-migrate-production.sh:129-145 (`DROP INDEX IF EXISTS` sur les `idx_%` avec `NOT indisvalid`). 2) Exécuter un `await client.query('CREATE INDEX CONCURRENTLY IF NOT EXISTS ...')` par index, chacun dans son propre try/catch pour qu'un échec (table absente, etc.) n'interrompe ni les suivants ni le chiffrement des secrets. Liste : celle de migrations/20260814_add_performance_indexes.sql, plus idx_deliveries_group_delivered_date, idx_orders_group_status, idx_deliveries_group_status, idx_dlc_products_group_expiry, idx_customer_orders_pending_calls, idx_supplier_mail_logs_group_created. Exclure idx_session_expire, pg_trgm et l'index unique user_groups. 3) Faire ANALYZE des tables concernées. Lancer ensureIndexes sans bloquer le démarrage, par exemple après listen ou sans await, avec un .catch qui journalise.
+
+### DB-03
+
+**Le logo base64 du magasin et sa config SMTP/NocoDB sont recopiés dans chaque ligne de chaque liste** — perf-api, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:553`
+- **Constat :** shared/schema.ts:66 `logo: text("logo"), // Logo en data URI (data:image/png;base64,...)` (jusqu'à 200 Ko, Groups.tsx:39 `MAX_LOGO_KB = 200`, soit ~270 Ko en base64). Les listes sélectionnent la ligne groups entière : storage.ts:553 et 599 (`group: groups` dans loadDeliveriesByOrderIds/loadOrdersByIds), 693 (getOrders), 740, 913 (getDeliveries), 967, 1536 (participations publicités), 1873 (getCustomerOrders), 1945, 1981 (getDlcProducts), 2274 (getTasks), 2547 (getAvoirs), 2668 (getSavTickets), 3047 (getReconciliationComments). getOrders imbrique deliveries[] qui ont chacune leur propre `group` : 2 copies par livraison. Le client ne lit que group.name (22×), color (7×), webhookUrl, nocodbTableName, nocodbConfigId (5× chacun). Toute la réponse est ensuite recopiée récursivement par stripSmtpPassword (routes.ts:168).
+- **Impact :** Avec un logo de 150 Ko, 500 commandes ayant chacune une livraison font ~150 Mo de JSON ; même sans logo, ~25 colonnes inutiles par ligne (smtp_host, smtp_user, colonnes NocoDB...). Pages Commandes, Livraisons, Rapprochement, Publicités, Tableau de bord directement ralenties.
+- **Recommandation :** Comme proposé : `const groupSummary = { id: groups.id, name: groups.name, color: groups.color, nocodbConfigId: groups.nocodbConfigId, nocodbTableName: groups.nocodbTableName, webhookUrl: groups.webhookUrl }` à la place de `group: groups` dans les select listés, sans toucher getGroup ni getGroups. Ajuster les types (Pick<Group, ...>) pour que tsc reste propre.
+
+### DB-04
+
+**La ligne users complète, hash du mot de passe compris, est renvoyée au navigateur** — bug, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:2669`
+- **Constat :** storage.ts:2669 `creator: users,` (getSavTickets) et 2726 (getSavTicket) ; storage.ts:3046 `author: users,` (getReconciliationComments) et 3099 ; routes.ts:4276-4285 `const baseUsers = await storage.getUsers(); ... return { ...baseUser, userGroups: ...` avec getUsers = `db.select().from(users)` (storage.ts:410). sanitize.ts:36 ne retire que `smtpPassword`.
+- **Impact :** Tout employé qui ouvre la page SAV ou les commentaires de rapprochement reçoit le hash scrypt des créateurs/auteurs ; la page Utilisateurs (et Tâches qui l'appelle) reçoit le hash de tous les comptes. Octets inutiles en plus du risque de sécurité.
+- **Recommandation :** Remplacer `creator: users` et `author: users` par `{ id: users.id, firstName: users.firstName, lastName: users.lastName, username: users.username, email: users.email }` aux lignes 2669, 2726, 3046 et 3099. Dans GET /api/users, retirer le hash dans le map : `const { password, ...safeUser } = baseUser;` (ou via la méthode de DB-05).
+
+### DB-06
+
+**L'utilisateur et ses magasins sont rechargés deux fois à chaque appel API (6 allers-retours BD avant les données)** — perf-serveur, sévérité haute, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:1345`
+- **Constat :** localAuth.production.ts:193-196 `passport.deserializeUser(async (id) => { const user = await storage.getUserWithGroups(id);` : req.user est déjà un UserWithGroups. Puis 91 routes refont `const user = await storage.getUserWithGroups(req.user.claims ? req.user.claims.sub : req.user.id);` (ex. routes.ts:1345, 1754, 2799, 3195 ; 106 appels au total, plus 24 `await storage.getUser(`). getUserWithGroups enchaîne 2 requêtes séquentielles (storage.ts:372 puis 376). connect-pg-simple ajoute un SELECT de session et un `UPDATE ... SET expire` (node_modules/connect-pg-simple/index.js:435) à chaque requête.
+- **Impact :** Latence fixe sur chaque appel ; le tableau de bord desktop (~10 appels) consomme ~60 requêtes rien que pour l'authentification.
+- **Recommandation :** 1) Ajouter `const getCurrentUser = (req: any) => req.user as UserWithGroups;` et ne remplacer que les appels dont l'argument est exactement l'identifiant de l'utilisateur courant (`storage.getUserWithGroups(req.user.claims ? req.user.claims.sub : req.user.id)`, ou une variable userId tirée de req.user), en gardant le `if (!user)` existant. Ne pas toucher aux appels portant sur un autre utilisateur (ex. routes.ts:4511 userToDelete). 2) Réécrire getUserWithGroups en une seule requête avec le query builder drizzle (`db.select({ user: users, group: { id: groups.id, name: groups.name, color: groups.color, createdAt: groups.createdAt, updatedAt: groups.updatedAt } }).from(users).leftJoin(userGroups, ...).leftJoin(groups, ...).where(eq(users.id, id))`), en filtrant les group null et en gardant le format userGroups actuel. Abandonner le point 3 (pas de PostgresSessionStore en production).
+
+### DB-07
+
+**L'échéancier charge toutes les livraisons de tous les magasins puis filtre en JavaScript** — perf-serveur, sévérité haute, effort M
+
+- **Fichier :** `server/routes.ts:430`
+- **Constat :** routes.ts:430-431 `const allDeliveries = await storage.getDeliveries(); const groupDeliveries = allDeliveries.filter((d: any) => d.groupId === groupId && d.invoiceReference);` ; même chose dans l'export routes.ts:596-600. Puis boucles séquentielles routes.ts:444 `for (const delivery of deliveriesWithoutDueDate) { const result = await verificationService.verifyInvoice(...)` + `await storage.updateDelivery(...)`, et 491 pour le TTC ; routes.ts:519 relit encore tous les fournisseurs.
+- **Impact :** Temps de réponse proportionnel à toute la base (tous magasins, relations, logos) + un appel NocoDB et une écriture BD l'un après l'autre par facture.
+- **Recommandation :** Auto-implémentable : remplacer `storage.getDeliveries()` par `storage.getDeliveries([groupId])` à la l.430 et `storage.getDeliveries([validatedGroupId])` à la l.596, en gardant les filtres JS existants. La requête dédiée et la file NocoDB à concurrence limitée relèvent d'un chantier séparé.
+
+### DB-08
+
+**Le tableau de bord télécharge l'historique complet de 3 tables pour afficher des compteurs** — perf-api, sévérité haute, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `client/src/pages/Dashboard.tsx:78`
+- **Constat :** Dashboard.tsx:78 `// Construire les URLs pour récupérer toutes les données (pas de filtrage par date)`, 79-81 `/api/orders`, `/api/deliveries`, `/api/customer-orders` sans borne ; puis 316 `allOrders.filter((order: any) => order.status === 'pending').length`, 373-376 comptages par statut, 381-386 comptages commandes clients, 318-328 livrées ce mois / palettes. Côté serveur getOrders (storage.ts:711) et getDeliveries (931) n'ont ni LIMIT ni filtre.
+- **Impact :** Page d'accueil de tous les utilisateurs : plusieurs Mo à plusieurs dizaines de Mo selon l'ancienneté du magasin, juste pour une dizaine de nombres et 5 lignes récentes.
+- **Recommandation :** Créer GET /api/stats/dashboard en respectant le filtrage par magasin et par rôle de /api/orders. Requêtes : `SELECT status, count(*) FROM orders WHERE group_id = ANY($1) GROUP BY status` ; idem customer_orders ; et pour deliveries : `SELECT count(*) AS total, count(*) FILTER (WHERE status='delivered' AND coalesce(delivered_date, created_at) >= date_trunc('month', now()) AND coalesce(delivered_date, created_at) < date_trunc('month', now()) + interval '1 month') AS delivered_this_month, coalesce(sum(quantity) FILTER (WHERE status='delivered' AND unit='palettes' AND coalesce(delivered_date, created_at) >= date_trunc('month', now()) AND coalesce(delivered_date, created_at) < date_trunc('month', now()) + interval '1 month'),0) AS palettes FROM deliveries WHERE group_id = ANY($1)`. Ajouter les listes `orders WHERE status='pending' ORDER BY created_at DESC` (limite à décider : la page affiche tout aujourd'hui) et `deliveries WHERE status='planned' ORDER BY scheduled_date LIMIT 4`. Les éventuelles limites sont une décision produit.
+
+### DB-09
+
+**Le paramètre `date=` du tableau de bord mobile est ignoré : tout l'historique est chargé et les compteurs sont faux** — bug, sévérité haute, effort S
+
+- **Fichier :** `client/src/pages/mobile/DashboardPage.tsx:101`
+- **Constat :** DashboardPage.tsx:101 `params.append('date', format(new Date(), 'yyyy-MM-dd'));` (idem l.119 pour les livraisons) ; le serveur ne lit que `const { startDate, endDate, storeId } = req.query;` (routes.ts:1350 et 1759) et retombe sur getOrders/getDeliveries complets. L'écran affiche `value={orders.length}` (l.152) et `value={deliveries.length}` (l.158) sous le libellé « Commandes »/« Livraisons » du jour.
+- **Impact :** Sur téléphone (réseau mobile), téléchargement de tout l'historique à chaque ouverture, et nombres affichés = total historique au lieu du jour.
+- **Recommandation :** Envoyer `startDate` et `endDate` égaux à la date du jour (routes existantes getOrdersByDateRange/getDeliveriesByDateRange, servies par idx_orders_group_planned_date et idx_deliveries_group_scheduled_date), ou utiliser le futur /api/stats/dashboard (DB-08).
+
+### DB-16
+
+**Top magasins d'Analytics : jointure multiplicative orders × deliveries par magasin** — perf-serveur, sévérité haute, effort S
+
+- **Fichier :** `server/storage.ts:3242`
+- **Constat :** storage.ts:3242-3258 `.from(groups).leftJoin(orders, eq(groups.id, orders.groupId)).leftJoin(deliveries, eq(groups.id, deliveries.groupId))` avec `COUNT(DISTINCT ${orders.id})` / `COUNT(DISTINCT ${deliveries.id})` : pour un magasin à 3 000 commandes et 3 000 livraisons, 9 millions de lignes intermédiaires. Seul groupIds est appliqué (3252-3254), pas les dates/fournisseurs. Les 4 requêtes du résumé (3213, 3223, 3236, 3255) sont séquentielles.
+- **Impact :** La page Analytics devient très lente puis tombe en timeout quand l'historique grossit ; le « top magasins » ignore la période choisie.
+- **Recommandation :** Comme proposé. Garder les clés de sortie id, name, orders et deliveries (alias explicites `g.id AS id, g.name AS name`), passer groupIds en paramètre lié (pas de sql.raw), et regrouper les 4 requêtes dans un Promise.all.
+
+### DB-02
+
+**Index absents du schéma Drizzle : `npm run db:push` les supprimerait, et l'auto-migration ne crée jamais un nouvel index** — dette-code, sévérité moyenne, effort M — vérification : partiellement confirmé
+
+- **Fichier :** `shared/schema.ts:28`
+- **Constat :** shared/schema.ts ne déclare qu'un index : l.28 `(table) => [index("IDX_session_expire").on(table.expire)]` (sur la table morte `sessions`). drizzle-kit calcule les index « supprimés » et génère des DROP INDEX (node_modules/drizzle-kit/bin.cjs:30084-30089 `prepareDropIndexesJson(it.name, it.schema, it.deletedIndexes || {})`) ; README.md:65 recommande `npm run db:push`. Par ailleurs scripts/auto-migrate-production.sh:125 ne crée les index que si `idx_deliveries_order_id` n'existe pas : tout index ajouté plus tard à ce bloc ne sera jamais créé sur une base déjà migrée.
+- **Impact :** Un `db:push` sur la base de prod effacerait silencieusement tous les index de performance ; les futurs index proposés ici ne seraient pas appliqués par le script actuel.
+- **Recommandation :** D'abord arrêter une liste canonique d'index (noms et définitions), en réconciliant init.sql et la migration 20260814. Ensuite seulement, la déclarer dans pgTable (`index('...').on(t.col.desc())`, `.where(sql`invoice_reference IS NOT NULL`)` pour l'index partiel). En attendant, mettre un avertissement dans le README : ne jamais lancer db:push sur la base de production.
+
+### DB-05
+
+**N+1 sur /api/users : 2 requêtes par utilisateur lancées toutes en même temps** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/routes.ts:4279`
+- **Constat :** routes.ts:4279-4282 `const usersWithData = await Promise.all(baseUsers.map(async (baseUser) => { ... const userWithGroups = await storage.getUserWithGroups(baseUser.id);` ; getUserWithGroups = `await this.getUser(id)` (storage.ts:372) puis la jointure user_groups/groups (storage.ts:376-388). Soit 2N+1 requêtes, toutes émises simultanément sur un pool limité à 25 connexions (server/db.ts `max: 25`).
+- **Impact :** Avec 60 utilisateurs : 121 requêtes et saturation du pool, qui ralentit aussi les autres utilisateurs pendant ce temps.
+- **Recommandation :** Créer storage.getUsersWithGroups() avec le query builder drizzle (pour garder le camelCase) : `db.select({ user: { id: users.id, username: users.username, email: users.email, name: users.name, firstName: users.firstName, lastName: users.lastName, profileImageUrl: users.profileImageUrl, role: users.role, passwordChanged: users.passwordChanged, createdAt: users.createdAt, updatedAt: users.updatedAt }, groupId: userGroups.groupId, group: { id: groups.id, name: groups.name, color: groups.color, createdAt: groups.createdAt, updatedAt: groups.updatedAt } }).from(users).leftJoin(userGroups, eq(userGroups.userId, users.id)).leftJoin(groups, eq(groups.id, userGroups.groupId))`. Regrouper ensuite dans une Map par user.id, en n'ajoutant à userGroups que les lignes où group.id n'est pas null (même sémantique que l'INNER JOIN), au format `{ userId, groupId, group }`. Garder `userRoles: []`, ne pas ajouter d'ORDER BY et ne jamais exposer password. Ajouter la méthode à IStorage et à MemStorage.
+
+### DB-10
+
+**Le rapprochement charge toutes les livraisons (tous statuts, tout l'historique) puis filtre côté client** — perf-api, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/pages/BLReconciliation.tsx:357`
+- **Constat :** BLReconciliation.tsx:352-357 `const params = new URLSearchParams({}); ... fetch(`/api/deliveries?${params.toString()}`` sans date ni statut, puis l.371 `deliveries.filter((d: any) => d.status === 'delivered')`, avec `staleTime: 0` (l.376). Le filtre serveur `withBL` est lui aussi fait en JS après chargement complet : routes.ts:1864-1866 `if (withBL === 'true') { deliveries = deliveries.filter((d: any) => d.blNumber && d.status === 'delivered'); }`.
+- **Impact :** Les livraisons planifiées (inutiles ici) et des années d'historique sont transférées et rechargées à chaque visite.
+- **Recommandation :** Ajouter un paramètre optionnel `status` à getDeliveries(groupIds, { status }) dans DatabaseStorage et MemStorage (condition `eq(deliveries.status, status)` combinée par and avec le filtre magasin). Le lire dans GET /api/deliveries sans toucher au contrôle d'accès par rôle, et l'envoyer depuis BLReconciliation (`params.append('status','delivered')`), en gardant le filtre client par sécurité. Ne pas borner la période sans décision produit. L'index (group_id, status) passe par la migration de DB-01.
+
+### DB-11
+
+**Les modales de livraison téléchargent toutes les commandes pour en garder quelques-unes (et rien pour un employé)** — perf-api, sévérité moyenne, effort M
+
+- **Fichier :** `client/src/components/modals/CreateDeliveryModal.tsx:61`
+- **Constat :** CreateDeliveryModal.tsx:60-62 `const { data: allOrders = [] } = useQuery<OrderWithRelations[]>({ queryKey: ['/api/orders'] });` et EditDeliveryModal.tsx:50-52, puis filtre client par supplierId, groupId et `status !== 'delivered'`. queryFn par défaut = fetch(queryKey[0]) donc aucun paramètre : admin -> storage.getOrders() de TOUS les magasins avec livraisons imbriquées ; employé sans storeId -> `return res.json([]);` (routes.ts:1442).
+- **Impact :** Ouverture de la modale lente pour l'admin ; un employé ne peut jamais lier une livraison à une commande (liste vide).
+- **Recommandation :** Appeler `/api/orders?storeId=${groupId}&supplierId=${supplierId}&status=pending,planned` et exécuter côté serveur `SELECT id, planned_date, status, quantity, unit FROM orders WHERE group_id = $1 AND supplier_id = $2 AND status <> 'delivered' ORDER BY planned_date DESC LIMIT 50` (sans livraisons imbriquées). Index : `CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_orders_group_supplier_status ON orders (group_id, supplier_id, status);`.
+
+### DB-12
+
+**getDelivery enchaîne 5 requêtes séquentielles et sert surtout à des contrôles d'accès** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:1041`
+- **Constat :** storage.ts:1005-1034 requête principale (sans JOIN users), puis 1041 `const user = await this.getUser(delivery.createdBy);`, 1060 `const orderData = await this.getOrder(delivery.orderId);` (2 requêtes : storage.ts:784 et 816, qui recharge aussi toutes les livraisons de la commande avec groupe complet), 1079 comptage des commentaires. Appelée par routes.ts:1885, 1914, 2144, 2183, 2219, 2338, 2474, 2617, 2691 ; ex. GET reconciliation-comments (2183) n'utilise que `delivery.groupId`.
+- **Impact :** Chaque validation, vérification de facture ou ouverture de commentaires paie 5 allers-retours ; la file d'auto-vérification du rapprochement les multiplie.
+- **Recommandation :** a) Dans getDelivery : `.leftJoin(users, eq(deliveries.createdBy, users.id))` avec `creator: { id, firstName, lastName, username, email }`, puis `Promise.all([orderId ? this.getOrder(orderId) : undefined, countQuery])`, en gardant le contrôle du magasin (STORE MISMATCH) et les try/catch. b) Ne basculer vers une méthode légère getDeliveryAccessInfo que les routes qui ne lisent que groupId ou status (à vérifier route par route, ex. 2183).
+
+### DB-13
+
+**Statistiques mensuelles et annuelles : 4 requêtes indépendantes exécutées l'une après l'autre** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:1270`
+- **Constat :** getMonthlyStats : storage.ts:1270 `const ordersResult = await db...`, 1276 `const deliveriesResult = await db...`, 1287 `const pendingResult = await db...`, 1308 `const deliveriesStatsResult = await db...`. getYearlyStats : 1409, 1415, 1426, 1446. Le tableau de bord appelle les deux (Dashboard.tsx:29 et 55).
+- **Impact :** 8 allers-retours séquentiels au lieu de 2 parallèles sur la page d'accueil.
+- **Recommandation :** `const [ordersResult, deliveriesResult, pendingResult, deliveriesStatsResult] = await Promise.all([q1, q2, q3, q4]);` ou fusion en une requête : `SELECT count(*) FILTER (WHERE planned_date >= $1 AND planned_date < $2) AS orders_count, count(*) FILTER (WHERE status = 'pending') AS pending_count FROM orders WHERE group_id = ANY($3);`.
+
+### DB-14
+
+**Aucun index sur deliveries.delivered_date alors que les stats filtrent dessus** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/storage.ts:1295`
+- **Constat :** getMonthlyStats storage.ts:1294-1299 `gte(deliveries.deliveredDate, sql`${startDate}::timestamp`), lt(deliveries.deliveredDate, ...), eq(deliveries.status, 'delivered')` ; getYearlyStats 1397-1400 (compte des livraisons sans filtre statut) et 1432-1437. Index deliveries existants : init.sql:511-515 (group_id, status, bl_number, invoice_reference, due_date), migration 20260814 l.30-39 (order_id, group_id, supplier_id, created_by, scheduled_date, (group_id, scheduled_date), created_at, invoice_reference) : rien sur delivered_date.
+- **Impact :** Parcours de toutes les livraisons du magasin (ou de toute la table pour l'admin « tous magasins ») à chaque affichage du tableau de bord.
+- **Recommandation :** Ajouter `CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_deliveries_group_delivered_date ON deliveries (group_id, delivered_date)` à la liste de DB-01 (une requête, try/catch). idx_deliveries_delivered_date est facultatif.
+
+### DB-18
+
+**Annonces : N+1 (auteur + magasin par message) alors qu'une version avec JOIN existe déjà** — perf-serveur, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:5815`
+- **Constat :** routes.ts:5815 `const announcements = await Promise.all(messages.map(async (message: any) => {` puis 5823-5829 `db.select({...}).from(users).where(eq(users.username, message.createdBy))` et 5852 `await db.select().from(groups).where(eq(groups.id, message.storeId));` (ligne complète avec logo pour n'en garder que id/name). AnnouncementDatabaseStorage.getAnnouncements (announcementStorage.ts:22-46) fait déjà `.leftJoin(users, eq(dashboardMessages.createdBy, users.username)).leftJoin(groups, ...)`. Le paramètre `recent=true` envoyé par Dashboard.tsx:104 est ignoré ; le filtre « moins de 2 jours » est fait côté client (Dashboard.tsx:117-123).
+- **Impact :** Jusqu'à 11 requêtes au lieu d'une à chaque chargement du tableau de bord.
+- **Recommandation :** Garder exactement la condition actuelle (filtre uniquement pour l'admin avec storeId) et le LIMIT 5. Remplacer les recherches par message par `.leftJoin(users, eq(users.username, dashboardMessages.createdBy)).leftJoin(groups, eq(groups.id, dashboardMessages.storeId))` en ne sélectionnant que users.id, username, firstName, lastName, name, groups.id et groups.name. Reconstruire `author` avec la même logique de nom affiché et le même repli « Utilisateur Inconnu », et `group = { id, name }` ou null. Le filtre recent=true est optionnel.
+
+### DB-19
+
+**updateExistingReconciledCaches : chargement de toutes les livraisons puis 2 à 4 requêtes par livraison** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/invoiceVerification.ts:216`
+- **Constat :** invoiceVerification.ts:216-217 `const deliveries = await storage.getDeliveries(); const reconciledDeliveries = deliveries.filter(d => d.reconciled);` puis 222-233 `for (const delivery of reconciledDeliveries) { ... await this.updateCacheAsReconciled(delivery.invoiceReference, delivery.groupId); ... await this.updateCacheAsReconciled(delivery.blNumber, delivery.groupId);` ; chaque appel = SELECT (l.173) + UPSERT (l.195). Clé : `${groupId}_${invoiceReference.trim().toLowerCase()}` (l.13).
+- **Impact :** Action admin qui dure plusieurs minutes et monopolise des connexions sur une base d'un an.
+- **Recommandation :** Comme proposé, en ajoutant `AND d.invoice_reference IS NOT NULL AND btrim(d.invoice_reference) <> ''` (idem pour bl_number) pour reproduire les tests `.trim()` actuels. Écart résiduel : trim/lower de PostgreSQL ne traitent pas les blancs Unicode comme JS, ce qui est acceptable.
+
+### DB-21
+
+**La purge périodique du cache de vérification des factures ne tourne pas en production** — perf-serveur, sévérité moyenne, effort S
+
+- **Fichier :** `server/index.production.ts:62`
+- **Constat :** server/index.ts:63-64 `const { startMaintenanceJobs } = await import('./maintenance.js'); startMaintenanceJobs();` n'existe que dans le point d'entrée de développement ; le build Docker compile server/index.production.ts (Dockerfile:41) qui ne l'appelle pas (aucune occurrence de « maintenance » dans ce fichier, registerRoutes l.62). Les entrées expirées ne sont supprimées qu'à la relecture de la même clé (storage.ts:1730).
+- **Impact :** invoice_verification_cache continue de grossir sans limite en production, ce que le commit 753b301 pensait avoir corrigé.
+- **Recommandation :** Dans index.production.ts, après `await registerRoutes(app);` : `const { startMaintenanceJobs } = await import('./maintenance.js'); startMaintenanceJobs();`.
+
+### DB-24
+
+**Aucune liste n'est paginée ; les relations sont ensuite chargées via des IN de milliers d'identifiants** — perf-api, sévérité moyenne, effort L
+
+- **Fichier :** `server/storage.ts:711`
+- **Constat :** Pas de .limit() : getOrders storage.ts:711 `await query.orderBy(desc(orders.createdAt))`, getDeliveries 931, getCustomerOrders 1883, getDlcProducts 2064, getTasks 2301 (tâches terminées comprises), getAvoirs 2565, getSavTickets 2701. Orders.tsx:73 et Deliveries.tsx:80 appellent sans date. getOrders passe ensuite tous les ids à `inArray(deliveries.orderId, orderIds)` (566) et getDeliveries tous les ids à `inArray(reconciliationComments.deliveryId, deliveryIds)` (631) : PostgreSQL refuse plus de 65 535 paramètres liés.
+- **Impact :** Temps de chargement et mémoire navigateur croissant sans fin ; erreur SQL certaine au-delà de ~65 000 commandes ou livraisons pour l'admin « tous magasins ».
+- **Recommandation :** Pagination keyset : `WHERE group_id = ANY($1) AND (created_at, id) < ($2, $3) ORDER BY created_at DESC, id DESC LIMIT 50`, avec `CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_orders_group_created ON orders (group_id, created_at DESC, id DESC);` (idem deliveries, customer_orders, avoirs, sav_tickets, tasks). Remplacer les inArray(ids) par une sous-requête sur le même filtre, ex. `inArray(deliveries.orderId, db.select({ id: orders.id }).from(orders).where(inArray(orders.groupId, groupIds)))`.
+
+### DB-36
+
+**/api/groups renvoie à l'admin la ligne magasin complète (logo, SMTP, NocoDB) à 24 composants** — perf-api, sévérité moyenne, effort M
+
+- **Fichier :** `server/routes.ts:979`
+- **Constat :** routes.ts:979-981 `if (user.role === 'admin') { const groups = await storage.getGroups(); res.json(groups);` avec getGroups = `db.select().from(groups)` (storage.ts:433). `'/api/groups'` est utilisé par 24 fichiers client ; le logo n'est lu que par le formulaire de Groups.tsx (l.282). Les non-admins reçoivent déjà une version légère (id, name, color) via getUserWithGroups (storage.ts:380-384).
+- **Impact :** Avec 10 magasins ayant un logo, ~2,7 Mo téléchargés par l'admin à chaque invalidation de ['/api/groups'].
+- **Recommandation :** Faire renvoyer à /api/groups une projection (id, name, color, nocodbConfigId, nocodbTableName, webhookUrl, smtpEnabled) et ajouter GET /api/groups/:id (complet, admin) utilisé par le formulaire d'édition de Groups.tsx.
+
+### DB-37
+
+**Synthèse de la couverture d'index par table (colonnes lues dans storage.ts)** — perf-serveur, sévérité moyenne, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `migrations/20260814_add_performance_indexes.sql:15`
+- **Constat :** orders : group_id, planned_date, created_at, supplier_id, created_by -> couverts par la migration 20260814 (l.20-26) ; status -> init.sql:519 seulement (DB-15). deliveries : order_id, group_id, scheduled_date, created_at, invoice_reference -> migration (l.30-39) ; delivered_date -> AUCUN (DB-14) ; status, bl_number -> init.sql seulement. user_groups : user_id, group_id -> migration (l.17-18), pas d'unicité (DB-23). users : id PK, username et email UNIQUE -> OK. tasks : group_id, status, due_date -> migration (l.56-59) ; start_date, created_at (tri) -> aucun. customer_orders : group_id, status, created_at -> migration (l.44-47) ; customer_notified -> aucun (DB-35). dlc_products : group_id, supplier_id, expiry_date, (group_id,status) -> migration (l.50-53) ; (group_id, expiry_date) -> aucun (DB-34). sav_tickets / avoirs : group_id, supplier_id, created_at, (group_id,status) -> migration. publicities : year -> migration + init.sql ; pub_number UNIQUE. publicity_participations : PK (publicity_id, group_id) + group_id. dashboard_messages : store_id, created_at -> migration + init.sql. invoice_verification_cache : cache_key UNIQUE, expires_at, group_id -> OK. session (connect-pg-simple) : sid PK, expire -> AUCUN (DB-22). Attention : tous les index « migration » ne sont présents que si le script a été lancé à la main (DB-01).
+- **Impact :** Donne la liste exacte des index à garantir au démarrage et des trous restants.
+- **Recommandation :** Liste à ajouter à migrations.production.ts (CONCURRENTLY IF NOT EXISTS, une requête et un try/catch par index, après purge des index invalides, sans bloquer le démarrage) : idx_deliveries_group_delivered_date, idx_orders_group_status, idx_deliveries_group_status, idx_dlc_products_group_expiry, idx_customer_orders_pending_calls, idx_supplier_mail_logs_group_created, plus les index de la migration 20260814. Ne pas créer idx_session_expire. Puis ANALYZE des tables et contrôle via pg_stat_user_indexes.
+
+### DB-15
+
+**Index (group_id, status) absent sur orders et deliveries, alors qu'il existe pour les autres tables** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/storage.ts:1282`
+- **Constat :** storage.ts:1282-1290 `let pendingWhereCondition = eq(orders.status, 'pending'); ... inArray(orders.groupId, groupIds)` (et 1421-1429) ; filtre deliveries.status dans les stats (1297) et le rapprochement (DB-10). idx_orders_status / idx_deliveries_status n'existent que dans init.sql:512 et 519 (bases neuves uniquement). La migration 20260814 crée (group_id, status) pour customer_orders (l.47), dlc_products (53), tasks (59), avoirs (65), sav_tickets (71) mais pas pour orders ni deliveries.
+- **Impact :** Comptage des commandes en attente et filtrage des livraisons livrées non servis par un index sélectif.
+- **Recommandation :** Ajouter idx_orders_group_status et idx_deliveries_group_status à la liste de DB-01 (CONCURRENTLY, une requête par index).
+
+### DB-17
+
+**Série temporelle Analytics : 2 requêtes indépendantes séquentielles** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/storage.ts:3333`
+- **Constat :** storage.ts:3333 `const ordersData = await db.execute(sql.raw(ordersSql));` puis 3344 `const deliveriesData = await db.execute(sql.raw(deliveriesSql));`.
+- **Impact :** Latence doublée à chaque changement de filtre ou de granularité.
+- **Recommandation :** `const [ordersData, deliveriesData] = await Promise.all([db.execute(sql.raw(ordersSql)), db.execute(sql.raw(deliveriesSql))]);`.
+
+### DB-20
+
+**Diagnostic du cache : toutes les livraisons chargées pour compter, et clé de cache erronée** — bug, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:2735`
+- **Constat :** routes.ts:2725-2727 `const deliveries = await storage.getDeliveries(); const reconciledCount = deliveries.filter(d => d.reconciled).length;` ; routes.ts:2735 `const cacheKey = `${delivery.invoiceReference.toLowerCase()}_${delivery.groupId}`;` alors que generateCacheKey (invoiceVerification.ts:13) produit `${groupId}_${invoiceReference.trim().toLowerCase()}`.
+- **Impact :** Le diagnostic affiche toujours « cacheExists: false » et coûte un chargement complet de la table.
+- **Recommandation :** Comme proposé. Garder le même format de réponse (statistics.totalDeliveries, reconciledDeliveries, percentageReconciled en protégeant la division par zéro, et sampleCaches), et caster les count en Number.
+
+### DB-23
+
+**user_groups n'a ni clé primaire ni contrainte d'unicité (user_id, group_id)** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `shared/schema.ts:82`
+- **Constat :** shared/schema.ts:82-86 `export const userGroups = pgTable("user_groups", { userId: ..., groupId: ..., createdAt: ... });` sans primaryKey ; init.sql:67-71 idem. assignUserToGroup (storage.ts:1210-1213) insère sans vérification, depuis routes.ts:4241 et 4469.
+- **Impact :** Affectations en double possibles ; elles se répercutent dans userGroups de chaque requête (deserializeUser) et dans les listes de magasins.
+- **Recommandation :** Dédoublonner (`DELETE FROM user_groups a USING user_groups b WHERE a.ctid < b.ctid AND a.user_id = b.user_id AND a.group_id = b.group_id;`) puis `CREATE UNIQUE INDEX CONCURRENTLY IF NOT EXISTS uq_user_groups_user_group ON user_groups (user_id, group_id);` (rend idx_user_groups_user_id redondant) et `.onConflictDoNothing()` dans assignUserToGroup.
+
+### DB-25
+
+**Statistiques SAV : 3 requêtes séquentielles, plus une requête morte** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/storage.ts:2832`
+- **Constat :** storage.ts:2825-2829 `let baseQuery = db.select().from(savTickets); ... baseQuery = baseQuery.where(...)` jamais exécutée ; 2832 statusResults (GROUP BY status), 2842 priorityResults (GROUP BY priority), 2852 totalResult, chacun `await` à la suite.
+- **Impact :** 3 allers-retours au lieu d'un à chaque affichage de la page SAV.
+- **Recommandation :** Comme proposé, en castant les count en Number et en gardant les clés totalTickets, newTickets, inProgressTickets, resolvedTickets et criticalTickets. Supprimer baseQuery.
+
+### DB-26
+
+**getSavTickets attend un historique par ticket qui renvoie toujours un tableau vide** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `server/storage.ts:2704`
+- **Constat :** storage.ts:2704-2706 `const ticketsWithHistory = await Promise.all(results.map(async (result: any) => { const history = await this.getSavTicketHistory(result.ticket.id);` alors que getSavTicketHistory (2790-2806) est entièrement commenté et fait `return [];`.
+- **Impact :** Une promesse par ticket pour rien ; trompe le lecteur qui croit à un N+1.
+- **Recommandation :** `return results.map((r: any) => ({ ...r.ticket, supplier: r.supplier, group: r.group, creator: r.creator, history: [] }));`.
+
+### DB-27
+
+**Numérotation des tickets SAV : filtre non indexable et risque de doublon** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:2753`
+- **Constat :** storage.ts:2750-2755 `.where(sql`EXTRACT(year from created_at) = ${currentYear}`)` puis `SAV-${currentYear}-${count + 1}` ; ticket_number n'est pas unique (schema.ts:871).
+- **Impact :** Parcours complet de sav_tickets à chaque création (l'index created_at ne sert pas) ; deux créations simultanées ou une suppression produisent des numéros en double.
+- **Recommandation :** Auto-implémentable seulement : remplacer le filtre par `created_at >= make_date(${currentYear}::int, 1, 1) AND created_at < make_date(${currentYear + 1}::int, 1, 1)` (année suivante calculée en JS). À traiter à part, avec décision produit : le bug de concaténation (`Number(count[0]?.count ?? 0) + 1`) et l'unicité de ticket_number (séquence ou max par année, puis index unique).
+
+### DB-28
+
+**La synchronisation des statuts charge toutes les commandes et livraisons, puis met à jour une par une** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:1700`
+- **Constat :** routes.ts:1700 `const orders = await storage.getOrders();` (tous magasins, livraisons imbriquées), puis 1704-1724 `for (const order of orders) { ... await storage.updateOrder(order.id, { status: 'delivered' });`.
+- **Impact :** Action admin lente et coûteuse en mémoire sur une base d'un an.
+- **Recommandation :** `WITH c AS (SELECT o.id, o.status AS current_status, count(*) FILTER (WHERE d.status = 'delivered') AS delivered, count(*) AS total FROM orders o JOIN deliveries d ON d.order_id = o.id WHERE o.status <> 'delivered' GROUP BY o.id, o.status HAVING count(*) FILTER (WHERE d.status = 'delivered') > 0), u AS (UPDATE orders SET status = 'delivered', updated_at = now() FROM c WHERE orders.id = c.id RETURNING orders.id) SELECT c.* FROM c JOIN u ON u.id = c.id;`, puis reconstruire problematicOrders et fixedOrders au même format (counts castés en Number).
+
+### DB-29
+
+**getPublicities ignore groupIds, groupe les participations en O(P×N) et trie deux fois ; le tableau de bord l'appelle 3 fois de suite** — perf-api, sévérité basse, effort S
+
+- **Fichier :** `server/storage.ts:1502`
+- **Constat :** storage.ts:1502 signature `getPublicities(year?: number, groupIds?: number[])` mais groupIds n'est jamais utilisé ; 1522 `orderBy(publicities.pubNumber)` puis 1544 re-tri JS ; 1552-1553 `participations.filter((p: any) => p.publicityId === publicity.id)` pour chaque publicité. Dashboard.tsx:205-211 `for (const year of years) { ... await fetch(`/api/ad-campaigns?${params}`)` (3 appels séquentiels).
+- **Impact :** Réponses plus lourdes que nécessaire et 3 allers-retours HTTP+BD successifs sur l'accueil.
+- **Recommandation :** Grouper les participations dans une Map<publicityId, []> ; trier en SQL `ORDER BY NULLIF(regexp_replace(pub_number, '\D', '', 'g'), '')::int` ; pour l'accueil, une seule requête `WHERE end_date >= current_date ORDER BY start_date LIMIT 10`. Filtrer par magasin via `EXISTS (SELECT 1 FROM publicity_participations pp WHERE pp.publicity_id = p.id AND pp.group_id = ANY($1))` est une décision produit.
+
+### DB-30
+
+**Météo : deux lectures indépendantes séquentielles et recherche « date la plus proche » non indexable** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/routes.ts:5683`
+- **Constat :** routes.ts:5683-5684 `let currentYearData = await storage.getWeatherData(today, true); let previousYearData = await storage.getWeatherData(previousYearDate, false);` ; storage.ts:2936-2938 `sql`ABS(${weatherData.date} - ${date}::date) <= ${maxDistanceDays}`` puis ORDER BY ABS(...).
+- **Impact :** Latence ajoutée au widget météo affiché sur l'accueil.
+- **Recommandation :** `const [currentYearData, previousYearData] = await Promise.all([storage.getWeatherData(today, true), storage.getWeatherData(previousYearDate, false)]);`. Dans getNearestWeatherData, si on le souhaite : `${weatherData.date} BETWEEN ${date}::date - ${maxDistanceDays}::int AND ${date}::date + ${maxDistanceDays}::int`, en gardant l'ORDER BY ABS(...) et le LIMIT 1.
+
+### DB-31
+
+**Chaque vérification de facture relit la fiche magasin complète (logo) et la configuration NocoDB** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/invoiceVerification.ts:285`
+- **Constat :** invoiceVerification.ts:285 `const group = await storage.getGroup(groupId);` (= `db.select().from(groups)`, storage.ts:437, logo compris) et 360 `const nocodbConfig = await storage.getActiveNocodbConfig();` (+ déchiffrement) ; idem 658 et 734 pour les BL. Appelé en boucle par l'échéancier (routes.ts:444, 491) et la file d'auto-vérification du rapprochement.
+- **Impact :** Des centaines de relectures identiques (jusqu'à ~270 Ko chacune) quand on vérifie un lot de factures.
+- **Recommandation :** Seule partie sûre : une méthode storage.getGroupVerificationSettings(id) qui ne projette que name, nocodbConfigId, nocodbTableName, nocodbTableId, invoiceColumnName, nocodb*ColumnName et webhookUrl, utilisée aux l.285 et 658. Le cache mémoire de la config NocoDB est à décider séparément, avec la liste complète des invalidations.
+
+### DB-32
+
+**server/cache.ts n'est importé nulle part et son middleware de compression est piégeux** — dette-code, sévérité basse, effort S
+
+- **Fichier :** `server/cache.ts:96`
+- **Constat :** Aucun import de './cache' dans server/*.ts. cache.ts:96-104 `setupCompression` pose `res.setHeader('Content-Encoding', 'gzip')` sans compresser réellement ; `createOptimizedQuery` (l.108-123) ajoute `LIMIT 1000` à l'aveugle. Aucun middleware `compression` n'est monté dans index.production.ts : les gros JSON des listes partent non compressés (sauf si un proxy compresse).
+- **Impact :** Aucun cache serveur malgré l'apparence ; brancher ce fichier tel quel casserait les réponses.
+- **Recommandation :** Auto-implémentable : supprimer setupCompression et createOptimizedQuery (ou tout cache.ts, qui n'a aucun import), ajouter la dépendance `compression` (et @types/compression) avec mise à jour du lockfile, puis `app.use(compression())` dans index.production.ts avant registerProductionRoutes. Le cache mémoire de getGroups et getSuppliers est hors périmètre auto.
+
+### DB-33
+
+**Suppression d'utilisateur : un DELETE par magasin dans une boucle** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/routes.ts:4514`
+- **Constat :** routes.ts:4511-4516 `const userWithGroups = await storage.getUserWithGroups(userToDelete); if (userWithGroups) { for (const userGroup of userWithGroups.userGroups) { await storage.removeUserFromGroup(userToDelete, userGroup.groupId); }`.
+- **Impact :** 2 + N requêtes au lieu d'une.
+- **Recommandation :** Ajouter `removeUserFromAllGroups(userId)` (`db.delete(userGroups).where(eq(userGroups.userId, userId))`) à IStorage, DatabaseStorage et MemStorage, puis l'appeler à la place de la boucle.
+
+### DB-34
+
+**DLC : pas d'index composite magasin+date, recherche texte non indexable** — perf-serveur, sévérité basse, effort S — vérification : partiellement confirmé
+
+- **Fichier :** `server/storage.ts:2052`
+- **Constat :** storage.ts:1990 `inArray(dlcProducts.groupId, groupIds)` + 2007-2008 `gt(dlcProducts.expiryDate, today), lte(dlcProducts.expiryDate, in15Days)` + tri 2064-2077 sur expiry_date ; index existants séparés idx_dlc_products_group_id / idx_dlc_products_expiry_date (migration l.50-52). Recherche 2052-2053 `LOWER(${dlcProducts.productName}) LIKE LOWER(${'%' + filters.search + '%'})`.
+- **Impact :** Les filtres « expire bientôt » et la recherche parcourent toutes les lignes du magasin.
+- **Recommandation :** N'ajouter que `CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_dlc_products_group_expiry ON dlc_products (group_id, expiry_date)` à la liste de DB-01. Pas de pg_trgm.
+
+### DB-35
+
+**Index complémentaires : appels clients en attente et historique des mails fournisseurs** — perf-serveur, sévérité basse, effort S
+
+- **Fichier :** `server/storage.ts:1933`
+- **Constat :** getPendingClientCalls storage.ts:1932-1938 `eq(customerOrders.customerNotified, false), inArray(customerOrders.status, [...])` + groupId, tri created_at (1951) : aucun index sur customer_notified. getSupplierMailLogs storage.ts:2976-2988 `inArray(supplierMailLogs.groupId, groupIds)` + `.orderBy(desc(supplierMailLogs.createdAt)).limit(500)` : seul idx_supplier_mail_logs_group (init.sql:439) existe.
+- **Impact :** Faible aujourd'hui, croissant avec l'historique.
+- **Recommandation :** Ajouter ces deux index à la liste de DB-01 (CONCURRENTLY, une requête chacun).