Comprendre l'architecture 3-Tiers

Durée: 6m31s

Date de sortie: 29/08/2025

Un client, un serveur et une base de données, que pourrait-il se passer de mal ? Rien, à part qu'on confonde ça avec le modèle MVC


Notes de l'épisode :

Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage,
je m'appelle Nicolas Bondein-Bernard et aujourd'hui on va parler de l'architecture 3 tiers.
Alors l'architecture 3 tiers c'est simplement un modèle de conception logicielle
qui va séparer une application en trois couches distinctes.
La première des couches c'est la présentation, la deuxième couche c'est la logique métier
et la troisième couche c'est la gestion des données.
C'est un modèle qu'on retrouve très souvent dans le développement web, logiciel et même mobile
puisque on va avoir par exemple un front, un backend et une base de données
où parfois ça va être une application mobile, un serveur et une base de données.
Alors pourquoi est-ce qu'on a cette architecture ?
Tout simplement c'est une évolution des architectures monolithiques et des architectures 2 tiers.
Dans une architecture monolithique en un seul bloc,
toutes les fonctionnalités de l'application et ses dépendances sont intégrées dans un seul programme
et donc ça va rendre la maintenance et l'évolution du système plus difficile.
Imaginez un programme qui va tout gérer et stocker les données directement dans les fichiers du système par exemple.
L'architecture 2 tiers elle va séparer l'application en deux couches,
la présentation et la gestion des données.
Alors c'est mieux mais c'est une approche qui peut encore poser des problèmes
notamment de couplage entre les composants ou parfois même de sécurité en fonction du projet.
L'architecture 3 tiers résout ses problèmes en introduisant une couche intermédiaire
qui est dédiée à la logique métier, ce qui va permettre de mieux organiser le code
et de faciliter les modifications, les extensions etc.
En général, comme je l'ai dit au début, on va parler de clients, de serveurs et de base de données.
Alors parfois vous allez entendre parler de clients, d'API, de base de données, frontaine, back end etc.
Mais tout ça, ça désigne la même chose.
Alors c'est quoi ces trois couches de l'architecture et pourquoi est-ce qu'on en a trois exactement ?
Donc d'abord la couche de présentation, elle va servir d'interface utilisateur,
ça va être l'interface utilisateur de votre application,
elle est responsable de l'affichage des données et de gérer les interactions avec l'utilisateur.
Son objectif, normalement son seul objectif, c'est de fournir une expérience utilisateur,
fluide, intuitive au maximum et donc que ce soit facilement utilisable.
Ensuite on a la couche de logique métier, la couche de logique c'est le cœur de l'application
puisque si jamais il n'y a aucune logique métier, ça veut dire que votre application n'est sert à rien.
Elle va contenir les règles, les processus qui vont définir le fonctionnement de l'application.
Son objectif c'est de traiter les données et d'appliquer les règles métier qui correspondent à ce qu'on attend.
Et ensuite, la couche de gestion des données, c'est simplement ce qui est responsable du stockage
et de la récupération des données.
Alors là en termes de technologie, ça peut être des bases données relationnelles, non relationnelles,
ça peut être en partie des fichiers, peut y avoir plein de choses.
Son objectif c'est d'assurer l'intégrité et la sauvegarde et la sécurité des données.
Les avantages, comme j'ai dit de cette architecture, c'est d'abord la modularité,
que ce soit pour le développement, mais aussi les tests et le déploiement qui vont être indépendants pour chaque couche,
la main de nabilité puisque on va réduire les risques d'introduction de bugs pendant les modifications
puisque on va modifier qu'une seule partie à la fois en général au lieu de modifier un monolithe,
tout interagir avec tout.
Évidemment, c'est plus facile de faire évoluer le logiciel puisque, pareil, chaque couche va évoluer de manière indépendante
et la sécurité, en fait, on va pouvoir permettre un meilleur contrôle des accès aux données
et on va pouvoir ajouter des couches de sécurité à chaque moment, donc pour le client, pour le serveur et aussi pour la base données,
que ce soit avec des rôles et la gestion d'accès utilisateur, par exemple, pour la base données,
mais évidemment tout un système de chiffrement, par exemple, côté serveur, pareil d'accès de jetons JWT, de token,
on peut imaginer plein de choses, mais aussi évidemment le filtrage des données pour éviter les injections SQL, les failles XSS, etc.
Alors, souvent, on a un problème, c'est qu'on confond l'architecture 3 tiers et ce qu'on appelle MVC, le modèle vu contrôleur.
Alors, en fait, ces deux architectures et modèles, en fait, ils partagent évidemment des similitudes en termes de séparation des préoccupations,
mais ils sont réellement bien différents. L'architecture 3 tiers, ça se concentre sur la séparation physique des composants d'une application,
comme j'ai dit, en trois couches distinctes, présentation, logique métier et gestion des données.
Cette séparation, elle va permettre de déployer chaque couche sur des serveurs différents, etc.
En revanche, le modèle MVC, c'est ce qu'on appelle un patron de conception logicielle.
Lui, il va séparer un logiciel en trois composants interconnectés, le modèle qui va gérer les données et la logique métier,
la vue qui va gérer l'interface utilisateur et le contrôleur qui va plutôt être la gestion des interactions utilisateurs.
Contrairement à l'architecture 3 tiers, le MVC, il ne va pas nécessiter de séparation physique des composants
et il peut même être implémenté au sein d'un même logiciel, ce qui veut dire que parfois, vous allez avoir un patron de conception qui va être MVC dans votre serveur
et vous allez avoir un autre patron de conception logicielle dans votre client, ça va être MVVM par exemple, etc.
En résumé, les deux approches peuvent être complémentaires.
Avec une architecture 3 tiers, on va utiliser pour structurer les composants à un niveau macro,
tandis que le MVC, on va plutôt l'utiliser pour organiser le code au niveau micro
et on va pouvoir avoir plusieurs patrons de conception au sein d'un même projet global.
J'espère que cet épisode vous aura plu, que vous aurez appris quelque chose.
Je vous donne rendez-vous la semaine prochaine pour un prochain épisode, mais évidemment, pensez à laisser 5 étoiles sur votre application de podcast préférée.
N'hésitez pas même à mettre un avis, à créer un petit texte, ça encourage toujours et ça permet de faire découvrir le podcast à plus de monde.
Et surtout, on vous retrouve sur code tierrigarage.com pour retrouver toutes les nouveautés.
On a un court réacte qui vient de sortir, on a des challenges interactifs.
Bref, venez faire un tour, il y a plein de nouvelles choses.
Je vous donne rendez-vous la semaine prochaine, prenez soin de vous, salut !

Les infos glanées

Je suis une fonctionnalité encore en dévelopement

Signaler une erreur

Code-Garage

Découvrons ensemble des sujets passionnants autour du métier de dev et de la programmation en général !
Tags
Card title

Lien du podcast

[{'term': 'Technology', 'label': None, 'scheme': 'http://www.itunes.com/'}]

Go somewhere