CHAP.III. ANALYSE FONCTIONNELLE ET MODELISATION

III.1. NOTION
L’analyse du système d’information a pour but de s’informer de la structure de
l’entreprise car, l’enjeu de toute entreprise consiste à mettre en place un système destiné à
collecter, mémoriser, traiter et distribuer l’information au moment favorable.20
L’analyse d’un SI consiste à mettre à la disposition le schéma de circulation de
l’information qui met en évidence la charge de flux entre l’acteur du système
organisationnel et le tableau de flux grâce à des interviews, à l’étude des documents internes
et à la circulation de l’information21.
Pour Jean Paul Getty, un système d’information d’une organisation est l’ensemble des
moyens humains et matériels qui permet de collecter, traiter et diffuser les informations. Le SI
permet par ailleurs le suivi et la réalisation des objectifs d’une entreprise à tous les niveaux et
dans toutes les principales fonctions22.
De ce fait, le système est un ensemble d’éléments matériels ou immatériels (homme,
machine, méthode, règles…) en interaction transformant par un processus des éléments (les
entrées) en d’autres éléments (les sorties)23. Ainsi donc, chaque organisation dispose d’un
système qui fonctionne en vue de la réalisation de ses objectifs.
Toute organisation est constituée de trois systèmes d’information :
 Le système de pilotage (SP) : constitué des responsables ou membres décisionnels.
Son rôle est de prendre des décisions et définir les stratégies en vue du développement
et de la gestion de l’entreprise.24.
 Le système Opérant (SO) : consiste à exécuter les tâches concurrentes à la réalisation
des objectifs fixés par le corps décisionnel25.
 Le système d’Information (SI) : il joue le rôle intermédiaire entre le système de
pilotage et le système opérant. Il est composé d’éléments divers (employés,
20 CLAUDEL H, Concevoir et Réussir son informatique, éd ; Rue, Paris, 1984.P.20
21 Félix JOLIVET et Gérard REBOUL, Informatique appliquée à la gestion, Tome 2, Deuxième éd. Dunod, Paris,
1993, p. 196.
22 Jean Paul GETTY, Organisation et Gestion, éd. Foucher, 158 Rue Jean Bleu, Août 2004, P.4.
23 Olga Kinyamusitu, cours de Merise I, ISTEGI, 2011-2012, Inédit.
24 Olga Kinyamusitu, Op.cit.
25 Idem.
22
ordinateurs, règles et méthodes…) chargés de stocker et de traiter les informations
relatives au (SO) afin de le mettre à la disposition du (SP) système pilotage. Il a
pour rôle la collecte, l’analyse et le traitement diffusion des informations.26
III.2. ETUDE DES DOCUMENTS UTILISES
Un document est un renseignement écrit servant de preuve d’information ou de
témoignage. On peut en distinguer deux types : les documents d’entrée et les documents de
sortie.27
III.2.1. Recensement des documents
Les documents ci-après sont d’usage quotidien dans diverses institutions par les professeurs
du cours d’informatique.
1. Cahier de préparation
2. Cahier de critiques
3. Journal de classe
4. Cahier des côtes
5. Cahier de prévision de matières.
III. 3. CRITIQUE DE L’EXISTANT
La tenue manuelle de différents documents ayant trait à la gestion des côtes entraine
une perturbation dans beaucoup des services, le retard perpétré et autres insuffisances
pourraient être constatés.
Ainsi, les informations se trouvant dans les documents précédemment présentés servent
d’éléments de base au gestionnaire pour prendre une décision efficace. C’est pourquoi il
s’avère important de critiquer ces documents du point de vue fonds et forme pour qu’ils
répondent valablement aux aspirations du gestionnaire en présentant ainsi tous les éléments
nécessaires pour une bonne prise de décision.
Dans l’ensemble, les différents documents que l’enseignant utilise pour la gestion de
côtes manquent certaines rubriques qu’il faut ajouter et d’autres qu’il convient de modifier.
Parce que la plupart de ces documents sont complétés manuellement, il y a lieu de se tromper
facilement.
26 Ibidem.
27 Dicos Encarta 2009
23
Au vu de l’analyse du système d’information actuel, on constate que les activités de
l’enseignant ne sont pas automatisées, car il n’y a pas un logiciel que les enseignants utilisent
dans la dispensation quotidienne du cours d’informatique.
III.4. DES SOLUTIONS PROPOSEES
III.4.1. La solution manuelle
Pour ce point, les conseils pour bien changer la manière de tenir les documents compte
tenu des remarques sont repris ci-haut.
Dans l’objectif de rendre le climat de travail apaisé ou bien encore en chercher une
amélioration, l’enseignant du cours d’informatique devra compléter d’abord toutes les
rubriques qui manquent dans les différents documents énumérés pour un bon contrôle et une
bonne précision.
III.4.2. La solution informatique
Dans cette perspective, l’informatique offre plusieurs possibilités qui nous permettent
de stocker, de traiter et de consulter une information dans un temps réduit d’une façon
automatique.
La solution informatique présente plusieurs avantages par rapport à la solution manuelle
améliorée. Cependant, cette solution une fois appliquée, permettra de dégager le temps pour
dispenser le cours d’informatique, lors de la passation et la correction des travaux : TP et
examen.
Pour y parvenir, la nécessité de trouver des équipements informatiques avec un logiciel
adapté à l’enseignement/apprentissage assisté par ordinateur s’impose.
III.5. MODELISATION DE L’APPLICATION AVEC UML
Dans cette partie, les différentes étapes que nous offrent l’UML (Unified Modeling
Language, doivent être prises en considération, et pourraient être traduites en français par
"langage de modélisation unifié). Ce dernier est un langage permettant de modéliser un
problème informatique de façon standard. A travers ces étapes, nous allons atteindre la
représentation idéale, étape par étape, et aboutir ainsi à la réalisation de notre application qui
n’aura rien d’autre que la mise en oeuvre de notre didacticiel du cours d’informatique. Il
semble confus de parler de l’UML sans pour autant en faire la description du portrait.
24
III.5.1. Présentation d’UML
Quelques concepts relatifs au langage UML28
a. UML (Unified Modeling Language): se définit comme un langage de modélisation basé
sur le formalisme graphique et textuel destiné à comprendre et à définir les besoins,
spécifier et documenter les systèmes, esquisser des architectures logicielles, concevoir
des solutions et communiquer des points de vue importants.
b. Un modèle : Un modèle est une représentation simplifiée d’une réalité.
c. Entité : Objet concret ou abstrait du monde réel au sujet duquel une organisation est
susceptible de conserver des données.
d. Attribut : Donnée élémentaire qui sert à caractériser une propriété des entités et des
associations dans un modèle conceptuel de données
e. Association : Lien sémantique qui existe entre deux entités ou plus. Elle représente
souvent la mémoire d’un événement qui a permis d’établir un lien logique entre ces
entités
f. Scénario : Une liste d’instructions qui décrivent une interaction à effectuer entre
l’utilisateur et le système (application).
g. Interaction : un comportement qui comprend un ensemble de messages échangés par un
ensemble d'objets dans un certain contexte pour accomplir une certaine tâche.
h. Message : Un message représente une communication unidirectionnelle entre objets qui
transporte de l'information avec l'intention de déclencher une réaction chez le récepteur.
i. Connexion : A cette étape, il est demandé à l’administrateur de se connecter pour
effecteur des modifications dans la base
j. Ajout des élèves: Ajouter d’autres personnes qui désormais auront l’accès en la base
pour effectuer les opérations telles que suivre le cours et passer les examens et travaux
pratiques
k. Consulter résultats : Pour consulter les résultats.
Tels sont les concepts utilisables dans ce système, permettant de bien montrer la manière
dont les opérations seront effectuées et décrites.
28Michael Blaha et James Rumbaugh, Modélisation et conception orientées objet avec UML2,
2ème Edition, Pearson Education, 2005.
25
III.5.2. Les besoins fonctionnels
a. Identification des acteurs
Un acteur représente l’abstraction d’un rôle joué par des entités externes qui interagissent
directement avec le système étudié. Un acteur peut consulter et/ou modifier directement l’état
du système, en émettant et/ou en recevant des messages éventuellement porteurs de données.
Les acteurs ci-après constituent le présent système : les étudiants et les enseignants car
ils interagissent avec notre système.
1. Les étudiants qui souhaitent suivre des cours s’identifieront, car ils sont déjà
inscrits par l’enseignant. Une fois l'étudiant es t inscrit, il pourra consulter les
cours et faire les travaux qui lui sont proposés notamment télécharger les cours,
passer les examens, consultent également les résultats.
2. Les enseignants sont ceux sur qui repose la longévité et de la pérennité de ce projet.
Ils fournissent des ressources, initient les activités de l’enseignement, ils suivent
également les travaux des étudiants, donnent des TP et font faire enfin des examens.
b. Identification des cas d’utilisation
Un cas d'utilisation (use case) « représente un ensemble de séquences d'actions réalisées par le
système et produisant un résultat observable intéressant pour un acteur particulier ».
En effet, ils sont des représentations fonctionnelles du système, ils permettent de
modéliser les attentes des utilisateurs afin de réaliser une bonne délimitation du système et
également d'améliorer la compréhension de son fonctionnement. Les cas d’utilisation sont
déclenchés suite à la stimulation d'un acteur externe.
Les besoins fonctionnels listent les opérations réalisables de notre application. Ce sont des
besoins spécifiant un comportement d'entrée / sortie du système. En fait, le système doit
établir les charges préliminaires suivantes:
Gestion de l’enseignant ou administrateur Gestion des étudiants ou
apprenants
 S’authentifier
 Inscrire un apprenant
 Gestion de la formation
 Evaluation des apprenants
 Faire la correction et la publication des résultats
 S’authentifier
 Assister à une formation
 Télécharger le cours
 Passer les TP et les examens
Table 3.1 : Les besoins fonctionnels
26
III.5.3. Les besoins opérationnels29
Les besoins opérationnels représentent les besoins non fonctionnels, qui caractérisent
le système comme la performance ainsi que la sécurité et l’ergonomie du système.
Ces besoins peuvent être énoncés suivant des plans de classifications.
a. L'ergonomie des interfaces:
 l'interface d'une application web, est délicate et doit être simple et claire : La
manipulation de l'interface ne doit pas nécessiter des connaissances avancées.
 L’application web doit être compatible avec n'importe quel système d'exploitation,
facile à manipuler et bien compréhensible.
 Les interfaces des applications web doivent être bien organisées du point de vue
graphique, choix des couleurs et de styles.
b. Robustesse: L'application doit permettre le stockage des informations des utilisateurs
inscrits, ainsi qu'assurer une bonne gestion d'erreurs.
c. Sécurité: L'application doit garantir à l'utilisateur connecté l'intégrité et la
confidentialité de ses données. Ce système devra également certifier la disponibilité
qui s'avère primordiale pour le bon fonctionnement.
d. L'application doit garantir: la Fiabilité, l'évolutivité ainsi que la flexibilité et la
réutilisabilité de ses ressources.
Après avoir dégagé les besoins fonctionnels et opérationnels ainsi que tous les critères
qui doivent être pris en considération, on devra entamer l’étape suivante pour bien
formaliser ces besoins.
III.5.4. Formalisation des besoins fonctionnels
III.5.4.1. Diagrammes d’UML
Les diagrammes sont des objets qui permettent à UML de modéliser plus correctement
des applications. En UML, on peut définir jusqu’à treize diagrammes divisés en deux grandes
catégories qui suivent :
ï‚· Diagrammes statiques (structurels) : diagramme de classes, diagramme d’objets,
diagramme de composants, diagramme de déploiement, diagramme de paquetages et
diagramme de structures composites.
29 www.phppourlesnuls.org, visité en Novembre 2015
27
ï‚· Diagrammes dynamiques (comportementaux) : diagramme de cas d’utilisation,
diagramme d’activités, diagramme d’états-transitions, diagrammes d’interaction,
diagramme de séquence, diagramme de communication, diagramme global
d’interaction, diagramme de temps.
Quant à la complexité du problème, on peut choisir des diagrammes qui permettent la
compréhension et la modélisation idéales du problème en question. Pour ce qui est de notre
cas, nous utiliserons :
- Le Diagramme des Cas d’utilisation
- Le Diagramme des Séquences
- Le Diagramme des Classes
1- DIAGRAMME DE CAS D’UTILISATION
Un diagramme de cas d’utilisation est un formalisme qui permet de modéliser
le fonctionnement d’un système par un découpage de celui-ci en fonctionnalités. Il explicite
de plus la nature des interactions avec ses fonctionnalités offertes à titre des services à des
acteurs externes au système.
Le tableau suivant représente quelques cas d’utilisation, les acteurs et les relations entre les
deux :
Tableau 2.2 : Identification des scénarios par cas d’utilisation
Acteur Cas d’utilisation Scénarios
Enseignant ou
administrateur
Gestion technique de la plate-forme S0 : Gestion technique de la plateforme
Authentification S1 : login et mot de passe
Gestion des comptes utilisateurs S2: Gestion des comptes des
utilisateurs
Gestion des examens S3 : Correction des examens
S4 : Publication des résultats
Gestions des cours S5 : Publier les cours sur le web
S6 : Mise à jour des cours
Elève Authentification S1 : Login et mot de passe
Accès aux cours S7 : Accès aux cours
Faires des examens et les TP S8 : Faire des examens et les TP
Consultation des résultats S9: Consultation des résultats
28
Par la suite, nous illustrons graphiquement ce tableau par un diagramme de cas d’utilisation
globale (voir la Figure 3.3 ci-dessous).
Graphique de cas d’utilisation
Ce diagramme représente les cas d’utilisation sans en faire les détails, car chaque cas
d’utilisation sera détaillé dans les pages suivantes.
 Présentation du diagramme de cas d’utilisation
 Description textuelle des cas d’utilisation
Afin de décrire les interactions entre les cas d’utilisation, nous les présentons de façon
textuelle.
Il s’agit donc d’associer à chaque cas d’utilisation un nom, un objectif, les acteurs qui y
participent, les pré-conditions et les scénarios. Cependant ; il existe trois types de scénario :
les scénarios nominaux ; les scénarios d’exceptions et les scénarios alternatifs. Dans cette
description textuelle, nous présentons seulement les scénarios nominaux et alternatifs.
Nous nous restreindrons à la description des cas d’utilisation suivants :
authentification et inscription (application Web).
<include>
<include>
Enseignant
Gestion Gestion des examens et TP Gestion des cours des étudiants
Accès au cours
Faire les examens et tp
Consulter le résultat
Authentification
Etudiant
Consulter les résultats
<include> <include> <include> <include>
29
CU1: Inscription au site
Résumé: Ce CU permet à l’acteur de s’inscrire.
Acteurs: Enseignant, Etudiant
Post-Condition: le cas démarre après le point 02 de l’enchainement nominal, l’utilisateur
s’inscrit au site
Scénario nominal
DESCRIPTION DU SCENARIO NOMINAL
« DEBUT»
01 : le système affiche un formulaire d’inscription à l’acteur
02 : l’acteur saisit ses informations.
03 : le système vérifie la validité des informations saisies.
04 : le système enregistre ces informations dans la base de données.
05 : le système notifie l’acteur du bon déroulement de l’inscription
«ScFeInNa»rio alternative
Les informations sont manquantes ou incorrectes: ce scénario commence au point 03 du
scénario nominal.
01 : Le système informe l’acteur que les données saisies sont erronées, garde les
informations saisies avant et le scénario reprend au point 02 du scénario nominal.
CU2: Authentification
Résumé: Ce CU permet à un utilisateur de se connecter au système ; et lui présenter
l’interface, les fonctionnalités relatives à son profil.
Acteurs: Enseignant, Etudiant
Pré conditions : Introduire login et mot de passe
Post-Condition: le cas démarre après le point 02 de l’enchainement nominal, l’utilisateur
s’authentifie
Scénario nominal
DESCRIPTION DU SCENARIO NOMINAL
« DEBUT»
01 : Le système invite l’acteur à entrer son login et son mot de passe.
02: L’acteur saisit le login et le mot de passe et choisit son profil.
03: Le système vérifie les paramètres.
04: Le système ouvre l'espace de travail correspondant au profil.
« FIN»
30
 Scenario alternatif
Le login ou le mot de passe est incorrect: ce scénario commence au point 03 du scénario
nominal.
01: Le système informe l’acteur que les données saisies sont erronées et le scénario reprend
au point 01 du scénario nominal.
 Organisation des cas d’utilisation
Dans cette partie, nous procédons à l’organisation des cas d’utilisation en les
rassemblant dans des packages.
Packages de cas d’utilisation
En cas de système de grande taille, on peut structurer l’analyse des besoins en découpant
le système en sous-systèmes. Un sous-système (appelé package) doit avoir un nom et
regrouper une famille de fonctionnalités clairement identifiable.30
Dans cette étape; nous regroupons les différents cas d’utilisation cités auparavant dans des
packages. Ce regroupement se fait suivant des critères. Le critère de regroupement que nous
adoptons dans ce processus est le domaine d'expertise métier.
Par la suite; nous reprenons le tableau avec les acteurs et les cas d'utilisation en
affectant chaque cas d'utilisation à un package. Nous obtenons le tableau ci-dessous :
Tableau 3.4: Liste des cas d’utilisation et de leurs acteurs par package
30 C. Johnen, UML en pratique, IUT Bordeaux 1
Cas d’utilisation Acteurs Package
Gestion technique de la plate-forme Administrateur ou
enseignant
Gestion de
l’administration
Gestion de formation
Gestion des étudiants
Gestion des examens et TP
Gestion des cours
Accès aux cours
Faire les examens Elève Gestion des élèves
Consultation des résultats
31
a) Package «Package «gestion de l’enseignant »
Figure 3.5. Diagramme de cas d’utilisation du package « Gestion des enseignants»
b) Package «gestion des étudiants »
Figure 3.6. Diagramme de cas d’utilisation du package « Gestion des étudiants»
2-Diagrammes des séquences
Le diagramme des séquences, permet l’interaction entre les objets met l’accent sur le
classement des messages par ordre chronologique durant l’exécution du système. Il est un
tableau dans lequel les objets sont rangés sur l’axe des abscisses et des messages par ordre
d’apparition sur l’axe des ordonnées.31
Il est utilisé pour représenter certains aspects dynamiques d’un système : dans le contexte
31 Pascal Roques, UML 2 Modéliser une application web, éditions eyrolles, Année 2007.
<includet>
enseignant
gestion des étudiants
suivi des étudiants
création de groupe de travail
correction des examens et TP
gestion des examens et TP
publication des résultats
gestion des cours
authentification
inscription étudiant
<includet>
<includet>
<includet>
<includet>
<includet>
<includet>
<include>
Etudiant
accès aux cours
faire les examens et TP
consultation des résultats
autentification
<include>
<include>
<include>
32
d’une opération d’un système, d’un sous-système, d’un cas d’utilisation (un scénario d’un cas
d’utilisation) selon un point de vue temporel.
Dans notre système, nous avons les scénarios suivants :
 Diagrammes de séquences de« Authentification »
Après le démarrage de l’application, l’utilisateur saisi son pseudo et son mot de passe.
Une fois qu’il valide la saisie des données, le système s’assure d’abord que les informations
entrées n’ont pas la valeur NULL, puis il vérifie ces données auprès de la base de données.
Cette étape s’achève soit par l’ouverture de l’espace personnel associé à l’utilisateur, soit par
l’affichage de message d’erreur.
Dans ce diagramme loop(1,3) indique qu’il aura une répétition d’affichage de
l’interface d’authentification jusqu’à la validation du pseudo et mot de passe (voir
Figure 2.7).
 Graphique diagramme de séquence
Après le démarrage de l’application, l’utilisateur saisi son pseudo et son mot de passe.
Une fois qu’il valide la saisie des données, le système s’assure d’abord que les informations
entrées n’ont pas la valeur NULL puis il vérifie ces données auprès de la base de données.
Cette étape s’achève soit par l’ouverture de l’espace personnel associé à l’utilisateur, soit par
l’affichage de message d’erreur.
Dans ce diagramme loop(1,3) indique qu’il aura une répétition d’affichage de
l’interface d’authentification jusqu’à la validation du pseudo et mot de passe (voir
Figure 3.7).
33
 Diagramme de séquence du scénario « inscription d’un étudiant »
Ce cas d’utilisation commence lorsque l’enseignant demande au système de faire une
inscription. Une fois le formulaire est affiché, il remplit les champs de saisies puis
enregistre ses données. Le système s’assure d’abord que les champs obligatoires n’ont
pas la valeur NULL ensuite il enregistre les informations entrées dans la base de données
(voir figure 3.6).
Figure 3.8 : Diagramme de séquence « Authentification »
34
 Diagramme de séquence du scénario « faire les examens et TP »
Figure 3.9. Diagramme de séquence du scénario « faire les examens et TP »
3-Diagramme des classes :
Un diagramme de classes est un graphe dont les noeuds sont des classes et les arcs des
relations entre ces classes. Le diagramme de classes est considéré comme le plus important
dans la modélisation orientée objet, il est le seul obligatoire lors d’une telle modélisation.
Les principaux éléments de cette vue statique sont les classes et leurs relations :
association, généralisation et plusieurs types de dépendances telles que la réalisation et
l’utilisation.
a) La classe : est la description formelle d’un ensemble d’objets ayant une sémantique
et des caractéristiques communes (mêmes attributs + mêmes opérations).
b) Objet : est une instance d'une classe (ex : Français est un objet d’une classe appelée
«Départements »).
c) Attributs : est une propriété partagée par tous les objets de la classe
d) Opérations : est un service qui peut être demandé à tout objet de la classe si une fois
connecté au système.
 Identification des classes
1. Enseignant : elle enregistre l’administrateur du site
2. Elèves: elle enregistre la liste des élèves inscrits
3. Côtes: elle enregistre les côtés des travaux journaliers et examens obtenus par les
élèves
4. Temp : consiste à enregistre le nombre de fois qu’un élève se connecte au système
35
 Méthodes et attributs des classes
Les méthodes et attributs des classes seront structurés de la manière suivante :
Classes Attributs Méthodes
Enseignant Idenseignant, nomsenseignant,login,password Ajouter()
Modifier()
Elèves Ideleve, nomseleve, login, password Ajouter()
Modifier()
Cotes Idcote, tj, ex, ideleve Ajouter()
Modifier()
Supprimer()
Temp Ideleve, compte Ajouter()
Modifier()
Supprimer()
 Dictionnaire des données
Codification Désignation Type Taille Obs
Ideenseignant Numéro de l’enseignant Entier 11
Nomsenseignant Nom et post-nom de l’énseignant Varchar 100
Login Identifier de l’enseignant Varchar 30
Password Mot de passe de l’enseignant Varchar 30
Ideleve Numéro de l’élève Entier 11
Nomseleve Nom et post-nom de l’élève Varchar 100
Login Identifier de l’élève Varchar 30
Password Mot de passe de l’élève Varchar 30
Idcote Numéro de la côte Entier 11
tj Travail journalier ou travail pratique Entier 11
Ex Examen Entier 11
Ideleve Numéro de l’élève Entier 11
Ideleve Numéro de l’élève Entier 11
Compte Nombre de connexion d’un élève Entier 11
36
 Diagrammes des classes
Figure 3.10 : Diagramme des classes
4-Modèle relationnel de données optimisé :
Les relations correspondant aux sous-classes ont comme clés étrangère et primaire, la clé de la
relation correspondant à la classe parente. Un attribut type est ajouté dans la relation
correspondant à la classe parente.
Dans ce qui suit, le modèle relationnel de données optimisées est susceptible d’être présenté.
- Enseignant (idenseignant, nomsenseignant, login, password)
- Eleve (ideleve, nomseleve, login, password;
- Cote (idcote, tj, ex, #ideleve) ;
- Temp (ideleve, compte) ;
5- Capture des besoins techniques
Nous choisissons lors de cette phase l’environnement de travail ainsi que l’architecture globale
utilisée pour notre système.
ï‚· Architectures Client/serveur
Les choix des prérequis techniques déjà mentionnés dans l’étude préliminaire lors de
l’expression des besoins opérationnels, impliquent des contraintes relatives à la
configuration du réseau matériel, les performances d’accès aux données ainsi que la
37
sécurité du système, l’intégration des applications, la volumétrie et le mode d’utilisation du
système.
Dans la conception de cette application, nous avons opté à l’architecture 2-tiers. Elle
représente la solution la plus adaptée à notre système, car elle nous offre :
 Des meilleures performances grâce à la répartition des charges de travail.
 Une disponibilité de l’information en temps réel.
 Une répartition des tâches entre les acteurs du système
 Une technologie à la mode et plus présentable.
La configuration matérielle de ce système est schématisée comme suit :
Figure 3.11 : Configuration matérielle du système
Comme le montre la figure4.10, ce système est équipé de :
 Client web sont des ordinateurs de bureau ou toutes sortes de machine ayant un
navigateur web qui permet d’accéder au réseau local
 Serveur d’application est l’environnement d’exécution des applications.