REPUBLIQUE DU BENIN

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE

SCIENTIFIQUE (MESRS)
****************
UNIVERSITE NATIONALE DES SCIENCES, TECHNIQUE, D’INGENIERIE ET
MATHEMATIQUES
*************

INSTITUT NATIONALE DE SCIENCE ET DE TECHNOLOGIE

INDUSTRIELLE DE LOKOSSA
************

Filière : Génie Electrique et Informatique

Option : Informatique et Télécommunications
ANNéE D’éTuDE : 2ème Année
UE : Clients légers

Architecture client-serveur

Réalisé par : Sous la SUPERVISION DE :

AGOSSOU Samson M. Osias TOSSOU
BOKO Cédric
DJIVOEDO Arsène
do-REGO Marie Julio
LISSANON Jean-Jaurès

Année académique : 2024-2025

 Table des matières
1. Introduction .............................................................................................................................. 2
2. Concept clé de l’architecture client-serveur ............................................................................. 3
2.1. Définition de l'architecture client-serveur ........................................................................ 3
2.2. Modèle de communication (requête-réponse) .................................................................. 3
2.2.1. Requête ..................................................................................................................... 4
2.2.2. Réponse .................................................................................................................... 4
2.2.3. Fonctionnement du modèle requête-réponse............................................................ 4
2.3. Protocoles et standards utilisés ......................................................................................... 5
2.3.1. TCP/IP ...................................................................................................................... 5
2.3.2. HTTP & HTTPS....................................................................................................... 8
2.3.3. DNS ........................................................................................................................ 11
3. Modèles architecturaux........................................................................................................... 13
3.1. Modèle 2-tiers ................................................................................................................ 13
3.1.1. Description et exemples ......................................................................................... 13
3.1.2. Avantages et inconvénients du modèle 2-tiers ....................................................... 15
3.2. Modèle 3-tiers ................................................................................................................ 15
3.2.1. Présentation des couches dans le modèle 3-tiers .................................................... 15
3.2.2. Utilisation typique et bénéfices du modèle 3-tiers ................................................. 17
3.3. Variations avancées ........................................................................................................ 19
3.3.1. Modèle n-tiers : Présentation.................................................................................. 19
3.3.2. Architectures basées sur les micro-services ........................................................... 20
3.4. Comparaison entre les architectures ............................................................................... 21
4. Répartition des tâches et responsabilités ................................................................................ 22
4.1. Côté client : .................................................................................................................... 22
4.2. Côté serveur : ..................................................................................................................... 22
4.3. Exemple d'application illustrant cette répartition : ......................................................... 22
5. Avantages et inconvénients de l'architecture client-serveur ................................................... 23
5.1. Avantages ....................................................................................................................... 23
5.2. Inconvénients ................................................................................................................. 24
6. Conclusion .............................................................................................................................. 25

1
 1. Introduction
L'architecture client-serveur est une pierre angulaire des systèmes informatiques modernes.
Elle repose sur un modèle structuré qui répartit les tâches et responsabilités entre les composants
du système, permettant une communication fluide et efficace. Ce travail explore les concepts
fondamentaux, les modèles architecturaux et la répartition des responsabilités entre le client et le
serveur. Il aborde également les avantages et les limites des différents modèles, notamment le 2-
tiers, le 3-tiers et les architectures avancées basées sur les micro-services, tout en illustrant chaque
aspect par des exemples concrets. Ces éléments visent à mettre en lumière la pertinence et la
diversité des approches dans le développement d'applications fiables et évolutives.

2
 2. Concept clé de l’architecture client-serveur
2.1. Définition de l'architecture client-serveur

L'architecture client/serveur est un modèle informatique fondamental qui régit l'interaction

entre différents dispositifs informatiques connectés en réseau, tels que des ordinateurs, des serveurs
et des périphériques. Elle implique deux acteurs principaux :

o Le client

Le client, actif ou esclave, initie les communications en envoyant une requête vers le serveur.
Ce sont les postes d'où proviennent les demandes. Ils peuvent être individuels ou multiples et sont
actifs dans le processus, initiant les communications en envoyant des requêtes vers le serveur. Il
attend ensuite la réception des réponses pour continuer sa tâche. Un client a accès à un portail
central qui centralise les différentes ressources ou services fournis par le serveur.

o Le serveur

Il répond aux demandes des clients en fournissant la ressource demandée ou en exécutant les
actions spécifiées. Le serveur, considéré comme passif ou maître, se tient prêt à réagir aux
sollicitations des clients. Il traite les demandes reçues et renvoie les informations nécessaires. Ce
dernier peut avoir différentes spécialités, avec la capacité de gérer les demandes de plusieurs clients
en même temps, assurant ainsi une utilisation efficace des ressources réseau : il peut gérer des
applications, modifier des données, stocker des fichiers, piloter des terminaux ou traiter des
courriels.

Dans l’architecture client-serveur, une machine comme un ordinateur physique peut être à la
fois client et serveur. Le fait qu’il envoie ou reçoive les requêtes de services et de ressources
détermine son rôle dans le réseau.

2.2. Modèle de communication (requête-réponse)

Le client et le serveur communique par message (requête-réponse). Une requête représente les
paramètres d’appels, de spécification du service requis. La réponse quant - à elle fait office de
résultat, d’indicateur éventuel d’exécution ou d’erreur.

3
 2.2.1. Requête

Une requête est une demande envoyée par le client (par exemple, un navigateur web ou une
application) au serveur. Cette demande précise les informations ou services dont le client a besoin.
Les éléments constitutifs d'une requête incluent généralement :

o une méthode : (par exemple, GET, POST, PUT en HTTP) qui indique l'action à effectuer.

o Une URL : pour identifier la ressource ou service demandé.

o En-têtes : qui transportent des métadonnées (par exemple, format accepté, authentification,
etc.).

o Un corps (facultatif) : qui contient des données supplémentaires (par exemple, dans une
soumission de formulaire).

2.2.2. Réponse

Une réponse est le message renvoyé par le serveur au client après avoir traité la requête. Elle
contient les informations ou résultats demandés. Les composants typiques d'une réponse incluent :

o Un code de statut : indiquant le résultat du traitement (par exemple, 200 pour succès, 404 pour
ressource non trouvée, etc.).

o En-têtes : transportant des informations sur la réponse (type de contenu, taille, etc.).

o Un corps (facultatif) : contenant les données demandées, comme une page HTML, des fichiers
JSON ou d'autres formats.

2.2.3. Fonctionnement du modèle requête-réponse

a) Initiation par le client :

o Le client envoie une requête au serveur pour demander une action spécifique (exemple :
récupérer une page web ou soumettre un formulaire).

o Cette requête est souvent transmise via un protocole de communication, comme HTTP ou
HTTPS.
4
 b) Traitement par le serveur :

o Le serveur reçoit la requête et l'analyse.

o Il exécute les processus nécessaires (par exemple, effectuer un calcul, interroger une base de
données, etc.).

c) Réponse du serveur :

o Une fois le traitement terminé, le serveur retourne une réponse au client.

o Cette réponse contient généralement les données ou informations demandées (comme une page
web au format HTML ou un fichier).

d) Boucle itérative :

o Ce cycle peut se répéter chaque fois que le client a besoin d'une nouvelle ressource ou d'une
action supplémentaire.

Figure 1: Illustration du mode de communication, [Link]

2.3. Protocoles et standards utilisés

2.3.1. TCP/IP

TCP et IP sont des protocoles distincts qui permettent ensemble de garantir la transmission
effective des données à leur destination prévue au sein d’un réseau. Le protocole IP obtient et

5
définit l’adresse, notamment l’adresse IP, de l’application ou du périphérique auquel les données
doivent être envoyées. Le protocole TCP est ensuite chargé du transport et du routage des données
à travers l’architecture réseau et de s’assurer qu’elles sont livrées à l’application ou au dispositif
de destination que l’IP a défini. Les deux technologies fonctionnant ensemble permettent la
communication entre les dispositifs sur de longues distances, ce qui permet de transférer les
données là où elles doivent aller de la manière la plus efficace possible.

En d’autres termes, l’adresse IP est semblable à un numéro de téléphone attribué à un

smartphone. TCP est la version réseau informatique de la technologie utilisée pour faire sonner le
smartphone et permettre à son utilisateur de parler à la personne qui l’a appelé.

Les deux protocoles sont fréquemment utilisés ensemble et dépendent les uns des autres pour
que les données aient une destination et y parviennent en toute sécurité. C’est pourquoi le processus
est régulièrement appelé TCP/IP. Avec les protocoles de sécurité appropriés en place, la
combinaison du TCP/IP permet aux utilisateurs de suivre un processus sûr et sécurisé lorsqu’ils
doivent déplacer des données entre deux ou plusieurs appareils.

Fonctionnement le protocole TCP (Transmission Control Protocol)/IP

Le modèle TCP/IP est la norme pour la communication sur Internet. Développé par le
Department of Defense des États-Unis, il assure une transmission fiable des données en divisant
les messages en paquets, évitant ainsi de renvoyer l'intégralité du message en cas de problème.
Les paquets empruntent des itinéraires différents en fonction de la disponibilité des chemins et
sont réassemblés automatiquement à leur destination.

Le modèle repose sur une architecture en couches standardisées, permettant aux logiciels
et matériels de suivre un processus uniforme. Les données traversent ces couches, où chaque
couche gère une tâche spécifique, et sont finalement reconstituées dans leur format initial à
destination.

Le protocole TCP, basé sur une connexion stable, garantit la division, la numérotation, et
le réassemblage des paquets, tout en s'assurant que chaque paquet atteint sa destination. Il
intervient également dans la retransmission des paquets abandonnés et le contrôle des flux.

6
 L’envoi d’un courriel via SMTP est un bel exemple ; le serveur divise le message en paquets
à la couche TCP, qui les transmet ensuite à la couche IP pour acheminement au serveur destinataire.
À réception, les paquets sont réassemblés et transmis à la boîte de réception du destinataire.

Le protocole TCP utilise une liaison à trois voies pour établir une connexion entre les
périphériques, synchronisant les paquets avant leur transfert, garantissant ainsi la fiabilité des
communications.

Les 4 couches du modèle TCP/IP

Le modèle TCP/IP définit la manière dont les périphériques doivent transmettre des
données entre eux et facilite la communication sur les réseaux et les grandes distances. Le modèle
décrit la manière dont les données sont échangées et organisées sur les réseaux. Il est divisé en
quatre couches, qui définissent les normes en matière d’échange de données et représentent la
manière dont les données sont traitées et regroupées lorsqu’elles sont transmises entre des
applications, des périphériques et des serveurs.

Les quatre couches du modèle TCP/IP sont les suivantes :

a) Couche liaison de données :

o Gère l'envoi et la réception des données sur un réseau.

o Utilise des dispositifs comme les câbles Ethernet, cartes réseau (NIC) ou réseaux sans fil.
o Définit la manière dont les données sont converties en signaux physiques et transmises.
b) Couche Internet :

o Responsable du routage des paquets de données à travers différents réseaux pour atteindre leur
destination.

o Assure que les paquets suivent des itinéraires disponibles même si le chemin initial est saturé
ou indisponible.

c) Couche transport :
o Assure une communication fiable entre l'émetteur et le récepteur.

o Divise les données en paquets, les numérote et vérifie leur réception correcte.

7
o Gère la retransmission des paquets perdus et contrôle les flux pour éviter la congestion du
réseau.

d) Couche application :

o Interface entre les utilisateurs et le modèle TCP/IP.

o Permet aux applications (emails, messagerie, navigation web) d’échanger des données de
manière standardisée.

Figure 2: Couche du modèle TCP/IP, [Link]

2.3.2. HTTP & HTTPS

Le protocole de transfert hypertexte (HTTP) est un protocole ou un ensemble de règles régissant

la communication client-serveur. Lorsque vous visitez un site Web, votre navigateur envoie une
requête HTTP au serveur Web, qui renvoie une réponse HTTP. Le serveur Web et votre navigateur
échangent des données sous forme de texte brut. En bref, le protocole HTTP est la technologie
sous-jacente qui régit la communication réseau. Comme son nom l'indique, le protocole de transfert
hypertexte sécurisé (HTTPS) est une version plus sûre ou une extension du protocole HTTP. Avec
HTTPS, le navigateur et le serveur établissent une connexion sécurisée et chiffrée avant de
transférer des données.

8
Figure 3: Différence entre HTTP & HTTPS, [Link]

Fonctionnement du protocole HTTP

HTTP est un protocole de la couche application dans le modèle OSI (Open Systems
Interconnection) ou encore TCP de communication réseau. Il définit plusieurs types de
demandes et de réponses. Par exemple, lorsque vous souhaitez consulter les données d'un
site Web, vous envoyez la requête HTTP GET. Si vous souhaitez envoyer des informations,
par exemple remplir un formulaire de contact, vous envoyez la requête HTTP PUT.

De la même manière, le serveur envoie différents types de réponses HTTP sous forme de codes
numériques et de données. Voici quelques exemples :

o 200 - OK

o 400 - Demande erronée

o 404 - Ressource non trouvée

Cette communication demande-réponse est généralement invisible pour vos utilisateurs. Il

s'agit de la méthode de communication utilisée par le navigateur et les serveurs Web qui permet au
World Wide Web de fonctionner de la même façon pour tout le monde.

9
Figure 4;Http fonctionnement, [Link]

Fonctionnement du protocole HTTPS

Le protocole HTTP transmet des données non chiffrées, ce qui signifie que les informations
envoyées depuis un navigateur peuvent être interceptées et lues par des tiers. Ce processus n'étant
pas idéal, il a été étendu au protocole HTTPS pour ajouter une couche de sécurité supplémentaire
aux communications. Le protocole HTTPS associe les requêtes et les réponses HTTP aux
technologies SSL et TLS.

Les sites Web HTTPS doivent obtenir un certificat SSL/TLS auprès d'une autorité de
certification (CA) indépendante. Ces sites Web partagent le certificat avec le navigateur avant
d'échanger des données pour établir la confiance. Le certificat SSL contient également des
informations cryptographiques, qui permettent au serveur et aux navigateurs Web d'échanger des
données chiffrées ou brouillées. Le processus fonctionne comme suit :

a) Vous visitez un site Web HTTPS en saisissant le format d'URL https:// dans la barre
d'adresse de votre navigateur.

b) Le navigateur tente de vérifier l'authenticité du site en demandant le certificat SSL du

serveur.

c) Le serveur envoie le certificat SSL contenant une clé publique en réponse.

10
 d) Le certificat SSL du site Web prouve l'identité du serveur. Une fois que le navigateur est
satisfait, il utilise la clé publique pour chiffrer et envoyer un message contenant une clé de
session secrète.

e) Le serveur Web utilise sa clé privée pour déchiffrer le message et récupérer la clé de session.
Il chiffre ensuite la clé de session et envoie un message d'accusé de réception au navigateur.

f) Désormais, le navigateur et le serveur Web utilisent la même clé de session pour échanger
des messages en toute sécurité.

2.3.3. DNS

Le protocole DNS (Domain Name System) est un processus qui permet aux internautes de
naviguer sur Internet à l’aide de noms d’hôtes et non d’adresses IP numériques. Le DNS est
l’annuaire téléphonique d’Internet : il simplifie le processus de recherche de sites web
spécifiques via les navigateurs web.

Fonctionnement du protocole DNS

Le processus suivant implique la résolution de requêtes DNS et la connexion des utilisateurs

à l’adresse IP du serveur web hébergeant le site :

o Lorsque vous utilisez un client DNS tel que votre ordinateur, un appareil intelligent, un
navigateur web ou une application pour vous connecter à un nom de domaine, vous déclenchez
ce que l’on appelle une requête récursive, une requête DNS, une recherche DNS ou une
demande DNS.

o Lorsqu’une demande d’enregistrement DNS est effectuée à partir d’un appareil comme un
smartphone, un ordinateur ou une tablette, un navigateur (tel que Google Chrome) recherche
d’abord l’enregistrement dans son cache. Si aucun enregistrement n’existe, le résolveur du
système d’exploitation est interrogé. Ce composant du système d’exploitation, appelé résolveur
de stub, vérifie l’enregistrement.

11
o Si l’enregistrement demandé n’est pas mis en cache au niveau local, les requêtes DNS sont
alors dirigées vers une série de serveurs DNS externes qui résolvent la demande.

o Le premier de la série est le serveur DNS récursif, également connu sous le nom de récurseur
DNS ou de résolveur DNS récursif, souvent géré par un fournisseur d’accès à Internet (FAI).
Quand c’est possible, le résolveur récursif utilise les données du cache DNS pour atteindre le
site souhaité. Si ces données ne sont pas disponibles, il dirige la demande vers le serveur de
noms racine.

o Les serveurs de noms racine, ou serveurs DNS racine, acheminent la requête vers un serveur
connu sous le nom de serveur de noms de domaine de premier niveau (TLD), en fonction de
l’extension du site : .com, .org ou .net, par exemple.

o Les serveurs de noms TLD envoient les demandes concernant des extensions spécifiques au
serveur de noms faisant autorité, également appelé serveur DNS faisant autorité ou serveur de
noms de domaine faisant autorité.

o Le serveur de noms faisant autorité contient des informations sur la zone DNS qu’il gère,
notamment des informations relatives aux noms de domaine spécifiques stockés dans les
enregistrements de ressources DNS, et il connecte les noms de domaine aux adresses IP
correspondantes.

o L’information est renvoyée au client DNS, complétant ainsi la résolution DNS.

Lorsqu’un serveur DNS ne parvient pas à récupérer une réponse complète, il déclenche une
requête DNS itérative. Les serveurs continueront de renvoyer la demande par différents
serveurs jusqu’à ce qu’une adresse IP soit trouvée, qu’un délai d’expiration soit atteint ou
qu’une erreur se produise.

12
Figure 5: DNS, [Link]

3. Modèles architecturaux

3.1. Modèle 2-tiers

3.1.1. Description et exemples

Le modèle 2-tiers est une architecture logicielle divisée en deux couches principales :

Côté client :

o C'est l'interface utilisateur ou l'application utilisée par l'utilisateur final.

o Cette couche peut inclure des éléments de présentation (comme des boutons, des formulaires)
et parfois une partie de la logique, comme la validation des données avant leur envoi.

o Exemple : Un logiciel sur un poste de travail ou une application web légère.

Côté serveur :

o Cette couche gère les données, leur stockage et le traitement des requêtes.

o C'est souvent une base de données (ex. : SQL, Oracle) où toutes les informations sont
centralisées.

13
o Exemple : Un serveur qui reçoit des requêtes pour afficher, modifier ou supprimer des données
stockées.

Le client et le serveur communiquent directement grâce à des protocoles comme TCP/IP, sans
intermédiaire supplémentaire.

Figure 6: 2-tiers, [Link]/p/[Link]

Exemples concrets d'utilisation

Système de gestion d'inventaire :

o Le client est une application installée sur les postes des employés.

o Le serveur central contient la base de données avec les informations des produits.

o L'utilisateur peut consulter ou mettre à jour l'inventaire en temps réel.

Application bancaire basique :

o Le client est une application qui permet de vérifier les soldes ou effectuer des transactions
simples.

o Le serveur gère la base de données des comptes bancaires et traite les demandes.

14
 3.1.2. Avantages et inconvénients du modèle 2-tiers

Avantages

o Simplicité de conception et de déploiement : La structure est facile à comprendre et rapide à

mettre en œuvre pour des petites applications.

o Performances locales optimales : La connexion directe entre le client et le serveur permet des
échanges rapides, surtout sur un réseau local.

o Coût réduit : Nécessite moins de ressources matérielles ou logicielles, ce qui en fait une
solution économique pour les petites entreprises.

o Centralisation des données : Toutes les données sont regroupées sur un serveur unique, ce
qui facilite leur gestion.

Limites

o Manque d'évolutivité : Ce modèle fonctionne mal si le nombre d'utilisateurs augmente

fortement, car le serveur unique risque d'être surchargé.

o Sécurité limitée : Les données circulent directement entre le client et le serveur, ce qui peut
les exposer à des risques si la communication n'est pas protégée.

o Dépendance réseau : Toute interruption ou lenteur du réseau affecte directement le

fonctionnement du système.

o Couplage fort : Les deux couches sont fortement dépendantes l'une de l'autre. Une mise à jour
du serveur peut nécessiter des modifications côté client, ce qui complique la maintenance.

Le modèle 2-tiers est bien adapté pour des applications simples ou internes à une organisation,
mais il montre ses limites dès qu'on doit gérer des systèmes complexes ou des utilisateurs à grande
échelle.

3.2. Modèle 3-tiers

3.2.1. Présentation des couches dans le modèle 3-tiers

a) Couche client (ou présentation) :

15
o Rôle : Fournir une interface utilisateur pour interagir avec le système.

o Fonctions principales : Collecter les données saisies par l'utilisateur (par exemple, via des
formulaires), afficher les résultats ou les réponses provenant du serveur applicatif.

o Exemples : Un navigateur web (par exemple, Chrome ou Firefox), une application mobile ou
un logiciel de bureau.

b) Couche serveur applicatif (ou logique métier) :

o Rôle : Gérer la logique métier et le traitement des données.

o Fonctions principales : Recevoir les requêtes provenant du client, appliquer les règles métiers
(par exemple, calculs, décisions, vérifications), transmettre les requêtes nécessaires à la base
de données.

o Exemples : Une API REST ou SOAP utilisée pour traiter les requêtes des utilisateurs, des
serveurs d'applications comme [Link], Java EE ou .NET.

c) Couche serveur de base de données :

o Rôle : Stocker et gérer les données de l'application.

o Fonctions principales : Répondre aux requêtes envoyées par le serveur applicatif (lecture,
écriture, mise à jour), garantir l'intégrité, la sécurité et la sauvegarde des données.

o Exemples : Bases de données relationnelles comme MySQL, PostgreSQL ou Oracle, bases de

données NoSQL comme MongoDB ou DynamoDB.

16
Figure 7: 3-tiers, [Link]

3.2.2. Utilisation typique et bénéfices du modèle 3-tiers

Utilisations typiques :

o Applications web dynamiques : Par exemple, les sites de commerce électronique où les
utilisateurs naviguent via un navigateur, le traitement des commandes est fait côté serveur
applicatif, et les informations sur les produits sont récupérées dans une base de données.

o Applications d'entreprise : ERP ou CRM qui nécessitent une gestion complexe des données
et une interface utilisateur conviviale.

o Jeux en ligne : Où le client (le jeu) interagit avec un serveur applicatif pour les mécanismes
du jeu, qui accède ensuite à la base de données des scores ou des profils des joueurs.

Bénéfices :

o Modularité : Chaque couche est indépendante, facilitant l'ajout ou la modification des

fonctionnalités.

o Facilité de maintenance : Les développeurs peuvent intervenir sur une couche sans affecter
directement les autres.

o Évolutivité : Chaque couche peut être mise à l'échelle séparément selon les besoins (par
exemple, ajouter plus de serveurs pour la base de données).

17
o Sécurité : La séparation des responsabilités permet un meilleur contrôle des accès et des
données sensibles.

Avantages du modèle 3-tiers

o Répartition claire des responsabilités : Chaque couche a un rôle bien défini, ce qui permet
de maintenir une architecture claire.

o Flexibilité : Les modifications dans une couche (par exemple, mise à jour de la base de
données) n'affectent pas directement les autres couches.

o Support des grands systèmes : Idéal pour les systèmes complexes avec un grand nombre
d'utilisateurs ou une forte charge de données.

o Portabilité : Les clients peuvent utiliser différents appareils ou navigateurs pour se connecter
(ordinateur, smartphone, tablette).

Limites du modèle 3-tiers

o Complexité accrue : Nécessite une expertise plus poussée pour concevoir, implémenter et
maintenir les différentes couches.

o Coûts plus élevés : Les infrastructures (serveurs dédiés, bases de données robustes) et le
développement sont plus coûteux.

o Dépendance réseau : Comme le client, le serveur applicatif et la base de données doivent

communiquer entre eux, une panne ou une lenteur du réseau peut affecter les performances.

o Latence possible : Le passage par plusieurs couches peut ralentir les réponses, surtout si le
système n'est pas optimisé.

Le modèle 3-tiers est couramment utilisé dans des systèmes nécessitant modularité, évolutivité et
sécurité.

18
3.3. Variations avancées
3.3.1. Modèle n-tiers : Présentation

Le modèle n-tiers est une architecture logicielle qui divise les fonctionnalités d'une
application en plusieurs couches indépendantes. Chaque couche joue un rôle spécifique, ce qui
améliore la modularité, la flexibilité et la maintenance du système. Ces couches coopèrent pour
traiter les données, appliquer les règles métier et présenter les résultats à l'utilisateur. La
première couche est la couche client ou présentation. Elle représente l'interface utilisateur
permettant de communiquer avec l'application. Par exemple, un navigateur web ou une
application mobile envoie des requêtes aux autres couches pour interagir avec le système.

La couche serveur applicatif, ou logique métier, gère les traitements des données et
applique les règles métier. Elle agit comme intermédiaire entre le client et la base de données.
Par exemple, elle traite les calculs, les validations ou encore les connexions avec des services
externes comme une passerelle de paiement. Dans certains cas, des couches supplémentaires
comme une couche de cache pour accélérer les requêtes fréquentes, une couche d'intégration
pour connecter des systèmes tiers ou encore une couche de sécurité pour protéger contre les
intrusions peuvent être ajoutées pour optimiser le système.

Enfin, la couche serveur de base de données stocke et gère les données de manière
centralisée. Elle exécute les requêtes de la couche applicative pour fournir ou modifier les
informations nécessaires. Par exemple, elle peut héberger les données d'un système de
commerce électronique (produits, commandes, utilisateurs). Ces couches additionnelles, bien
qu'augmentant la complexité, apportent des bénéfices en termes de performances, d'intégration
et de sécurité.

Le modèle n-tiers est souvent utilisé pour des systèmes complexes comme les plateformes
web et les applications d'entreprise. Parmi ses avantages figurent une évolutivité accrue, une
meilleure maintenance et une sécurité renforcée grâce à la séparation des responsabilités.
Cependant, il peut introduire une certaine latence et complexité, tout en nécessitant des
infrastructures plus coûteuses.

19
3.3.2. Architectures basées sur les micro-services

Les architectures basées sur les microservices sont des systèmes où les applications sont
décomposées en services autonomes, chacun ayant une fonction précise. Chaque service est
indépendant, peut être développé et déployé séparément, et communique avec les autres via des
API légères comme REST ou gRPC. Ces services sont conçus pour répondre aux besoins métier
spécifiques de manière modulaire.

L’un des principaux avantages des microservices est leur évolutivité. Chaque service peut
être mis à l'échelle indépendamment selon les besoins. Par exemple, dans un site de commerce
électronique, le microservice de gestion des commandes peut être renforcé en cas de forte
demande sans impacter les autres parties du système. Cette architecture offre également une
flexibilité technologique : chaque microservice peut être développé dans une technologie
adaptée à ses besoins, permettant ainsi des choix optimaux pour chaque fonctionnalité.

Cependant, les microservices introduisent une complexité accrue. La coordination de

nombreux services peut nécessiter des outils spécialisés comme Docker pour la
conteneurisation ou Kubernetes pour l’orchestration. De plus, des problèmes de latence peuvent
survenir à cause de la communication entre services, notamment si le réseau est saturé ou
instable.

Ce modèle est particulièrement adapté aux applications à grande échelle, telles que Netflix
ou Amazon, où chaque fonctionnalité (streaming, gestion des comptes, recommandations) est
gérée par un microservice distinct. Les solutions cloud natives et les systèmes IoT sont
également des exemples typiques d'utilisation, car ils bénéficient de l'indépendance et de la
modularité des microservices.

En résumé, les architectures basées sur les microservices sont idéales pour des applications
nécessitant flexibilité, évolutivité et livraison continue, bien qu'elles demandent une expertise
technique plus poussée pour leur mise en œuvre et leur maintenance.

20
 3.4. Comparaison entre les architectures

Figure 8:Tableaux comparatifs entre le modèle 2-tiers et le modèle 3-tiers, [Link]

[Link]/~dr/XPOSE2001/perrot/[Link]
21
 4. Répartition des tâches et responsabilités
La répartition des tâches et responsabilités dans une architecture client-serveur repose sur
une séparation claire entre les rôles du client et ceux du serveur. Voici une présentation détaillée :

4.1. Côté client :

a) Interfaces utilisateur :

o Le client gère l'interaction directe avec l'utilisateur à travers une interface conviviale,
comme une application mobile, un navigateur web ou un logiciel de bureau.

o L'objectif est de permettre aux utilisateurs de saisir des données, de naviguer dans
l'application ou de visualiser des résultats.

b) Logique de présentation :

o Le client est également responsable de la gestion de la logique de présentation, qui

concerne l'affichage et le formatage des données reçues du serveur pour rendre les
informations compréhensibles et attractives (par exemple, mise en page HTML, CSS).

4.2. Côté serveur :

a) Logique métier :

o Le serveur centralise les règles métier de l'application.

o Par exemple, pour une boutique en ligne, il vérifiera les stocks, calculera les montants totaux
des commandes et appliquera des règles telles que les réductions ou les frais de livraison.

b) Gestion des données (stockage, sécurité, traitement) :

o Le serveur s'occupe du stockage des données dans une base de données, de leur sécurisation
pour éviter tout accès non autorisé, et de leur traitement (ex. : calculs, requêtes SQL).

o Il garantit l'intégrité des données, notamment en cas d'accès simultané par plusieurs
utilisateurs.

4.3. Exemple d'application illustrant cette répartition :

Prenons l'exemple d'une application bancaire en ligne :

22
o Côté client : L'utilisateur utilise une application mobile ou un navigateur pour consulter son
solde ou transférer de l'argent. L'interface affiche les relevés bancaires et un formulaire pour
saisir les informations de transfert.
o Côté serveur : Le serveur traite la demande de transfert en vérifiant que le solde est suffisant
(logique métier), puis met à jour les données dans la base de données pour enregistrer la
transaction (gestion des données). Enfin, il renvoie une confirmation au client.

Cette répartition garantit une séparation des responsabilités, facilitant la maintenance, la

sécurité et l'évolutivité du système.

5. Avantages et inconvénients de l'architecture client-serveur

Le concept de répartition des tâches et des services au sein d’un réseau selon le modèle client-
serveur présente des avantages indéniables mais aussi certains inconvénients qu’il convient de
rappeler.

5.1. Avantages
Si le modèle client-serveur constitue l’une des architectures les plus utilisées dans la technique
des réseaux, c’est notamment grâce à ses nombreux avantages.

Une administration centrale

L’un des grands avantages réside dans son administration centrale : le serveur constitue le
centre du réseau. Tous les utilisateurs ou clients l’utilisent. Les ressources les plus importantes,
comme les bases de données, sont disponibles sur le serveur et donc centralisées. Cette
structure simplifie l’administration et la maintenance des ressources importantes et sensibles.
La position centrale du serveur permet aussi d’effectuer facilement et sûrement les mises à jour
avec peu de risques.

Contrôle global des droits d’accès

23
 La centralisation des ressources-clés permet aussi de gérer au plus près les droits d’accès
pour une plus grande sécurité. Il est important de savoir à tout moment qui a accès aux données
sensibles, et qui peut effectuer certaines manipulations. Afin de garantir une protection optimale
des données, il s’agit dans ce cas de limiter au maximum les droits d’accès.

Un seul serveur pour de nombreux clients

Le nombre de clients est extensible et plusieurs clients travaillent simultanément avec un

serveur. Les clients se partagent les ressources du serveur. Il est aussi possible que le serveur se
trouve physiquement à un autre endroit que les clients : c’est l’architecture du réseau qui
déterminera la relation entre serveur et clients. À ce titre, il n’est pas nécessaire d’avoir les
ressources sur place.

5.2. Inconvénients
Malgré ses nombreux avantages, le modèle client-serveur présente aussi certains inconvénients.

Panne de serveur

L’inconvénient majeur du modèle client-serveur réside dans sa centralisation : une panne

serveur entraîne une panne générale du système. S’il devait être indisponible, les clients ne
pourraient plus faire leur travail car ils ne recevraient plus les réponses attendues du serveur.

Ressources serveur

Le serveur exécute des tâches qui demandent beaucoup de ressources. Le client fonctionne
avec des exigences en matière de ressources nettement moins élevées. Un serveur qui disposerait
de trop peu de ressources aurait une incidence sur le travail de tous les clients. C’est pourquoi il
est important de choisir un fournisseur fiable qui garantisse la mise à disposition de ressources.

Chronophage

Un autre élément à ne pas sous-estimer est le temps à consacrer pour l’exploitation de son
propre serveur. Non seulement ce type de matériel demande le savoir-faire correspondant,
notamment pour sécuriser et configurer les serveurs, mais aussi des ressources en temps non
négligeables.

24
 6. Conclusion
En conclusion, l'architecture client-serveur représente une base indispensable pour la
conception des systèmes informatiques, offrant des solutions adaptées aux besoins variés des
utilisateurs et des entreprises. À travers l'exploration des modèles 2-tiers, 3-tiers et des micro-
services, ce travail démontre comment la modularité, la répartition des responsabilités et
l'intégration des couches supplémentaires contribuent à la performance, à la sécurité et à la
maintenance des applications. Bien que chaque modèle ait ses limites, il est clair que leur choix
dépend des contraintes techniques et des exigences métiers. Ces architectures, en constante
évolution, continueront de jouer un rôle essentiel dans les innovations numériques.

25
 Webographie

[Link]

[Link]

[Link]
serveur#Comparaison_des_architectures_centralis%C3%A9es_et_distribu%C3%A9es

[Link]

[Link]

[Link]

[Link]

[Link]

[Link]

[Link]

[Link]
[Link]

[Link]

[Link]

26