Pfe conception et réalisation d'une application de gestion des processus d'achat et de sous traitance

Département: STIC
Référence:
Licence Appliquée en Science et Technologies
de l’Information et de la Communication
Option SR
Conception et Réalisation d’une
application de gestion des processus d'achat et de sous-traitance
Réalisé par : Ahmed MAKNI
Classe : L3SRC
Encadrant de l’Iset’COM : Dr Hafedh GAHA
Encadrant de l’entreprise : M. Mourad GALLES
Responsable : M. Riadh SHIL
Entreprise d’Accueil : Tunisair Technics
Année Universitaire : 2016-2017

Résumé
Ce travail s’inscrit dans le cadre du projet de fin d’études pour
l’obtention de diplôme de licence en science et technologies de l'information
et de la communication. Il vise à réaliser une application web pour
l’évaluation des fournisseurs tenant compte les chiffres d'affaires, la
condition des livraisons par rapport aux commandes ainsi que les non
conformités. Pour ce faire l'application associe des critères quantitatifs pour
calculer un taux de respect des engagements moyennant une extraction des
données du logiciel de gestion à des critères qualitatifs pour évaluer les
aspects affaire et technique des fournisseurs.
Mots clés : Evaluation fournisseur, web, JEE, SPRING, HIBERNATE.

Abstract
This work is part of the final project studies for the license in science and
information and communication technologies. It aims at creating a web
application for the evaluation of suppliers taking into account turnover, the
situation of deliveries in relation with the purchase and the reparation orders
and the non-conformities. To achieve this, the application combines
quantitative criteria to calculate a rate of compliance with commitments by
extracting the data from the management software with a qualitative one to
evaluate the business and technical aspects.
Keywords: Supplier evaluation, web, JEE, SPRING, HIBERNATE.

‫ص‬ّ‫خ‬‫مل‬
‫ّة‬‫ي‬‫طبيق‬ّ‫ت‬‫ال‬ ‫اإلجازة‬ ‫شهادة‬ ‫على‬ ‫للحصول‬ ‫ّروس‬‫د‬‫ال‬ ‫ختم‬ ‫مشروع‬ ‫إعداد‬ ‫إطار‬ ‫في‬ ‫العمل‬ ‫هذا‬ ‫يندرج‬
‫في‬‫المعلومات‬ ‫وتكنولوجيا‬ ‫العلوم‬‫ويهد‬ .‫واالتصاالت‬‫ف‬‫إلى‬‫تطبيق‬ ‫إنشاء‬‫واب‬ّ‫المور‬ ‫لتقييم‬‫دين‬‫أ‬‫خذا‬
‫في‬‫االعتبار‬‫حجم‬‫وحالة‬ ‫الدوران‬ّ‫ت‬‫ال‬‫سليم‬‫ب‬ ‫مقارنة‬‫أوامر‬‫راء‬ّ‫ش‬‫ال‬‫وعدم‬ ‫واإلصالح‬‫لتحقي‬ .‫المطابقة‬‫ق‬
ّ‫ت‬‫ال‬ ‫يجمع‬ ،‫ذلك‬ّ‫م‬‫ك‬ ‫معايير‬ ‫بين‬ ‫طبيق‬‫لحساب‬ ‫ية‬‫احتراما‬ ‫نسبة‬‫اللتزامات‬‫البيانات‬ ‫استخراج‬ ‫خالل‬ ‫من‬
‫بر‬ ‫من‬‫ن‬‫ال‬ ‫امج‬‫ف‬ّ‫صر‬ّ‫ت‬‫ّة‬‫ي‬‫نوع‬ ‫ومعايير‬ّ‫ت‬‫ال‬ ‫الجوانب‬ ‫لتقييم‬ّ‫ي‬‫جار‬ّ‫ت‬‫وال‬ ‫ة‬ّ‫ي‬‫قن‬.‫ة‬
‫الكلمات‬:‫المفاتيح‬‫تقييم‬‫المور‬،‫التجاري‬ ‫اإلصدار‬ ‫جافا‬ ،‫واب‬ ،‫د‬‫منصة‬‫ال‬‫عمل‬‫جافا‬‫سبرين‬‫غ‬،‫بيئة‬
‫الهايبرنت‬

Dédicaces
Au symbole de douceur,
Amour et affection pour le sens du devoir et aux sacrifices
qu’elle a consenti, maman Monia, grâce à qui j’ai pu
arriver à réaliser ce projet.
J’espère que ce travail sera une récompense suffisante.
Que Dieu te garde pour moi.
A mon père Fethi, l’épaule solide, l'œil attentif compréhensif
et la personne la plus digne de mon estime et de mon respect.
Aucune dédicace ne saurait exprimer mes sentiments,
Que Dieu te préserve et te procure santé et longue vie.
A tous mes amis et camarades proches
Vous êtes les meilleurs, merci pour tout votre temps passé à
m’encourager et me motiver.

Remerciements
Avant de présenter mon travail, je voudrais rendre mérite et exprimer
ma gratitude à tous ceux qui m’ont aidé à mener à bien mon projet.
Mon encadrant académique Dr. Hafedh GAHA, pour ses conseils
précieux et qui s'est toujours montré à l'écoute et très disponible tout au
long de la réalisation de ce projet de fin d’études.
Le Directeur des Approvisionnements Aéronautiques de Tunisair
Technics M. Riadh SHIL pour son accueil chaleureux.
Mon encadrant d’entreprise M. Mourad GALLES pour ses précieux
conseils et la qualité de l'encadrement dont il m’a fait profiter tout au long
de ce projet.
Mademoiselle Yossra BEN AMOR, analyste IT à VERMEG Tunisie
pour tout l’apport dont j'ai pu bénéficier concernant le contexte de
développement avec le langage Java.
A tous les employés de Tunisair Technics qui ont déployé tous leurs
efforts pour me fournir les informations nécessaires.
A toutes les personnes qui ont participé, de près ou de loin, à la
réalisation de ce projet.
A tous mes amis qui m'ont apporté leur soutien moral pendant cette
année d'études, je les en remercie sincèrement.
Et finalement, aux respectueux membres du jury qui m’ont honoré
d’avoir accepté d’évaluer mon travail.

Table des matières
Introduction Générale _______________________________________________ 1
Chapitre 1. Présentation Générale __________________________________ 2
Introduction__________________________________________________________ 2
1.1. Cadre du stage_________________________________________________ 2
1.1.1. Organisme d’accueil __________________________________________________ 2
1.1.2. Direction d’accueil ___________________________________________________ 4
1.1.3. Cadre du travail______________________________________________________ 5
1.2. Présentation du projet __________________________________________ 5
1.2.1. Problématique _______________________________________________________ 5
1.2.2. Objectifs ____________________________________________________________ 8
1.2.3. Planification du projet ________________________________________________ 8
1.3. Technologies utilisées ___________________________________________ 8
1.3.1. Le formalisme UML __________________________________________________ 8
1.3.2. Le choix du cycle de développement _____________________________________ 9
Conclusion __________________________________________________________ 14
Chapitre 2. Etude préalable _______________________________________ 15
Introduction_________________________________________________________ 15
2.1. Etude de l’existant_____________________________________________ 15
2.1.1. Le logiciel de Gestion AMASIS_______________________________________ 15
2.1.2. Procédure actuelle _________________________________________________ 16
2.1.3. Critique de l’existant _______________________________________________ 17
2.2. Solution proposée _____________________________________________ 18
Conclusion __________________________________________________________ 18
Chapitre 3. Spécification des Besoins _______________________________ 19
Introduction_________________________________________________________ 19
3.1. Identification des besoins _______________________________________ 19
3.2. Spécification des besoins fonctionnels_____________________________ 19

3.3. Spécification des besoins non fonctionnels _________________________ 20
3.4. Planification des sprints ________________________________________ 21
Conclusion __________________________________________________________ 22
Chapitre 4. Conception Détaillée___________________________________ 23
Introduction_________________________________________________________ 23
4.1. Conception architecturale de la solution __________________________ 23
4.2. Architecture détaillée __________________________________________ 24
4.2.1. Diagramme de Classe ______________________________________________ 24
4.2.2. Diagramme de Cas d’utilisation Général _______________________________ 29
4.2.3. Raffinement Cas « Gérer les utilisateurs »______________________________ 30
4.2.4. Raffinement cas « Evaluer Tiers » ____________________________________ 32
4.2.5. Diagramme de Séquence cas « Authentification »________________________ 32
4.2.6. Raffinement cas « Gérer Litiges »_____________________________________ 33
4.2.7. Diagramme de Paquetage ___________________________________________ 34
Conclusion __________________________________________________________ 36
Chapitre 5. Réalisation___________________________________________ 37
Introduction_________________________________________________________ 37
1.1. Environnement de développement _______________________________ 37
1.1.1. Environnement matériel ____________________________________________ 37
1.1.2. Environnement Logiciel ____________________________________________ 38
1.2. Les langages de programmation _________________________________ 42
1.3. Phase d’implémentation ________________________________________ 44
1.3.1. Contraintes_______________________________________________________ 44
1.3.2. Pratiques adoptées_________________________________________________ 44
1.4. Diagramme de déploiement _____________________________________ 45
1.5. Les interfaces_________________________________________________ 46
Conclusion __________________________________________________________ 49
Conclusion générale _______________________________________________ 50
Nétographie ______________________________________________________ 51
Annexe 1 : Formulaire de pré évaluation des Fournisseurs et des Sous-traitants
____________________________________________________________________ 52

Annexe 2 : Fiche de suivi de la performance des Fournisseurs _____________ 54
Annexe 3 : Fiche de suivi de la performance des Sous-traitants_____________ 55

Table des figures
Figure 1: Organigramme actuel de Tunisair Technics...................................................... 3
Figure 2: Organigramme de la direction d'accueil (DAA) ............................................... 4
Figure 3: Diagramme de Gantt : Planning du stage.......................................................... 8
Figure 4: Processus de Scrum......................................................................................... 10
Figure 5: Le logiciel AMASIS........................................................................................ 16
Figure 6: Planification des Releases du Scrum............................................................... 21
Figure 7: Architecture matérielle de l'application........................................................... 24
Figure 8: Diagramme des Classes................................................................................... 28
Figure 9: Diagramme de cas d'utilisation Général.......................................................... 29
Figure 10: Diagramme de cas d'utilisation « Gérer les utilisateurs » ............................. 30
Figure 11: Diagramme de cas d'utilisation « Evaluer Tiers »......................................... 32
Figure 12: Diagramme de Séquence cas « Authentification »........................................ 33
Figure 13: Diagramme de cas « Gérer litiges » .............................................................. 33
Figure 14 : Diagramme de paquetage............................................................................. 35
Figure 15 : Diagramme de Déploiement......................................................................... 45
Figure 16 : Interface « Accueil » .................................................................................... 46
Figure 17 : Interface « Login »....................................................................................... 46
Figure 18 : Interface « Logout »..................................................................................... 47
Figure 19 : Interface « Gestion des Contrats » ............................................................... 47
Figure 20 : Interface « Ajout Contrat »........................................................................... 48
Figure 21 : Interface « Modifier Contrat » ..................................................................... 48

Table des tableaux
Table 1: Critères de sélection des fournisseurs de la norme ISO 9001 ............................ 7
Table 2: Méthode classique Vs Scrum ........................................................................... 12
Table 3: Description textuelle des Classes ..................................................................... 26
Table 4: Description textuelle du Diagramme de cas d'utilisation Général.................... 30
Table 5: Description textuelle du cas d'utilisation « Ajouter un utilisateur »................. 31
Table 6: Description textuelle du cas d'utilisation « Supprimer un utilisateur »............ 31
Table 7: Description textuelle du cas d'utilisation « Gérer Evènement Estimable »...... 32
Table 8: Description textuelle du cas d'utilisation « Ajouter Litige » ............................ 34
Table 9: Environnement Matériel................................................................................... 37
Table 10: Environnement Logiciel ................................................................................. 38

Glossaire
Abréviation Signification
AMASIS Aircraft Maintenance And Spares Information System
AOG Aircraft On Ground (Avion cloué au sol)
APRS Approbation pour Remise en Service
AS/400 Mini-Ordinateur d’IBM dont le système d’exploitation est l’OS/400
(Operating System 400)
DAA Direction des Achats Aéronautiques
DGAC Direction Générale de l'Aviation Civile
EASA European Aviation Safety Agency (Agence européenne de la sécurité
aérienne)
GMAO Logiciel de Gestion de la Maintenance Assistée par Ordinateur
ISO 9001 Fait partie de la série des normes ISO 9000. Elle définit des exigences
concernant l'organisation d'un système de gestion de la qualité.
Part 145 Certification de l'EASA qui prescrit les exigences des ateliers
d’entretien des aéronefs et éléments d'aéronefs destinés à être remis en
service en transport aérien public
Scrum Abréviation de scrummage = mêlée (Rugby) : schéma d'organisation
de développement de produits complexes
UML Unified Modeling Language

1
Introduction Générale
Le système de management de la qualité est très important pour une organisation
parce qu’il permet de mesurer la performance par rapport aux objectifs fixés, ainsi que
l’engagement dans une démarche d’amélioration continue.
Son application peut varier selon la structure du domaine appliqué. Dans un service
achat, qui est le cas de ce projet, il est difficile de réussir le virage qualité en l'absence
d'un système performant d'évaluation des fournisseurs. La qualité des produits et des
services étant intimement liée à celle des fournisseurs, il sera difficile de maîtriser la
chaîne d'approvisionnement si on ne connaît pas la performance de ces derniers. La
qualité n'arrive pas seule et ne s'achète pas. Il faut la bâtir et l'entretenir constamment.
Un tel « tableau de bord », particulièrement intéressant pour le Service des Achats,
l'est aussi pour la Direction de la Qualité, d'autant plus qu'il constitue la base des
programmes de certification et de partenariat avec les fournisseurs. En contrepartie, sa
mise en application pose des enjeux de taille aussi bien dans la conception, la collecte et
le traitement des données volumineuses et dans la présentation.
Encore une fois, les technologies de l'information et des communications ouvrent des
perspectives intéressantes en la matière. Dans le présent rapport, nous allons montrer
comment peut être si important l'apport de ces technologies pour une compagnie telle que
Tunisair Technics vues les exigences particulières en matière de qualité de son domaine
d'intervention à savoir la maintenance aéronautique. Il comporte cinq chapitres. Le
premier est consacré à une présentation générale du cadre du stage, du projet et des
technologies utilisées. Le deuxième chapitre décrit une étude préalable du projet. Le
troisième chapitre est dédié à la spécification et l’analyse du nouveau système. Le
quatrième chapitre expose la conception détaillée du système, une approche globale et
détaillée. Enfin, le dernier chapitre, présente l’étape de réalisation de l’application.

Chapitre 1. Présentation Générale
Introduction
Dans ce chapitre, nous présenterons une vue globale sur l’organisme d’accueil,
l’infrastructure, le fonctionnement et le domaine d’activité de Tunisair Technics au sein
duquel ce stage a été réalisé. Nous aborderons dans une première section une présentation
de la société, dans la deuxième section une présentation du projet et dans la troisième
section les technologies choisies pour mener à bien la phase d'analyse.
1.1. Cadre du stage
1.1.1. Organisme d’accueil
TUNISAIR :
TUNISAIR est la première compagnie aérienne en Tunisie, inaugurée le 21 octobre
1948. Elle avait transporté plus de 90 Millions de passagers en 65 ans d’existence.
Possédant une flotte de 28 avions en exploration dont 19 Airbus et 9 Boeing. TUNISAIR
organise environ 96 vols par jour vers 116 destinations dans 38 pays.
Tunisair Technics :
Tunisair Technics est un Organisme d’Entretien filial du groupe TUNISAIR
(transporteur aérien).Il réalise les travaux, de maintenance, de révision partielle ou
générale, d'inspection, de réparation, de modification sur les aéronefs et éléments
d'aéronef selon un tableau qui spécifie leurs types et le degré d'intervention allant du
simple test à la révision générale.
L’organisme assure ainsi le maintien des avions dans un état de navigabilité et de
sécurité permanente conformément à la réglementation aéronautique en vigueur. Le
programme d'entretien pour une navigabilité permanente associe les fonctions de
Maintenance, de Contrôle, d'Engineering et de l'Approvisionnement. Pour cela Tunisair
Technics a établi un Manuel des spécifications d'Organisme d’Entretien (MOE)
conformément aux exigences PART 145 qui contient toutes les procédures qui doivent

Chapitre 01. Présentation générale
3
être mises en place afin de se conformer aux exigences de la réglementation européenne
et d’obtenir l’agrément.
TUNISAIR à travers sa filiale Tunisair Technics a obtenu l’agrément PART-145
depuis Janvier 2003 sous le N° EASA .145.0135, qui lui permet aussi d'entretenir et
d'intervenir sur les avions européens et de déclarer leur remise en service à l'issue de tout
entretien en signant l'APRS.
L’organigramme de Tunisair Technics présenté dans la figure suivante montre les
différents directions et départements de l’organisme.
Figure 1: Organigramme actuel de Tunisair Technics

4
1.1.2. Direction d’accueil
Ce stage a été effectué au sein de la Direction des Achats Aéronautiques (DAA). Elle
comporte quatre départements, gérés chacun par un chef de département qui est en contact
permanent avec le directeur responsable de la DAA. Chaque département est subdivisé à
des services comportant des entités, est présenté par la figure suivante :
Figure 2: Organigramme de la direction d'accueil (DAA)
La DAA assure les fonctions suivantes :
 Fonction Gestion et Achat de Services :
 Gestion des révisables et de la sous-traitance Airbus, Boeing et divers ;
 Planification de la matière : Gestion des consommables, gestion des ingrédients
et des divers, et gestion des chantiers de maintenance ;
 Analyse et optimisation des stocks.
 Fonction Achats à l'étranger et locaux :
 Prospection et étude de marchés ;
 Gestion des commandes Airbus, Boeing et divers : Lancement, suivi et traitement
des arrivées et des litiges.
 Fonction Contrôle de Gestion :
Direction
Achats
Aéronautiques
Département
Gestion &
Achat de Services
Département
Achats à l’Etranger
Département
Achats Locaux
Département
Contrôle de Gestion
Département
AOG Desk
Secrétariat de
Direction

5
 Gestion du budget et analyse des coûts ;
 Gestion des contrats d'achat et de sous-traitance ;
 Paiement des achats et des services à l'étranger et locaux.
 Fonction AOG Desk :
 Résoudre les problèmes de pièces de rechange critiques conjointement avec le
personnel de contrôle de la maintenance.
1.1.3. Cadre du travail
Ce projet à Tunisair Technics, rentre dans le cadre d’un projet de fin d’études au
cours de notre formation de technicien supérieur en Science et technologies de
l’information et de la communication au sein de l’ISET’Com. Il a pour but de mettre en
place une application de gestion de processus dans le cadre de l’achat et de la sous-
traitance.
1.2. Présentation du projet
1.2.1. Problématique
Origine :
Afin de répondre à des exigences réglementaires DGAC et Part 145, Tunisair
Technics est appelée à mettre en place d'un système informatisé de gestion des processus
d'achat et de sous-traitance dont principalement le système d'évaluation des fournisseurs.
Ceci requiert de la DAA une gestion et un contrôle rigoureux et proactifs, qui une
fois mis en place permettront en plus, de répondre à des exigences des normes de qualité,
de maîtriser le processus d'achat et de sous-traitance, d'améliorer ses relations avec les
fournisseurs en vue d'éventuels partenariats victorieux, de satisfaire au mieux aux
exigences de ses clients à l’échelle mondiale, et même d’augmenter les gains de
productivité.

6
Motivation :
Face à des marchés fortement compétitifs, caractérisés par une demande de produits
personnalisés, de bonne qualité, livrés dans des délais minimaux et le tout au moindre
coût, une gestion efficace des achats locaux et/ou internationaux peut constituer un
avantage concurrentiel substantiel. En effet, la part du poids des achats se situe
fréquemment entre 40% et 80% du coût total du produit. La sélection des fournisseurs
devient ainsi une décision stratégique qui a un impact crucial sur la performance globale
de toute entreprise.
Aspects de la sélection :
Le problème de la sélection des fournisseurs doit être étudié sous deux aspects :
 La détermination des fournisseurs qui vont rentrer en compétition. Dans notre cas
tous les fournisseurs agréés ; donc disposant d’une certification. L’ANNEXE 1
détaille le formulaire de pré évaluation des fournisseurs et des sous-traitants établi
par la Direction de la Qualité.
 La sélection des meilleurs fournisseurs parmi les alternatives existantes. C'est cet
aspect du problème du choix des fournisseurs qu'on considèrera dans notre travail.
Critères de sélection :
Les critères de sélections des fournisseurs et sous-traitant utilisés dans la norme ISO
9001 sont les suivants.
Rang Critère
1 Prix
2 Livraison
3 Qualité
4 Capacité de production
5 Localisation géographique
6 Capacité technique
7 Gestion et organisation
8 Réputation et position dans l'industrie
9 Situation financière
9 Performance Passée

7
9 Services de réparation
10 Attitude
11 Habileté d'emballage
11 Contrôle des opérations
12 Formation et support
12 Conformité des processus
12 Relations sociales
12 Système de communication
12 Réciprocité de la relation
12 Impression
13 Désir de faire des affaires
13 Volume des achats dans le passé
14 Politique de garantie
Table 1: Critères de sélection des fournisseurs de la norme ISO 9001
On distingue deux types de critères : les critères quantitatifs et ceux qualitatifs. Ils
ont fait l'objet d'une procédure diffusée par la Direction de la Qualité. Les critères de
sélection des fournisseurs se trouvent en Annexe 2. Les critères de sélection des sous-
traitants se trouvent en Annexe 3.
Méthode d'évaluation :
Plusieurs méthodes d'évaluation sont utilisables. La Direction de la Qualité a spécifié
la méthode linéaire avec des pondérations spécifiques.
Mission :
Pour récapituler, la mission de ce sujet est de gérer des fournisseurs et des sous-
traitants en marge de leurs échanges commerciaux avec l’entreprise. Ceux qui disposent
de certificats de vente ou de réparation aéronautiques vont entrer en compétition. Toute
leur activité commerciale sera suivie depuis l’attribution des devis, passant par la
livraison et la facturation et terminant par la garantie. Un certain nombre de critères
d’évaluation devra être enregistré et évalué à chaque échange : respect des délais, des
prix, la qualité des services, les litiges, la garantie, … etc. Aux meilleurs de ces
fournisseurs et sous-traitants seront attribués des contrats.

8
1.2.2. Objectifs
L'objectif de ce travail vise à créer et maintenir un réseau de fournisseurs fiables et
efficaces nécessaires à l'entreprise pour relever les défis concurrentiels croissants. La
capacité de cette dernière à produire un produit de qualité, à un coût raisonnable et de
manière opportune est fortement influencée par la performance des fournisseurs qui est
considérée comme l'un des facteurs déterminants pour le succès.
1.2.3. Planification du projet
A fin de mieux exploiter le temps alloué à la réalisation du projet de fin d’étude, une
bonne gestion de ce temps est nécessaire. La figure suivante vous montre les différentes
tâches et sous tâches qu’on exécutera pendant la période du stage.
Figure 3: Diagramme de Gantt : Planning du stage
1.3. Technologies utilisées
Le choix d’une méthodologie de développement devient une décision primordiale
puisqu’elle permet de guider un utilisateur tout au long du processus de développement
et de fournir un moyen de vérifier, valider et tester les fonctionnalités de l’application.
1.3.1. Le formalisme UML
Le recours à la modélisation est depuis longtemps une pratique indispensable au
développement, car un modèle est prévu pour arriver à anticiper les résultats du codage.

9
Un modèle est en effet une représentation abstraite d’un système destiné à en faciliter
l’étude et à le documenter.
C’est un outil majeur de communication entre les différents intervenants au sein d’un
projet. Aujourd’hui, langage de modélisation UML est le standard industriel de la
modélisation objet N[1].
UML se définit comme un langage de modélisation graphique et textuel destiné à
comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des
architectures logicielles, concevoir des solutions et communiquer des points de vue. Nous
avons choisi UML pour ces deux points essentiels : UML n’impose pas de méthode de
travail particulière, il peut être intégré à n’importe quel processus de développement
logiciel de manière transparente N[2]. En plus UML est une sorte de boîte à outils, qui
permet d’améliorer progressivement les méthodes de travail, tout en préservant les modes
de fonctionnement.
Intégrer UML par étapes dans un processus, de manière pragmatique, est tout à fait
possible. La faculté d’UML de se fondre dans le processus courant, tout en véhiculant
une démarche méthodologique, facilite son intégration et limite de nombreux risques.
1.3.2. Le choix du cycle de développement
La méthodologie est une démarche à suivre pour obtenir un résultat quasi-certain.
Parmi ces différentes méthodologies, on peut citer le modèle en cascade (waterfall)
utilisée souvent pour des projets dont les besoins sont spécifiés dès le début et les
méthodologies agiles (Scrum) qui peuvent être utilisé avec divers types de projets. Pour
ce projet nous avons opté pour la méthode de gestion de projet Scrum N[3].
Le principe de base de Scrum:
 Consiste à dégager en un premier temps le maximum de fonctionnalités à réaliser
pour former le backlog du produit ;
 En second temps, le Scrum master, Product owner et l’équipe font une réunion « la
sprint planning » pour dégager les sprints backlog ;

10
 Ensuite, nous décomposons les sprints backlog en sprint (itération) et durant chaque
sprint on fait une réunion « le Scrum master et l’équipe » pour inspecter l’avancement
du sprint.
 Ainsi et à la fin de chaque sprint on a un produit partiellement fonctionnel appelé
incrément, donc on fait deux réunions la « sprint review » et la « rétrospective » ;
 Et ainsi de suite jusqu’à ce que tous les sprints soient achevés.
Figure 4: Processus de Scrum
Le choix de la méthode Scrum pour le pilotage de notre projet est basé sur les
avantages que ce dernier apporte, vu que cette méthode offre plus de souplesse, plus de
réactivité et une meilleure adaptation au changement due à des itérations courtes.
 Pourquoi la méthodologie Scrum :
Dans cette section nous allons comparer la méthode classique avec la méthode Scrum
à l’aide du tableau suivant :

11
Thème Approche Traditionnelle Approche Agile
Cycle de vie En cascade ou en V, sans
rétroaction possible, phases
séquentielles.
Itérative et Incrémentale
Planification Prédictive, caractérisé par des
plans plus ou moins détaillés sur la
base d’un périmètre et d’exigences
définies et stable au début du projet
Adaptative avec plusieurs niveaux de
planification avec ajustements si
nécessaires au fil de l’eau en fonction
des changements survenus
Documentation Produire en quantité importante
comme support de communication,
de validation
Réduite au strict nécessaire au profit
d’incréments fonctionnels pour
obtenir le feedback du client
Equipe Une équipe avec des ressources
spécialisées, dirigées par un chef
de projet
Une équipe responsabilisée ou
l’initiative et la communication sont
privilégiées, soutenue par le chef de
projet
Qualité Contrôle qualité à la fin du cycle
de développement. Le client
découvre le produit fini
Un contrôle qualité précoce et
permanent, au niveau du produit et
du processus. Le client visualise les
résultats tôt et fréquemment
Changement Résistance vire opposition au
changement. Processus lourds de
gestions des changements acceptés
Accueil favorable au changement
inéluctable intégré dans le processus
Suivi de
l’avancement
Mesure de la conformité aux plans
initiaux
Un seul indicateur d’avancement : le
nombre de fonctionnalités
implémentées et le travail restant à
faire

12
Thème Approche Traditionnelle Approche Agile
Gestion des
risques
Processus district, rigoureux de
gestion des risques
Gestion de risque intégrée dans le
processus global, avec la
responsabilité de chacun dans
l’identification et la résolution des
risques.
Mesure du
succès
Respect des engagements initiaux
en termes de cout et niveau de
qualité
Satisfaction client par la livraison de
valeur ajoutée
Table 2: Méthode classique Vs Scrum
 Pilotage du projet avec la méthodologie Scrum
Scrum se base sur quatre concepts qui sont l’équipe avec les rôles bien définis, les
blocs de temps et les artefacts et les réunions.
Pour piloter un projet, les membres de l’équipe Scrum font recours à plusieurs
techniques. La technique la plus populaire et la plus répandue, consiste à créer des Post-
It note et de les faire coller sur un tableau. L’autre technique consiste à créer des fichiers
sur Excel contenant les informations sur les sprints et les user story, Ce fichier est partagé
entre les membres de l’équipe avec la possibilité de le consulter et de le modifier.
Pour cette raison, plusieurs outils sont apparus offrant des services qui facilitent le
suivi de la priorité, la traçabilité et la gestion du travail. Parmi les outils existant nous
avons choisi d’utiliser Ice Scrum.
o L’équipe et les rôles
Il existe 3 rôles qu’on décrira brièvement :
 Directeur de produit ou (Product owner en anglais) : Représente le client ou le
client lui-même et il est généralement expert dans le domaine. Et contrairement à ce que
son nom l’indique, ses responsabilités sont limitées à l'établissement des limites des
projets et de chaque itération.

13
 Scrum master : gérant de l’application, assigner souvent comme le manager du
projet, veille à ce que chacun travaille en maximum de sa capacité et essaye d’éliminer
les obstacles.
 Equipe de Scrum (Scrum Team): formé par des personnes chargées d’implémenter
les besoins du client. Cette équipe est formée d’infographiste, développeurs, testeurs et
concepteurs.
o Les réunions
Scrum est dirigé par quatre types de réunion :
 Sprint planning (planification du sprint): pour planifier les itérations ou sprints
(soit pour présenter la liste du product owner ou pour décomposer le projet en tâches) et
discuter des user stories;
 Mêlée quotidienne ou Scrum quotidien (Daily Scrum) : cette réunion qui se fait
debout, quotidiennement et à une durée de 15 minutes. Le Scrum master inspecte l’état
de l’avancement du sprint et identifie les problèmes. Au cours de ce meeting ils doivent
répondre à trois questions (Qu’est-ce que j’ai fait hier? Qu’est-ce que je fais aujourd’hui?
Quels sont les problèmes?);
 Sprint review (Revue du sprint): bilan de l’itération et pour faire une présentation
au client afin d’avoir son feedback. L’objectif ici est de valider le logiciel qui a été produit
pendant ce sprint;
 Retrospective : Cette étape se fait à la fin de chaque sprint, on inspecte le processus
du travail et essaye de déduire ce qui a fonctionné ou pas. Cette réunion dure de 15 à 30
minutes. On applique un principe « Start/Stop/Continue »: ce qu’on aimerait " faire,
arrêter de faire et continuer à faire ".

14
o Les artéfacts
 Burn down chart :
C’est un tableau d’analyse qui permet d’inspecter la progression du sprint.
 Le Backlog de sprint (sprint Backlog):Le backlog de sprint est une liste de tâches
identifiées par l'équipe de Scrum et qui doit être achevée au cours du sprint. Lors
de la réunion de planification du sprint, l'équipe sélectionne un certain nombre
d'éléments produits du carnet de commandes, généralement sous forme d'histoires
utilisateurs, et identifie les tâches nécessaires pour compléter chaque user story.
La plupart des équipes estiment également le nombre d'heures. Chaque tâche aura
quelqu'un de l'équipe pour l’achever.
 Le backlog du produit (product backlog) :C’est un artéfact important du Scrum
représenté sous forme de tableau contenant les caractéristiques fonctionnelles ou
techniques qui constituent le produit souhaité. Les caractéristiques fonctionnelles
(user story) et les caractéristiques techniques (technical story).
Conclusion
Dans ce chapitre nous avons présenté le contexte général du projet, ensuite nous
avons exposé la problématique et les objectifs de notre travail et terminé avec le
chronogramme de son acheminement. La définition des connaissances et les technologies
nécessaires à notre projet permettent de passer à la phase suivante qui consiste à la
spécification et l’analyse du nouveau système. Cette spécification détaillée permettra de
mieux comprendre la conception de notre projet et qui fera l’objet du chapitre suivant.

Chapitre 2. Etude préalable
Introduction
L'Etude de l’existant est une étape importante pour la mise en route d’un projet
informatique ou autre type de projet qui permet de définir le processus métier et de
dégager les imperfections du système existant afin de l’améliorer ou le corriger.
2.1. Etude de l’existant
2.1.1. Le logiciel de Gestion AMASIS
AMASIS (Aircraft Maintenance And Spares Information System) est le progiciel de
gestion technique intégré (GMAO) utilisé par les services de Tunisair Technics dans la
gestion de sa maintenance aéronautique. Il est commercialisé depuis 25 ans par la société
IFRSKEYES ; une filiale d’Airbus créée en 1987.
Il est installé sur un mini-ordinateur d’IBM : l’AS/400 appelé encore system i5. Il est
développé en Java/400 et utilise la base de données de l’AS/400 qu’est la db2.
Il présente une architecture modulaire composée de 14 modules distincts et
complémentaires :
 La Gestion de la chaine logistique : Permet de gérer et suivre les expressions de
besoins, les niveaux des stocks, les flux de matière et d’assurer les
approvisionnements et la facturation relative aux achats, réparations, locations ou
échanges standards réalisés. Il comporte aussi un module de gestion des contrats.
 La Gestion Financière ;
 Le suivi de navigabilité ;
 La maintenance corrective ;
 La maintenance planifiée ;
 La Gestion de la production ;
 La Gestion de la Main d’œuvre ;

16
 La Gestion des documents de Référence. Etude préalable
Figure 5: Le logiciel AMASIS
2.1.2. Procédure actuelle
La majorité écrasante des processus d’achat et de sous-traitance sont dominés par un
traitement manuel. Ci-après la situation actuelle des différents processus :
 Evaluation des fournisseurs : le logiciel d’AMASIS ne comportant pas un tel outil
et en l’absence d’un outil approprié c’est du manuel pratiquement, si ce n’est
l’utilisation de quelques états récapitulatifs édités à partir d’AMASIS pour dresser le
tableau d’évaluation. Aucune gestion informatisée n’existe pour gérer les accusés de
réception et les notifications d’envois des fournisseurs qui ne sont pas pris en
considération jusque-là. Les dates de ces éléments étant calculées grossièrement à
partir de la date d’une pièce : Ajout de 3 jours pour un tiers local et 7 jours pour un
tiers étranger.
 Gestion des licences : Un outil performant assurant cette fonction, est contenu dans
AMASIS mais n’est pas exploité. La gestion des licences se fait aussi manuellement ;

17
 Gestion des Contrats : Un outil novice assurant cette fonction est contenu dans
AMASIS et ne satisfait pas aux besoins car il n’intègre aucun prix ni remise dans les
lignes de contrats. La gestion des contrats se fait donc aussi manuellement.
 Gestion des Commandes d’Achat : Un outil performant assurant cette fonction, est
contenu dans AMASIS et utilisé. La gestion des Commandes d’Achat est donc
informatisée.
 Gestion des Commandes de Réparation : Un outil performant assurant cette
fonction, est contenu dans AMASIS mais n’est pas utilisé en sa totalité. En faite la
gestion des devis n’y est pas utilisée quoi que très performante, pour cause qu’il ne
s’adapte pas à une règle de gestion de la procédure actuelle à savoir le logiciel
AMASIS n’accepte pas d’avoir la date de la Commande de Réparation antérieure à
la date du Devis. La gestion des Commandes de Réparation se fait donc aussi
manuellement dans une partie importante qu’est la gestion des devis.
 Gestion des Price Catalogs : Ces informations sont importantes pour l’évaluation
car elles donnent des prix d’achat références. Leur gestion est aussi manuelle.
 Gestion des Capability Lists : Ces informations sont importantes pour l’évaluation
car elles donnent des prix de réparation références, pour les différents types
d’intervention. Leur gestion est aussi manuelle.
 Gestion des Litiges : AMASIS ne supporte pas cette fonction que très peu. En effet
une simple zone de texte libre est prévue dans les Bons de Livraison servant à cet
effet. Quoi qu’utilisée par le service, elle reste insuffisante pour détailler le litige. En
effet il faudrait qu’il y ait au moins une date de constat de l’anomalie, et une
codification détaillée des causes de litiges.
2.1.3. Critique de l’existant
La majorité écrasante des processus d’achat et de sous-traitance sont dominés par un
traitement manuel. Tout le processus d’évaluation des fournisseurs se fait manuellement
via des documents non maitrisés nécessitant l’intervention d’un effectif important
engendrant une perte de temps énorme.
Le travail manuel et non maitrisé qui caractérise cette tâche stratégique pour la
compagnie, altère considérablement son fonctionnement engendrant des retards énormes

18
pour l’exécution de ses taches dont les délais fixés par la norme sont dépassés largement.
En plus, il n’a pas la main mise sur le Système de Gestion (AMASIS) ce qui représente
un écart majeur dans la réglementation qualité en vigueur.
2.2. Solution proposée
Tenant compte des critiques citées ci-dessus et des besoins d'informatiser la fonction
d’évaluation des fournisseurs pour la DAA, la solution est de :
 Remédier au problème majeur de gestion manuelle des devis des Commandes de
Réparation et faire le nécessaire pour utiliser le module Gestion des devis d’AMASIS.
 Assister les utilisateurs de la DAA à démarrer l’exploitation du module Gestion
des licences d’AMASIS.
Ces deux points ont été traités avec mon encadrant d’entreprise, et ne figureront pas dans
la suite de ce rapport
 Concevoir et développer une application permettant d’assurer les deux parties
constituantes du processus de l’évaluation des fournisseurs :
 Fonction de Gestion :
 Gérer les Contrats ;
 Gérer les Price Catalogs ;
 Gérer les Capability Lists ;
 Gérer les Litiges.
 Fonction Qualité :
 Récapituler activité Tiers ;
 Evaluer Tiers.
Conclusion
A la fin de ce chapitre nous avons détaillé, analysé et critiqué la procédure existante
ce qui nous permet d’avoir une idée claire sur les spécifications de notre future application
qui seront détaillées dans le chapitre suivant.

Chapitre 3. Spécification des Besoins
Introduction
Pour réussir un projet, il est obligatoire de mener à bien l’analyse et la spécification
des besoins. Etant la première étape primordiale du cycle de vie d’un logiciel, il est
fondamental de bien déterminer les exigences exprimées par l’utilisateur. Afin de
comprendre le contexte de l’application nous allons, au cours de cette étape, déterminer
les besoins fonctionnels, les besoins non fonctionnels ainsi que les acteurs qui interagiront
avec notre application.
3.1. Identification des besoins
Identification des acteurs
Les différents acteurs qui se présentent pour notre système se répartissent en trois
catégories principales à savoir :
 Administrateur : Il a pour rôle de gérer les comptes des utilisateurs, de gérer les
auditeurs, les audités, gérer les référentiels, les formations réglementaires et les
secteurs d’activité.
 Utilisateur de Gestion : Il a un rôle de gestion des litiges, des Contrat, prix.
 Gestion de Qualité : Il a un rôle de qualité qui lui permet d’évaluer Tiers
3.2. Spécification des besoins fonctionnels
Ce sont les fonctionnalités du système et les actions qu’un acteur peut effectuer afin
de répondre à la demande de l’utilisateur.
Nous allons dans cette partie identifier les besoins fonctionnels par acteurs, c’est-à-
dire l’action que peut effectuer chaque intervenants sur le système et ceci dans le but de
préciser le rôle de chaque acteur au sein du futur logiciel.
 Besoins fonctionnels pour l’administrateur:
 Gérer les Utilisateurs.
 Gérer les Logs.

l’outil
20
 Gérer les Paramètres.
 Besoins fonctionnels de l’Utilisateur de gestion:
 Gérer les Contrats.
 Gérer les Price Catalogs.
 Gérer les Capability Lists.
 Gérer les Litiges.
 Besoins fonctionnel de l’Utilisateur de qualité:
 Récapituler activité Tiers ;
 Evaluer Tiers.
 Besoins fonctionnel pour tous les utilisateurs :
 S’authentifier pour accéder à l’application : l’utilisateur doit être authentifié pour
accéder à l’interface le concernant selon son rôle dans le système.
3.3. Spécification des besoins non fonctionnels
Un besoin non fonctionnel aussi appelé besoin d’affaire, Ce sont les contraintes et
restrictions liés à l’environnement lors de l’implémentation de l’application.
Les besoins non fonctionnels sont :
 La disponibilité : Le système constitue le cœur de l’activité, il est obligatoire qu’il
soit toujours en service.
 La sécurité : C’est primordial pour l’application, étant donné qu’elle gère des
données confidentielles. Une authentification et un cryptage des données sensibles
est indispensable.
 La performance : Le fait que l’application est multiutilisateur et contient un nombre
de données important, le temps de traitement doit être réduit impérativement.
 L’ergonomie : L’utilisation d’une interface utilisateur simple et facile à comprendre,
pour qu’elle ne soit pas ambiguë à tous utilisateurs ignorant l’informatique.
 L’interopérabilité : On n’a pas besoin d’installer quoi ce soit pour pouvoir utiliser
cette application, juste un navigateur web, en plus elle est multiplateforme.
 La clarté des documents : Les documents et les rapports que le système imprimera
seront lisibles.

l’outil
21
3.4. Planification des sprints
La réunion de planification des sprints (sprint planning) est l’événement le plus
important dans Scrum. Le but de cette réunion est de préparer le planning de travail et
d’identifier le backlog des sprints.
L’un des produits de cette réunion est le choix de la durée des sprints et qui diffère
selon la complexité du projet et la taille de l’équipe. Pour notre projet nous avons choisi
de développer deux releases:
Le premier sera gestion des ressources et des établissements et le deuxième sera la
gestion des processus.
Pour notre cas la durée de 10 jours pour un sprint semble adéquate.
La suivante résume notre planning de travail
Figure 6: Planification des Releases du Scrum
Plan de
Release
Sprint#1 Sprint#2 Sprint#3 Sprint#4
Gérer Personnel
Gérer Direction
Gérer Référentiels
Gérer Secteur
Gérer Personnel
Gérer Processus
de Gestion
Gérer Notification
Gérer Validation
Gérer Tiers
Gérer CR
Gérer CA
Authentification
Gérer Litiges

l’outil
22
Conclusion
Après avoir distingué les rôles de chaque utilisateur, spécifié les besoins fonctionnels
et non fonctionnels et planifié nos sprints, il est temps de commencer à concevoir et à
développer notre application. Dans le chapitre suivant, nous allons nous initier avec la
conception et le développement du premier release.

Chapitre 4. Conception Détaillée
Introduction
Une fois qu’on a déterminé le backlog du produit, nous le découpons en petites
parties qui s’appellent « release ». La release est constitué d’itération ou sprint. La durée
de la release est déterminée par le « product owner » en collaboration avec l’équipe. Au
niveau de ce chapitre, nous allons traiter les histoires utilisateurs de nos sprints afin de
produire les releases pour produire logiciel potentiellement livrable.
4.1. Conception architecturale de la solution
Architecture matérielle
Notre application est une application web qui se connecte à un serveur de base de
données distant, via Internet, afin de récupérer les données. Ceci nécessite aussi
l’intégration d’un serveur web entre l’application client et le serveur de base de données.
D’où l’architecture de notre application à 3 niveaux (architecture 3-tiers), partagée entre
les trois éléments suivants :
 L’utilisateur (Administrateur, Utilisateur de Gestion, Gestion de Qualité) ;
 Le serveur Web : Vu que les données seront communiquées entre deux
environnements hétérogènes, le rôle principal du serveur web est de gérer la
communication entre l’utilisateur et le serveur de base de données ;
 , Le serveur de base de données fournit les données au serveur web.

24
Figure 7: Architecture matérielle de l'application
4.2. Architecture détaillée
Maintenant, nous détaillerons la conception de notre solution en présentant aussi bien
les diagrammes des classes, le diagramme association, les diagrammes de package, ainsi
que quelques diagrammes d’activités de notre système.
4.2.1. Diagramme de Classe
Notre base des données est une base regroupant plusieurs informations cohérentes
qui seront d’une utilité majeure. Afin de détailler l’architecture de cette base, Nous avons
développé le modèle Entité-Association. A partir de la figure 8, nous présentons le
diagramme de classes du paquet modèle qui comporte les différents objets permettant le
déroulement des scénarios de notre application.
Ces classes représentent les différentes tables de notre base mappées grâce au
« Framework Hibernate ». Le diagramme suivant illustre les différentes classes créées
pour notre système :
Entité Description
Applicabilité Elle représente l’applicabilité des pièces
BonDeReception Elle représente l’entête du Bon de Réception
Catalogue Elle représente la liste des prix d’achat des pièces
Certificat Elle représente les données Relatives à un certificat

25
Entité Description
Commande Elle représente l’entête d'une Commande
Constructeur Elle représente un type de Tiers
ContactTiers Elle représente les données relatives à la personne de
contact de tiers
Contrat Elle représente l’entête du Contrat
CotationFournisseur Elle représente l’entête de la Cotation Fournisseur
DemandeDeCotation Elle représente l’entête de la Demande de Cotation
Devise Elle représente la devise utilisée
Evaluation Elle représente l’évaluation du Tiers
Facture Elle représente l’entête de Facture
Fournisseur Elle représente le type de Tiers
Indicateur Elle représente les champs d’évaluation
LigneDeFacture Elle représente les Factures passées par un Tiers
Litige Elle représente les types de litiges
Magasin Elle représente le magasin émetteur de la commande
ModeDePaiement Elle représente le Mode de Paiement
ModeDeReglement Elle représente le Mode de Règlement
MotifLitige Elle représente l’explication de litige
OrganismeDeCertificat
ion
Elle représente l’organisme de Certification
PartNumber Elle Représente les pièces d’un avion
PersonneContact Elle représente la personne de Contact
Piece Elle représente le numéro de la série de la pièce
PosteDeCommande Elle représente les commandes passées par la société.
PosteDeContrat Elle représente les Ligne de Contrat
PosteDeDemandeDeCo
tation
Elle représente les Cotations passées par la société.
PostesCotationFournis
seur
Elle représente les Cotations passées par les Fournisseurs
PostesDeReception Elle représente les Postes de Réceptions

26
Entité Description
ReceptionRejetee Elle représente la Réception Annulée
RepresentantTiers Elle représente le Représentant du Tiers
Société Elle représente la Société (Tunisair, Tunisair Express, ….)
SousTraitant Elle représente le tiers Réparateur
Tiers Elle représente le tiers
Travail Elle représente le Type de Travail (Test, Repair,
Overhaul)
TypeContrat Elle représente le Type de contrat (contrat d’achat, contrat
de réparation)
TypeDePaiement Elle représente le type de paiement
Table 3: Description textuelle des Classes

27

28
Figure 8: Diagramme des Classes

29
4.2.2. Diagramme de Cas d’utilisation Général
Un cas d'utilisation (en anglais use case) permet de mettre en évidence les relations
fonctionnelles entre les acteurs et le système étudié. Le format de représentation d'un cas
d'utilisation est complètement libre, mais UML propose un formalisme et des concepts
issus de bonnes pratiques.
Figure 9: Diagramme de cas d'utilisation Général
Acteur Cas d’utilisation
Administrateur  Gérer les Utilisateurs.
 Gérer les Logs.
 Gérer les Paramètres.

30
Utilisateur Qualité  Gérer les Litiges.
 Gérer les Contrats.
 Gérer les Capability Lists
 Gérer les Price Catalogs
Utilisateur Gestion  Evaluer Cotation
 Consulter Tiers
 Evaluer Tiers
Table 4: Description textuelle du Diagramme de cas d'utilisation Général
4.2.3. Raffinement Cas « Gérer les utilisateurs »
Figure 10: Diagramme de cas d'utilisation « Gérer les utilisateurs »
Titre Ajouter un Utilisateur
Acteur initiateur Administrateur
But du cas Ajouter un nouvel utilisateur de l'application
Pré-condition Application, BD, Serveur d’application
Post-condition en
cas de succès
L'utilisateur peut accéder à l'application.

31
Titre Ajouter un Utilisateur
Description du
scénario
1. Ce cas commence quand l'administrateur demande l’ajout d’un
nouvel utilisateur.
2. le système affiche un formulaire d'ajout.
3. Après le remplissage du formulaire, l'administrateur valide les
coordonnées.
4. Le système vérifie si tous les champs sont remplis.
5. Si les champs sont vides. Alors Exception(E1)
6. Sinon le système vérifie si l’utilisateur existe déjà. Alors
Exception (E2).
7. Si l’utilisateur n’existe pas alors il va être enregistré et le système
affiche un message de succès
Exception (E1): s’il y'a un champ non rempli ou il y'a une erreur à la
connexion à la base de données. Le système affiche un message
d'erreur
(E2): si l’utilisateur existe, Le système affiche un message
d’erreur.
Table 5: Description textuelle du cas d'utilisation « Ajouter un utilisateur »
Titre Supprimer un Utilisateur
Acteur
initiateur
Administrateur
But du cas Supprimer un utilisateur de l'application
Post-condition
en cas de
succès
L'utilisateur ne peut pas encore accéder à l'application.
Description du
scénario
1. Ce cas commence quand l'administrateur demande la
suppression d’un utilisateur.
2. Le système affiche une interface de suppression avec la liste des
utilisateurs déjà enregistrés.
3. L'administrateur choisit l’utilisateur voulu et demande sa
suppression.
4. Le système effectue la suppression et affiche un message de
succès de suppression.
Table 6: Description textuelle du cas d'utilisation « Supprimer un utilisateur »

32
4.2.4. Raffinement cas « Evaluer Tiers »
Figure 11: Diagramme de cas d'utilisation « Evaluer Tiers »
Titre Gérer Evènement Estimable
Acteur
initiateur
Utilisateur Qualité
But du cas Evaluer un Tiers
Post-condition
en cas de
succès
L’évènement ajouté pour faciliter l’évaluation .
Description du
scénario
1. Ce cas commence quand l'utilisateur demande d’évaluer un tiers.
2. le système affiche un formulaire d’indication des Evaluations.
3. Après le remplissage du formulaire, l’utilisateur valide les
coordonnées.
5. l’utilisateur demande d’imprimer l’évaluation
Table 7: Description textuelle du cas d'utilisation « Gérer Evènement Estimable »
4.2.5. Diagramme de Séquence cas « Authentification »
Les diagrammes de séquences peuvent servir à illustrer chaque cas d’utilisation et
forment une représentation temporelle des objets et de leurs interactions.
Nous débutons par le diagramme d’authentification.

33
A ce stade, nous commençons par l’élaboration des diagrammes de séquence
systèmes à partir des cas d’utilisation détaillés précédemment.
En se référant aux descriptions textuelles élaborées dans la section précédente, nous
présenterons les diagrammes de séquences système adéquats. Nous constatons que certain
de ces cas sont similaires, nous avons choisi donc de faire certains cas d’utilisation.
Figure 12: Diagramme de Séquence cas « Authentification »
4.2.6. Raffinement cas « Gérer Litiges »
Figure 13: Diagramme de cas « Gérer litiges »

34
Titre Ajouter Litige
Acteur
initiateur
Utilisateur Qualité
But du cas Ajouter un nouvel Litige
Post-condition
en cas de
succès
L'utilisateur ajout un type de litige.
Description du
scénario
1. Ce cas commence quand l’utilisateur demande l’ajout d’un
nouveau litige.
2. Le système affiche un formulaire d'ajout.
3. Après le remplissage du formulaire l'utilisateur valide les
coordonnées.
5. Si les champs sont vides. Alors Exception
(E1)
6. Sinon le système vérifie si le litige
existe déjà. Alors Exception (E2).
7. Si le litige n’existe pas alors il va être
enregistré et le système affiche un message de succès
Exception (E1): s’il y'a un champ non rempli ou il y'a une erreur à la connexion
à la base de données. Le système affiche un message d'erreur
(E2): si litige existe, Le système affiche un message d’erreur.
Table 8: Description textuelle du cas d'utilisation « Ajouter Litige »
4.2.7. Diagramme de Paquetage
Afin de garantir l’extensibilité de l’application et de minimiser le temps de
développement, nous avons découpé les différentes classes en modules N[4]. En effet,
cette décomposition nous permet de mieux structurer notre système et faciliter la
compréhension de ses fonctionnalités.
L’organisation de l’ensemble des modules constitue l’architecture logicielle de notre
système.
En effet on peut, avant présenter le diagramme de paquetage, distribuer les différents
paquets de notre diagramme (la figure 8) sur les différentes couches du modèle MVC
comme suit :
 Le modèle : A ce niveau, nous trouvons le paquetage model qui contient les objets
de persistance. Ces objets sont des classes utilisées par tous les paquetages de

35
l’application. Elles représentent les tables de notre base des données. La principale
propriété de ces classes est qu’elles ne contiennent aucune méthode de traitement.
Elles contiennent simplement les getters et les setters pour récupérer ou bien
retourner la valeur d’un attribut. Ces classes contiennent ainsi le mappage avec
notre base de données relationnelle en utilisant la méthode d’annotations. On veut
dire par mappage la liaison entre les classes java avec les tables de la base.
En effet le mappage englobe la correspondance des attributs avec les colonnes de
la table associée à cette classe ainsi que le mappage des relations existantes entre
les tables, par exemple la relation one-to-many ou many-to-many.
 Le contrôleur : A ce niveau, nous trouvons les Managed Beans plus le contrôleur
« faces servlet » du « Framework JSF » pour la partie web. Concernant la partie
desktop, le contrôleur implémente donc un Action Listée c’est à dire un « écouteur »
de boutons.
 La vue : A ce niveau, nous trouvons seulement les pages xhtml (facelet du
Framework JSF), JSP (Java Server Pages) uniquement sans actions avec une
référence sur le Modèle pour faire des changements (en lecture) sur la vue en cas
de changement du Modèle.
Figure 14 : Diagramme de paquetage

36
Conclusion
A ce stade, nous avons achevé le développement de notre dernier release de notre
application pour produire un logiciel complet et fonctionnel. Il nous reste cependant une
dernière étape qui consiste à implémenter l’application auprès du client final.

Chapitre 5. Réalisation
Introduction
La phase de clôture ou de fermeture est la dernière phase dans le cycle de
développement d’un logiciel avec Scrum. Cette phase est souvent appelée sprint de
stabilisation ou durcissement. Les tâches effectuées pendant cette phase ne sont pas
claires, et elles dépendent fortement du type de déploiement du logiciel.
Pour notre projet, on consacrera ce chapitre pour la présentation des langages et outils
de programmation utilisés pour la réalisation de notre application ainsi que le
déploiement. Nous finissons par la suite avec quelques interfaces graphiques du logiciel
fourni.
1.1. Environnement de développement
L’environnement de développement est un terme qui désigne l’ensemble des outils
et de langages utilisés pour l’implémentation d’une solution informatique. Nous
commençons par l’environnement matériel.
1.1.1. Environnement matériel
Pour le développement de cette application, Nous avons utilisé un pc avec la
configuration suivante :
Model ASUS X556U
CPU Intel Core i5-6200U (up to 2.80 GHz, 3M mémoire cache)
RAM 8 Go DDR3
GPU NVIDIA® GeForce® GT 920M (2 Go dédiée DDR3)
HDD 1To
SE Windows 10 64Bits pro
Table 9: Environnement Matériel

38
1.1.2. Environnement Logiciel
Les outils utilisés pour le développement des projets concernent :
 Le kit de développement en Java (JRE).
 La mise en place d'un environnement de développement (Eclipse Néon 2.0).
 L'installation et la configuration du serveur Java (Apache Tomcat V8.0).
 le SGBD MySQL 5
Les logiciels qui ont été utilisés pour l’implémentation de notre solution sont les
suivants:
Version Apache Tomcat 8.0
Version Eclipse Néon 2.0
Version Spring IDE 3.6.3.201411271034-RELEASE
Version Hibernate Tools for Eclipse 3.5.1.v20130102-1835-H100-Final
Version du Framework Hibernate Hibernate-release-4.3.8.Final
Version du Framework Spring Spring-Framework-4.1.5.RELEASE-dist
Version jsf Primefaces 2.0
Table 10: Environnement Logiciel
Eclipse
Eclipse est un IDE (environnement de développement intégré) écrit en Java,
extensible par des greffons, multi-langages et multi-plates-formes. Il est d'abord conçu
pour le langage Java mais ses nombreux greffons en font un environnement de
développement pour de nombreux autres langages de programmation N[5].
JRE
JRE : Java SE Runtime Environment (couramment JRE) c’est l’environnement où le
code java va être compilé afin que la machine virtuelle puisse l’interpréter puis l’exécuter.
Nous utiliserons le JRE1.8u121

39
Apache Tomcat
Apache Tomcat: C’est un serveur Java EE obligatoire pour le développement des
pages web dynamiques. Pour combler le manque de serveurs http classique qui ne
comprennent pas les servlets et JSP celui-ci utilise un moteur de servlet
Hibernate
Hibernate est un (ORM) mapping objet-relationnel N[6], c’est un ensemble de
bibliothèques qui vont ajouter une surcouche au SGBD pour permettre aux développeurs
de manipuler seulement les objets et ne plus se soucier de la base de données et des
requêtes SQL.
Hibernate Tools
Hibernate Tools est un ensemble d'outils pour Hibernate3 mis en œuvre comme une
suite intégrée de plugins Eclipse. Hibernate Tools est un élément essentiel de JBoss Tools
et donc également partie de JBoss Développer Studio.
Intègre les fonctionnalités suivantes à éclipse : Lapping Editor, Console, Reverse
engineering, etc.
Springs IDE
Springs IDE est un projet open-source qui fournit un ensemble de plugins pour l'IDE
Eclipse. Après l'installation des plugins Springs IDE, votre IDE comprend vos projets de
point de vue du cadre de Springs et vous offre une grande variété de fonctionnalités
supplémentaires qui font qu'il est plus facile et plus commode de travailler avec des
projets Springs dans Eclipse.

40
Springs Framework
Springs est considéré comme un conteneur dit « léger ». La raison de ce nommage
est expliquée par Erik Gollot dans l’introduction du document Introduction au Framework
Spring4 N[7].
Springs est effectivement un conteneur dit « léger », c’est-à-dire une infrastructure
similaire à un serveur d'applications J2EE. Il prend donc en charge la création d’objets et
la mise en relation d’objets par l’intermédiaire d’un fichier de configuration qui décrit les
objets à fabriquer et les relations de dépendances entre ces objets. Le gros avantage par
rapport aux serveurs d’application est qu’avec SPRING, les classes n’ont pas besoin
d’implémenter une quelconque interface pour être prise en charge par le Framework (au
contraire des serveurs d’applications J2EE et des Embus). C’est en ce sens que SPRING
est qualifié de conteneur « léger ».
Le contexte le plus important qu’on a utilisé pour notre application c’est IOC :
l’inversion de contrôle est assurée de deux façons différentes : la recherche de
dépendances et l'injection de dépendances, la programmation orientée aspect, une couche
d’abstraction.
Power Designer
C’est un logiciel de modélisation. Il permet de modéliser les traitements
informatiques et leurs bases de données associées. Créé par SDP sous le nom
AMC*Designer, racheté par Powersoft, ce logiciel est produit par Sybase depuis le rachat
par cet éditeur en 1995. Hors de France, la version internationale est commercialisée par
Sybase sous la marque Power Designer N[8].
Power AMC permet de réaliser tous les types de modèles informatiques. Il reste un
des seuls qui permet de travailler avec la méthode Merise, cela permet d'améliorer la
modélisation, les processus, le coût et la production d'applications.

41
WampServer
J’ai utilisé WampServer puisque c’est une plate-forme de développement Web sous
Windows pour des applications Web dynamiques. Il m’a permis donc de pouvoir
concevoir le site web transactionnel en local sur mon ordinateur.
WampServer est très complet puisqu’il dispose du serveur Apache2, gère des fichiers
du langage de scripts PHP et d’une base de données MySQL. Il possède également PHP
MyAdmin qui permet de gérer les bases de données.
Adobe Dreamweaver
Si un simple éditeur de texte, comme Notepad ou Bloc-notes fait très bien l’affaire.
J’ai tout de même choisi d’utiliser Adobe Dreamweaver.
Tout d’abord pour son auto complétion HTML et CSS qui est très pratique, agréable
et rapide. Ainsi que par les différents modes de conception offerts, la transition entre les
différents modes de conception est très rapide ce que je trouve très agréable lors du
commencement de la structure du site web. Il me permet de voir instantanément si mes
éléments graphiques ont été correctement appelés, structurés et positionnés.
Microsoft Word
Microsoft Word est souvent appelé simplement Word ou MS Word. C’est un
traitement de texte commercial largement utilisé a été conçue par Microsoft. MS Word
est un composant de la suite MS Office de logiciels de productivité. Il a été initialement
lancé en 1983 et a depuis été révisée de nombreuses fois. Il est disponible sous Windows
et Macintosh.

42
Microsoft Project
Microsoft Project est un logiciel de gestion de projet le plus populaire au monde,
développé et vendu par Microsoft. MS Project est conçue pour aider les gestionnaires de
projets à élaborer des plans, l'affectation de ressources à des tâches, suivi des progrès, la
gestion des budgets et l'analyse des charges de travail, etc.
1.2. Les langages de programmation
Java
Java est un langage de programmation informatique d'usage général qui est
concurrente, sur la base de classe, orienté objet, et spécifiquement conçu pour avoir aussi
peu de dépendances de mise en œuvre possible. Il est destiné à permettre aux
développeurs d'application « écrire une fois, exécuté partout » (WORA : « write once,
run anywhere »), ce qui signifie que le code Java compilé peut fonctionner sur toutes les
plateformes qui supportent Java sans la nécessité d'une recompilation. Des applications
Java sont généralement compilées en byte code qui peut fonctionner sur n’importe quelle
machine virtuelle Java (JVM) indépendamment de l'architecture informatique. En 2015,
Java est l'un des langages de programmation les plus populaires dans l'utilisation, en
particulier pour les applications web client-serveur.
HTML5
Le HTML est un langage qui a pour rôle de gérer et organiser le contenu d'une page
web. C'est un langage de description de données, et non un langage de programmation.
J'ai utilisé le HTML 5 qui est la dernière version du HTML qui est actuellement toujours
en développement.

43
CSS3
Le rôle du CSS est de gérer l'apparence de la page web (agencement, positionnement,
décoration, couleurs, taille du texte…). Ce langage est le complément du langage HTML
pour obtenir une page web avec du style. Le navigateur parcourt le document HTML.
Lorsqu'il rencontre une balise, il demande à la CSS de quelle manière il doit l'afficher.
JavaScript
JavaScript est un langage interprété par le navigateur. Le JavaScript est un langage
« client », c'est-à-dire exécuté chez l'utilisateur lorsque la page Web est chargée. Il a pour
but de dynamiser les sites Internet.
UML
Le langage de modélisation unifié, de l'anglais Unifie Modeling Language (UML),
est un langage de modélisation graphique à base de pictogrammes conçu pour fournir une
méthode normalisée pour visualiser la conception d'un système. Il est couramment utilisé
en développement logiciel et en conception orientée objet.
HQL (Hibernate Query Language) :
Hibernate Query Language (HQL) est un langage de requête orientée objet, similaire
à SQL, mais au lieu d'opérer sur les tables et colonnes, HQL travaille avec des objets
persistants et leurs propriétés. Les requêtes HQL sont traduits par Hibernate en requêtes
SQL classiques qui effectuent à tour de rôle action sur la base de données.

44
Bootstrap
Bootstrap est une collection d'outils utile à la création du design (graphisme,
animation et interactions avec la page dans le navigateur ... etc. ...) de sites et
d'applications web. C'est un ensemble qui contient des codes HTML et CSS, des
formulaires, boutons, outils de navigation et autres éléments interactifs, ainsi que des
extensions JavaScript en option.
1.3. Phase d’implémentation
1.3.1. Contraintes
Pour garantir la fiabilité, l’optimalité et la sécurité du projet, il est indispensable
d’étudier les contraintes et les problèmes pouvant nous rencontrer.
Pour répondre aux exigences d’implémentation de notre application, nous avons
respecté les contraintes suivantes :
 La modularité : La décomposition du logiciel en petits modules facile à maintenir
et entretenir, qui, en les rassemblant donneront un logiciel.
 La maintenabilité : la facilité de maintenir le système afin de le mettre à jour, c’est-
à-dire un système simple et rapide à réparer.
 La sécurité : les informations critiques seront cryptées, tels que les mots de passe
par des algorithmes de hachages.
 La portabilité : La capacité de l’application à fonctionner dans sous différents
environnements d'exécution.
1.3.2. Pratiques adoptées
 Règles de nommage : Donner des noms significatifs et explicites qui seront faciles
à retenir pour les noms des tables, attributs, nom des méthodes.
 Règles de présentation : Commenter les lignes de codes des classes java
 Règles de syntaxe : Utiliser des structures simples à comprendre et éviter les
complexités dans le code afin de réduire les risques de dysfonctionnement.

45
1.4. Diagramme de déploiement
Le diagramme de déploiement est une vue statique qui sert à représenter l'utilisation
de l'infrastructure physique par le système et la manière dont les composants du système
sont répartis ainsi que la relation entre eux N[9]. Les éléments utilisés par un diagramme
de déploiement sont principalement les nœuds, les composants et les associations. Les
caractéristiques des ressources matérielles physiques et des supports de communication
peuvent être précisées par stéréotype.
Figure 15 : Diagramme de Déploiement

46
1.5. Les interfaces
Figure 16 : Interface « Accueil »
Figure 17 : Interface « Login »

47
Figure 18 : Interface « Logout »
Figure 19 : Interface « Gestion des Contrats »

48
Figure 20 : Interface « Ajout Contrat »
Figure 21 : Interface « Modifier Contrat »

49
Conclusion
Au cours de ce chapitre nous avons décrit la phase de réalisation de notre système
d’information dans lequel nous avons défini les outils de travail utilisés. Nous avons
donné un aperçu sur les contraintes et la pratique adopté. Et les interfaces utilisateurs.

50
Conclusion générale
Au terme de ce rapport, j’avance que ce stage a été très enrichissant pour moi car il
m’a permis de découvrir le milieu professionnel à travers une société de grande envergure
telle que Tunisair Technics. J'ai pu distinguer à cet occasion plusieurs détails du secteur
de la maintenance en aéronautique dont principalement le volet de l'approvisionnement
qui présente plusieurs contraintes dans sa gestion en général et dans son système de
gestion informatisée plus particulièrement.
Il m’a permis de participer concrètement à ses enjeux au travers de ma mission visant
à mettre en application les éléments nécessaires pour l'élaboration assistée d'un tableau
de bord pour l'évaluation des fournisseurs. J’ai particulièrement apprécié l'approche de
compléter un logiciel de gestion déjà existant; l'objectif étant de fournir une solution et
non uniquement de développer des applications.
Au cours de mon stage, et pour le mener à bien, j'ai suivi une bonne planification
pour chaque étape. J'ai tout d’abord exploré les lieux pour la collecte d’informations
moyennant des interviews avec les services concernés afin de définir le système étudié.
Pour la conception j'ai utilisé des formalismes et des méthodes simples qui facilitent le
travail. Pour la réalisation de l’application, j'ai eu l'occasion d'apprendre et d'utiliser un
langage riche et souple.
Cette expérience m'a permis aussi bien de concrétiser les connaissances qui m'ont été
transmises au cours de ma formation que d’apprendre de nouvelles techniques et
technologies. J'ai été appelé à surmonter plusieurs difficultés auxquelles j'ai fait face. Au
début c’était de comprendre le besoin du client, ensuite de collecter et mettre en ordre le
tas d’informations collectées. Enfin j'ai dû faire le nécessaire pour développer le nouvel
outil avec des techniques que j'ai apprises au cours de mon stage même.
Plusieurs améliorations peuvent être apportées au système étudié. En plus de
compléter l'application, il y a lieu de limiter la partie estimative du tableau de bord. Pour
cela je sollicite de développer une procédure pour saisir des évaluations normalisées au
niveau des commentaires des Devis, Commandes et Bons de Livraison et de développer
une routine pour les récapituler pour les insérer dans le tableau de bord.

51
Nétographie
N[1] https://www.projet-plume.org/ressource/uml
N[2] Roels, C. (2015). openclassrooms. Récupéré sur
http://openclassrooms.com/courses/debutez-l-analyse-logicielle-avec-uml/les-differents-types-
de-diagrammes.
N[3] Lothon, F. (2013, Juin). agiliste. Récupéré sur http://www.agiliste.fr/items/bien-demarrer-
avec-scrum/.
N[4] wikipedia. (2015). Récupéré sur
http://en.wikipedia.org/wiki/Java_(programming_language)
N[5] ubuntu-fr. (2013). Récupéré sur http://doc.ubuntu-fr.org/eclipse.
N[6] hibernate. (2015). Récupéré sur http://hibernate.org/tools/.
N[7] docs.spring.io (2015). Récupéré sur http://docs.spring.io/spring/docs/current/spring-
framework-reference/htmlsingle/
N[8] wikipedia. (2015). Récupéré sur http://fr.wikipedia.org/wiki/PowerAmc.
N[9] wikipédia. (2015) Récupéré sur http://fr.wikipedia.org/wiki/Diagramme_de_déploiement

52
Annexe 1 : Formulaire de pré évaluation des
Fournisseurs et des Sous-traitants

54
Annexe 2 : Fiche de suivi de la performance des
Fournisseurs

55
Annexe 3 : Fiche de suivi de la performance des
Sous-traitants

Pfe conception et réalisation d'une application de gestion des processus d'achat et de sous traitance

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Pfe conception et réalisation d'une application de gestion des processus d'achat et de sous traitance

Similar to Pfe conception et réalisation d'une application de gestion des processus d'achat et de sous traitance (20)

Pfe conception et réalisation d'une application de gestion des processus d'achat et de sous traitance