Objectifs

• Définir ce qu'est un tier logique et le distinguer d'un composant d'infrastructure.
• Décrire les topologies 2-tiers, 3-tiers et 4-tiers.
• Identifier les responsabilités de chaque tier et leurs frontières.
• Comprendre les mécanismes de scalabilité horizontale et verticale.
• Appliquer les patterns de résilience fondamentaux.

1. Évolution historique

Chaque étape de l’évolution des architectures applicatives a été motivée par un besoin concret — et a souvent introduit de nouvelles contraintes :

• Mainframe (années 60–80) : centralisation totale → scalabilité impossible
• Client-Serveur (années 80–90) : calcul réparti → couplage fort client/serveur
• 3-tiers (années 90–2000) : séparation des responsabilités → la couche logique devient un goulot
• SOA (années 2000–10) : réutilisation des services → ESB (enterprise service bus) = single point of failure, complexité
• Microservices (2010+) : déploiement indépendant → complexité opérationnelle, cohérence distribuée
• Cloud native (2015+) : élasticité automatique → vendor lock-in, observabilité complexe

2. Architecture 2-tiers (Client-Serveur)

Le client contient la logique applicative et communique directement avec le serveur de données.

flowchart LR
  subgraph tier1 ["Tier 1 — Client"]
    App["Application desktop"]
  end
  subgraph tier2 ["Tier 2 — Serveur"]
    DB[("Base de données")]
  end
  App -->|"SQL direct"| DB