Cadrage et gestion de projet

Menu Maker by Qwenta

Cadrage technique et gestion de projet d’une application web de création de menus pour restaurateurs.

Outils de gestion

Architecture technique proposée

Contexte

Menu Maker est un projet de cadrage et de planification d’une application permettant à des restaurateurs de créer et gérer leurs menus en ligne. L’objectif n’était pas de développer l’application complète, mais de préparer sa réalisation en définissant les besoins, les fonctionnalités, les tâches, les choix techniques et l’organisation du projet.

Objectifs

Analyser le besoin client et le transformer en fonctionnalités.
Rédiger les spécifications techniques et les user stories.
Construire un Kanban et découper le développement en tâches.
Définir les priorités, dépendances et estimations par story points.
Proposer une architecture technique et organiser une veille technologique.

Visuels du projet

Spécifications techniques du projet Menu Maker by Qwenta

Livrables

Kanban technique.
Spécifications techniques.
Présentation destinée au client ou à l’interlocuteur projet.
Veille technologique.

Gestion de projet

Kanban organisé autour de : À faire, En cours, À tester / Valider et Terminé.
Cartes comprenant notamment user story, priorité, epic, story points, sous-tâches, critères de succès, spécifications techniques et dépendances.
Story points utilisés pour estimer une complexité relative, et non une durée exacte.

Flux d’architecture proposé

React / Vite
API Node.js / Express
Prisma ORM
PostgreSQL

Cette architecture est une proposition technique retenue pour l’implémentation future. Les services complémentaires prévus sont Cloudinary pour les images, Puppeteer avec Chromium pour l’export PDF, Brevo pour les e-mails transactionnels, GitHub Actions pour la CI, Vercel pour le front-end et Render pour l’API.

Exemples de spécifications

Catégories

Spécification prévue : POST /api/menus/:menuId/categories, PATCH /api/categories/:id et DELETE /api/categories/:id. Le modèle prévu est Menu 1 → N Category avec un champ position ; le contrôleur devait vérifier que le menu appartient à l’utilisateur authentifié avant modification.

Plats et images

Spécification prévue : Category 1 → N Dish, avec nom, prix, description et image. Le flux d’upload prévu était Multer, une limite de 2 Mo, Cloudinary puis l’enregistrement de l’URL dans PostgreSQL.

Export PDF

Fonctionnalité prévue : GET /api/menus/:id/export/pdf, route protégée. Le flux prévu était React → Express → Prisma → PostgreSQL → template HTML/CSS → Puppeteer / Chromium headless → PDF A4, avec les réponses Content-Type: application/pdf et Content-Disposition: attachment.

Déploiement

Scénario prévu : React / Vite sur Vercel, Node.js / Express sur Render, PostgreSQL avec Prisma, assets Cloudinary, e-mails Brevo et CI GitHub Actions. HTTPS devait être fourni par les plateformes et les variables sensibles placées en variables d’environnement.

Veille technologique

OWASP pour suivre les évolutions de sécurité.
Prisma pour vérifier les choix liés à l’ORM et aux données.
Veille organisée pour comparer les solutions et anticiper la maintenance.

Challenge principal

Transformer un besoin fonctionnel en plan de développement suffisamment précis pour qu’une équipe puisse commencer l’implémentation. Cela implique de relier le besoin utilisateur aux user stories, aux tâches techniques, aux dépendances, à l’architecture et aux critères de validation.

Solution apportée

La solution repose sur un découpage fonctionnel, un Kanban, la priorisation, l’estimation relative, des spécifications détaillées, une architecture cohérente, l’identification des dépendances, des choix de services externes et une veille technologique.

Résultats

Le projet aboutit à une feuille de route technique exploitable pour lancer le développement de Menu Maker, avec une vision claire des fonctionnalités, des dépendances, de l’architecture et des critères de validation.

Améliorations possibles

Implémenter l’application.
Confronter les estimations aux temps réels.
Compléter les tests.
Ajouter un environnement de staging.
Enrichir la documentation API.
Suivre les métriques de production.
Ajuster le backlog à partir des retours utilisateurs.