1. Contexte
• Client: Qwenta, solution “Menu Maker” pour restaurateurs souhaitant composer et mettre en page leurs menus facilement.
• Équipe: Artdantech, Webgencia, Soufiane (Product Owner), John (Chef de projet Qwenta), UI designer (maquette desktop).
• Livrables: Présentation de veille (≤ 15 slides) + lien vers l’outil de veille, Spécifications techniques (≤ 15 pages) suivant le modèle Webgencia, Planification projet (≤ 15 slides) + lien outil de gestion + Kanban complet, Présentation finale (≤ 20 slides) pour John avec solution technique visuelle et plan de communication.
• Point de départ: maquette desktop, spécifications fonctionnelles, user stories Notion, modèle de specs techniques à compléter.
2. Besoin
• Mettre en place une veille technique pertinente et pérenne, documentée et partageable, pour inspirer les choix de solution.
• Définir et justifier les spécifications techniques du Menu Maker (architecture, modèle de données, sécurité, accessibilité, performance, export).
• Organiser la gestion de projet agile: Kanban, priorisation, estimations, jalons, RACI et plan de communication clair avec Qwenta.
3. Client
• Utilisateurs finaux: restaurateurs (création/édition de menus), éventuellement équipe Qwenta (support/validation), clients des restaurants (consultation publique selon périmètre).
• Parties prenantes: John (chef de projet), Soufiane (PO), Webgencia (conception/planification), UI designer (maquette).
4. Objectifs
4.1 Fonctionnels
• Menu Maker: création, édition et gestion de menus, sections et items (plats, boissons), prix, descriptions, visuels, et styles/ thèmes (selon specs fonctionnelles).
• Prévisualisation responsive et export imprimable/PDF avec mise en page fidèle à la maquette (gabarits).
• Sauvegarde/chargement des menus, duplication, versionning léger et partage (URL publique ou export – selon specs).
• Authentification et gestion basique des droits (restaurateur/équipe Qwenta – selon specs).
4.2 Techniques
• Architecture modulaire front/back, modèle de données documenté, stratégie d’export (print CSS ou service PDF), accessibilité (WCAG AA) et performance.
• Outils projet: veille (Feedly/Notion/Raindrop), gestion (Jira/Trello/Notion), diagrammes (Miro/Excalidraw/diagrams.net), communication (rituels agiles).
5. Contraintes / défis
• Sponsor non technique: vulgarisation nécessaire via schémas/maquettes fonctionnelles.
• Délai court jusqu’à la réunion de validation: prioriser P1, sécuriser un MVP clair, garder des options ouvertes.
• Qualité d’export d’impression et cohérence visuelle multi‑supports (web/print), gestion d’images (poids, DPI, cadrage).
• Sécurité et RGPD si comptes utilisateurs/stockage d’assets (selon périmètre validé).
6. Processus / méthodologie
6.1 Analyse
• Lecture croisée: specs fonctionnelles, maquette desktop (parcours + prototype), user stories Notion (priorités, critères d’acceptation).
• Alignement: mapping US ↔ écrans ↔ composants; identification des P1/P2/P3, dépendances et risques (export, upload images, perf).
• Pré‑cadrage: hypothèses ouvertes à valider en réunion (PDF server‑side vs print CSS, stockage assets, authentification).
6.2 Découpage en tâches (Kanban)
• Cadrage/Design: ateliers de clarification, glossaire, critères “Definition of Ready/Done”, diagrammes (C4, flux, ERD).
• Technique: architecture front, API/back (si nécessaire), modèle de données, stratégie d’export, gestion des médias, accessibilité/perf.
• Produit: builder de menu (UI drag & drop ou édition structurée), templates/thèmes, prévisualisation, sauvegarde/chargement.
• Qualité: scénarios de test (cahier de recette), tests unitaires/éventuels E2E, revues, contrôles A11y/Perf.
• Projet: rituels agiles, plan de communication, jalons, démonstrations.
• Colonnes Kanban: À faire / En cours / À tester / Terminé, avec assignés, acteurs impliqués, estimations, descriptions claires.
6.3 Architecture et logique
• Front (proposition): SPA React + TypeScript, gestion d’état (Redux Toolkit/Zustand), composants UI modulaires, formulaire/validation (React Hook Form + Zod), impression via media queries print.
• Back (si requis): Node.js (Express/Nest), API REST, base de données (PostgreSQL) pour menus/sections/items/thèmes/utilisateurs, stockage d’images (S3 ou équivalent).
• Export:
– Option A (client‑side): styles print CSS avec pagination CSS et génération PDF via “Imprimer en PDF” (simple, rapide, contrôle moyen).
– Option B (server‑side): service headless (Puppeteer) générant un PDF fidèle et stable (meilleur contrôle, plus coûteux).
• Modèle de données (ex.):
– User: { id, name, email, role }
– Menu: { id, title, themeId, createdAt, updatedAt, ownerId }
– Section: { id, menuId, title, order }
– Item: { id, sectionId, name, description, price, tags[], imageUrl, order }
– Theme: { id, name, palette, typography, spacing, layout }
6.4 Choix techniques (justification)
• TypeScript pour fiabilité et maintenabilité du builder; validation via Zod pour sécuriser la structure des données.
• React pour l’édition en direct et la prévisualisation; librairie drag & drop (ex. dnd‑kit) si manipulation d’items nécessaire.
• Export: commencer par print CSS (MVP) puis option server‑side PDF si besoin de qualité/contrôle avancé.
• Accessibilité dès la conception (structure sémantique, focus, contrastes), performances (images optimisées, virtualisation si longues listes).
6.5 Flux principaux
• Onboarding: création de compte/projet menu (selon specs), choix d’un template.
• Édition: ajout/édition d’items, réorganisation, styles/theme, upload d’images avec contraintes (poids/dimensions).
• Prévisualisation: rendu live responsive et mode print; vérification pagination pour l’export.
• Sauvegarde/Partage: enregistrement draft, duplication, export PDF/print, lien public (selon périmètre validé).
6.6 Tests et qualité
• Cahier de recette: scénarios par US (Given/When/Then), critères d’acceptation, cas limites (grandes cartes, prix manquants, images lourdes).
• Qualité: checklist A11y (WCAG AA), performance (Lighthouse), responsive, non‑régression sur builder et export.
• Démonstrations: revues de sprint, feedback de John/Soufiane, mise à jour du backlog/estimation.
7. Analyse
• Le succès du projet repose sur un MVP bien borné: édition structurée, preview fiable et export print de qualité suffisante, avec une trajectoire claire vers un PDF server‑side si nécessaire.
• La justification des choix (simplicité, coût, délais) est clé pour un sponsor non technique; la veille outille ces décisions et prépare les évolutions.
8. Choix techniques
• Veille: Feedly/Raindrop/Notion (sources: a11y, perf, PDF/print CSS, design systems, éditeurs WYSIWYG, drag & drop, SSG/SPA).
• Gestion de projet: Jira/Trello/Notion (Kanban, estimations, dépendances, RACI), Miro/diagrams.net pour schémas.
• Standards: WCAG 2.1 AA, RGPD, bonnes pratiques web perf (images, lazy‑load, bundles).
9. Logique de résolution
• Prendre en main docs → lancer veille et classifier les sources → rédiger specs techniques et justifications → configurer l’outil projet et Kanban → découper/estimer P1 → préparer présentations (veille, planif, solution technique + plan de communication) → répétition et ajustements.
10. Stack utilisée
• Proposition: React + TypeScript, Redux Toolkit/Zustand, React Hook Form + Zod, dnd‑kit (optionnel), CSS modules/SCSS; Node/Express + PostgreSQL + S3 (si back requis); Puppeteer (option PDF avancé).
• Outils: Notion/Jira/Trello (Kanban), Feedly/Raindrop (veille), Miro/Excalidraw (diagrammes), Figma (maquette).
11. Résultat final
• Présentation de veille (≤ 15 slides) avec lien outil configuré, sources triées/commentées/diffusables.
• Spécifications techniques (≤ 15 pages) complètes et argumentées, incluant architecture, modèle de données, options d’export et A11y/Perf/Sécu.
• Planification (≤ 15 slides) avec Kanban consultable (tâches assignées, acteurs, estimations, descriptions), jalons et rituels agiles.
• Présentation finale (≤ 20 slides) claire pour John: schémas de la solution technique + plan de communication projet (cadence, formats, interlocuteurs).