Pour compléter l'explication précédente, en architecture 3-tiers :
- Une partie application, par exemple un client.
- Une partie logique qui gère les connexions des clients et la couche métier, par exemple un serveur Web.
- Une partie de stockage de données, comme une base de données.
Le client communique avec le serveur Web qui communique avec la base de données. Tu peux avoir plusieurs serveurs Web dans cette architecture ce qui te permettra de faire de la répartition de charge de tes clients.
Dans une architecture 2-tiers, le client communique directement avec le serveur Web qui contient également la base de données. La répartition de charge et la tolérance de panne devient plus contraignante.
Tu peut retrouver aussi l'architecture 3-tiers au sein d'une application :
- Une couche présentation, avec ton interface IHM.
- Une couche métier, qui contiendra la logique de ton application, les algorithmes, etc...
- Une couche acces aux données qui fera le lien entre la couche métier et la base de données. Cette couche contiendra les méthodes d'accès à la base de données.
Tout ceci permet de segmenter l'application, pour faciliter entre autre l'administration, la maintenance et l'évolutivité de ton application. Si demain tu veux passer d'une base Mysql à une base Oracle, tu n'as logiquement qu'a modifier ta couche acces aux donnés, sans toucher aux algorithmes métiers !