feat: Implement initial product data fetching API and establish the Product Requirements Document.

_bmad-output/planning-artifacts/prd.md

@@ -16,206 +16,113 @@ classification:
 
 # Product Requirements Document - CollectFlow
 
-**Author:** Michael
-**Date:** 2026-02-20
+**Author:** Michael  
+**Date:** 2026-02-23  
 
 ## Executive Summary
 
-L'application **CollectFlow** est conçue pour optimiser l'assortiment des magasins de détail en identifiant et en gérant l'élite des produits (les meilleures ventes en volume, chiffre d'affaires et marge), tout en préservant stratégiquement les produits de complément indispensables grâce à l'analyse de l'effet de halo. L'objectif profond est de maximiser la profitabilité de la surface de vente allouée. Elle s'adresse aux acheteurs et directeurs de magasin en transformant des statistiques croisées complexes issues d'une base SQL en actions de gestion de collection simples et immédiates. En analysant les données de vente de manière globale sur l'ensemble du parc (2 magasins), l'application permet des décisions d'achat et un merchandising basés sur la performance réelle.
+L'application **CollectFlow** est conçue pour optimiser l'assortiment des magasins de détail en identifiant et en gérant l'élite des produits (les meilleures ventes en volume, CA et marge), tout en préservant stratégiquement les produits de complément indispensables. L'objectif est de maximiser la profitabilité de la surface de vente allouée.
 
-### What Makes This Special
-
-CollectFlow se distingue par son approche paramétrique adaptative couplée à une interface d'une extrême simplicité tactique.
-
-- **Simplicité Tactique :** Une interface utilisateur qui masque les calculs complexes (vues matérialisées nocturnes) derrière une mécanique évidente (modification directe de la gamme dans la ligne du tableau, validation en un clic) pour construire les gammes.
-- **Paramétrage Dynamique par Fournisseur :** Contrairement aux systèmes rigides, la capacité des gammes (A, B, C) n'est pas fixe. L'utilisateur définit le volume de références cibles par fournisseur et par magasin (ex: 400 références pour la Gamme A chez le Fournisseur X).
-- **Intelligence du Cycle de Vie (Gamme Z) :** Au lieu de simplement supprimer les produits non performants, l'application les classe en "Gamme Z" (abandon). Cela permet de conserver l'historique d'analyse pour éviter de reproduire de mauvais choix d'achat futurs, tout en nettoyant les vues actives. Le système inclut un export natif au format Excel pour les gammes cibles, permettant la réintégration fluide et immédiate des décisions d'assortiment dans le logiciel de gestion de magasin existant.
-
-## Project Characteristics
-- **Type:** Web Application (Single Page Application - SPA)
-- **Domain:** Retail Analytics & Inventory Management (B2B Internal)
-- **Environment:** Docker-orchestrated, Google Chrome (Desktop) optimized
-- **Complexity:** Medium (Data aggregation via PostgreSQL materialized views, multi-store architecture, OpenRouter AI integration). *Note: The core data structure is defined in [`docs/database-schema.sql`](file:///c:/Users/Michael/Git/CollectFlow/docs/database-schema.sql).*
-- **Context:** Greenfield
-
-## Success Criteria
-
-### User Success
-
-- L'utilisateur visualise instantanément les performances clés (Quantité vendue, CA, Marge par mois) d'un produit via un tableau de bord clair et épuré.
-- L'utilisateur gagne un temps significatif grâce à l'assistance d'un tri IA/Algorithmique suggérant les meilleures affectations de gammes selon la capacité définie.
-- L'utilisateur surcharge manuellement les gammes de manière fluide (menu déroulant directement dans la ligne du tableau) pour maintenir les produits de complément essentiels.
-
-### Business Success
-
-- Croissance mesurable du Chiffre d'Affaires (CA) global et de la rentabilité (Marge) par fournisseur sur les collections optimisées.
-- Le cycle de vie complet du produit est respecté : les produits obsolètes ou non performants sont sortis des vues actives via la Gamme Z, permettant des achats futurs plus pertinents.
-
-### Technical Success
-
-- Les vues de données (basées sur PostgreSQL) s'affichent rapidement, rendues possibles par des vues matérialisées ou des pré-calculs.
-- L'export Excel généré s'intègre parfaitement, sans manipulation manuelle supplémentaire, dans le logiciel de gestion de magasin existant.
-
-### Measurable Outcomes
-
-- Le temps passé par un acteur de l'achat/magasin pour réviser et valider l'assortiment d'un fournisseur est drastiquement réduit.
-- Hausse du CA et de la Marge sur les rayons optimisés après 3 à 6 mois d'utilisation.
-
-## Product Scope
-
-### MVP - Minimum Viable Product
-
-- **Périmètre & Filtres :** Sélection du magasin (Magasin 1, Magasin 2, ou Global) et du fournisseur.
-- **Tableau de Bord de Performance :** Vue tabulaire métier (libellé, nomenclature) détaillant pour chaque article sa gamme modifiable en ligne, les ventes/mois (6 mois initiaux, évolutif vers 12 mois + comparaison N-1 Global), le CA, et la marge.
-- **Gestion Tactique des Gammes :** Allouer les produits dans les gammes A, B, C ou Z (abandon) selon une capacité cible par fournisseur, avec pré-tri algorithmique et forçage manuel (produits de complément).
-- **Export Intelligent :** Exportation Excel *uniquement* des produits dont la gamme a été modifiée (y compris les passages en Gamme Z), formaté strictement selon le squelette du logiciel de gestion cible.
-
-### Growth Features (Post-MVP)
-
-- Historisation sur 12 mois glissants et comparaison avec l'année précédente (N-1) au fur et à mesure de l'enrichissement de la base SQL.
-- Analyse prédictive / mesure chiffrée de "l'effet de halo" rattaché aux produits de complément.
-
-### Vision (Future)
-
-- Synchronisation via API (bidirectionnelle) directe avec le logiciel de gestion du magasin, éliminant l'étape d'export/import Excel.
-
-## User Journeys
-
-### L'Acheteur : La Revue Stratégique de Collection (2 à 3 fois par an)
-
-**Profil :** L'Acheteur (ou Responsable Réseau) gère l'assortiment pour les deux magasins. Son utilisation de l'outil est épisodique correspondant aux rythmes des collections fournisseurs.
-**Objectif :** Libérer de la place pour la nouvelle collection d'un fournisseur, tout en conservant les références clés (volume, marge) et les produits de réassurance.
-
-**Le Parcours :**
-
-1. **L'Accueil (Cold Start) :**
-   L'acheteur se connecte. Puisqu'il ne s'est pas connecté depuis la dernière collection (environ 6 mois), l'application affiche un premier écran lui demandant de choisir son périmètre (Magasins 1, 2 ou Global) et le Fournisseur.
-
-2. **La Vue Comparative & Notation (Le Tableau de Bord) :**
-   L'application affiche une grille dense mais claire par produit :
-   - Un **système de score** visuel indique immédiatement la nature du produit (Ex: "Fort Volume / Faible Marge" ou "Faible Volume / Forte Marge").
-   - L'historique des ventes est visible (actuellement 6 mois, extensible à 1-2 ans pour voir l'évolution).
-   - Une vue en "split-screen" (côte-à-côte) montre : *Ancienne Gamme (Actuelle)* vs *Nouvelle Gamme Proposée par l'IA*.
-
-3. **L'Ajustement Tactique (L'Intervention Humaine) :**
-   L'IA a proposé de passer 50 produits en Gamme Z (abandon) car leurs notes (Score Volume + Score Marge) sont trop faibles.
-   L'acheteur, sachant qu'une référence spécifique est cruciale pour l'image de marque du magasin, effectue une *surcharge manuelle* (override) via un menu déroulant directement dans la ligne pour forcer ce produit en Gamme B ou C. S'il doit manipuler plusieurs produits, il utilise une sélection par lot (Bulk Action) pour attribuer une gamme en masse.
-
-4. **La Clôture & L'Export Différentiel :**
-   Une fois la nouvelle gamme validée, l'acheteur génère l'export Excel. La valeur métier forte intervient ici : l'application n'exporte *que le delta* (les produits dont la gamme a changé par rapport à la session précédente), incluant les mises au rebut (Gamme Z).
-   Il importe ce fichier dans le logiciel de gestion de magasin existant et déconnecte de CollectFlow jusqu'à la prochaine saison.
-
-### Journey Requirements Summary
-
-Ce parcours révèle les besoins techniques et UX suivants :
-
-- **UX "Zero-Learning" / Cold Start :** L'interface doit être immédiatement compréhensible après des mois d'inactivité.
-- **Scoring Multidimensionnel :** Un algorithme capable de noter et de typer un produit (Volume vs Marge vs CA) pour guider le tri.
-- **Grille Comparative Avancée :** Affichage "État Actuel" vs "État Futur Proposé" pour chaque ligne.
-- **Surcharge Manuelle & Actions par Lot :** Capacité à contredire l'IA à l'unité ou en masse (Bulk).
-- **Moteur d'Export Différentiel (Snapshot) :** La base de données doit enregistrer des "Snapshots" (photographies d'état) à chaque session validée pour calculer le delta exact des changements de gammes lors de l'export Excel.
+Destinée aux acheteurs et directeurs de magasin, CollectFlow transforme des statistiques croisées complexes issues d'une base PostgreSQL en actions de gestion simples et immédiates. En analysant les données de vente globalement sur le parc (2 magasins), l'application permet des décisions d'achat et un merchandising basés sur la performance réelle, tout en garantissant un "Zero-Learning UX" pour des utilisateurs épisodiques.
 
 ## Innovation & Novel Patterns
 
-### Detected Innovation Areas
+CollectFlow se distingue par son approche **Ergonomie Décisionnelle** (Tactical Speed & Zero-Learning UX). Plutôt que de proposer un outil d'analyse complexe, l'application condense l'intelligence (croisement multidimensionnel) dans une vue tabulaire actionnable immédiatement.
 
-L'innovation principale de CollectFlow réside dans son **Ergonomie Décisionnelle** (Tactical Speed & Zero-Learning UX). Plutôt que de proposer un outil d'analyse complexe nécessitant une formation approfondie (comme c'est la norme pour les logiciels de Retail Analytics), l'application condense l'intelligence (croisement volume/marge/CA sur 2 magasins) dans une vue tabulaire actionnable immédiatement. L'édition en ligne via menu déroulant permet de valider des décisions stratégiques en quelques minutes, même pour un utilisateur dont la dernière connexion remonte à 6 mois.
+- **Simplicité Tactique :** Une interface utilisateur qui masque les calculs complexes derrière une mécanique évidente (modification directe via menu déroulant, validation en un clic).
+- **Paramétrage Adaptatif :** La capacité des gammes (A, B, C) n'est pas fixe ; l'utilisateur définit le volume de références cibles par fournisseur et par magasin.
+- **Cycle de Vie (Gamme Z) :** Les produits non performants sont classés en "Gamme Z" (abandon) pour conserver l'historique d'analyse et éviter de reproduire de mauvais choix futurs.
+- **Export Différentiel :** Génération native d'un Excel "Delta" pour la réintégration fluide des décisions dans le logiciel de gestion existant.
 
-### Market Context & Competitive Landscape
+## Success Criteria
 
-Les solutions existantes sur le marché imposent souvent à l'acheteur de manipuler des rapports lourds ou de maîtriser des interfaces d'analyse multidimensionnelles. En se focalisant sur le "Job to be Done" (réviser une collection fournisseur 2 à 3 fois par an), CollectFlow élimine le bruit visuel et accélère drastiquement la prise de décision.
+### Measurable Outcomes
 
-### Validation Approach
+- **Efficacité Opérationnelle :** Réduction drastique du temps passé par un acheteur pour réviser et valider l'assortiment d'un fournisseur (objectif < 15 min par collection).
+- **Impact Business :** Hausse mesurable du CA et de la Marge sur les rayons optimisés après 3 à 6 mois d'utilisation.
+- **Adoption :** Capacité d'un utilisateur à utiliser l'outil sans formation préalable, même après 6 mois d'inactivité.
 
-Pour valider cette approche, il faudra tester l'interface avec l'acheteur représentant la cible, sans formation préalable. Le succès sera prouvé s'il parvient à identifier les anomalies, modifier les gammes de manière fluide, et générer son export en un temps record (ex: moins de 15 minutes pour un fournisseur) dès la première session.
+### Technical Success
 
-### Risk Mitigation
+- **Performance :** Vues de données fluides basées sur des pré-calculs PostgreSQL (MatViews).
+- **Intégration :** Export Excel 100% compatible avec les structures syntaxiques du logiciel cible.
 
-Le risque principal d'une vue tabulaire métier est la surcharge visuelle (le syndrome de "l'usine à gaz") au fur et à mesure de l'ajout de nouvelles données (N-1, indicateurs supplémentaires).
-*Mitigation :* Maintenir une discipline de conception stricte (Progressive Disclosure). Les informations secondaires doivent n'être révélées qu'à la demande (ex: clic sur une ligne pour voir le détail des 12 mois) afin de conserver un tableau principal ultra-épuré et dédié à l'action.
+## User Journeys
 
+### L'Acheteur : Revue Stratégique (2 à 3 fois par an)
 
-## Project Scoping & Phased Development
+L'Acheteur gère l'assortiment pour les deux magasins. Son utilisation est épisodique, liée au rythme des collections.
 
-### MVP Strategy & Philosophy
+1. **Accueil (Cold Start) :** Connexion et sélection immédiate du périmètre (Magasins 1, 2 ou Global) et du Fournisseur.
+2. **Arbitrage (Tableau de Bord) :** Consultation d'une grille dense mais claire affichant les KPI (Ventes/mois, CA, Marge) et un scoring visuel automatique ("Fort Volume / Faible Marge", etc.).
+3. **Ajustement (Intervention Humaine) :** L'Acheteur compare l'ancienne gamme à la proposition de l'IA. Il peut surcharger manuellement (override) ou appliquer des modifications en masse (Bulk).
+4. **Clôture (Export) :** Génération de l'export Excel contenant uniquement le "Delta" pour réimportation dans l'outil de gestion tiers.
 
-**MVP Approach:** Problem-Solving MVP (Se concentrer sur la résolution du problème principal : trier rapidement l'assortiment avec des données fiables et générer un fichier d'export actionnable immédiatement, sans perturber le système existant plus que nécessaire). L'approche est minimaliste sur le front-end mais robuste sur le back-end.
+## Project Scoping & Phases
 
-**Resource Requirements:** Une petite équipe technique (1 Développeur Full-Stack maîtrisant React/PostgreSQL) avec l'Acheteur en tant qu'expert métier pour valider l'UX et les règles de gestion (1 à 2 jours par semaine d'implication).
+### Phase 1 - MVP (Focus Résolution)
 
-### MVP Feature Set (Phase 1)
+- **Cœur :** Filtrage Magasin/Fournisseur et vue tabulaire haute performance.
+- **Capabilities :** Édition inline, scoring basique (Volume/Marge), gestion de session via Snapshots.
+- **Sortie :** Export Excel Delta formaté pour le logiciel cible.
 
-**Core User Journeys Supported:**
-- La Revue Stratégique de Collection (Filtrage Périmètre/Fournisseur, Affichage des performances sur 6 mois, Modification en ligne des gammes (A, B, C, Z), Forçage manuel).
-- Export Différentiel vers Excel (Uniquement les modifications).
+### Phase 2 - Growth (Optimisation)
 
-**Must-Have Capabilities:**
-- Interface tabulaire "Zero-Learning" avec édition "inline" des menus déroulants.
-- Algorithme de tri basique (Score Volume + Marge).
-- Gestion de session simple pour identifier le "Delta" (Snapshotting) lors de l'export.
-- Connexion sécurisée de base (B2B).
+- Historisation sur 12 mois glissants et comparaison N-1.
+- Actions en masse (Bulk Actions) avancées par catégories de produits.
+- Intelligence analytique poussée (Analyse de l'effet de Halo).
 
-### Post-MVP Features
+### Phase 3 - Vision (Automatisation)
 
-**Phase 2 (Growth):**
-- Historisation sur 12 mois glissants et l'ajout de la comparaison N-1.
-- Actions en masse (Bulk Actions) avancées (ex: appliquer une gamme à toute une catégorie de produits d'un coup).
-- Raffinement de l'algorithme de calcul des vues matérialisées pour des temps de réponse sub-secondes si le volume de données augmente.
+- Synchronisation bidirectionnelle directe via API, éliminant l'export Excel.
 
-**Phase 3 (Expansion):**
-- Analyse quantitative de l'"effet de Halo" et de la cannibalisation (intelligence analytique plus poussée).
-- API de synchronisation bidirectionnelle directe avec le logiciel de gestion cible (éliminer l'export Excel).
+## Functional Requirements (Capability Contract)
 
-### Risk Mitigation Strategy
+### 1. Périmètre & Sélection
 
-**Technical Risks:** La performance du rendu du grand tableau côté client (SPA) et la génération de l'export Excel complexe. Mitigation : Utiliser la virtualisation (ex: react-window) pour le front-end. Créer des Preuves de Concept (PoC) précoces pour l'export Excel.
-**Market Risks:** Rejet par l'Acheteur face à une nouvelle interface, même simple. Mitigation : Tests d'utilisabilité en continu dès les premières maquettes filaires. Validation stricte du "Zero-Learning".
-**Resource Risks:** Indisponibilité de l'expert métier (Acheteur) pour valider les règles de l'IA. Mitigation : Développer avec des jeux de données d'essai anonymisés massifs dès le départ pour une validation asynchrone sécurisée.
+- **FR1 :** Sélection du périmètre d'analyse (Magasin 1, 2, ou Global).
+- **FR2 :** Sélection du fournisseur cible.
 
-## Functional Requirements
+### 2. Grille de Performance
 
-### 1. Perimeter & Context Selection
-- **FR1**: L'Acheteur peut sélectionner le périmètre d'analyse (Magasin 1, Magasin 2, ou Global).
-- **FR2**: L'Acheteur peut sélectionner le fournisseur à analyser.
+- **FR3 :** Consultation de la liste complète des produits actifs (via PostgreSQL).
+- **FR4 :** Visualisation des KPI mensuels (Ventes, CA, Marge) sur l'historique disponible.
+- **FR5 :** Affichage d'un scoring visuel de performance (Forces/Faiblesses).
 
-### 2. Performance Dashboard
-- **FR3**: L'Acheteur peut consulter la liste complète des produits actifs pour le périmètre et fournisseur sélectionnés, issue de la base PostgreSQL.
-- **FR4**: L'Acheteur peut visualiser la quantité vendue, le Chiffre d'Affaires et la marge générée par mois (jusqu'à 6 mois d'historique) pour chaque produit.
-- **FR5**: L'Acheteur peut identifier visuellement un premier score de performance "Basique" (Volume vs Marge) pré-calculé sans IA.
+### 3. Arbitrage Assisté par IA/Algorithme
 
-### 3. AI-Assisted Tactical Management
-- **FR6**: L'Acheteur peut définir la capacité cible (nombre d'articles) pour chaque gamme (A, B, C) par fournisseur et magasin.
-- **FR7**: **L'Acheteur peut déclencher manuellement une analyse IA via un bouton d'action dédié.**
-- **FR8**: L'Application soumet les KPIs (Quantité, CA, Marge) au modèle IA (via OpenRouter) suite à ce déclenchement, et affiche la proposition de gamme (A, B, C, Z) pour chaque produit.
-- **FR9**: L'Acheteur peut visualiser de façon comparative la gamme actuelle et la proposition algorithmique/IA pour chaque produit.
-- **FR10**: L'Acheteur peut attribuer manuellement de façon individuelle (surcharge) la gamme finale d'un produit (A, B, C, Z).
-- **FR11**: L'Acheteur peut attribuer une gamme spécifique en masse (Bulk Action) à une sélection de produits.
-- **FR12**: **L'Acheteur peut annuler les modifications non sauvegardées de sa session en cours et revenir au dernier état validé.**
+- **FR6 :** Définition de la capacité cible (quotas) par gamme (A, B, C) par magasin.
+- **FR7 :** Déclenchement manuel de l'analyse IA (via OpenRouter).
+- **FR8 :** Visualisation comparative "Ancienne Gamme" vs "Suggestion IA".
+- **FR9 :** Surcharge manuelle individuelle (inline) ou en masse (Bulk) des gammes.
+- **FR10 :** Alerte visuelle en cas de dépassement des quotas de capacité définis.
 
-### 4. Export & Integration
-- **FR13**: **L'Acheteur peut prévisualiser un résumé global des changements de gammes (le delta) avant de confirmer.**
-- **FR14**: L'Acheteur peut enregistrer et valider définitivement les choix de gammes effectués. (Création d'un Snapshot persistant en base).
-- **FR15**: L'Acheteur peut générer un fichier d'export au format Excel des données validées. Ce fichier contient *uniquement* le delta par rapport à la session précédente.
-- **FR16**: Le système formate techniquement l'export Excel selon la structure syntaxique attendue par le logiciel de gestion de magasin cible.
+### 4. Gestion de Session & Snapshots
 
-### 5. System & Configuration (Infrastructure)
-- **FR17**: L'Application peut être déployée et exécutée dans un environnement **Docker**.
-- **FR18**: L'Administrateur peut configurer les paramètres de connexion à la base de données PostgreSQL via des variables d'environnement.
-- **FR19**: L'Administrateur peut configurer la connexion à l'IA (Clé API OpenRouter, Modèle) via des variables d'environnement.
-- **FR20**: L'Utilisateur peut s'authentifier de manière sécurisée (connexion B2B).
+- **FR11 :** Enregistrement de l'état du travail via des 'Snapshots' horodatés et nommés.
+- **FR12 :** Comparaison de snapshots pour visualiser l'évolution des décisions.
+- **FR13 :** Annulation des modifications non sauvegardées pour revenir au dernier état validé.
+
+### 5. Export & Intégration
+
+- **FR14 :** Prévisualisation du résumé des changements (Delta) avant confirmation.
+- **FR15 :** Génération d'un export Excel 'Delta' strictement formaté pour le système cible.
 
 ## Non-Functional Requirements
 
-### Performance
-- **NFR-PERF-1 :** Le tableau de bord initial (liste des produits d'un fournisseur) doit s'afficher en moins de 3 secondes pour un jeu de données contenant jusqu'à 10 000 lignes.
-- **NFR-PERF-2 :** Les modifications de gamme "en ligne" (inline editing) par l'Acheteur doivent être répercutées visuellement dans l'interface en moins de 100 millisecondes (ressenti immédiat).
-- **NFR-PERF-3 :** Les réponses de l'IA (via OpenRouter) suite à une demande d'analyse de gamme doivent s'afficher en moins de 10 secondes.
+### Performance & UX
 
-### Security
-- **NFR-SEC-1 :** L'authentification de l'Acheteur nécessite des mots de passe forts (minimum 12 caractères, incluant majuscules, minuscules, chiffres, caractères spéciaux).
-- **NFR-SEC-2 :** Les clés de l'API OpenRouter et les identifiants de la base de données PostgreSQL ne doivent jamais être exposés côté client (SPA) et doivent être gardés exclusivement côté serveur via des variables d'environnement.
-- **NFR-SEC-3 :** L'ensemble du trafic entre le client et le serveur doit utiliser une connexion sécurisée (HTTPS/TLS 1.2 minimum).
+- **Fluidité Grille :** Réponse au défilement et filtrage < 100ms.
+- **Réactivité Bulk :** Application des changements en masse < 200ms côté client.
+- **Vitesse IA :** Retour des propositions IA en moins de 10 secondes.
 
-### Integration & Reliability
-- **NFR-INT-1 :** Le fichier d'export Excel produit *doit* respecter strictement l'encodage (ex: UTF-8) et le nommage de colonnes (sans coquille) imposés par les contraintes du logiciel cible.
-- **NFR-REL-1 :** Le système de `Snapshot` (FR14) doit garantir que lors d'un crash du navigateur ou d'une perte réseau, l'utilisateur ne perde que les actions de sa session active (non validées), sans altération des états historiques.
+### Intégration & Sortie
+
+- **Fiabilité Export :** Traitement sans échec jusqu'à 10 000 lignes de produits.
+- **Intégrité :** Respect strict des types de données (GTIN/Codein) pour l'interopérabilité.
+
+### Sécurité & Infrastructure
+
+- **Rôles :** Distinction entre 'Admin' (gestion quotas/nomenclatures) et 'Acheteur' (arbitrage).
+- **Secret Management :** Clés API et Database URL conservées exclusivement côté serveur.
+- **Déploiement :** Environnement conteneurisé Docker et optimisation pour Google Chrome.

src/features/grid/api/get-product-rows.ts

@@ -40,7 +40,7 @@ export async function getProductRows(input: GetProductRowsInput): Promise<Produc
     // ... (allowedPeriods calculation remains the same)
     const now = new Date();
     const allowedPeriods = new Set<string>();
-    for (let i = 12; i >= 1; i--) {
+    for (let i = 12; i >= 0; i--) { // i >= 0 au lieu de 1 pour inclure le mois en cours
         const d = new Date(now.getFullYear(), now.getMonth() - i, 1);
         allowedPeriods.add(`${d.getFullYear()}${String(d.getMonth() + 1).padStart(2, "0")}`);
     }

src/features/grid/components/grid-filter-bar.tsx

@@ -1,7 +1,7 @@
 "use client";
 
 import React, { useMemo } from "react";
-import { Search, X, ChevronDown } from "lucide-react";
+import { Search, X, ChevronDown, RotateCw } from "lucide-react";
 import { useGridStore } from "@/features/grid/store/use-grid-store";
 import { GammeCode } from "@/types/grid";
 import { cn } from "@/lib/utils";
@@ -29,6 +29,7 @@ export function GridFilterBar({ fournisseurs, magasins, nomenclature }: GridFilt
     const { filters, setFilter, rows, draftChanges } = useGridStore();
     const router = useRouter();
     const searchParams = useSearchParams();
+    const [isRefreshing, setIsRefreshing] = React.useState(false);
 
     // Compute dynamic counts and present Gammes
     const { gammeCounts, activeGammes } = React.useMemo(() => {
@@ -79,8 +80,29 @@ export function GridFilterBar({ fournisseurs, magasins, nomenclature }: GridFilt
         router.push(`/grid?${params.toString()}`);
     };
 
+    const handleRefresh = () => {
+        setIsRefreshing(true);
+        router.refresh();
+        // Visual feedback delay
+        setTimeout(() => setIsRefreshing(false), 800);
+    };
+
     return (
         <div className="flex items-center gap-3 flex-wrap">
+            {/* Refresh Button */}
+            <button
+                onClick={handleRefresh}
+                title="Rafraîchir les données SQL"
+                className={cn(
+                    "flex items-center justify-center w-9 h-9 rounded-lg transition-all",
+                    "bg-[var(--bg-elevated)] border border-[var(--border)]",
+                    "hover:bg-[var(--bg-surface)] hover:text-emerald-500",
+                    isRefreshing && "opacity-50"
+                )}
+            >
+                <RotateCw className={cn("w-4 h-4", isRefreshing && "animate-spin")} />
+            </button>
+
             {/* Supplier Selector */}
             <SupplierCombobox
                 fournisseurs={fournisseurs}

task.md

@@ -4,37 +4,20 @@ Create a PRD for a retail analytics application. The app will manage product col
 
 # Current Focus
 
-Follow the `/create-prd` workflow to generate the PRD.
+# Current Focus
 
-# Master Plan
+Ajout d'un bouton de rafraîchissement des données dans la barre de filtres.
 
-- [x] Analyze the user's request for the retail application
-- [x] Locate and load the `/create-prd` workflow instructions
-- [x] Draft the initial PRD based on the workflow and user input
-- [ ] Review and refine the PRD with the user
+- [x] Étape 11 : Polissage final et validation du PRD
+- [x] PRD Finalisé et prêt pour la suite (Architecture/UX)
+- [x] Ajout du bouton de rafraîchissement SQL dans l'UI
 
 # Progress Log
 
-- User provided initial requirements for the retail analytics app.
-- Located the `workflow-create-prd.md` file. Reading instructions now.
-- Initialized `prd.md` workspace and prepared to move to Project Discovery.
-- User selected 'C'. Proceeding to Step 2: Project Discovery.
-- Classified project as Retail Analytics Web App (Medium complexity, Greenfield). User chose to continue. Proceeding to Step 2b: Product Vision.
-- Discovered product vision: Optimizing top-performing product collections while keeping essential complementary items, using clear statistics and a store-specific A/B/C classification system.
-- User selected [P] to enter Party Mode. Running collaborative brainstorming.
-- User clarified: Multi-supplier filter is needed. User sets the capacity (e.g. 400 refs for Gamme A). Gamme Z is for discontinued items.
-- Finalized vision constraints: Analyze both stores globally to maximize intelligence. Export Gamme Z (and others) via an Excel template to integrate directly into the existing store management software. Moved to Step 2c.
-- Drafted Executive Summary. User approved. Appending to PRD and proceeding to Step 3: Success Criteria.
-- Discussing Success Criteria and M.V.P scope with the user.
-- User defined success: Clear tabular view (Qty/CA/Margin/month), AI sorting assistance, overall CA/Margin increase, and easy manual override for gammes. Drafting Success section.
-- User clarified: Export must include ALL changed gammes (if any), not just Gamme Z. Appended Success Criteria to PRD. Proceeding to Step 4: User Journey Mapping.
-- Identifying personas and drafting their journeys in the application.
-- User clarified: Single persona ('Acheteur' for both stores), usage is episodic (2-3 times a year per supplier collection change). Drafting journeys for PRD.
-- User selected [P] for Step 4. Running Party Mode to enrich the Acheteur journey.
-- Finalized User Journeys: Added scoring system (volume vs margin), side-by-side range comparisons, and historic evolution views. Appending to PRD and moving to Step 5.
-- Evaluating Domain Requirements (Step 5). The project is Medium complexity in Retail Analytics.
-- User opted to focus on core logic (traffic-driving items vs margin-driving items) and chose to Continue (skip formal Step 5). Moving directly to Step 6: Innovation Focus.
-- Evaluating Innovation Focus (Step 6). Checking for signals of genuine differentiation.
-- Appended Innovation logic (Tactical Speed & Zero-Learning UX). Starting Step 7: Project Type Deep Dive.
-- Loaded project-types.csv. Asking user technical discovery questions for a Web Application (SPA, Browser support, Real-time needs).
-- User confirmed: SPA, Chrome only, Real-Time data, No SEO needed. Appending to PRD.
+- Correction du bug SQL (filtre 12 mois) effectuée et validée par Michael.
+- Synchronisation du dépôt local (108 commits récupérés de origin/main).
+- Exécution du workflow /create-prd (Étapes 8 à 12).
+- Synthèse de 22 Functional Requirements (Étape 9) et définition des NFR (Étape 10).
+- Polissage complet du document pour éliminer les redondances (Étape 11).
+- PRD archivé dans `prd.md` et prêt pour validation de l'implémentation.
+- Début de l'implémentation du bouton de rafraîchissement SQL (demande Michael).