🍔 NexusEats — Développement Back-end & Conception d'API (49 h)

Fil narratif

Pitch : Les apprenants sont recrutés comme Squad Back-end chez NexusEats, une startup FoodTech en hyper-croissance qui doit remplacer son monolithe PHP vieillissant par une architecture API moderne. Le CTO (le formateur) guide l'équipe à travers 11 sprints — chaque sprint correspond à un module du programme et produit un livrable fonctionnel qui s'intègre au précédent.

La plateforme NexusEats permet aux restaurants de publier leurs menus, aux clients de commander et suivre en temps réel, aux livreurs de gérer leurs courses, et aux admins de piloter le tout via un dashboard.

Personnages récurrents

Progression narrative

Sprint 1-2  → Fondations : "On pose les bases de la nouvelle plateforme"
Sprint 3-4  → Solidification : "Les premiers restaurants s'inscrivent, il faut sécuriser"
Sprint 5-7  → Montée en charge : "10 000 commandes/jour, ça tient ?"
Sprint 8-9  → Architecture : "On passe en micro-services, on documente pour les partenaires"
Sprint 10   → Mise en production : "Go live dans 48h"
Sprint 11   → Projet intégrateur : "La démo investisseurs"

Architecture technique

• Runtime : Node.js 20+ / TypeScript strict
• Framework : NestJS 10+
• ORM : Prisma (principal) + démonstration TypeORM
• BDD : PostgreSQL (principal) + Redis (cache/sessions)
• Message Broker : RabbitMQ (+ démonstration Kafka)
• Auth : Passport.js + JWT + OAuth2 (OIDC via Keycloak ou Auth0)
• Tests : Jest + Supertest + Pact
• Observabilité : OpenTelemetry + Prometheus + Grafana
• CI/CD : GitHub Actions + Docker + Docker Compose
• Documentation : Swagger/OpenAPI intégré NestJS

Plan détaillé des 11 sprints

🟢 SPRINT 1 — Paradigmes d'API (5 h)

Brief d'Alex : "On doit choisir les bons protocoles pour chaque besoin de NexusEats. REST pour le CRUD, GraphQL pour le catalogue flexible, WebSocket pour le suivi temps réel."

Objectifs pédagogiques

• Comparer REST, GraphQL, gRPC et WebSocket sur des critères objectifs
• Implémenter un CRUD RESTful complet avec NestJS
• Créer un endpoint GraphQL avec @nestjs/graphql
• Mettre en place un gateway WebSocket pour le temps réel

Contenu théorique (1h30)

• Taxonomie des paradigmes : requête/réponse vs streaming vs pub/sub
• REST : contraintes architecturales (Richardson Maturity Model), HATEOAS
• GraphQL : schéma, résolveurs, N+1 problem, quand l'utiliser vs REST
• gRPC : Protocol Buffers, streaming bidirectionnel, cas d'usage inter-services
• WebSocket & SSE : comparaison, cas d'usage temps réel

Travaux pratiques (3h30)

1. TP1 — API REST Restaurants (1h30)

   • Scaffolding NestJS : nest new nexuseats-api
   • Module restaurants : CRUD complet (Controller, Service, DTOs avec class-validator)
   • Validation des entrées, codes HTTP appropriés, pagination basique
   • 🎯 Livrable : API REST /restaurants fonctionnelle avec 5 routes

2. TP2 — GraphQL Catalogue (1h)

   • Module menu avec @nestjs/graphql (code-first)
   • Résolveurs pour requêtes imbriquées : Restaurant → Menus → Items
   • Comparaison des réponses REST vs GraphQL sur le même jeu de données
   • 🎯 Livrable : Endpoint /graphql avec playground fonctionnel

3. TP3 — WebSocket Suivi de commande (1h)

   • Gateway WebSocket NestJS (@WebSocketGateway)
   • Événements : order:status-update, delivery:location
   • Mini-client HTML pour visualiser les événements en direct
   • 🎯 Livrable : Gateway WS émettant des mises à jour de position

Évaluation sprint

• Quiz interactif : choisir le bon paradigme selon un scénario donné (6 scénarios)
• Défi : implémenter un endpoint gRPC basique entre deux services NestJS (bonus)

🟢 SPRINT 2 — Spécifications contractuelles (3 h)

Brief d'Alex : "Avant d'aller plus loin, on contractualise notre API. Les équipes front et mobile doivent pouvoir travailler en parallèle."

Objectifs pédagogiques

• Générer une documentation OpenAPI 3.x automatiquement depuis NestJS
• Maîtriser les décorateurs Swagger de NestJS
• Appliquer le versioning sémantique à une API
• Valider les payloads avec JSON Schema

Contenu théorique (1h)

• OpenAPI 3.0 vs 3.1 : structure, paths, components, security schemes
• Swagger UI vs Redoc vs Stoplight : choix d'outil
• JSON Schema : $ref, oneOf, discriminator, validation stricte
• Versioning : URI (/v1/), header, media-type — avantages et inconvénients
• Contract-first vs code-first : quand utiliser quoi

Travaux pratiques (2h)

1. TP1 — Swagger NestJS (1h)

   • Installation @nestjs/swagger, décorateurs @ApiTags, @ApiOperation, @ApiResponse
   • Documentation complète du module restaurants du Sprint 1
   • Ajout des schémas de réponse, exemples, groupes de tags
   • Export du fichier openapi.json
   • 🎯 Livrable : Swagger UI accessible sur /api/docs avec toutes les routes documentées

2. TP2 — Versioning & JSON Schema (1h)

   • Activation du versioning NestJS (URI strategy)
   • Création d'un endpoint v1 et v2 avec breaking change contrôlé
   • Validation JSON Schema sur les DTOs avec ajv en complément de class-validator
   • Génération d'un changelog API
   • 🎯 Livrable : API versionnée v1/v2 avec documentation différenciée

Évaluation sprint

• Peer review : échange de specs OpenAPI entre binômes, identification d'incohérences
• Défi : générer un SDK client TypeScript depuis le fichier OpenAPI (bonus)

🟢 SPRINT 3 — Modélisation & Persistance (5 h)

Brief de Mia : "Les premiers restaurants veulent s'inscrire ! On a besoin d'un vrai modèle de données : restaurants, menus, commandes, utilisateurs, livreurs."

Objectifs pédagogiques

• Concevoir un schéma relationnel complet avec Prisma
• Gérer les migrations, seeds et rollbacks
• Implémenter des transactions ACID pour les commandes
• Optimiser les requêtes (eager loading, index, requêtes brutes)

Contenu théorique (1h30)

• ORM vs Query Builder vs Raw SQL : compromis performance/productivité
• Prisma : schema.prisma, relations, types, enums, middleware
• Migrations : stratégie de versioning, rollback, données de seed
• Transactions : ACID, niveaux d'isolation, deadlocks
• Patterns : Repository pattern dans NestJS, Unit of Work
• Démonstration TypeORM : comparaison syntaxique avec Prisma

Travaux pratiques (3h30)

1. TP1 — Schéma Prisma NexusEats (1h30)

   • Modélisation complète : User, Restaurant, Menu, MenuItem, Order, OrderItem, Delivery, Review
   • Relations : 1-N, N-N (tags/catégories), self-relation (réponse à un avis)
   • Enums : OrderStatus, UserRole, DeliveryStatus
   • Seed script : 5 restaurants, 20 items, 3 utilisateurs
   • 🎯 Livrable : BDD PostgreSQL initialisée avec schéma complet + seed

2. TP2 — Repository Pattern & Requêtes avancées (1h)

   • Abstraction Repository dans NestJS (injection de dépendances)
   • Requêtes complexes : filtres dynamiques, tri, recherche full-text
   • Eager loading optimisé : include vs select dans Prisma
   • Index sur les colonnes critiques (restaurant_id sur orders, etc.)
   • 🎯 Livrable : Service OrdersService avec requêtes optimisées

3. TP3 — Transactions & Concurrence (1h)

   • Transaction de création de commande : vérifier stock → créer order → décrémenter stock
   • Gestion des cas d'erreur : rollback si stock insuffisant
   • Simulation de concurrence : deux commandes simultanées sur le dernier item
   • Optimistic locking avec champ version sur MenuItem
   • 🎯 Livrable : Endpoint POST /orders transactionnel et résistant à la concurrence

Évaluation sprint

• Code review croisée : évaluation des choix de modélisation
• Défi : implémenter le soft-delete et l'audit trail sur les entités critiques (bonus)

🔶 SPRINT 4 — Sécurité by Design (5 h)

Brief de Sam : "On ouvre l'API au public la semaine prochaine. Je veux zéro faille. Authentification solide, autorisations granulaires, et conformité OWASP."

Objectifs pédagogiques

• Implémenter l'authentification JWT + refresh tokens avec NestJS/Passport
• Configurer un flux OAuth2/OIDC complet
• Mettre en place RBAC et ABAC avec des guards NestJS
• Appliquer les recommandations OWASP API Security Top 10

Contenu théorique (1h30)

• JWT : structure, algorithmes (RS256 vs HS256), rotation de clés, stockage sécurisé
• OAuth 2.0 : flows (Authorization Code + PKCE, Client Credentials), scopes
• OIDC : ID Token, UserInfo endpoint, providers (Keycloak, Auth0)
• RBAC vs ABAC : matrice de permissions, policies dynamiques
• OWASP API Security Top 10 (2023) : les 10 risques avec exemples NexusEats
• Rate limiting, CORS, helmet, validation d'entrée, protection SSRF

Travaux pratiques (3h30)

1. TP1 — Auth JWT complète (1h30)

   • Module auth NestJS avec Passport (local strategy + JWT strategy)
   • Inscription, connexion, refresh token (rotation), déconnexion (blacklist)
   • Guards : @UseGuards(JwtAuthGuard) sur les routes protégées
   • Hashing bcrypt, validation email, protection brute-force (throttler)
   • 🎯 Livrable : Flux auth complet avec access + refresh tokens

2. TP2 — RBAC & Autorisations (1h)

   • Décorateur custom @Roles('admin', 'restaurant_owner', 'customer', 'driver')
   • Guard RolesGuard avec vérification dans le JWT
   • ABAC : un restaurant owner ne peut modifier que SES restaurants
   • Intercepteur de vérification de propriété des ressources
   • 🎯 Livrable : Matrice RBAC appliquée sur toutes les routes existantes

3. TP3 — Hardening OWASP (1h)

   • Rate limiting avec @nestjs/throttler (par route et par rôle)
   • Helmet + CORS configuré finement
   • Protection BOLA : vérification systématique de ownership
   • Protection mass assignment : DTOs stricts, @Exclude() sur les champs sensibles
   • Audit : log de toutes les actions sensibles (connexion, modification de rôle)
   • 🎯 Livrable : Rapport de conformité OWASP Top 10 pour l'API NexusEats

Évaluation sprint

• Pentest entre équipes : chaque binôme tente d'exploiter l'API d'un autre binôme
• Défi : intégrer un flux OAuth2 avec Keycloak/Auth0 (bonus)

🔶 SPRINT 5 — Gestion des erreurs & Observabilité (4 h)

Brief de Sam : "Le Client Fantôme a fait planter l'API 3 fois hier. On a mis 2 heures à trouver le bug. Plus jamais ça — on instrumente tout."

Objectifs pédagogiques

• Concevoir une stratégie d'erreurs cohérente (codes HTTP, enveloppes, i18n)
• Implémenter des filtres d'exception globaux dans NestJS
• Mettre en place des logs structurés (JSON) avec corrélation de requêtes
• Déployer un pipeline d'observabilité : traces → métriques → alertes

Contenu théorique (1h)

• Taxonomie des erreurs : validation, métier, infrastructure, inattendues
• Enveloppe d'erreur standardisée (RFC 7807 — Problem Details)
• Logs structurés : Winston/Pino, niveaux, correlation ID, PII masking
• Observabilité : les 3 piliers (logs, métriques, traces)
• OpenTelemetry : SDK Node.js, propagation de contexte, exporteurs
• Prometheus : types de métriques (counter, gauge, histogram), convention de nommage

Travaux pratiques (3h)

1. TP1 — Gestion d'erreurs pro (1h)

   • HttpExceptionFilter global : formatage RFC 7807
   • Exceptions métier custom : InsufficientStockException, RestaurantClosedException
   • Intercepteur de logging : request ID, durée, user, route
   • Validation pipe global avec messages d'erreur exploitables
   • 🎯 Livrable : Toutes les erreurs de l'API retournent un format uniforme

2. TP2 — Logs structurés & Traces (1h)

   • Configuration Pino dans NestJS avec nestjs-pino
   • Correlation ID automatique (middleware → header → logs)
   • Intégration OpenTelemetry : auto-instrumentation HTTP + Prisma
   • Export des traces vers Jaeger (Docker)
   • 🎯 Livrable : Trace distribuée visible dans Jaeger pour un flux commande

3. TP3 — Métriques & Dashboard (1h)

   • Exposition Prometheus via @willsoto/nestjs-prometheus
   • Métriques custom : orders_created_total, order_processing_duration_seconds
   • Dashboard Grafana avec Docker Compose (4 panneaux : requêtes/s, latence p95, erreurs, commandes)
   • Alerte : notification si taux d'erreur > 5%
   • 🎯 Livrable : Dashboard Grafana fonctionnel connecté à l'API NexusEats

Évaluation sprint

• Investigation : le formateur injecte 3 bugs, les apprenants doivent les trouver via les traces/logs
• Défi : ajouter un health check endpoint avec détails (DB, Redis, broker) (bonus)

🔶 SPRINT 6 — Tests & Qualité (4 h)

Brief de Jordan : "Zéro fonctionnalité ne passe en staging sans tests. Je veux du vert partout : unitaires, intégration et contrats."

Objectifs pédagogiques

• Écrire des tests unitaires efficaces avec Jest et les patterns NestJS
• Implémenter des tests d'intégration avec base de données de test
• Mettre en place des tests contractuels avec Pact
• Automatiser les tests dans une pipeline CI

Contenu théorique (1h)

• Pyramide des tests : coût, vitesse, confiance — trouver l'équilibre
• Tests unitaires NestJS : Test.createTestingModule(), mocking des providers
• Tests d'intégration : Supertest + BDD de test (Prisma + testcontainers ou BDD séparée)
• Tests contractuels : Pact — consumer-driven contracts, broker
• Mocks : jest.mock(), jest.spyOn(), bibliothèques de fixtures
• Coverage : métrique utile ou vanity metric ? Seuils raisonnables (80%+ lignes)

Travaux pratiques (3h)

1. TP1 — Tests unitaires (1h)

   • Tests du OrdersService : création, annulation, calcul de total
   • Mocking de PrismaService, NotificationService
   • Tests des guards : RolesGuard, JwtAuthGuard
   • Edge cases : commande vide, restaurant fermé, stock à 0
   • 🎯 Livrable : 15+ tests unitaires passants avec > 80% coverage sur les services

2. TP2 — Tests d'intégration (1h)

   • Setup : BDD PostgreSQL de test, beforeAll / afterAll avec seeds
   • Tests Supertest du flux complet : inscription → login → commande → vérification
   • Test de la transaction de commande avec concurrence
   • Test des erreurs : 401, 403, 404, 422 sur les routes protégées
   • 🎯 Livrable : Suite d'intégration du flux commande (8+ tests)

3. TP3 — Tests contractuels & CI (1h)

   • Pact : consumer test (le front attend GET /orders/:id avec un certain format)
   • Provider verification : le back valide qu'il respecte le contrat
   • Pipeline GitHub Actions : lint → unit → integration → contract → coverage report
   • Badge de status dans le README
   • 🎯 Livrable : Pipeline CI verte avec 3 étapes de tests

Évaluation sprint

• Mutation testing : le formateur introduit des mutations, les tests doivent les détecter
• Défi : atteindre 90%+ de coverage sur le module orders (bonus)

🔴 SPRINT 7 — Performance & Scalabilité (4 h)

Brief d'Alex : "On vient de signer un partenariat avec une chaîne de 200 restaurants. L'API doit tenir 10 000 requêtes/minute. Optimisez tout."

Objectifs pédagogiques

• Implémenter la pagination cursor-based pour les grandes collections
• Mettre en place un cache multi-niveaux (HTTP + Redis)
• Profiler et optimiser les endpoints lents
• Définir et exposer des métriques de performance

Contenu théorique (1h)

• Pagination : offset vs cursor-based — pourquoi cursor gagne à l'échelle
• Cache : HTTP (ETag, Cache-Control), applicatif (Redis), invalidation (TTL, event-based)
• Compression : gzip/brotli, quand c'est utile, impact CPU
• Profiling : flamegraphs Node.js, slow query log PostgreSQL, EXPLAIN ANALYZE
• Patterns : connection pooling, lazy loading, batch processing
• Métriques de performance : Apdex, p50/p95/p99, throughput

Travaux pratiques (3h)

1. TP1 — Pagination cursor-based (45min)

   • Refactoring de GET /restaurants et GET /orders en cursor-based
   • Encodage opaque du cursor (base64)
   • Réponse standardisée : { data, cursor, hasMore }
   • Comparaison de performance avec EXPLAIN ANALYZE (offset vs cursor sur 100k lignes)
   • 🎯 Livrable : Pagination cursor sur les 3 principales collections

2. TP2 — Cache Redis (1h)

   • Module cache NestJS avec @nestjs/cache-manager + Redis
   • @CacheKey() et @CacheTTL() sur les endpoints de lecture
   • Invalidation intelligente : un POST/PUT/DELETE invalide le cache concerné
   • Headers HTTP : ETag sur les réponses, Cache-Control adapté par route
   • 🎯 Livrable : Cache Redis fonctionnel avec invalidation sur le module restaurants

3. TP3 — Profiling & Optimisation (1h15)

   • Identification des N+1 queries avec le logging Prisma
   • Optimisation : include ciblé, index composites, requêtes brutes si nécessaire
   • Compression brotli avec @fastify/compress (ou express equivalent)
   • Test de charge avec autocannon ou k6 : avant/après optimisation
   • Dashboard Grafana : ajout des panneaux latence p95 et throughput
   • 🎯 Livrable : Rapport de performance avant/après avec gains chiffrés

Évaluation sprint

• Challenge perf : quel binôme obtient la meilleure latence p95 sous charge ?
• Défi : implémenter un cache de second niveau avec stale-while-revalidate (bonus)

🔴 SPRINT 8 — Micro-services & Event-driven (5 h)

Brief d'Alex & Mia : "Le monolithe NexusEats commence à craquer. On extrait les notifications et les paiements en services séparés, reliés par un broker de messages."

Objectifs pédagogiques

• Décomposer un monolithe en micro-services NestJS
• Implémenter une communication asynchrone via RabbitMQ
• Appliquer les patterns de résilience : retry, circuit breaker, idempotence
• Comprendre les alternatives : Kafka, serverless

Contenu théorique (1h30)

• Monolithe vs micro-services : quand découper, les pièges (distributed monolith)
• Communication : synchrone (HTTP, gRPC) vs asynchrone (message broker)
• RabbitMQ : exchanges, queues, bindings, acknowledgments, dead-letter queues
• Kafka : topics, partitions, consumer groups — comparaison avec RabbitMQ
• Patterns de résilience : retry avec backoff exponentiel, circuit breaker, bulkhead
• Idempotence : clé d'idempotence, déduplication, exactly-once semantics
• Saga pattern : orchestration vs chorégraphie pour les transactions distribuées
• Serverless : FaaS (AWS Lambda, Cloud Functions), quand c'est pertinent

Travaux pratiques (3h30)

1. TP1 — Extraction du service Notifications (1h30)

   • Nouveau projet NestJS : nexuseats-notifications
   • Communication via @nestjs/microservices + RabbitMQ (Docker)
   • Événements : order.created → email de confirmation, order.delivered → email + push
   • Dead-letter queue pour les messages en échec
   • 🎯 Livrable : Service notifications autonome consommant les événements de commande

2. TP2 — Service Paiement fictif (1h)

   • Service nexuseats-payments avec API interne
   • Flux : API principale → event payment.requested → service paiement → event payment.confirmed
   • Idempotence : clé unique par commande, rejet des doublons
   • Simulation de panne : le service paiement crash → dead-letter → retry automatique
   • 🎯 Livrable : Flux de paiement asynchrone avec gestion des échecs

3. TP3 — Résilience & Circuit Breaker (1h)

   • Implémentation circuit breaker avec opossum sur les appels inter-services
   • États : closed → open → half-open, avec métriques
   • Retry avec backoff exponentiel sur les appels HTTP inter-services
   • Test de résilience : couper un service, observer le comportement
   • Démonstration Kafka : même flux avec Kafka au lieu de RabbitMQ (comparaison)
   • 🎯 Livrable : Communication inter-services résiliente avec circuit breaker

Évaluation sprint

• Chaos engineering light : le formateur coupe des services aléatoirement, l'API doit survivre
• Défi : implémenter un saga orchestré pour le flux commande-paiement-livraison (bonus)

🟢 SPRINT 9 — Documentation & Portail développeur (2 h)

Brief de Mia : "On ouvre notre API aux partenaires externes (agrégateurs de livraison). Il nous faut un portail développeur irréprochable."

Objectifs pédagogiques

• Générer une documentation exhaustive et maintenable automatiquement
• Créer un portail développeur avec sandbox et exemples
• Définir une politique de versioning et de dépréciation

Contenu théorique (30min)

• Documentation as Code : génération depuis les décorateurs NestJS
• Portail développeur : DX (Developer Experience), onboarding en < 5 min
• Sandbox / Try-it : Swagger UI, Postman collections, mock server
• Politique de dépréciation : sunset header, timeline, migration guide
• Exemples inspirants : Stripe, Twilio, GitHub API docs

Travaux pratiques (1h30)

1. TP1 — Documentation enrichie (45min)

   • Enrichissement Swagger : exemples de requêtes/réponses pour chaque endpoint
   • Groupes thématiques : "Restaurants", "Commandes", "Auth", "Admin"
   • Collection Postman générée depuis OpenAPI + variables d'environnement
   • 🎯 Livrable : Documentation Swagger complète avec exemples + collection Postman

2. TP2 — Portail & Politique de dépréciation (45min)

   • Page de démarrage rapide (Getting Started) en Markdown
   • Guide d'authentification avec exemples cURL, JavaScript, Python
   • Endpoint de dépréciation : header Sunset, Deprecation, réponse enrichie
   • Changelog automatisé depuis les commits conventionnels
   • 🎯 Livrable : Guide développeur complet + politique de dépréciation appliquée

Évaluation sprint

• Test utilisateur : un apprenant doit intégrer l'API d'un autre en utilisant uniquement sa documentation
• Défi : déployer un portail Redoc standalone (bonus)

🔴 SPRINT 10 — Déploiement continu (4 h)

Brief de Sam : "Go live dans 48h. Je veux un pipeline béton : conteneurs, multi-environnements, et zéro downtime."

Objectifs pédagogiques

• Conteneuriser l'application NestJS avec Docker (multi-stage build)
• Orchestrer les services avec Docker Compose (dev) et préparer la prod
• Construire un pipeline CI/CD multi-environnements avec GitHub Actions
• Implémenter une stratégie de déploiement blue-green ou canary

Contenu théorique (1h)

• Docker : multi-stage build, optimisation de la taille d'image, sécurité (non-root)
• Docker Compose : orchestration des services (API + DB + Redis + RabbitMQ + monitoring)
• Pipeline CI/CD : stages (build, test, deploy), environnements (dev, staging, prod)
• Stratégies de déploiement : rolling update, blue-green, canary — trade-offs
• Infrastructure as Code : introduction à Terraform / Pulumi (démonstration)
• Secrets management : GitHub Secrets, .env, vault

Travaux pratiques (3h)

1. TP1 — Conteneurisation (1h)

   • Dockerfile multi-stage : build → production (image < 200MB)
   • .dockerignore optimisé
   • Docker Compose complet : api, postgres, redis, rabbitmq, jaeger, grafana, prometheus
   • Health checks Docker sur tous les services
   • 🎯 Livrable : docker compose up lance l'intégralité de NexusEats

2. TP2 — Pipeline CI/CD (1h)

   • GitHub Actions : workflow multi-jobs
     • Job 1 : Lint + Build
     • Job 2 : Tests unitaires + intégration (service containers PostgreSQL + Redis)
     • Job 3 : Build & push de l'image Docker
     • Job 4 : Deploy staging (si branche develop)
     • Job 5 : Deploy production (si tag v*, avec approbation manuelle)
   • Matrice de tests Node 18/20
   • Cache des node_modules et des layers Docker
   • 🎯 Livrable : Pipeline CI/CD complète sur GitHub Actions

3. TP3 — Stratégie Blue-Green (1h)

   • Simulation blue-green avec Docker Compose et Nginx comme reverse proxy
   • Déploiement sans downtime : basculement du trafic blue → green
   • Rollback automatique si health check échoue
   • Smoke tests post-déploiement
   • 🎯 Livrable : Déploiement blue-green fonctionnel avec rollback

Évaluation sprint

• Simulation de release : les apprenants déploient une nouvelle version en conditions réelles
• Défi : implémenter un déploiement canary avec pourcentage de trafic progressif (bonus)

🏆 SPRINT 11 — Projet intégrateur PWA "La Démo Investisseurs" (8 h)

Brief de toute l'équipe : "Les investisseurs arrivent vendredi. La plateforme NexusEats doit être complète, performante et impressionnante. C'est le moment de tout assembler."

Objectifs pédagogiques

• Intégrer tous les concepts des sprints 1-10 dans une application complète
• Connecter le back-end API au front-end PWA (réalisé dans le module front)
• Démontrer la maîtrise de bout en bout : conception → développement → déploiement → monitoring

Organisation (8h)

Fonctionnalités attendues (checklist)

• [ ] Authentification : JWT + refresh token + OAuth2 social login
• [ ] Catalogue : REST restaurants + GraphQL menus avec recherche et filtres
• [ ] Commande : flux transactionnel complet (panier → paiement fictif → confirmation)
• [ ] Temps réel : suivi de livraison via WebSocket (position livreur sur carte)
• [ ] Dashboard admin : statistiques commandes, restaurants, revenus (GraphQL)
• [ ] Notifications : micro-service asynchrone (email confirmation de commande)
• [ ] Sécurité : RBAC 4 rôles, rate limiting, conformité OWASP
• [ ] Observabilité : dashboard Grafana avec métriques métier + techniques
• [ ] Documentation : Swagger complet + guide Getting Started
• [ ] CI/CD : pipeline GitHub Actions → staging → production
• [ ] Tests : couverture > 70% + tests d'intégration du flux principal

Grille d'évaluation

Récapitulatif des heures

Prérequis techniques

• Node.js 20+, npm/pnpm
• Docker Desktop
• VS Code avec extensions : ESLint, Prisma, NestJS Snippets, Thunder Client
• Compte GitHub (pour CI/CD)
• PostgreSQL (via Docker)
• Postman ou Insomnia

Livrables cumulatifs

Chaque sprint produit un incrément fonctionnel. À la fin du sprint 10, les apprenants disposent d'une plateforme NexusEats complète prête pour le projet intégrateur du sprint 11 :

• API REST + GraphQL documentée et sécurisée
• 3 micro-services communicant via RabbitMQ
• Temps réel WebSocket
• Pipeline CI/CD déployant sur 3 environnements
• Stack d'observabilité complète (logs + traces + métriques)
• Suite de tests automatisés (unitaires + intégration + contractuels)

PostgreSQL Confirmé — Optimisation & Performance

Durée : 3 jours (18 heures) | Niveau : Confirmé (Application)

Objectif : Approfondir les connaissances sur PostgreSQL pour maîtriser les outils et techniques permettant d'optimiser les performances des bases de données et applications associées.

Compétences visées

• Diagnostiquer les performances d'un serveur PostgreSQL
• Identifier et résoudre les goulots d'étranglement dans les applications et requêtes SQL
• Optimiser les schémas relationnels et configurer les paramètres serveur pour des performances accrues

Fil rouge : PerfGuard

Tout au long de la formation, vous construisez PerfGuard, une plateforme de diagnostic et d'optimisation des performances d'une base PostgreSQL en production simulée. Chaque module ajoute une brique : monitoring, analyse de requêtes, restructuration de schéma, tuning serveur.

Prérequis : Bonne maîtrise de PostgreSQL (requêtes, transactions, administration de base). Connaissance des concepts relationnels et des langages SQL.