Mise_en_place_dun_Systeme_de_Management

Mise en place d’un Système
de Management de Qualité
Rapport de stage de fin d’études
14/03/2013
Rédigé par : Hajji Anass
Encadrant de l’entreprise : M. Edraoui Mouloud
Encadré par : M. Belabbes Anas

Mise en place d’un Système de Management de Qualité
Rédigé par : Hajji Anass Page 1

Je tiens à adresser mes sincères remerciements :
Au directeur de l’agence de l’aménagement de la vallée de

Bouregreg
Pour l’acceptation de mon passage de stage de fin d’étude au sein de
son entreprise, ainsi que pour sa disponibilité et sympathie accordées.
À mon encadrant au sein de l’agence M. EDRAOUI

MOULOUD
Pour le partage de son expérience professionnelle, ainsi que ses conseils
précieux qui m’ont aidé à avancer dans mon projet de stage.
À toute l’équipe du service informatique de l’agence

Pour leur disponibilité, ainsi que leur grand soutien qui m’a permis de
réaliser mon projet de fin d’études dans de très bonnes conditions.
À mon encadrant à l’EMSI M. BELABBES ANAS

Pour son soutien, ses recommandations judicieuses et sa disponibilité,
sans oublier son avis favorable pour la démarche de travail proposée.
À mes enseignants
Auxquels je dois chaque bribe de connaissance acquise au cours de ma
formation, et pour le savoir qu’ils m’ont transmis ainsi que pour la fierté
et l’ambition que leurs personnalités m’inspirent.
À tous les membres du jury

D’avoir accepté de consacrer leur précieux temps à l’évaluation de ce
travail.
Et à tous ceux qui, directement ou indirectement, m’ont aidé à la finalisation de
ce travail

Résumé
Le présent rapport représente la synthèse de mon travail effectué
auprès de l’Agence pour l’Aménagement de la Vallée du Bouregreg,
dans le cadre de l’élaboration du projet de fin d’études.
L’objectif de ce projet consiste à mettre en place un Système de

Management de Qualité inspiré de la norme ISO9001 et adapté aux
pratiques courantes régissant l’ensemble des organismes marocains, ce
qui nous mène à concevoir une plateforme dont le rôle serait de gérer
l’ensemble des activités de l’entreprise, à savoir : les documents, les
processus, les non-conformités, les actions préventives et correctives, les
audits et réunions pour le compte de l’entreprise cliente, tout en tenant
compte des exigences imposées par les normes de gestion de qualité.
Les étapes directrices dans ce présent document seraient

structurées comme suit :
La première étape consiste d’effectuer une étude préalable, afin

d’assimiler les exigences imposées par la norme ISO9001, tout en ayant
une vue globale sur le fonctionnement du système de gestion de qualité.
Vient ensuite la phase d’étude fonctionnelle et technique, ainsi que
l’étude conceptuelle (cette dernière étant basée sur le langage UML).
Concernant la méthodologie de conception des modules du système, j’ai
adopté la méthodologie RUP (suivant le cycle de vie en ‘b’). Pour ce qui
est de la réalisation du projet, j’ai utilisé la technologie ‘.NET’, en
adoptant une architecture distribuée similaire à celle de la technologie
J2EE, dans la mesure où j’ai utilisé le Framework « .NET» avec le pattern
MVC pour la séparation en couches de l’architecture technique du SMQ,
sans oublier l’interfaçage avec « MS SQL SERVER 2005 » comme système
de gestion de base de données relationnelles.
** Mots clefs: [SMQ, ISO9001, UML, RUP, ASP.NET MVC,

NHIBERNATE, Framework, SQL SERVER].

ABSTRACT
This report represents the summary of my work with the

Bouregreg Agency, in the context of the development of the project of
end of studies. The objective of this project is to implement a quality
management system inspired by the ISO9001 standard and adapted to
the practices governing all Moroccan bodies, which leads us to design a
platform whose role would be to manage all the activities of the
company, namely: documents, processes, non-conformances, remedial
and preventive actions, the audits and meetings on behalf of the client
company, taking into account the requirements of quality management
standards. The guidelines steps in this document would be structured as
follows: the first step is to conduct a preliminary study, in order to
understand the requirements of the ISO9001 standard, while having a
global view on the operation of the quality management system
The first step is to conduct a preliminary study to assimilate the

requirements of the ISO9001 standard, while having an overall view of
the operation of the quality management system. Followed by the
functional and technical design phase, as well as the conceptual design
(the latter based on UML). On the design methodology of system
modules, I adopted the RUP (following the life cycle 'b'). In terms of the
project, I used the technology. 'NET' by adopting a distributed
architecture similar to the J2EE, since I used the Framework ". NET" with
the MVC pattern for separating layers of the technical architecture of the
QMS, plus interfacing with "MS SQL SERVER 2005" as a management
system relational database.
** Keywords: [QMS, ISO9001, UML, RUP, ASP.NET MVC, NHibernate,
Framework, SQL SERVER].

Liste des abréviations

Abréviation Designation
SMQ Système de Management
de la Qualité
TB Tableau de Bord
PQP Plan Qualité Projet
DP Design Pattern
CDC Cahier De Charge
HMTL Hypertext Markup
Language
IDE Integrated Development
Environment
AJAX Asynchronous
JavaScript And XML
MVC Model View Controller
SGBD Système de Gestion de
Base de Données
UML Unified Modeling
Language
CVS Concurrent Versions
System
RUP Rationnal Unified
Process
E.F. ENTITY FRAMEWORK
wpf Windows presentation
foundation

Figure 1 : Organigramme de l’agence .............................................................................................15
Figure 2 : Planning prévisionnel ............................................................................................... 24-25
Figure 3 : Planning réel ............................................................................................................... 26-27
Figure 4 : Workflow Documentaire .................................................................................................34
Figure 5 : Acteurs du système ...........................................................................................................43
Figure 6 : Diagrammes de cas d’utilisation – Module ‘Administration’ ..................................44
Figure 7 : Diagramme de cas d’utilisation – Module ‘Processus’ ..............................................45
Figure 8 : Description du scénario ‘Créer un processus’ .............................................................46
Figure 9 : Diagramme de séquence – Création d’un processus et d’une activité....................47
Figure 10 : Diagramme de cas d’utilisation – Module ‘Document’ ...........................................48
Figure 11 : Diagramme d’état – Cycle de vie d’un document .....................................................50
Figure 12 : Diagramme de cas d’utilisation – Module ‘Non-Conformité’ ...............................52
Figure 13 : Diagramme de cas d’utilisation – Module ‘Audit et réunion’ ...............................53
Figure 14 : Processus de création d’un audit et d’une réunion ..................................................55
Figure 15 : Diagramme de cas d’utilisation – Module Tableau de bord ..................................56
Figure 16 : Diagramme de classes – bloc ‘Gestion des utilisateurs’ .........................................58
Figure 17 : Diagramme de classes – bloc ‘Gestion des compétences et formations’ ..............59
Figure 18 : Diagramme de classes – bloc ‘Organisme’ .................................................................60
Figure 19 : Diagramme de classes – Module ‘Processus’.............................................................61
Figure 20 : Diagramme de classes – Module ‘Document’ ...........................................................62
Figure 21 : Diagramme de classes – Module ‘Non-Conformité’ ................................................64
Figure 22 : Diagramme de classes – Module ‘Audit et réunion’ ................................................65
Figure 23 : Diagramme de classes – Module ‘Tableau de bord’ ................................................66
Figure 24 : Architecture applicative du projet ...............................................................................68
Figure 25 : Architecture technique du projet ................................................................................69

Figure 26 : Application MySMQ – Page d’accueil ........................................................................74
Figure 27 : Application MySMQ – liste des processus ................................................................75
Figure 28 : Application MySMQ – Liste des activités par processus .......................................76
Figure 29 : Application MySMQ – Ajout d’une activité par processus ...................................77
Figure 30 : Application MySMQ – Gestion des organismes .....................................................78
Figure 30 : Application MySMQ – Interface de saisie des entités d’un organisme ..............79
Figure 30 : Application MySMQ – Gestion individuelle des compétences ...........................80

Liste des tableaux

Tableau 1 : Livrables du projet ...............................................................20-21
Tableau 2 : Description de la phase d’étude préalable ......................... 23
Tableau 3 : Description de la phase de conception ................................ 23
Tableau 4 : Description de la phase de développement ......................... 24
Tableau 5 : Matrice des risques .................................................................... 29
Tableau 6 : Équipe du service informatique............................................... 30
Tableau 7 : Équipe du projet .......................................................................... 30
Tableau 8 : Série des normes ISO9000 ....................................................... 33
Tableau 9 : Tableau d’étude comparative ................................................... 40
Tableau 10 : Description du scénario ‘publier un document’ .............. 50
Tableau 11 : Description du scénario ‘gérer plan d’action’ ................ 53
Tableau 12 : Description du scénario ‘créer une réunion’ .................. 55
Tableau 13 : Tableau des tests fonctionnels .......................................... 71

Table des matières
Introduction générale ........................................................................................................................12
Chapitre 1 : Contexte du Projet ........................................................................................................13
1. L’agence Bouregreg : ......................................................................................................15
1.1. Présentation de la société : ...................................................................................15

1.2. Les missions de l’agence : ....................................................................................15
1.3. Organigramme de l’agence : ................................................................................16
2. Cadre général du projet : ..............................................................................................17

Chapitre 2 : Étude Générale du Projet ............................................................................................17
1. Identification du projet : ..............................................................................................19
1.1. Problématique générale du projet :...............................................................19
1.2. But du projet : .......................................................................................................19
1.3. Objectifs du projet : ............................................................................................20
1.4. Livrables : ..............................................................................................................20
2. Conduite du projet : .......................................................................................................21

2.1. Le développement par processus unifié (RUP) : .....................................21
2.2. Les phases du cycle de vie dans RUP : .........................................................21
2.3. Le choix de la méthode RUP :..........................................................................22
2.4. Cycle de vie du projet : ......................................................................................22
2.4.1. Description des phases : .............................................................................. 23
2.4.2. Déroulement du projet : ........................................................................ 25
2.4.2.1. Planning Prévisionnel : ..............................................................25
2.4.2.2. Planning Réel : ..............................................................................27
2.4.2.3. Matrice des risques : ....................................................................29
2.4.2.4. Analyse des écarts : ......................................................................29
2.5. Organisation du projet : ....................................................................................30
Chapitre 3 : Cahier de charges..........................................................................................................30
1. La qualité : ......................................................................................................................32
2. Les normes références : ..............................................................................................32

2.1. Systèmes traditionnelles : les normes ISO ..................................................32

2.2. Tendances actuelles d’un SMQ : .....................................................................33
3. La gestion électronique des documents : .............................................................33
4. Les modules SMQ : .....................................................................................................36
4.1. Module « Document » : ......................................................................................36
4.2. Module processus : ..............................................................................................36
4.3. Module « Non-conformité » : ................................................................................37
4.4. Module « Audit et Réunion » : .........................................................................37
4.5. Module « Administration » :.............................................................................37
4.6. Module « Indicateurs et tableau de bord » : ................................................38
Chapitre 4 : Étude Comparative .......................................................................................................38
1. Objectif de l’étude : ...................................................................................................40
2. Les logiciels SMQ : ....................................................................................................40
Chapitre 5 : Analyse et Conception du Projet ...............................................................................41
1. Langage de modélisation : ........................................................................................43
1.1. Présentation du langage UML : .........................................................................43
1.2. Le choix du langage UML : ................................................................................43
2. Analyse et Conception du projet : ..........................................................................44
2.1. Les acteurs de l’application :.............................................................................44

2.2. Étude fonctionnelle : ...........................................................................................45
2.2.1. Module « Administration » : ....................................................................45
2.2.1.1. Diagramme de cas d’utilisation : ............................................45
2.2.2. Module « Processus » : .............................................................................46
2.2.2.2. Description du scénario ‘Créer un processus’ : ..................47
2.2.2.3. Processus de création des processus et des activités : ......48
2.2.3. Module « Document » : .............................................................................49


2.2.3.2. Description du scénario ‘Publier Document’ : ...................50
2.2.3.3. Cycle de vie d’un document : ..................................................51
2.2.4. Module ‘Non-Conformité’ : .....................................................................52

2.2.4.2. Description du scénario ‘Gérer plan d’action’ : .................53
2.2.5. Module « Audit et réunion » : .................................................................54
2.2.5.2. Description du scénario « Créer réunion » : ........................55
2.2.5.3. Processus de création d’un audit et d’une réunion : ........55
2.2.6. Module « Tableau de bord » .....................................................................56
2.3. Étude conceptuelle : .............................................................................................58
2.3.1. Module « Administration » : ....................................................................58
2.3.1.1. Bloc « Gestion des utilisateurs » : ..........................................58
2.3.1.2. Bloc ‘Gestion des compétences et formations’ : .................59
2.3.1.3. Bloc ‘Organisme’ : .......................................................................61
2.3.2. Module « Processus » : ..............................................................................62
2.3.3. Module « Document » :..............................................................................63
2.3.4. Module « Non-Conformité » : .................................................................64
2.3.5. Module « Audit et réunion » : .................................................................65
2.3.6. Module « Tableau de bord » : .................................................................66
Chapitre 6 : Mise en œuvre du Projet .............................................................................................66

1. Étude technique : .......................................................................................................68
1.1. Architecture applicative du projet : .............................................................68
1.2. Patrons de conception : ....................................................................................70
2. Tests et simulations : ................................................................................................70

2.1. Test fonctionnel : ...............................................................................................70
2.2. Tests unitaires : ...................................................................................................71
2.3. Tests d’intégration :...........................................................................................71
2.4. Tests de recette : .................................................................................................71
3. Technologies de développement : .......................................................................72
3.1. Le Framework .NET – version 4.5 : ..............................................................72
3.2. ASP.NET MVC :4 ...............................................................................................72
3.3. Mappage objet/relationnel : ...........................................................................72
3.3.1. ENTITY FRAMEWORK : .......................................................................72
3.4. Outils de développement : .............................................................................72
3.4.1. MS SQL SERVER 2008 :..........................................................................72
3.4.2. MS VISUAL STUDIO 2012 : .................................................................73
3.4.3. TORTOISE SVN : .....................................................................................73
4. Interfaces du projet : .................................................................................................73
4.1. Page d’accueil : ....................................................................................................73
4.2. Liste des processus : ..........................................................................................75
4.3. Ajout d’une activité à un processus :...........................................................76
4.4. Création d’un organisme et de ses entités :...............................................78
4.5. Affectation d’une compétence à un employé :.........................................79
Conclusion et perspectives de travail .............................................................................................80
Bibliographie / Webographie ...........................................................................................................82

Introduction générale :
On définit la gestion de qualité comme étant l’ensemble des méthodes et
techniques permettant, sur le plan organisationnel, d’assurer la conformité des
activités d’un organisme par rapport à une norme standard. Ceci implique le concept
de gestion des ressources matérielles et logicielles. De ce concept, on peut décrire un
système de management de qualité (SMQ en abrégé) comme étant un ensemble des
processus d’un organisme, par l’amélioration de ses résultats et de ses performances.
Dans le cadre de cette démarche, il m’a été confié de mettre en place un

système de management de qualité adapté aux pratiques courantes des organismes
marocains et basé sur la norme ISO9001- version 2008. Le système d’information doit
être adapté aux différentes entités de l’agence, mais aussi à la structure de l’entité
chargée de la fonction logistique.
Le premier chapitre aura donc pour but de définir le projet sous le volet
organisationnel pour cerner les objectifs fixés dans le travail, mais aussi sous le volet
contextuel pour mettre en place la méthodologie permettant sa bonne conduite. Vient
ensuite l’étape d’étude générale faisant l’objet du second chapitre, ainsi que le
troisième chapitre portant sur l’étude des besoins. Le quatrième chapitre concernera
quant à lui l’étude fonctionnelle et conceptuelle du projet. Par la suite, le cinquième
chapitre abordera l’architecture applicative et technique, sans oublier le choix de la
technologie et Framework utilisées. Ce rapport sera donc conclu par la description de
l’ensemble des perspectives de travail détaillant ainsi de manière globale les
différentes tâches effectuées, et celles qui doivent être améliorées à l’avenir.

Chapitre 1 : Contexte du projet

Le but dans ce chapitre serait de présenter le contexte général dans lequel

s’intègre le projet. Deux parties seront donc abordées :
 La première partie concerne la présentation de l’agence Bouregreg, abordant

ainsi les métiers exercés par l’organisme.
 La deuxième partie concerne quant à elle le cadre général du projet.
1. L’agence Bouregreg :
1.1. Présentation de la société :
L’Agence d’Aménagement pour la vallée de Bouregreg (AAVB), parfois

appelée ‘Agence Bouregreg’, est un établissement public marocain à
caractère économique et social, sous tutelle de l’état et disposant de
l’autonomie financière.
L’Agence Bouregreg est une institution sui generis qui a été chargée de
développer les berges du fleuve Bouregreg séparant la capitale Rabat de sa
ville jumelle Salé. Elle a été créée par l’état marocain en vue de développer
cette zone de près de 6000 hectares. Il s’agit d’un établissement public à
caractère économique et commercial doté de l’autonomie administrative et
financière.
1.2. Les missions de l’agence :
Les missions de l’agence incluent :
 L’élaboration de l'ensemble des études ou plans généraux techniques,

économiques et financiers se rapportant à l'aménagement de la Vallée
du Bouregreg;
 L’élaboration du Plan d'Aménagement Spécial et son approbation par

les autorités compétentes conformément aux dispositions de la loi 16-
04;
 La contribution à la recherche et à la mobilisation des financements

nécessaires à la réalisation du programme d'aménagement de la Vallée
du Bouregreg en concours avec les financements budgétaires ;
 La réalisation des travaux nécessaires à l'urbanisation de la zone;
 L’octroi, conformément aux dispositions de la loi 16-04, des

autorisations de lotir, de morceler et de créer des groupes

d'habitations, des permis de construire et d'habiter et des certificats de

conformité ;
 La veille au respect des lois et règlements en matière d'urbanisme ;
 La collecte et la diffusion de toutes informations relatives au

développement de la Vallée du Bouregreg, et à la promotion de zones
résidentielles, commerciales et de loisirs à l'intérieur du périmètre de la
zone d'aménagement.
1.3. Organigramme de l’agence :
L’organigramme suivant donne une répartition schématique de l’ensemble de

directions et services faisant partie de l’Agence Bouregreg :
Figure 1 : Organigramme de l’Agence Bouregreg

2. Cadre général du projet :

L’Agence Bouregreg a décidé de lancer un projet consistant à réaliser un logiciel
de gestion de qualité, et ce afin d’analyser ses performances et d’éliminer
l’utilisation des documents papier.
La finalité de ce projet serait de proposer un système permettant de gérer

l’ensemble des processus de l’agence, par le biais des procédures informatisées, ce
qui lui donne la performance et la conformité des activités de l’agence par rapport
aux normes standard de qualité telles que ISO9001 – version 2008.
La réalisation de mon projet s’inscrit donc dans le cadre de la perspective de

conception et la mise en place d’un logiciel de gestion de qualité respectant les
exigences de la norme ISO9001, ce qui revient à développer plusieurs modules,
dont je peux citer : la gestion des documents, la gestion des processus, la gestion
des non-conformités, la gestion des compétences et formations, la gestion des
audits, etc.

Chapitre 2 : Étude générale du projet

Le but dans ce deuxième chapitre est d’avoir une compréhension claire sur la
problématique du projet, et donc ses principaux objectifs. Par la suite, un aperçu
global sera établit sur la méthodologie de développement adoptée, ainsi que la
planification prévue pour l’ensemble des tâches du projet.
1. Identification du projet :
1.1. Problématique générale du projet :
La gestion de qualité est un domaine central pour l’entreprise. Il est

donc souvent utile d’imaginer une structure à cette activité qui concerne
en fait l’ensemble de ses services. Par ailleurs, la gestion de qualité est une
activité support permettant d’assurer la flexibilité et l’efficience pour
atteindre la stratégie voulue de l’entreprise. Les ressources utilisées
peuvent donner aux services des capacités de :
 Standardisation.
 Mutualisation.
 Réutilisation.
La mise en œuvre d’un système de management de qualité est donc le

processus support de qualité de l’entreprise.
1.2. But du projet :
Dans le cadre d’une gestion efficace de la qualité de l’organisme, l’agence

s’est fixée comme objectif de mettre en place un système de management
de qualité adaptable aux pratiques courantes des entreprises marocaines
et qui recouvrent en même temps les aspects requis de quelques normes
de références, notamment la norme ISO9001. L’objectif étant de faciliter la
gestion des informations qualité et leur divulgation, de fédérer les acteurs
autour d’un outil commun, et de promouvoir la qualité dans l’entreprise
en la rendant vivante et interactive.
Ce système offre les fonctionnalités pour la gestion de la structure de

l’entreprise, de l’ensemble des processus, des documents, des non-
conformités, les compétences , les indicateurs qualité, etc. Tous les aspects
de qualité sont intimement liés, garantissant ainsi une cohésion et la
qualité des informations.

1.3. Objectifs du projet :
L’objectif induit est de réaliser un logiciel de management de qualité,

dont la fonction principale est de fournir à l’utilisateur final, à travers
une plateforme, l’ensemble des possibilités suivantes :
- Gestion des différents documents et processus auxquelles il est

impliqué à travers un cycle d’approbation, tout en étant alerté à
chaque notification.
- Gestion des non-conformités : ceci implique la planification et le

suivi des actions préventives et correctives.
- Préparation des audits et des séances de réunions.
- Gestion des tableaux de bord : il s’agit dans ce cas de surveiller

l’état du système, moyennant un ensemble d’indicateurs issues des
données existantes et des points de contrôle.
- Visualiser l’ensemble de la hiérarchie par l’intermédiaire d’un

organigramme détaillé.
- Gestion des ressources humaines : aide à la spécification des

compétences et des formations des employés.
1.4. Livrables :
Le tableau ci-après détaille les livrables attachés à chaque phase

planifié :
Phase Livrable(s) Responsable Date Date de Date de

de livraison validation
livrais réelle prévue
on
prévue
Étude  Plan d’assurance L’équipe du projet 20/03/ 20/03/20 20/03/2013
préalable

qualité. 2013 13

Planning projet.
CDC.
Analyse  Spécifications L’équipe du projet 02/04/ 02/04/20 02/04/2013

fonctionnelles. 2013 13
Étude technique.
Conception  Étude L’équipe du projet 10/05/ 15/05/20 15/05/2013
conceptuelle. 2013 13
Réalisation Les modules L’équipe du projet 29/08/ 29/08/13

composant le 13
système.
Test & L’application finale L’équipe du projet 30/08/ 30/08/2013
validation 2013
Tableau 1 : livrables du projet
2. Conduite du projet :
Afin d’assurer le bon déroulement de ce projet, il est convenable d’adopter
une certaine démarche visant à sa structuration, ainsi qu’à son optimisation. Cette
section détaillera donc le choix de la méthodologie de développement, pour
ensuite passer à la réalisation du planning à respecter. Vient ensuite l’étape de
présentation du processus de développement adopté, ses activités et ses phases
de vie, sans oublier les motivations du choix.
2.1. Le développement par processus unifié (RUP) :
Pour assurer une bonne démarche, et pour garder un bon niveau de

développement du SMQ, il a été décidé de la part de l’agence d’adopter la
méthodologie de développement par processus unifié (RUP). Cette méthode
étant conçue pour les projets de longue envergure, elle est alors jugée comme la
meilleure méthode à suivre dans le cadre de ce projet. Ajoutons à cela les
avantages offerts par cette méthode, notamment la construction du système à
base de composants, le pilotage des scénarios de réalisation via les cas
d’utilisation, ou encore son cycle de vie itératif et incrémental, ce dernier étant le
principal point fort de cette méthode dans la mesure où elle offre à chaque
itération une version du système au client, me permettant ainsi de mieux clarifier
au fur et à mesure ses besoins.
2.2. Les phases du cycle de vie dans RUP :
Chaque cycle de vie est caractérisé par quatre principales phases :
- Phase de création : traduction d’une idée en vision de produit fini et

présente une étude de rentabilité pour ce produit : c’est dans cette
phase là qu’on fait apparaitre les cas d’utilisation.
- Phase d’élaboration : précision des cas d’utilisation et conception de

l’architecture du système : cette phase est caractérisée par
l’émergence d’une architecture de base.
- Phase de construction : c’est dans cette étape qu’on construit une

première version testable du produit. Ce dernier contient tous les

cas d’utilisation mis en accord avec les utilisateurs finaux pour leur
mise en place.
- Phase de transition : le produit étant en version bêta, l’objectif est

d’y apporter des améliorations (y compris des corrections des
anomalies détectées), et ce afin d’obtenir un rapport de correction
pour passer à la version suivante.
2.3. Le choix de la méthode RUP :
Le choix de la méthodologie RUP réside du fait qu’elle est basée sur des
principes génériques pour le développement logiciel, ainsi que son
adaptation par rapport à l’architecture logicielle du projet en question.
Ajoutons à cela le fait qu’elle permet d’avoir un cycle de vie itératif et
incrémental, ce qui permet d’avoir en permanence une clarification des
besoins au niveau de l’entreprise.
2.4. Cycle de vie du projet :
Les phases du cycle de vie du projet sont les suivantes :
 Étude préalable : cette phase doit être focalisée sur la collecte des
informations relatives au projet, analyser le fonctionnement du
système désiré et rédiger le plan qualité projet afin de synthétiser
les différents composants du projet.
 Analyse et conception : Cette phase permet la conception graphique,

fonctionnelle et technique du projet en élaborant les différents
diagrammes.
 Développement : Cette phase permet l’implémentation technique de

l’application. Elle est testée puis installée sur l’environnement de
test par l’équipe de développement, cette étape a été réalisé module
par module.
 Test et validation : Cette phase a pour objectif de s’assurer du bon

fonctionnement de l’application.

2.4.1. Description des phases :
 Phase d’étude préalable :
 Comprendre les différents

Étude préalable
Objectifs
 Réaliser une étude globale

aspects du SMQ.
du sujet proposé.
Contraintes N/A
Prérequis N/A
 Plan d’assurance qualité.

Étapes de la phase Voir Planning
 Planning du projet.
Livrables en sortie
Dépendance N/A
Critères de fin de phase Définir le cadre général du projet
Tableau 2 : description de la phase d’étude préalable du projet
 Phase de conception :
Phase d’analyse et de conception

Objectifs  Appropriation
fonctionnelle et technique
de l’application
 Étude conceptuelle.
 Validation de la
compréhension de
l’application.
Contraintes Prise en compte des exigences
Prérequis Cahier de charges
 Dossier de spécification
Livrables en sortie
 Dossier de conception.
fonctionnelle.
Dépendance N/A
Critères de fin de phase Compréhension fonctionnelle et
technique de l’application par
l’équipe
Tableau 3 : description de la phase de conception du projet

 Phase de développement :
 Développer les modules

Phase de développement
Objectifs
 Valider l’application sur

fonctionnels.
le plan fonctionnel,
technique et
 Valider la cohérence de la
ergonomique.
solution avec les

spécifications et les
exigences du cahier de
charges.
 Validation du dossier de
Contraintes Respect des exigences
Prérequis
spécifications
fonctionnelles, techniques
 Validation de l’étude
et ergonomiques.
 Validation des maquettes.

organique.
 Validations des cas de

test.
 Procédure d’installation et
Livrables en sortie
de configuration de
l’application.
 Package d’installation de
l’application.
 Rapport de tests.
Dépendance Appropriation fonctionnelle de
l’équipe du projet.
Critères de fin de phase Aucune anomalie bloquante.
Tableau 4 : description de la phase de développement
du projet

2.4.2. Déroulement du projet :
Après la première semaine de découverte, il a été décidé de

mettre en place un planning prévisionnel dans le but d’estimer la
durée de chaque tâche à réaliser. Ce planning avait pour but de
m’aider à respecter le temps accordé dans le cadre de ce stage.
La durée des plages de travail a été estimée objectivement par le

volume de chaque partie, sachant qu’il est sujet de modification
selon les variations du projet en fonction des imprévus ou
difficultés rencontrés au cours de la phase de réalisation.
2.4.2.1. Planning Prévisionnel :

Figure 2 : Planning Prévisionnel

2.4.2.2. Planning Réel :

Figure 3 : Planning Réel

2.4.2.3. Matrice des risques :
Le tableau ci-dessous détaille les risques qui influencent sur l’avancement des
tâches du projet, et donc de sa réussite :
Tableau 5 : Matrice des risques du projet
2.4.2.4. Analyse des écarts :
Concernant l’analyse des écarts dans le cadre de ce projet, il y a eu un

retard dans l’assimilation de la norme ISO9001, ce qui est dû à la
compréhension du jargon technique de la norme.

2.5. Organisation du projet :
La réalisation de ce projet grâce à la participation de plusieurs efforts durant

toutes les taches du projet, chaque membre de l’équipe ayant participé à sa
progression, et par la suite contribué à la récolte des fruits de ce travail.
La période de stage m’a permis entre outre de travailler avec l’ensemble de

l’équipe du service informatique, ce qui m’a donné une vue globale sur
l’infrastructure du système d’information de l’agence. Le tableau ci-après illustre
les membres de l’équipe du service informatique :
Nom Fonction/Rôle pour le projet

M. Salah Moudnib Chef de personnel
M. Edraoui Mouloud Chef de projet [Docteur Ingénieur en
Développement Informatique]
M. Abdelilah EL Founoun Ingénieur Réseau & Telecom
M. Boumhaid Anass Administrateur système & réseau
Tableau 6 : équipe du service informatique
Le tableau ci-après illustre les membres de l’équipe du projet :
Nom Fonction/Rôle pour le projet

M. Edraoui Mouloud Chef de projet [Docteur Ingénieur en
Développement Informatique]
M. Aslouj Abdel Ali Responsable direction RH & Logistique
(testeur du système SMQ)
M. Hajji Anass Analyste / Développeur
Tableau 7 : équipe du projet

Chapitre 3 : Cahier de charges

Le but dans ce chapitre est d’essayer, dans un premier temps, de traiter la

qualité dans son contexte globale, à travers l’illustration de ses principes
fondamentaux. Vient ensuite l’étape qui décrit les normes directives du Système
de management de qualité, notamment la norme ISO9001- version 2008 comme
étant une norme généraliste et flexible de management de qualité.
1. La qualité :
Dans un contexte économique concurrentiel tendu marqué par l’évolution
des exigences attendues par les clients, les entreprises sont amenées à
améliorer la qualité de leurs produits et services en vue de renforcer leur
compétitivité en identifiant clairement leurs besoins et parvenir à y répondre
parfaitement. Dans la pratique, la qualité se décline sous deux formes :
- Qualité externe : C’est lorsqu’un produit ou service répond

parfaitement aux besoins et attentes des clients.
- Qualité interne : C’est la maîtrise et l’amélioration du fonctionnement

de l’organisme.
Les bénéficiaires en sont la direction, le personnel et bien sûr les clients.
2. Les normes références :

Une norme de système de gestion fournit un modèle à suivre dans la mise en
place et le fonctionnement du système.
2.1. Systèmes traditionnelles : les normes ISO
Adoptées en 1987, la série des normes ISO9000 permettent à un

organisme de prouver de manière objective l’existence et le bon
fonctionnement du système d’assurance qualité, sans oublier la garantie
de la conformité du système qualité par rapport aux exigences client.
Depuis décembre 2000 et la publication de la norme ISO9001, l’assurance
qualité devient Système de Management de Qualité (SMQ).
On distingue plusieurs normes ISO dans la famille ISO9000 :

Tableau 8 : série des normes ISO9000
2.2. Tendances actuelles d’un SMQ :
Les normes traditionnelles décrivant des Systèmes de

Management de la Qualité sont orientées vers l'activité de l'entreprise
(ses produits, ses services...), mais prennent peu en compte les impacts
sur l'environnement, sur les fournisseurs, sur l'hygiène et la sécurité du
travail, par exemple, qui font l'objet de normes ou de standards séparés
(norme ISO 14001 pour l'environnement et standard BS OHSAS 18001 ou
encore le MASE (en France) pour l'hygiène et la sécurité du travail). La
qualité totale a voulu aller dans ce sens.
3. La gestion électronique des documents :

On définit la gestion électronique des documents comme étant une procédure
informatisée visant à gérer et organiser les informations et les documents
électroniques au sein d’une organisation. Le rôle principal de cette procédure
étant de participer au processus de travail collaboratif, elle met en œuvre des
systèmes d’acquisition, de classement, de stockage, d’indexation et de
consultation.
3.1. Le processus de gestion de document :
La documentation du système de management de qualité dot

comprendre :
- L’expression documentée de la politique et des objectifs de qualité.
- Manuel qualité.

- Les documents jugés nécessaires par l’organisme pour assurer la

planification, le fonctionnement et la maitrise efficace de ses
processus.
Les documents requis pour le système de management de la qualité

doivent être maîtrisés. Ceci dit, une procédure documentée doit être
établie afin de définir les contrôles nécessaires pour :
- Approuver les documents quant à leur adéquation avant diffusion;
- Revoir, mettre à jour si nécessaire et approuver de nouveau les

documents;
- Assurer que les modifications et le statut de la version en vigueur

des documents sont identifiés;
- Assurer la disponibilité sur les lieux d'utilisation des versions

pertinentes des documents applicables;
- Assurer que les documents restent lisibles et facilement

identifiables;
- Assurer que les documents d'origine extérieure jugés nécessaires par

l'organisme pour la planification et le fonctionnement du système de
management de la qualité sont identifiés et que leur diffusion est
maîtrisée;
- Empêcher toute utilisation non intentionnelle de documents

périmés, et les identifier de manière adéquate s'ils sont conservés
dans un but quelconque.
Pour illustrer cela, dans ce qui va suivre, la représentation BPMN du

flux documentaire :

Figure 4 : Workflow documentaire

4. Les modules SMQ :

Le but dans cette section est d’illustrer les différents modules à mettre en place
dans le cadre de ce projet, avec pour chaque module ses caractéristiques à
implémenter :
4.1. Module « Document » :
L’ensemble des caractéristiques de ce module sont structurées

comme suit :
- Création d’un document.
- Importation d’un document.
- Modification d’un document.
- Suppression d’un document.
- Consultation d’un document.
- Publication d’un document.
- Diffusion d’un document.
- Recherche d’un document.
- Archivage d’un document.
- Référencement d’un document.
4.2. Module processus :
Le but dans ce projet étant principalement de proposer un

environnement générique permettant à l’utilisateur final de créer et de
manipuler son propre processus, il est alors utile de connaitre les
propriétés de cet environnement que voici :
- Création d’un processus.
- Modification d’un processus.
- Suppression d’un processus.
- Consultation d’un processus.
- Joindre un document à un processus.
- Gestion des tâches.

- Publication d’un processus.
4.3. Module « Non-conformité » :
Selon la norme ISO9001- version 2008, on définit une non-

conformité comme étant une non-satisfaction exprimée par le client vis-
à-vis d’une exigence au niveau d’un organisme. Cette non-satisfaction
peut être enregistrée soit par la déclaration d’un tiers, soit par celle d’un
employé, à partir d’un indicateur, ou encore en se basant sur les résultats
d’une réunion.
La réalisation de ce module dépend de la présence des

fonctionnalités suivantes :
- Créer une non-conformité.
- Modifier une non-conformité.
- Clore une non-conformité.
- Consulter une non-conformité.
- Rechercher une non-conformité.
- Créer un plan d’action.
- Suivi et vérification d’un plan d’action.
4.4. Module « Audit et Réunion » :
Les fonctionnalités à réaliser dans ce module sont les suivantes :
- Créer un audit.
- Modifier un audit.
- Clore un audit.
- Consulter un audit.
- Lier une non-conformité à un audit.
4.5. Module « Administration » :
Dans ce module, il est obligatoire de gérer les utilisateurs. Le

SMQ faisant l’objet de ce projet devant être multi-utilisateur, il doit par
conséquent gérer leur profil (soit par type de profil, par groupe

d’utilisateur,…). Pour ce module, il s’agit de réaliser les fonctionnalités

suivantes :
- Gestion des utilisateurs.
- Organigramme.
- Gestion de la communication interne.
- Gestion des compétences.
- Gestion des formations.
4.6. Module « Indicateurs et tableau de bord » :
Les tableaux de bord offrent à l’utilisateur final la possibilité

d’effectuer un suivi et de mesurer les performances des activités de
l’agence, à travers des calculs basés sur des indicateurs données, pour
ainsi avoir une vue globale sur l’état d’avancement de ces activités.
Les fonctionnalités à mettre en place pour ce module sont les suivantes :
- Créer un tableau de bord.
- Mettre à jour le tableau de bord.
- Supprimer le tableau de bord.
- Calculer un tableau de bord.
- Supprimer un tableau de bord.
- Créer un indicateur.
- Modifier un indicateur.
- Consulter un indicateur.
- Supprimer un indicateur.
- Simuler une mesure.
- Soumettre demande sur mesure.

Chapitre 4 : Étude Comparative

L’objectif dans ce chapitre est d’établir une étude comparative sur

quelques logiciels de management de qualité pour avoir une idée sur les modules
que doit implémenter un SMQ.
1. Objectif de l’étude :
L’objectif principale de cette étude est d’avoir une idée globale sur ce
que c’est un SMQ, ses modules, son fonctionnement, ainsi que les différences
existantes entre chaque logiciel présent sur le marché.
Cette étude permettra aussi de fixer définitivement les modules à

réaliser, leurs limites, ainsi que les données en entrée et les données en sortie.
Ce n’est que grâce à cette étape, avec les exigences de la norme ISO, et
l’expression des besoins du maitre d’ouvrage, qu’on a pu trancher
définitivement sur les fonctionnalités en détaille qu’opérera le logiciel.
2. Les logiciels SMQ :

Le tableau ci-après montre une étude comparative établie sur trois
logiciels de qualité les plus connus sur le marché :
Tableau 9: Étude comparative

Le but de cette étude comparative est d’établir une analyse sur les logiciels de
gestion de qualité les plus utilisés sur le marché, et de se baser sur les résultats de
cette comparaison pour mettre en place une structure adapté à la structure de
l’agence. Au cours de cette analyse, il a été jugé qu’il serait préférable de mettre un
SMQ propre à la structure courante de l’agence, en raison de manque de confiance à
l’égard des logiciels payants : chose qui m’a obligé à développer mon propre
application, et répondre ainsi à leur besoin.

Chapitre 5 : Analyse et Conception

Ce chapitre a pour but de décrire les étapes composant la phase

d’analyse et de conception du projet, laquelle est considérée comme
importante et obligatoire après la phase d’étude de besoin (ou encore « la
phase d’élaboration » selon la méthodologie RUP).
1. Langage de modélisation :
1.1. Présentation du langage UML :
UML (Unified Modeling Language), que l'on peut traduire par langage
de modélisation unifiée, est une notation permettant de modéliser un problème
de façon standard. Ce langage est né de la fusion de plusieurs méthodes
existant auparavant, et est devenu désormais la référence en termes de
modélisation objet.
1.2. Le choix du langage UML :
Le langage de modélisation le plus utilisé dans la plupart des sociétés

dont l’activité touche au développement de logiciels, est le langage UML. Ce
langage offre un canevas de développement structuré et c’est ce qui motive
mon choix.

2. Analyse et Conception du projet :

2.1. Les acteurs de l’application :
Le diagramme ci-dessous illustre les différents acteurs interagissant

avec le système de management de qualité :
Figure 5 : Acteurs du système

2.2. Étude fonctionnelle :
2.2.1. Module « Administration » :
L’objectif dans cette section est de décrire l’ensemble des rôles et

travaux pris en charge par l’administrateur du SMQ :
2.2.1.1. Diagramme de cas d’utilisation :
La figure ci-après décrit les fonctionnalités du module

d’administration :
Figure 6 : Module « Administration »

2.2.2. Module « Processus » :
Ce module permet à l’utilisateur final de créer et de gérer son propre

processus, à travers les différentes fonctionnalités illustrées par le
diagramme ci-dessous :
Figure 7 : diagramme de cas d’utilisation pour le module

« Processus »

2.2.2.2. Description du scénario ‘Créer un processus’ :
Le diagramme ci-après montre les étapes principales à suivre pour

créer et enregistrer un processus au sein du SMQ :
Figure 8 : description du scénario ‘Créer un processus’

2.2.2.3. Processus de création des processus et des activités :
Il est utile de montrer les échanges de flux effectués entre

l’utilisateur et le système pendant l’activité lié à un processus (sachant
que ce dernier est composé d’une ou plusieurs procédures, lesquelles
qui correspondent à des activités qui, à leur tour, sont divisées en
tâches). La figure ci-dessous détaille les étapes de création d’un
processus, ainsi que la jointure d’une activité à ce dernier :
Figure 9 : diagramme de séquence - création d’un processus et d’une

activité

2.2.3. Module « Document » :
L’objectif dans cette section est de décrire l’ensemble des

fonctionnalités et interactions entre les différents acteurs (en tant
qu’utilisateur final) et le système, dans le cadre de la gestion des
différents documents circulant au sein de l’organisme.
La figure 10 illustre les différentes fonctionnalités qu’offre le

module ‘Document’ à l’utilisateur final :
Figure 10 : diagramme de cas d’utilisation – Module ‘Document’

2.2.3.2. Description du scénario ‘Publier Document’ :
Le tableau ci-dessous décrit le scénario nominal concernant la

publication des documents dans un SMQ :
Nom Publier Document

Objectif Publier les documents de
l’organisme, après approbation des
différents utilisateurs finaux.
Acteur principal Auditeur
Acteurs secondaires Les employés de l’agence
Préconditions  L’utilisateur doit être
authentifié.
 Le document doit exister et
être identifié par le SMQ.
Exceptions Le document est déjà publié.
Flot d’événements 1) L’utilisateur choisit le
document concerné.
2) L’utilisateur choisit la liste des
approbateurs qui auront pour
charge d’approuver ou de
rejeter le document.
3) Les approbateurs sont notifiés
dans leurs agendas.
4) Chaque approbateur peut
approuver ou rejeter un
document.
- Si tous les approbateurs
acceptent, le document
est publié au sein du
système.
- Sinon, le document est
rejeté par le système.
Post conditions - Document publié.
- Document rejeté.
Tableau 10 : description du scénario ‘Publier Document’

2.2.3.3. Cycle de vie d’un document :
La figure ci-dessous décrit les différentes étapes du cycle de vie d’un

document au sein du SMQ :
Figure 11 : Diagramme d’état – Cycle de vie d’un document

2.2.4. Module ‘Non-Conformité’ :
Ce module a comme principale fonctionnalité de permettre à

l’utilisateur final de signaler, modifier ou encore de clôturer une non-
conformité concernant un processus ou une activité quelconque.
La figure ci-dessous montre les fonctionnalités du module ‘Non-

Conformité’ :
Figure 12 : Diagramme de cas d’utilisation – module ‘Non-

Conformité’

2.2.4.2. Description du scénario ‘Gérer plan d’action’ :
Le tableau ci-dessous décrit le scénario nominal concernant la

gestion des plans d’action :
Nom Gérer plan d’action

Objectif En cas de non-conformité signalée
au système, un plan d’action doit
être mis en place pour sa
correction.
Acteur principal  L’auditeur.
 Le responsable qualité.
Préconditions  L’utilisateur doit
s’authentifier.
 Non-conformité existante.
Exception Plan d’action existant
Flot d’événements 1. L’utilisateur choisit la non-
conformité concernée.
2. L’utilisateur choisit le type
de plan d’action devant être
mené.
3. L’utilisateur saisie les
informations du plan, et
affecte ce dernier aux
différents intervenants.
4. Les intervenants sont
notifiés dans leurs agendas.
5. L’utilisateur choisit le
vérificateur qui sera en
charge d’établir le suivi du
plan d’action.
6. Le vérificateur est vérifié
dans son agenda.
7. Le système valide le plan
d’action.
8. Le système enregistre le
plan d’action.
Post conditions  Plan d’action créé.

 Non-conformité acceptée.
 Non-conformité rejetée.
Tableau 11 : description du scénario ‘Gérer plan d’action’

2.2.5. Module « Audit et réunion » :
Le module « Audit et réunion » permet, parmi ses fonctionnalités, de

donner à l’utilisateur final un aperçu global sur l’ensemble des processus,
procédures et activités à auditer : chose qui fait l’objet des réunions à
établir, en vue d’élaborer par la suite des plans d’action en cas de non-
conformité signalée lors des réunions prévues.
La figure ci-après montre les interactions des utilisateurs avec le

système, ainsi que les fonctionnalités de ce dernier concernant le
module d’audit :
Figure 13 : diagramme de cas d’utilisation – module ‘Audit et

réunion’

2.2.5.2. Description du scénario « Créer réunion » :
Le tableau ci-dessous décrit le scénario nominal concernant le cas

d’utilisation ‘Créer réunion’ :
Nom Créer réunion

Objectif La création d’un audit doit faire
l’objet d’une ou plusieurs réunions
à réaliser
Acteur principal  L’auditeur.
 Le responsable qualité.
Pré conditions  L’utilisateur doit
s’authentifier.
 Audit existant.
Exception La réunion est déjà programmée
pour le même audit
Flot d’événements 1. L’utilisateur choisit
l’audit concerné.
2. L’utilisateur saisi les
informations relatives à
la réunion dans le
formulaire.
3. L’utilisateur choisit les
participants à la
réunion.
4. Les participants sont
notifiés dans leurs
agendas respectifs.
5. Le système valide le
formulaire.
6. Le système enregistre la
réunion.
Post conditions  Réunion créée.
Tableau 12 : description du scénario ‘Créer réunion’
2.2.5.3. Processus de création d’un audit et d’une réunion :
La figure ci-après illustre, à travers un diagramme de séquence,

le processus par lequel un audit doit être créé et signalé au niveau du
système :

Figure 14 : processus de création d’un audit et d’une réunion
2.2.6. Module « Tableau de bord »
La gestion des tableaux de bord constitue un travail essentiel au sein

d’un SMQ, dans la mesure où il permet de réaliser l’ensemble des suivis
d’activités au niveau de l’agence, et ce à travers des simulations des
mesures faites à base d’indicateurs (ces derniers devant être créé au
préalable par l’utilisateur final).

La figure suivante illustre les fonctionnalités offertes par le

module de gestion des tableaux de bord, ainsi que les interactions de ce
dernier avec les différents intervenants du SMQ.
Figure 15 : diagramme de cas d’utilisation – module « Tableau de

bord »

2.3. Étude conceptuelle :
L’objectif dans cette étude est de pouvoir établir la vue structurelle du

système de management de qualité, et ce à travers une conception détaillée
résultant des spécifications fonctionnelles faites pendant la phase d’analyse. Le
but dans cette section est donc de détailler, à travers des diagrammes de classes
de conception, l’ensemble des règles de gestion régissant l’ensemble des
modules détectés du SMQ.
2.3.1. Module « Administration » :
D’après la phase d’analyse, le module ‘Administration’ est composé de

trois blocs fondamentaux, à savoir :
- Le bloc de gestion d’utilisateurs : permettant la gestion des utilisateurs

et de leurs profiles, droits d’accès,…
- Le bloc de gestion de compétences et de formations : permettant de

faire les suivis de création de l’ensemble des formations établies au
niveau de l’agence, tout en tenant compte des compétence acquises par
chaque participants à la formation en question.
- Le bloc de gestion des entités : permettant de gérer l’ensemble des

entités et sous-organismes de l’agence, en fonction du degré
hiérarchique.
2.3.1.1. Bloc « Gestion des utilisateurs » :
La figure 15 illustre la vue structurelle du bloc de gestion des

utilisateurs, selon lequel :
Un utilisateur peut avoir plusieurs profils, chacun de ces

derniers lui procurant des droits d’accès particuliers.
Le système peut donner la possibilité à un utilisateur

d’appartenir à plusieurs groupes.
L’utilisateur peut occuper plusieurs fonctions dans une entité,

avec pour chaque fonction son libellé, ainsi que sa description.
L’implémentation de ces règles de gestion nous donne un

diagramme de classes de la forme suivante :

Figure 16 : diagramme de classes – bloc ‘Gestion d’utilisateurs’
2.3.1.2. Bloc ‘Gestion des compétences et formations’ :
Le but dans ce bloc du système est de pouvoir effectuer un suivi

de formation par plan, par lieu de formation, ainsi qu’en fonction des
compétences acquises par chaque participant. Une documentation
s’avère alors nécessaire.
Le diagramme de classes suivant implémente ces règles de gestion :

Figure 17 : diagramme de classes- Bloc ‘Gestion des compétences et

formations’
L’important dans ce diagramme est le fait que chaque participant peut intégrer les
formations auxquelles il a assisté dans son expérience, et donc dans son domaine de
compétence.

2.3.1.3. Bloc ‘Organisme’ :
La figure ci-dessus décrit le diagramme de classes pour le bloc de

‘Organisme’ :
Figure 18 : diagramme de classes – Bloc ‘Organisme’
Selon la figure ci-dessus, un organisme est composé de plusieurs entités, chacune

d’elles pouvant être classée selon un ordre hiérarchique (Entité/Sous-entité), laquelle
pouvant – à son tour – regrouper des sous-entités, chacune d’elles étant décrite par
son libellé, un commentaire contenant sa description, sans oublier le(s) secteur(s)
d’activité dans lesquels elle travaille. Reste à spécifier pour chaque entité et /ou sous-
entité l’ensemble du personnel qu’elle comporte, ainsi que les documents prises en
charges au niveau de l’organisme racine.

2.3.2. Module « Processus » :
La figure 18 montre le diagramme de classes détaillant la vue structurelle

de ce module :
Figure 19 : diagramme de classes – module « Processus »
Dans ce module, on distingue un ensemble de règles de gestion, parmi lesquelles :
 Un processus est composé de plusieurs activités, lesquelles pouvant être

modifiées et/ou réalisées par un ou plusieurs utilisateurs.
 Un utilisateur n’a le droit de créer qu’un seul et unique processus à la fois.
 L’utilisateur final a la possibilité de publier jusqu’à plusieurs processus.

 Pour chaque activité du processus en question, un suivi doit être établit et mis
en place pour garder l’état d’avancement de sa réalisation.
 Les processus doivent être catégorisés par type.
2.2.3. Module « Document » :
La figure 19 illustre la structure du module « Document » :
Figure 20 : Diagramme de classes – module ‘Document’
À travers ce diagramme, on remarque bien les opérations que peut

effectuer l’utilisateur final quant à la gestion des documents, ce qui nous amène à
constater certaines règles de gestion que voici :

- Un utilisateur peut ajouter jusqu’à plusieurs documents, ces derniers ne

pouvant être liés qu’à un seul processus.
- L’utilisateur peut être amené à diffuser et /ou approuver jusqu’à

plusieurs documents.
- Chaque document ne doit concerner qu’une seule non-conformité, et ne

doit appartenir qu’à un seul organisme.
- L’utilisateur final doit fournir des informations pour établir par la suite
le classement des documents qu’il gère dans sa session.
2.3.3. Module « Non-Conformité » :
La figure 20 détaille la structure du modèle ‘Non-Conformité’ :
Figure 21 : diagramme de classes – module ‘Non-Conformité’
Comme le montre la figure ci-avant, un utilisateur peut gérer jusqu’à

plusieurs conformités, chacune d’elles possédant une seule et UNIQUE source,
laquelle étant renseigné par sa désignation suivie d’un commentaire pour sa

description. Par ailleurs, il conviendrait d’établir pour une non-conformité un

ensemble de plans amélioratif, dans le but de mettre en place les actions
correctives pour chaque plan lié à la non-conformité en question.
2.3.4. Module « Audit et réunion » :
La figure 20 montre le diagramme de classes pour ce module :
Figure 22 : Diagramme de classes – module ‘Audit et réunion’
Comme le montre la figure ci-avant, on remarque l’importance de la

présence de l’utilisateur final dans ce module, ainsi que son rôle dans la
création, la modification et / ou enregistrement d’un audit, ou encore dans
la clôture d’un audit. Ajoutons à cela l’importance de garder la traçabilité
d’un audit donné : ce qui explique la présence de l’entité ‘Réunion’ au sein
du diagramme.

2.3.5. Module « Tableau de bord » :
Le diagramme de classes ci-dessous détaille quant à lui la structure

composant le module ‘Tableau de bord’ :
Figure 23 : diagramme de classes – module ‘Tableau de bord’

Chapitre 6 : Mise en œuvre du projet

1. Étude technique :
1.1. Architecture applicative du projet :
Le but dans cette section est de détailler la structure applicative dont

le projet a pris forme, pour ainsi déduire la structure technique qui en
découle. La figure 22 donne une vue globale sur l’architecture
applicative du projet, avec pour chaque couche le type de Framework
utilisé :
Figure 24 : architecture applicative du projet
Comme le détaille la figure ci-dessus, le système de management de

qualité sera conçu sur plusieurs couches, chacune d’elles regroupant un
ensemble de traitements spécifiques, ayant ainsi une bonne structuration du
système, ce qui nous mène à décomposer notre SMQ en quatre couches
principales, à savoir :
- La couche présentation : regroupant les traitements interagissant avec

l’utilisateur, notamment les vues des entrées/sorties, les traitements de
validation de l’information saisie par l’utilisateur, l’interception des
données avant leurs redirection vers les services correspondant, etc. la
réalisation de ces fonctionnalités est basée sur le Framework ASP.NET
MVC 4.
- La couche métier : regroupant les traitements métier du SMQ (règles de
gestions, objets du domaine,…).

- La couche de persistance : permettant la persistance des données

saisies par l’utilisateur dans la base de données cible. Pour cette couche,
il a été décidé de choisir « ENTITY FRAMEWORK 5.0 ».
En adoptant cette architecture applicative, j’ai pu arriver à concevoir une

structure technique afin de mettre en œuvre les fonctionnalités de chaque couche. La
figure 23 illustre l’architecture technique du projet :
Figure 25 : Architecture technique du projet

1.2. Patrons de conception :
Pour une bonne séparation des traitements effectués au niveau du

SMQ, et dans une optique de facilité de développement, il a été décidé
d’appliquer des patrons de conception au niveau de l’architecture du
projet.
S’agissant de la couche présentation (voir Figure 22), le choix avait été

porté sur le pattern MVC (Modèle/Vue/Contrôleur). L’avantage dans son
utilisation réside dans la séparation des traitements de la couche
présentation sur trois niveaux : un ‘modèle’ rassemblant les objets métiers
ainsi que les traitements liés à l’accès aux données, une ‘vue’ contenant les
entrées/sorties interagissant avec l’utilisateur final, et un contrôleur pour
l’établissement des traitements de validation et de contrôle de flux de
données circulant entre les vues et les modèles correspondants.
Quant à la couche métier, ainsi que pour la couche de persistance, il a

été jugé d’implémenter l’IOC pour faciliter la manière dont les objets sont
instanciés et/ou invoqués par l’utilisateur final.
2. Tests et simulations :
Afin de s’assurer du bon fonctionnement du SMQ, un ensemble de tests

doivent être mis en place pour validation de ses fonctionnalités, en se basant sur
plusieurs critères de contrôle et d’assurance qualité. L’objectif dans cette section
serait donc de décrire l’ensemble de type de tests effectués pour la validation des
critères de faisabilités du système.
2.1. Test fonctionnel :
Au cours de l’élaboration du projet, j’ai été amené à effectuer un

ensemble de tests pour contrôler le bon fonctionnement du SMQ
conformément au référentiel des exigences ayant été validé par l’agence. Le
tableau ci-après décrit l’ensemble des tests fonctionnels ayant été établis
pendant la période de mise en œuvre du projet :

Référence Description
Test 1 Test de gestion des entités et organismes
de l’agence au niveau hiérarchique
Test 2 Test des processus & document :
validation du cycle de vie des documents
du SMQ, validation de l’ensemble des
processus gérés
Test 3 Validation de la gestion des audits et
réunions pour le suivi de non-
conformités détectées dans l’ensemble
des activités de l’agence
Test 4 Test pour la validation des processus
gérés et les utilisateurs qui y sont
impliqués
Test 5 Tests pour la gestion des formations des
utilisateurs et leurs compétences
Test 6 Tests pour l’administration du SMQ :
création des plans d’action
Tableau 13 : tableau des tests fonctionnels
2.2. Tests unitaires :
Au niveau de l’application, un ensemble des tests unitaires a été établit

au niveau du développement des modules de manière indépendante. Les
tests ont principalement porté sur les contrôleurs du système, ces derniers
ayant pour fonction de contrôler les flux entre les vues interagissant avec
l’utilisateur et les différents modèles correspondants.
2.3. Tests d’intégration :
Après la phase des tests unitaires, vient ensuite la phase de test

d’intégration, et dont l’objectif est de valider l’assemblage des composants
du système, et ce afin de les intégrer dans l’environnement de production.
L’idée étant de déployer ces composants développés de façon
indépendante les uns des autres.
2.4. Tests de recette :
L’élaboration des recettes joue un rôle central dans le cadre de ce projet,

dans la mesure où elle procède aux différents tests finaux simulant
l’utilisation du SMQ en temps réel vis-à-vis des utilisateurs finaux.

3. Technologies de développement :
3.1. Le Framework .NET – version 4.5 :
Le Framework ‘.NET – version 4.5’ est un Framework conçu par

Microsoft. L’avantage de ce Framework réside sur l’appui de la norme
COMMON LANGUAGE INFRASTRUCTURE (CLI) qui est indépendant
du langage de programmation utilisé. Ainsi tous les langages de
programmation compatibles respectant la norme CLI ont accès à toutes
les bibliothèques installées dans l’environnement d’exécution.
3.2. ASP.NET MVC :
Le Framework ASP.NET est un Framework de présentation hautement

testable et léger avec les fonctionnalités ASP.NET existantes. Parmi ces
fonctionnalités, on peut citer : l’authentification fondée sur l’adhésion, ou
encore le mode d’authentification ‘Windows’ et/ou l’authentification par
formulaire.
3.3. Mappage objet/relationnel :
3.3.1. ENTITY FRAMEWORK :
Ce Framework présente un ensemble de technologies présentes dans

ADO.NET qui soutiennent le développement d’application
logicielles orientées données. Sa puissance offre aux développeurs la
possibilité de travailler avec des données sous format d’objets et de
propriétés spécifiques à un domaine, et ce sans avoir à se préoccuper
des tables de bases de données sous-jacentes et des colonnes où ces
données sont stockées.
3.4. Outils de développement :
3.4.1. MS SQL SERVER 2008 :
Microsoft ® SQL Server ™ 2008 est un système de gestion de

base de données et d'analyse pour l'e-commerce, line-of-business et
des solutions d'entreposage de données. Cette simplification permet
aux développeurs et administrateurs de tous niveaux de créer des
applications Web ou en local, à partir de bases de données et de
scripts SQL.

3.4.2. MS VISUAL STUDIO 2012 :
Visual Studio est un ensemble complet d'outils de développement

permettant de générer des applications ASP.NET, des services web
xml, des applications bureautiques et des applications mobiles. La
dernière version de visual studio (MS VISUAL STUDIO 2012)
introduit le développement sur l’environnement Windows RT.
3.4.3. TORTOISE SVN :
TORTOISE SVN est un des logiciels client SVN les plus

populaires. Cet outil permettant de gérer les versions d’un projet en
cours de développement : ceci permettant aux développeurs de
récupérer les versions précédentes de ses fichiers, sans oublier
l’examination et le suivi de modification de ces données.
4. Interfaces du projet :
Dans cette section, les interfaces qui suivent représentent le fruit de

conception et de développement de ce projet.
4.1. Page d’accueil :

La figure suivante illustre la page d’accueil de l’application
‘MySMQ’. Étant conçue sous forme d’application intranet, cette
application offre un grand avantage aux utilisateurs du système,
dans la mesure où elle se base sur le principe du ‘SINGLE SIGN
ON’ : il suffit alors d’accéder à la plateforme du MySMQ par le biais
de son compte Windows, à condition que celui-ci appartient au
domaine de l’agence.

Figure 26 : Application MySMQ - Page d’accueil

4.2. Liste des processus :
L’interface ci-après montre la liste des processus gérés au niveau de

l’agence, et qui sont pris en charge par l’application ‘MySMQ’ :
Figure 27 : Application MySMQ – liste des processus
Comme la montre la figure ci-dessus, on remarque pour chaque

processus la présence de l’utilisateur responsable de sa création et de sa publication,
son type ainsi qu’un lien qui redirige l’utilisateur final vers la liste des activités
composant chaque processus (voir l’interface suivante).

4.3. Ajout d’une activité à un processus :
La figure 26 illustre la liste des activités appartenant au processus de

« gestion de consommation d’eau et d’électricité ».
Figure 28 : Application MySMQ – liste des activités par processus
On ne peut accéder dans cette vue qu’aux activités liées au processus

demandé. Le lient de création en haut de la page permet d’ajouter une activité au
processus en question.
Après redirection, on obtient une interface semblable à la suivante :

Ce n’est ue l’utilisateu cou ant ui

peut ajouter une activité à ce
p ocessus (l’utilisateur doit être le
même qui déclaré le processus au
niveau du SMQ)
Figure 29 : Application MySMQ – Ajout d’une activité par processus

4.4. Création d’un organisme et de ses entités :
Avant de pouvoir créer une entité, il faut tout d’abord déclarer l’organisme
auquel elle sera affectée. L’interface ci-après montre la vue de gestion des
organismes :
Figure 30 : Application MySMQ – gestion des organismes
Après avoir déclaré l’organisme au niveau du système, l’utilisateur peut se diriger

vers le menu des entités à travers lesquels il peut affecter une entité à l’organisme
qu’il vient de créer.
L’interface ci-après montre le formulaire de saisie pour affecter une entité à un

organisme ou à une entité parent :

Figure 31 : Application MySMQ – interface de saisie des entités d’un organisme
4.5. Affectation d’une compétence à un employé :
Il est important dans un SMQ de gérer les ressources humaines, et en

particulier les compétences des membres du personnel. La figure 30 illustre
l’interface de gestion des compétences pour un employé : l’avantage dans
cette interface c’est de pouvoir donner la main à l’utilisateur courant la
possibilité de mettre à jour ses propres compétences, sans pour autant
entrer en conflit avec celles des autres employés.

Figure 32 : Application MySMQ – gestion individuelle des compétences

Conclusion & perspectives de travail

Durant les cinq années de mon cursus, j’ai pu acquérir des connaissances au
niveau technique, grâce aux efforts prolongés de la part des professeurs qui veillent à
la qualité de l’enseignement et qui partageaient leurs connaissances sans
modération.
Pour compléter mon cursus, j’ai été amené à réaliser un projet de fin d’étude au
sein de l’Agence pour l’Aménagement de la Vallée du Bouregreg, qui consistait à
développer, après établir une étude fonctionnelle, un Système de Management de
Qualité respectant les exigences imposés par la norme ISO9001-version 2008, et étant
aussi adaptable aux pratiques courantes des organismes marocains : ceci m’avait
permis par conséquent d’approfondir mes connaissances dans le métier de qualité,
mais aussi d’avoir l’occasion d’apprendre d’avantage les technologies de
développement dont je n’avais pas eu l’occasion d’étudier durant mon cursus. Ceci
m’a permis entre outre de préparer activement mon insertion professionnelle.
Néanmoins, l’élaboration l’analyse des besoins, de la conception ainsi que la

réalisation du projet présentent aussi quelques difficultés qu’il fallait surmonter,
notamment les contraintes techniques d’une part, et le degré de complexité imposé
par le système. Ajoutons à cela le respect de la bonne implémentation des procédures
gérées au sein de l’agence.
S’agissant de la réalisation de ce travail, j’ai pu réaliser les modules de gestion

des processus et celui de l’administration (à noter qu’ils sont opérationnels au sein de
l’environnement de production). Les autres modules quant à eux sont en cours de
réalisation dans les prochains jours avenir. Des actions correctives sont toutefois
prévues en cas de dysfonctionnement de l’application, avec la possibilité d’accomplir
les tâches restantes du projet pour d’éventuelles exigences.
En résumé, ce projet fut très instructif dans la mesure où il m’a permis

d’approfondir mes relations professionnelles et relationnelles, en appréhendant au
quotidien autre chose que la structure organisée du monde professionnel, en
s’intégrant à une équipe, et en participant activement, aux tâches professionnelles.

Bibliographie :
 [PDF] Présentation RUP (2010).

 [PDF] Professional_asp.net_mvc_4
 [PDF] ISO 9001 enjeux et connaissance de la norme v.1
 [PDF] cours08 mguc s651 les tableaux de bord
 [PDF] CALCUL AVEC ISO 19761 DE LA TAILLE DE
LOGICIELS DEVELOPPES SELON RATIONAL UNIFIED
PROCESS.
 [PDF] CMMI ® pour le développement, Version 1.2
Webographie :
 http://www.juliencorioland.net/tags/aspnet-mvc?page=2 :
procédure d’utilisation de jQuery.
 http://support.microsoft.com/kb/810098/fr : support de
documentation pour les bogues et les messages d’erreur.
 http://reward.developpez.com/tutoriels/dotnet/entity-
framework/approche-code-first/: l’approche Code-First de
ENTITY D+FRAMEWORK.

Mise_en_place_dun_Systeme_de_Management

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mise_en_place_dun_Systeme_de_Management

Transféré par

Droits d'auteur :

Formats disponibles

Mise en place d’un Système

Encadrant de l’entreprise : M. Edraoui Mouloud

Encadré par : M. Belabbes Anas

Rédigé par : Hajji Anass Page 1

Je tiens à adresser mes sincères remerciements :

Au directeur de l’agence de l’aménagement de la vallée de

À mon encadrant au sein de l’agence M. EDRAOUI

À toute l’équipe du service informatique de l’agence

À mon encadrant à l’EMSI M. BELABBES ANAS

À tous les membres du jury

Rédigé par : Hajji Anass Page 2

L’objectif de ce projet consiste à mettre en place un Système de

Les étapes directrices dans ce présent document seraient

La première étape consiste d’effectuer une étude préalable, afin

** Mots clefs: [SMQ, ISO9001, UML, RUP, ASP.NET MVC,

Rédigé par : Hajji Anass Page 3

This report represents the summary of my work with the

The first step is to conduct a preliminary study to assimilate the

Rédigé par : Hajji Anass Page 4

Liste des abréviations

Rédigé par : Hajji Anass Page 5

Figure 1 : Organigramme de l’agence .............................................................................................15

Figure 2 : Planning prévisionnel ............................................................................................... 24-25

Figure 3 : Planning réel ............................................................................................................... 26-27

Figure 4 : Workflow Documentaire .................................................................................................34

Figure 5 : Acteurs du système ...........................................................................................................43

Figure 6 : Diagrammes de cas d’utilisation – Module ‘Administration’ ..................................44

Figure 7 : Diagramme de cas d’utilisation – Module ‘Processus’ ..............................................45

Figure 8 : Description du scénario ‘Créer un processus’ .............................................................46

Figure 9 : Diagramme de séquence – Création d’un processus et d’une activité....................47

Figure 10 : Diagramme de cas d’utilisation – Module ‘Document’ ...........................................48

Figure 11 : Diagramme d’état – Cycle de vie d’un document .....................................................50

Figure 12 : Diagramme de cas d’utilisation – Module ‘Non-Conformité’ ...............................52

Figure 13 : Diagramme de cas d’utilisation – Module ‘Audit et réunion’ ...............................53

Figure 14 : Processus de création d’un audit et d’une réunion ..................................................55

Figure 15 : Diagramme de cas d’utilisation – Module Tableau de bord ..................................56

Figure 16 : Diagramme de classes – bloc ‘Gestion des utilisateurs’ .........................................58

Figure 17 : Diagramme de classes – bloc ‘Gestion des compétences et formations’ ..............59

Figure 18 : Diagramme de classes – bloc ‘Organisme’ .................................................................60

Figure 19 : Diagramme de classes – Module ‘Processus’.............................................................61

Figure 20 : Diagramme de classes – Module ‘Document’ ...........................................................62

Figure 21 : Diagramme de classes – Module ‘Non-Conformité’ ................................................64

Figure 22 : Diagramme de classes – Module ‘Audit et réunion’ ................................................65

Figure 23 : Diagramme de classes – Module ‘Tableau de bord’ ................................................66

Figure 24 : Architecture applicative du projet ...............................................................................68

Figure 25 : Architecture technique du projet ................................................................................69

Rédigé par : Hajji Anass Page 6

Figure 26 : Application MySMQ – Page d’accueil ........................................................................74

Figure 27 : Application MySMQ – liste des processus ................................................................75

Figure 28 : Application MySMQ – Liste des activités par processus .......................................76

Figure 29 : Application MySMQ – Ajout d’une activité par processus ...................................77

Figure 30 : Application MySMQ – Gestion des organismes .....................................................78

Figure 30 : Application MySMQ – Gestion individuelle des compétences ...........................80

Rédigé par : Hajji Anass Page 7

Liste des tableaux

Tableau 2 : Description de la phase d’étude préalable ......................... 23

Tableau 3 : Description de la phase de conception ................................ 23

Tableau 4 : Description de la phase de développement ......................... 24

Tableau 5 : Matrice des risques .................................................................... 29

Tableau 6 : Équipe du service informatique............................................... 30

Tableau 7 : Équipe du projet .......................................................................... 30

Tableau 8 : Série des normes ISO9000 ....................................................... 33

Tableau 9 : Tableau d’étude comparative ................................................... 40

Tableau 10 : Description du scénario ‘publier un document’ .............. 50