Architecture Moderne des Applications Web

Une présentation en 7 slides

🏛️ Évolution de l'Architecture Web

De la monolithique à la distribuée

timeline
    title Évolution des architectures web
    1995 : Pages HTML statiques
    2000 : Applications monolithiques
    2010 : SOA (Service-Oriented Architecture)
    2015 : Microservices
    2020 : Serverless & Edge Computing
    2025 : AI-Native Architecture

L'architecture d'une application détermine sa capacité à évoluer, à se maintenir et à résister aux pannes.

🧱 Architecture Monolithique

Avantages & Inconvénients

Aspect	✅ Avantages	❌ Inconvénients
Développement	Simple, rapide à démarrer	Couplage fort, difficile à tester
Déploiement	Un seul artefact	Tout redéployer pour une petite modif
Performance	Appels en mémoire	Scaling vertical uniquement
Maintenance	Base de code unique	Complexité croissante

graph TB
    Client --> Monolithe
    Monolithe --> DB[(Base de données)]
    Monolithe --> Cache[(Redis)]
    
    subgraph Monolithe
        UI[UI Layer]
        BL[Business Logic]
        DAL[Data Access Layer]
    end

⚡ Microservices

Décomposition par domaine métier

graph TB
    Client --> API_GW[API Gateway]
    API_GW --> Auth[Auth Service]
    API_GW --> Users[User Service]
    API_GW --> Orders[Order Service]
    API_GW --> Notif[Notification Service]
    
    Auth --> Auth_DB[(Auth DB)]
    Users --> Users_DB[(Users DB)]
    Orders --> Orders_DB[(Orders DB)]
    Orders --> MQ[Message Queue]
    MQ --> Notif

Règle des 3 S

Single Responsibility — Un service = un domaine métier
Stateless — Pas d'état entre les requêtes
Scalable — Chaque service scale indépendamment

🌍 Edge Computing & CDN

Architecture moderne avec Next.js

typescript

// Middleware s'exécutant à la Edge (Vercel Edge Network)
export function middleware(request: NextRequest) {
  const country = request.geo?.country ?? 'FR';
  
  // Redirection géographique
  if (country !== 'FR') {
    return NextResponse.redirect(
      new URL(`/${country.toLowerCase()}/`, request.url)
    );
  }
}

// Page générée statiquement et distribuée globalement
export const revalidate = 3600; // ISR : revalidation toutes les heures

Avantages :

🌍 Contenu servi depuis le nœud le plus proche
⚡ Latence réduite de 60-80%
🔒 Sécurité renforcée (filtrage à la périphérie)

📊 Métriques de Performance

Core Web Vitals Cibles

pie title Répartition des cas d'usage
    "Contenu statique (SSG)" : 45
    "Contenu dynamique (SSR)" : 30
    "Données temps réel" : 15
    "Interactivité client" : 10

Métrique	Seuil Bon	Seuil Moyen	Seuil Mauvais
LCP (Largest Contentful Paint)	< 2.5s	2.5–4.0s	> 4.0s
INP (Interaction to Next Paint)	< 200ms	200–500ms	> 500ms
CLS (Cumulative Layout Shift)	< 0.1	0.1–0.25	> 0.25

🔐 Sécurité by Design

Defense in Depth

graph LR
    Internet --> WAF[WAF / DDoS Protection]
    WAF --> LB[Load Balancer]
    LB --> MW[Middleware CSP/Rate Limit]
    MW --> App[Application]
    App --> Auth[Authentification]
    Auth --> DB[(Base de données chiffrée)]
    
    style WAF fill:#ef4444,color:#fff
    style MW fill:#f59e0b,color:#fff
    style Auth fill:#10b981,color:#fff
    style DB fill:#6366f1,color:#fff

Checklist implémentée dans ce blog :

✅ Content Security Policy avec nonce
✅ Headers de sécurité (X-Frame-Options, HSTS...)
✅ Validation des slugs (path traversal)
✅ Dépendances auditées (npm audit)
✅ SSG — pas de surface d'attaque serveur exposée

🎯 Comment Choisir son Architecture ?

Arbre de décision

flowchart TD
    A[Nouveau projet ?] --> B{Taille de l'équipe}
    B -->|1-5 devs| C[Monolithe modulaire]
    B -->|5-20 devs| D{Domaines métier distincts ?}
    B -->|20+ devs| E[Microservices]
    D -->|Non| C
    D -->|Oui| F[Modular Monolith → Microservices]
    C --> G{Trafic élevé ?}
    G -->|Non| H[✅ Monolithe + Cache]
    G -->|Oui| I[✅ Monolithe + Scaling horizontal]
    E --> J[✅ Microservices + Service Mesh]

Recommandation finale

Ne pas sur-architecturer. Commencez simple, mesurez, puis optimisez. La complexité a un coût.

Ressources :