# Comparaison des Styles Architecturaux - BricoLoc

**Version** : 1.0  
**Date** : 31 Octobre 2025  
**Projet** : BricoLoc - Migration Architecturale

---

## Contexte

Ce document compare les **3 styles architecturaux** évalués pour le projet BricoLoc :

1. **Architecture Monolithique** (Application Actuelle)
2. **Architecture Microservices** (Choix Retenu)
3. **Architecture Serverless** (Alternative Considérée)

---

## 1. Architecture Monolithique

### 1.1 Description

Architecture de l'**application legacy actuelle** BricoLoc.

```mermaid
graph TB
    subgraph "Monolithic Application"
        UI[UI Layer<br/>EJS Templates]
        Business[Business Logic Layer<br/>Routes + Controllers]
        Data[Data Access Layer<br/>SQLite]
    end
    
    Client --> UI
    UI --> Business
    Business --> Data
    Data --> DB[(SQLite DB)]
```

### 1.2 Caractéristiques

**Structure** :
- Tout le code dans un seul projet
- Base de données SQLite unique
- Déploiement en un seul bloc
- Couplage fort entre composants

**Technologies** :
- **Backend** : Node.js + Express
- **Frontend** : EJS Templates (server-side rendering)
- **Database** : SQLite
- **Deployment** : VM unique

### 1.3 Avantages ✅

| Avantage | Description | Impact |
|----------|-------------|--------|
| **Simplicité** | Structure simple à comprendre | ⭐⭐⭐⭐⭐ |
| **Performance** | Pas de latence réseau entre composants | ⭐⭐⭐⭐ |
| **Transactions** | ACID natif sur toute la base | ⭐⭐⭐⭐⭐ |
| **Déploiement Simple** | Un seul artefact à déployer | ⭐⭐⭐⭐ |
| **Debugging** | Debugging simple (single process) | ⭐⭐⭐⭐⭐ |
| **Coût** | Infrastructure minimale | ⭐⭐⭐⭐⭐ |

### 1.4 Inconvénients ❌

| Inconvénient | Description | Impact |
|--------------|-------------|--------|
| **Scalabilité** | Impossible de scaler par fonctionnalité | ⭐⭐⭐⭐⭐ |
| **Maintenabilité** | Code spaghetti, couplage fort | ⭐⭐⭐⭐⭐ |
| **Technologie** | Bloqué sur SQLite, stack monolithique | ⭐⭐⭐⭐ |
| **Déploiement** | Redéploiement complet pour chaque changement | ⭐⭐⭐⭐ |
| **Résilience** | Single point of failure | ⭐⭐⭐⭐⭐ |
| **Innovation** | Difficile d'adopter de nouvelles technos | ⭐⭐⭐⭐ |

### 1.5 Évaluation Globale

| Critère | Note | Commentaire |
|---------|------|-------------|
| **Maintenabilité** | 2/10 | Code legacy difficile à maintenir |
| **Scalabilité** | 2/10 | Scalabilité verticale uniquement |
| **Performance** | 6/10 | Correcte pour petit trafic |
| **Fiabilité** | 3/10 | SPOF, pas de redondance |
| **Sécurité** | 4/10 | Vulnérabilités connues (SQL injection) |
| **Coût** | 9/10 | Infrastructure minimale |
| **Time to Market** | 3/10 | Modifications longues et risquées |

**Score Total** : **29/70** (41%)

---

## 2. Architecture Microservices (Choix Retenu) ✨

### 2.1 Description

Architecture **moderne hybride** avec 6 microservices autonomes.

```mermaid
graph TB
    subgraph "Frontend"
        NextJS[Next.js 14<br/>App Router]
    end
    
    subgraph "Microservices"
        Auth[Auth Service]
        Catalogue[Catalogue Service]
        Reservation[Reservation Service]
        Inventory[Inventory Service]
        Payment[Payment Service]
        Notification[Notification Service]
    end
    
    subgraph "Infrastructure"
        Supabase[(Supabase<br/>PostgreSQL)]
        Storage[Supabase Storage]
        Realtime[Realtime]
    end
    
    NextJS --> Auth
    NextJS --> Catalogue
    NextJS --> Reservation
    NextJS --> Inventory
    NextJS --> Payment
    NextJS --> Notification
    
    Auth --> Supabase
    Catalogue --> Supabase
    Reservation --> Supabase
    Inventory --> Supabase
    Payment --> Supabase
    Notification --> Supabase
    
    Catalogue --> Storage
    Notification --> Realtime
```

### 2.2 Caractéristiques

**Structure** :
- 6 services autonomes avec bounded contexts
- Clean Architecture (3 couches) par service
- Base de données partagée (Supabase PostgreSQL)
- Communication REST + Event Bus

**Technologies** :
- **Frontend** : Next.js 14, React 18, TypeScript
- **Backend** : Next.js API Routes (serverless)
- **Database** : Supabase (PostgreSQL)
- **Auth** : Supabase Auth
- **Deployment** : Vercel Edge Network

### 2.3 Avantages ✅

| Avantage | Description | Impact |
|----------|-------------|--------|
| **Modularité** | Services autonomes, bounded contexts clairs | ⭐⭐⭐⭐⭐ |
| **Scalabilité** | Scale indépendamment par service | ⭐⭐⭐⭐⭐ |
| **Maintenabilité** | Code organisé, Clean Architecture | ⭐⭐⭐⭐⭐ |
| **Résilience** | Isolation des pannes | ⭐⭐⭐⭐ |
| **Innovation** | Stack moderne (Next.js 14, React 19) | ⭐⭐⭐⭐⭐ |
| **Team Autonomy** | Équipes peuvent travailler indépendamment | ⭐⭐⭐⭐ |
| **Testabilité** | Tests isolés par service | ⭐⭐⭐⭐⭐ |
| **Performance** | Serverless auto-scale, CDN edge | ⭐⭐⭐⭐⭐ |

### 2.4 Inconvénients ❌

| Inconvénient | Description | Impact |
|--------------|-------------|--------|
| **Complexité** | Plus de services à gérer | ⭐⭐⭐ |
| **Latence** | Calls inter-services (REST) | ⭐⭐ |
| **Transactions** | Transactions distribuées complexes | ⭐⭐⭐ |
| **Debugging** | Debugging distribué plus complexe | ⭐⭐⭐ |
| **Coût** | Infrastructure plus coûteuse | ⭐⭐ |

### 2.5 Évaluation Globale

| Critère | Note | Commentaire |
|---------|------|-------------|
| **Maintenabilité** | 9/10 | Clean Architecture, TypeScript strict |
| **Scalabilité** | 10/10 | Serverless auto-scale illimité |
| **Performance** | 9/10 | Edge CDN, optimisations Next.js |
| **Fiabilité** | 8/10 | Isolation des pannes, retry logic |
| **Sécurité** | 9/10 | RLS, JWT, HTTPS, CSP |
| **Coût** | 7/10 | Gratuit phase MVP, scale avec usage |
| **Time to Market** | 8/10 | Développement parallèle possible |

**Score Total** : **60/70** (86%) ✨

---

## 3. Architecture Serverless Pure

### 3.1 Description

Architecture **100% serverless** avec FaaS (Functions as a Service).

```mermaid
graph TB
    subgraph "Frontend"
        StaticSite[Static Site<br/>React SPA]
    end
    
    subgraph "Backend Functions"
        F1[Auth Function]
        F2[Catalogue Function]
        F3[Reservation Function]
        F4[Inventory Function]
        F5[Payment Function]
        F6[Notification Function]
    end
    
    subgraph "Services"
        API[API Gateway]
        DB[(Managed DB)]
        Queue[Message Queue]
        Storage[Object Storage]
    end
    
    StaticSite --> API
    API --> F1
    API --> F2
    API --> F3
    API --> F4
    API --> F5
    API --> F6
    
    F1 --> DB
    F2 --> DB
    F3 --> Queue
    F4 --> Storage
```

### 3.2 Caractéristiques

**Structure** :
- Frontend statique (React SPA)
- Backend = collection de fonctions indépendantes
- Pas de serveur à gérer
- Event-driven architecture

**Technologies Possibles** :
- **Frontend** : React SPA, Vite
- **Backend** : AWS Lambda / Google Cloud Functions
- **Database** : DynamoDB / Firestore
- **Auth** : Auth0 / Firebase Auth
- **Deployment** : AWS / GCP / Azure

### 3.3 Avantages ✅

| Avantage | Description | Impact |
|----------|-------------|--------|
| **Scalabilité Extrême** | Scale automatique illimité | ⭐⭐⭐⭐⭐ |
| **Pay-per-Use** | Coût proportionnel à l'usage | ⭐⭐⭐⭐⭐ |
| **Zero Ops** | Pas de serveur à maintenir | ⭐⭐⭐⭐⭐ |
| **Resilience** | Redondance native cloud provider | ⭐⭐⭐⭐⭐ |
| **Global Deployment** | Multi-région par défaut | ⭐⭐⭐⭐⭐ |

### 3.4 Inconvénients ❌

| Inconvénient | Description | Impact |
|--------------|-------------|--------|
| **Cold Start** | Latence au démarrage des fonctions | ⭐⭐⭐⭐ |
| **Vendor Lock-in** | Dépendance forte au cloud provider | ⭐⭐⭐⭐⭐ |
| **Debugging** | Debugging très complexe | ⭐⭐⭐⭐⭐ |
| **Stateless** | Pas de state partagé | ⭐⭐⭐ |
| **Coût Imprévisible** | Coûts peuvent exploser avec le trafic | ⭐⭐⭐⭐ |
| **Complexité** | Orchestration complexe | ⭐⭐⭐⭐⭐ |
| **Testing** | Tests locaux difficiles | ⭐⭐⭐⭐ |

### 3.5 Évaluation Globale

| Critère | Note | Commentaire |
|---------|------|-------------|
| **Maintenabilité** | 6/10 | Complexité distribuée élevée |
| **Scalabilité** | 10/10 | Scalabilité illimitée |
| **Performance** | 7/10 | Excellent sauf cold starts |
| **Fiabilité** | 9/10 | Redondance native |
| **Sécurité** | 8/10 | Sécurité gérée par provider |
| **Coût** | 6/10 | Imprévisible à grande échelle |
| **Time to Market** | 5/10 | Complexité freine le développement |

**Score Total** : **51/70** (73%)

---

## 4. Comparaison Détaillée

### 4.1 Tableau Comparatif

| Critère | Monolithique | Microservices ✨ | Serverless |
|---------|-------------|------------------|------------|
| **Complexité initiale** | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| **Scalabilité** | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| **Performance** | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| **Maintenabilité** | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| **Testabilité** | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| **Déploiement** | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| **Coût (MVP)** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| **Coût (Scale)** | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| **Résilience** | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| **Innovation** | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| **Learning Curve** | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| **Debugging** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ |

### 4.2 Cas d'Usage Idéaux

#### Monolithique
- ✅ Petite application
- ✅ Équipe réduite
- ✅ Budget limité
- ✅ Trafic prévisible
- ❌ BricoLoc (legacy, non maintainable)

#### Microservices ✨
- ✅ Application moyenne à grande
- ✅ Équipes multiples
- ✅ Besoin de scalabilité
- ✅ Évolution rapide
- ✅ **BricoLoc - CHOIX OPTIMAL**

#### Serverless
- ✅ Trafic très variable (spikes)
- ✅ Event-driven workflows
- ✅ Budget pay-per-use strict
- ✅ Pas d'expertise DevOps
- ❌ BricoLoc (trop complexe pour le projet)

---

## 5. Décision et Justification

### 5.1 Choix Retenu : **Architecture Microservices Hybride** ✨

### 5.2 Raisons du Choix

#### Raisons Techniques 🔧

1. **Modularité** : Clean Architecture + DDD adapté au domaine métier
2. **Scalabilité** : Serverless auto-scale de Vercel
3. **Performance** : Edge CDN + Server Components Next.js
4. **Maintenabilité** : TypeScript strict, tests, documentation
5. **Innovation** : Stack moderne (Next.js 14, React 19, Supabase)

#### Raisons Métier 💼

1. **Time to Market** : Développement parallèle par service
2. **Coût Optimisé** : Gratuit phase MVP, scale progressif
3. **Fiabilité** : Isolation des pannes, retry logic
4. **Évolutivité** : Ajout de services facile
5. **Recrutement** : Stack attractive (React, TypeScript)

#### Raisons Pédagogiques 📚

1. **Apprentissage** : Patterns modernes (Clean Architecture, DDD)
2. **Démonstration** : Showcase de compétences architecturales
3. **Documentation** : Projet bien documenté
4. **Migration** : Démontre migration Monolith → Microservices

### 5.3 Pourquoi Pas Serverless Pur ?

| Raison | Explication |
|--------|-------------|
| **Complexité** | Trop complexe pour un projet pédagogique |
| **Vendor Lock-in** | Dépendance forte AWS/GCP non souhaitée |
| **Debugging** | Debugging distribué très difficile |
| **Learning Curve** | Courbe d'apprentissage trop raide |
| **Overkill** | Pas besoin de cette échelle pour BricoLoc |

### 5.4 Compromis Choisi

**Architecture Microservices avec Infrastructure Serverless** :
- Bénéfices des microservices (modularité, maintenabilité)
- Bénéfices du serverless (auto-scale, zero-ops)
- Évite les inconvénients du serverless pur (lock-in, complexité)

---

## 6. Migration Path

### 6.1 Étapes de Migration (Monolith → Microservices)

```mermaid
graph LR
    M[Monolith] -->|Semaine 5-6| Auth[Auth Service]
    M -->|Semaine 7| Cat[Catalogue Service]
    M -->|Semaine 8| Res[Reservation Service]
    M -->|Semaine 9| Inv[Inventory Service]
    M -->|Semaine 10| Pay[Payment Service]
    M -->|Semaine 10| Not[Notification Service]
```

### 6.2 Stratégie : **Strangler Fig Pattern**

Remplacement progressif du monolithe par les microservices.

**Phase 1** : Nouveau frontend + Auth Service  
**Phase 2** : Migration domaine par domaine  
**Phase 3** : Décommission du monolithe

---

## 7. Risques et Mitigation

### 7.1 Risques Identifiés

| Risque | Probabilité | Impact | Mitigation |
|--------|-------------|--------|------------|
| Complexité accrue | Haute | Moyen | Documentation, formation |
| Latence réseau | Moyenne | Faible | Cache, CDN edge |
| Transactions distribuées | Haute | Moyen | Saga pattern, idempotence |
| Debugging difficile | Moyenne | Moyen | Logging structuré, tracing |
| Coûts imprévus | Faible | Moyen | Monitoring, alertes budget |

---

## Conclusion

L'**Architecture Microservices Hybride** est le choix optimal pour BricoLoc Moderne car elle offre :

✅ Maintenabilité et évolutivité maximales  
✅ Stack moderne et attractive  
✅ Scalabilité serverless sans complexité pure FaaS  
✅ Coût maîtrisé (gratuit en MVP)  
✅ Projet pédagogique démonstratif

**Score Final** : **60/70 (86%)** vs Monolithe 29/70 (41%)

---

**Prochaine révision** : Semaine 10 (après première release)