Comparatif Architectures

01

Vue d'ensemble — 4 patterns, 4 niveaux

Ces quatre patterns ne sont pas en compétition directe. Ils répondent à des questions différentes à des niveaux différents d'une application. On peut — et souvent on doit — les combiner.

Pattern	Question fondamentale	Niveau
Client-Serveur	Où tourne chaque partie ?	Réseau / système
MVC	Comment organiser le code back ?	Structure du code
MVVM	Comment lier données et interface ?	Interface utilisateur
Hexagonale	Comment isoler la logique métier ?	Architecture profonde

💡

Un projet typique peut combiner les 4 : Client-Serveur pour séparer front et back, MVC ou Hexagonale côté back, MVVM côté front (Vue/React). Les patterns se superposent, ils ne s'excluent pas.

🌐 Client-Serveur — niveau système

Découpe l'application entre machines physiques ou logiques distinctes.

↳ À l'intérieur du serveur :

🎮 MVC

Organise Model / View / Controller

⬡ Hexagonale

Isole le domaine des adapters

↳ À l'intérieur du client (SPA) :

🔄 MVVM — Model · View · ViewModel

Lie les données à l'interface via la réactivité (Vue, React, Angular).

02

Graphe comparatif

MVC

MVVM

Client-Serveur

Hexagonale

Critère	MVC	MVVM	C-S	Hexa
Simplicité	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐
Testabilité	⭐⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐
Scalabilité	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
Réactivité UI	⭐⭐	⭐⭐⭐⭐⭐	⭐	⭐
Isolation métier	⭐⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
Maturité / adoption	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Courbe d'apprent.	Faible	Moyenne	Faible	Élevée

03

Tableau détaillé

Aspect	MVC	MVVM	Client-Serveur	Hexagonale
Inventé par	Reenskaug, 1979	Gossman (Microsoft), 2005	Années 60 (mainframes)	Cockburn, 2005
Composants	Model, View, Controller	Model, View, ViewModel	Client, Serveur, Réseau	Domaine, Application, Infrastructure
Flux des données	Controller → Model → View	Bidirectionnel VM ↔ View	Requête → Réponse	Adapter → UseCase → Entité
Framework typique	Django, Rails, Laravel, Express+EJS	Vue.js, React, Angular	Express, Flask, Nginx	Indépendant du framework
Où appliqué	Côté serveur ou client	Côté client (SPA)	Entre machines / tiers	Côté serveur (domaine)
Taille projet idéale	Petite à moyenne	Moyenne à grande SPA	Tout	Moyenne à grande
Tests unitaires	Bons (Model isolable)	Bons (ViewModel isolable)	Moyens (dépend du réseau)	Excellents (domaine sans deps)
Changer de BDD	Difficile (ORM couplé)	N/A (côté front)	Dépend du tier	Facile (swap adapter)
Manipulation DOM	Manuelle	Automatique (réactivité)	N/A	N/A
Anti-pattern commun	Fat Controller, SQL dans View	Logique dans la View, store partout	Logique dans le client	Logique infra dans le domaine

04 — Choisir

Scénarios concrets — quoi utiliser ?

📰 Site de blog

Pages statiques, formulaire de contact, admin simple. Pas d'interactions complexes côté client.
→ MVC (Flask/Django)

💬 Application de chat

Interface très interactive, messages en temps réel, état complexe côté client, API REST + WebSocket.
→ Client-Serveur + MVVM (Vue/React)

🛒 E-commerce moyen

Catalogue produits, panier, commandes, paiement. Logique métier significative, plusieurs équipes.
→ Client-Serveur + MVC back + MVVM front

🏦 Application bancaire

Règles métier complexes, multiples interfaces (web, mobile, ATM), tests critiques, longue durée de vie.
→ Hexagonale (isoler le domaine)

📊 Dashboard admin

Tableaux de bord avec filtres, tri, pagination. Données chargées via API, interface riche.
→ MVVM (Vue/React + store Pinia/Zustand)

🎮 Jeu multijoueur

Serveur de jeu central, plusieurs clients connectés en simultané, état partagé, temps réel.
→ Client-Serveur + WebSocket

🎓 Projet fin d'études HEH

CRUD + quelques règles métier, deadline courte, équipe de 1-3 personnes.
→ MVC back (Express/Flask) + MVVM front (Vue)

🏥 Logiciel médical

Règles métier critiques, tests obligatoires, évolution sur 10+ ans, plusieurs interfaces.
→ Hexagonale (domaine testé exhaustivement)

05

Arbre de décision

1. As-tu besoin de séparer front-end et back-end sur des machines / ports différents ?

✓ Oui → Client-Serveur obligatoire comme base

✗ Non → app monolithique ou desktop

2. L'interface est-elle interactive (formulaires complexes, mises à jour en temps réel, SPA) ?

✓ Oui → MVVM côté front (Vue / React / Angular)

✗ Non → templates serveur (Jinja, EJS) suffisent

3. Est-ce une application avec des règles métier complexes qui doivent durer longtemps ?

✓ Oui → Hexagonale pour isoler le domaine

✗ Non → MVC suffit

4. As-tu besoin de tester sans base de données ni serveur démarré ?

✓ Oui → Hexagonale (repositories en mémoire)

✗ Non → MVC + mocks suffisent

5. Est-ce un prototype / projet court terme ?

✓ Oui → MVC (moins de fichiers, plus rapide à écrire)

✗ Non → investir dans Hexagonale rentable sur la durée

🎯

Règle pratique pour la HEH : pour un projet de cours ou de fin d'études, commencer par MVC + Client-Serveur. Si la logique métier devient complexe et que les tests deviennent difficiles à écrire, migrer progressivement vers l'hexagonale.

📐

La règle universelle : l'architecture doit servir le projet, pas l'inverse. Un CRUD de 5 tables en hexagonale complète = 3x plus de fichiers pour aucun bénéfice tangible. Un système bancaire en MVC plat = dette technique assurée.

⚠️

Piège fréquent : utiliser MVVM quand MVC avec templates suffit, parce que React/Vue "c'est moderne". Le surcoût en complexité doit être justifié par de vraies interactions côté client.

06

Combinaisons réelles en production

Stack web moderne typique

┌────────────────────────────────────────────┐
│          ARCHITECTURE FINALE               │
│                                            │
│  🌐 Client-Serveur (niveau réseau)         │
│     Client : port 5173  ↔  API : port 3000 │
│                                            │
│  ┌──────────────────┐  ┌─────────────────┐ │
│  │  🔄 MVVM (front)  │  │  🎮 MVC (back)  │ │
│  │  Vue 3 + Pinia    │  │  Express + ORM  │ │
│  │  Components       │  │  Controllers    │ │
│  │  Composables      │  │  Models         │ │
│  └──────────────────┘  └─────────────────┘ │
│           ↕ JSON / REST / WebSocket         │
└────────────────────────────────────────────┘

Stack avancée (domaine complexe)

┌────────────────────────────────────────────┐
│          ARCHITECTURE AVANCÉE              │
│                                            │
│  🌐 Client-Serveur                          │
│  ┌──────────────────┐  ┌─────────────────┐ │
│  │  🔄 MVVM (front)  │  │  ⬡ Hexagonale  │ │
│  │  React + Zustand  │  │  (back)         │ │
│  │                   │  │  Domain         │ │
│  │                   │  │  Application    │ │
│  │                   │  │  Infra/Adapters │ │
│  └──────────────────┘  └─────────────────┘ │
│           ↕ FastAPI (REST) / gRPC           │
└────────────────────────────────────────────┘

Entreprise / Projet	Stack architecture
Netflix	Client-Serveur + microservices + MVVM (React)
Airbnb	Client-Serveur + React (MVVM) + Rails (MVC) back
Application bancaire	Client-Serveur + MVVM front + Hexagonale back
Site vitrine PME	MVC seul (Django/Laravel)
Projet HEH standard	Client-Serveur + MVC (Express) + MVVM (Vue)
App mobile + web	Client-Serveur + Hexagonale back + MVVM × 2 fronts

💡

Pattern le plus fréquent en entreprise 2024 : API REST (Node.js ou Python) organisée en MVC ou hexagonale + front-end SPA en Vue ou React (MVVM) + déployés séparément (Client-Serveur). C'est exactement ce qu'on apprend à la HEH.

07 — Évaluation

Quiz interactif — 15 questions

🧠 Architectures logicielles Question 1 / 15

Comparatifdes Architectures