Rapport PFE

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université de Sousse
*-*-*-*-*
Institut Supérieur de Gestion de Sousse
RAPPORT DE STAGE
EN VUE D’OBTENTION DE LA
LICENCE APPLIQUÉE EN INFORMATIQUE DE GESTION
PARCOURS : TECHNOLOGIES DES SYSTÈMES D'INFORMATION
Conception et développement d’une application web de gestion des

projets
LIEU DU STAGE : WEB 2 COM
ELABORE PAR : SOUS LA DIRECTION DE :

BAHRI SOFIEN BOUSSEMA AMINA
NOBEL EL HOUSSINE BOUBAKER
Année Universitaire 2012/2013

Remerciement
Avant de présenter ce rapport, j'aimerais bien présenter mes vifs remerciements à tous ceux
ou celles qui, d’une manière directe ou indirecte, ont contribué par leur collaboration et leur
soutient à la réalisation de ce travail.
Ce travail n’aurait pu voir le jour sans le soutien de mes professeurs de l’Institut Supérieur
de Gestion de Sousse pour accomplir notre formation à l’informatique de gestion.
J’exprime mes profondes reconnaissances à Mlle. Amina Boussema son soutien constant au
cours de ce stage et ses recommandations avec ses conseils et son aide précieuse.
Je tiens à remercier Mr. Nobel Elhoussine Boubaker m’a fait l’honneur de me recevoir dans
son agence de Web marketing, je le remercie pour son encadrement laboureur, son soutient
constant au cours de la réalisation du projet et son assistance permanente.
Toute l’équipe de web 2 com pour leur coopération, leur sympathie et ses grands efforts de
faire son bien pour m’aider à réaliser le projet dans des bonnes conditions.
Tous les membres de jury pour l’honneur qu’ils m’ont fait en acceptant de juger mon travail.
Mes remerciements non seulement pour le savoir qu’ils nous ont transmis, mais aussi pour la
fierté et l’ambition qu’ils nous donnent. Ce sont des personnes qui nous ont soutenues à chaque
moment, et dans chacun de nos instants de faiblesse, avec leur attention et gentillesse.
DEDICACE
C’est avec un immense plaisir que je vous dédie ce modeste travail à tous ceux qui m’ont
soutenu et tous ceux qui m’aiment, en particulier à :
Mes très chers parents, en témoignage de la hauteur de leur patience, leur confiance et tous
les sacrifices déployés à mon égard, que Dieu me les protège.
Mon cher frère et ma chère sœur et tous mes amis qui m’ont aidé à accomplir ce travail.
Veuillez tous agréer mes vifs sentiments de respect.

Sommaire
Sommaire
Introduction Générale......................................................................................................................1
CHapitre 1 : Etude Préalable............................................................................................................2
1.1 Introduction...................................................................................................................................2
1.2 Présentation de l’organisme d'accueil............................................................................................2
1.2.1 Equipe...................................................................................................................................................2
1.2.2 Adresse de l’entreprise..........................................................................................................................3
1.2.3 Services offerts.....................................................................................................................................3
Organigramme de l’organisme d’accueil « WEB-2-COM »..........................................................................4
1.3 Etude de l’existant.........................................................................................................................5

1.3.1 Description de l’existant.......................................................................................................................5
1.3.2 Critique de l’existant.............................................................................................................................5
1.3.3 Solutions proposées..............................................................................................................................6
1.4 Présentation de projet....................................................................................................................6

1.4.1 Contexte................................................................................................................................................6
1.4.2 Objectifs de l’application......................................................................................................................6
1.5 Planification de stage.....................................................................................................................7

1.6 Conclusion.....................................................................................................................................7
Chapitre 2 : Spécification et analyse des besoins............................................................................9
2.1 Introduction...................................................................................................................................9
2.2 Méthodologie de conception.........................................................................................................9
2.2.1 Choix de processus de devloppement.........................................................................................9
2.2.2 Choix de l’approche objet...................................................................................................................10
2.2.3 Choix du langage de modélisation......................................................................................................10
2.3 Analyse des besoins.....................................................................................................................11

2.3.1 Identification des principaux acteurs..................................................................................................11
2.3.2 Besoins fonctionnels...........................................................................................................................12
2.3.3 Besoins non fonctionnels....................................................................................................................13
2.4 Modélisation des besoins fonctionnels........................................................................................14

2.4.1 Diagramme de cas d’utilisation général..............................................................................................14
2.4.2 Diagrammes de cas d’utilisation détaillés...........................................................................................15
2.4.2.1 Diagramme de cas d’utilisation « S’identifier »......................................................................16
2.4.2.2 Diagramme de cas d’utilisation « Gérer Utilisateur ».............................................................17
2.4.2.3 Diagramme de cas d’utilisation « Gérer Projet ».....................................................................19
2.4.2.4 Diagramme de cas d’utilisation « Gérer Campagne ».............................................................21
2.3 Diagramme de séquence..............................................................................................................22

2.3.1 Diagramme de séquence de cas d'utilisation « s'identifier »...............................................................23
2.3.2 Diagramme de séquence de cas d'utilisation « ajouter utilisateur »..................................................24
2.4 Diagramme D’activité.................................................................................................................24

2.4.1 Diagramme d’activité de cas d'utilisation «s'identifier».....................................................................24
2.4.2 Diagramme d’activité de cas d'utilisation «Supprimer Campagne»...................................................26
2.5 Conclusion...................................................................................................................................26
Chapitre 3 : Conception.................................................................................................................28
3.1 Introduction.................................................................................................................................28
Sommaire
3.2 Conception détaillée....................................................................................................................28

3.2.1 Vue Statique........................................................................................................................................28
3.2.1.1 Diagramme de classe...............................................................................................................29
3.2.1.2 Diagramme de deploiement.....................................................................................................33
3.2.2 Vue dynamique...................................................................................................................................34
3.2.2.1 But du modèle dynamique.......................................................................................................34
3.2.2.2 Diagramme de séquence..........................................................................................................34
3.3 Diagramme d’état........................................................................................................................38

3.3.1 Diagramme d’état «Avancer Campagne»...........................................................................................38
3.4 Conception de la base des données..............................................................................................39

3.4.1 Modèle Relationnel.............................................................................................................................39
3.5 Architecture client/serveur..........................................................................................................39

3.5.1 Architecture 3-tiers.............................................................................................................................39
3.5.2 Choix de l’architecture........................................................................................................................40
3.6 Conclusion...................................................................................................................................41
Chapitre 4 : Réalisation.................................................................................................................43
4.1 Introduction.................................................................................................................................43
4.2 Environnement de développement...............................................................................................43
4.2.1 Environnement matériel......................................................................................................................43
4.2.2 Environnement logiciel.......................................................................................................................43
4.3 Patron de conception...................................................................................................................45

4.3.1 Modèle MVC......................................................................................................................................45
4.4 Choix du langage de programmation...........................................................................................46

4.5 Système de gestion de la base de données relationnel.................................................................47
4.6 Enchainement des programmes...................................................................................................48
4.6.1 Organigramme la partie de l’Administrateur......................................................................................48
4.6.2 Organigramme de la partie de Chef de projet.....................................................................................49
4.6.3 Organigramme de la partie de Technicien..........................................................................................49
4.6.4 Organigramme de la partie de Client..................................................................................................50
4.7 Présentation des interfaces utilisateurs........................................................................................50

4.7.1 Interface d’identification.....................................................................................................................50
4.7.2 Interface de création d’ un nouvel utilisateur.....................................................................................51
4.7.3 Interface de création d’ un projet........................................................................................................51
4.7.4 Interface de création d’une campagne................................................................................................52
4.7.6 Consulter les projets............................................................................................................................53
4.7.7 Interface de « Avancer Tâche »..........................................................................................................54
4.8 Conclusion...................................................................................................................................54
Conclusion et Perspectives............................................................................................................55
Webliographie...............................................................................................................................56
Liste Des Figures
Liste Des Figures

Figure 1.1 : Organigramme de l’organisme d’accueil « WEB-2-COM ».......................................4
Figure 2.1 : Modèle en cascade.......................................................................................................9
Figure 2.2 : Diagramme de cas d’utilisation général.....................................................................14
Figure 2.3 : Description cas d’utilisation « S’identifier ».............................................................16
Figure 2.4 : Diagramme de cas d’utilisation « Gérer Utilisateur »................................................17
Figure 2.5 : Diagramme de cas d’utilisation « Gérer Projets ».....................................................19
Figure 2.6 : Diagramme de cas d’utilisation « Gérer Campagne »...............................................21
Figure 2.7 : Diagramme de séquence de cas d'utilisation «s'identifier»........................................23
Figure 2.8 : Diagramme de séquence de cas d'utilisation «Ajouter utilisateur»............................24
Figure 2.9 : Diagramme d’activité «s'identifier»...........................................................................25
Figure 2.10 : Diagramme d’activité «Supprimer Campagne».......................................................26
Figure 3.1 : Diagramme des classes..............................................................................................29
Figure 3.2 :Diagramme de déploiement........................................................................................33
Figure 3.3 :Diagramme de séquence de cas d'utilisation «créer campagne».................................35
Figure 3.4 :Diagramme de séquence de cas d'utilisation «Consulter campagne».........................35
Figure 3.5 :Diagramme de séquence de cas d'utilisation «créer utilisateur».................................36
Figure 3.6 :Diagramme de séquence de cas d'utilisation «avancer campagne»............................37
Figure 3.7 :Diagramme de séquence de cas d'utilisation «envoi message»..................................37
Figure 3.8 :Diagramme d’état-transition de l’objet «Campagne».................................................38
Figure 3.9 : Architecture 3 tiers ou à 3 niveaux............................................................................40
Figure 4.1 : Le pattern MVC.........................................................................................................46
Figure 4.2 : Menu principale de la partie administrateur...............................................................48
Figure 4.3 : Menu principale de la partie Chef de projet...............................................................49
Figure 4.4 : Menu principale de la partie Technicien....................................................................49
Figure 4.5 : Organigramme de la partie Client..............................................................................50
Figure 4.6 : Aperçu de l’interface d’identification........................................................................50
Figure 4.7 : Aperçu de l’interface « Créer un nouvel utilisateur »................................................51
Figure4.8 : Aperçu de l’interface « Créer projet».........................................................................51
Figure 4.9 : Aperçu de l’interface « Créer campagne ».................................................................52
Figure 4.10 : Aperçu de l’interface « Message d’erreur ».............................................................53
Figure 4.11 : Aperçu de l’interface « Consulter les projets »........................................................53
Figure 4.12 : Aperçu de l’interface «Avancer Tâche»..................................................................54
Liste Des Tableaux
Liste Des Tableaux

Tableau 1.1 : Adresse de l’entreprise..............................................................................................3
Tableau 1.2 : Planning prévisionnel................................................................................................7
Tableau 2.1 : Description de cas d’utilisation général...................................................................15
Tableau 3.1 : Dictionnaire des données « Classe utilisateur »......................................................31
Tableau 3.2 : Dictionnaire des données « Classe projet»..............................................................31
Tableau 3.3 : Dictionnaire des données « Classe campagne »......................................................31
Tableau 3.4 : Dictionnaire des données « Classe E-mailing »......................................................32
Tableau 3.5 : Dictionnaire des données « Classe SMS »..............................................................32
Tableau 3.6 : Dictionnaire des données « Classe Facebook ».......................................................32
Tableau 3.7 : Dictionnaire des données « Classe Google »...........................................................32
Tableau 3.8 : Dictionnaire des données « Classe Tâche ».............................................................33
Tableau 3.9 : Dictionnaire des données « Classe Message »........................................................33
Introduction Générale
Introduction Générale
Dans le monde d’aujourd’hui qui est de plus en plus régi par les lois de l’informatisation et les
nouvelles technologies de l’information vu sa performance et son efficacité, les
entreprises et les sociétés ont opté pour une stratégie d’informatisation afin de profiter de
ces technologies de l’information ainsi que de mettre à jour les services présentés et effectuer un
profit maximum.
En vertu de cette stratégie, Web2com intègre des applications informatiques et met en place un
système d’information qui permet l’analyse et la diffusion de l’information utile pour faciliter le
déroulement du travail au sein de son groupe technique et interaction avec ses clients.
C’est dans ce cadre que s’inscrit notre stage de fin d’année qui cible à concevoir et à
développer une application web pour la gestion des projets.
Le présent rapport présente donc le travail que nous avons effectué lors de notre stage au sein de
WEB 2 COM.
Il est structuré en quatre chapitres :
Le premier chapitre intitulé «étude de projet » est dédié à la présentation de cadre général de

projet. Où, nous présentons tout d’abord, l’organisme d’accueil, à savoir la Société « WEB-2-
COM ». Ensuite, une étude préliminaire et une critique de l’existant seront dressés accompagnés
des solutions envisagées.
Nous détaillons, par la suite dans le deuxième chapitre « spécification et analyse des besoins », la
méthodologie de conception aussi bien les besoins fonctionnels et non fonctionnels de notre
application. Cette phase présente une spécification complète des besoins issus de cas
d’utilisation, sous forme des diagrammes de séquence et activités.
Ensuite, et dans la troisième chapitre « Conception », nous présentons une modélisation

conceptuelle de notre solution. Pour ce faire, nous avons adoptés deux points de vue différents
qui sont la vue statique de notre base des données à travers le modèle relationnel.
Le dernier chapitre « Réalisation » sera consacré à la présentation d’une étude technique portant
sur l’environnement de développement logiciel et matériel utilisé. Nous présentons, ainsi, les
différentes fonctionnalités offertes par notre application à travers des captures d’écran.
1
Chapitre 1 :
Etude
Préalable
Chapitre 1 : Etude Préalable
CHapitre 1 : Etude Préalable

1.1 Introduction
L'étude préalable comporte une analyse approfondie sur les procédures de travail existantes afin
de dégager les insuffisances et fixer les objectifs à suivre. Cette étape est indispensable pour tout
projet de qualité et qui assure sa bonne réalisation en déterminant les différents fonctions et
contraintes
Ce premier chapitre est consacré à l'étude préalable de notre projet. Nous commençons par une
présentation de l'organisme d'accueil. Ensuite, nous dresserons une étude de l'existant. L’analyse
et le critique de l’existant nous ont permis de proposer des solutions aux différents problèmes
rencontrés. Enfin, nous présentons les objectifs de notre projet.
1.2 Présentation de l’organisme d'accueil
WEB-2-COM est une société unipersonnelle à responsabilité limitée (SUARL). C'est une agence
de webmarketing spécialisée dans le consulting de promotion, la notoriété et la popularité des
sites web, l’e-mailing, le référencement et le content management.
Ils sont connus par plusieurs sociétés de développement de site web et des agences de
communication grâce à notre effort marketing et commercial réalisé en Tunisie.
En effet, WEB-2-COM a effectué plusieurs actions pour des entreprises tunisiennes et étrangères
et a noué des partenariats avec plusieurs agences. Elle possède des consultants passionnés issus
des plus grandes écoles.
WEB-2-COM a effectué plusieurs actions "haut de gamme" pour des entreprises tunisiennes et
étrangères et a noué des partenariats avec plusieurs agences. Elle possède des consultants
passionnés, issus des plus grandes écoles de commerce, trilingues (Ar, Fr, Ang) ou quadrilingues
(Ar, Fr, Al, Ang).
1.2.1 Equipe
Le personnel du « web 2 com » est organisé en équipes.

La société WEB 2 COM est composée par des ingénieures et des techniciens disposant d’une
expérience laborieuse dans le domaine des TIC et scientifiques hautement qualifiés.
2
 Huit consultants dont un expert en commerce électronique et en NTIC et deux en

communication.
 Formation initiale : Bac + 3 / Bac + 6
 Age : entre 25 et 32 ans
 Langues maîtrisées : Arabe, Français, Anglais, Allemand.
1.2.2 Adresse de l’entreprise
4ème étage - Immeuble BOUHAJEB. Boulevard

Adresse du Leader Yasser ARAFAT. Sahloul I - 4054
Sousse. Tunisie
Téléphone (+216)73 82 09 62 – (+216)73 82 16 54
Fax (+216)73 82 05 60
Site web www.web-2-com.com
E-mail commercial@web-2-com.com
Tableau 1.1 : Adresse de l’entreprise
1.2.3 Services offerts
 Community Management / Recrutement des Fan

 Publicité sur les Réseaux Sociaux : Facebook / Vidéo / Linkedln / Twitter.
 Publicité sur les Moteurs de Recherche : Google / Yahoo ! / Bing / Display…
 Affiliation et Netlinking
 Conseil et budgétisation medias planning
 Hébergement des Sites Web
 E-mail marketing : Ciblage, Routage et Tracking
 Mobile Marketing: SMS / MMS / Bluetooth
3
Organigramme de l’organisme d’accueil « WEB-2-COM »
Figure 1.1 : Organigramme de l’organisme d’accueil « WEB-2-COM »
L’organisme de « WEB-2-COM » se compose de quatre principaux départements :

 Département FINANCIER & RESSOURCES HUMAINES
 Département TECHNIQUE CHEF DES PROJETS
 Département DIRECTEUR COMMERCIAL
 Département COMMUNICATION & MARKETING
4
1.3 Etude de l’existant

Dans cette partie, nous élaborons une étude de l'existant afin de dégager les principaux
problèmes rencontrés auxquels nous allons proposer des solutions.
1.3.1 Description de l’existant
Dans la société, le suivi des processus de travail et une tâche très difficile et très compliquée qui
se déroule de la manière suivante :
 Le chef de projet fait le suivi des projets avec des papiers imprimés appelés «Projets
en cours»
 il suit aussi d'autres documents qui sont appelés « travail de jour » et qui sont
distribués par les techniciens au premier lieu pour remplir les tâches effectuées pour
chacun des projets et par jour.
 Puis, il va attribuer les rôles, les tâches et les dossiers des projets aux des techniciens
correspondent
 Une fois que le projet est lancé, le chef de projet va suivre les processus effectué par
le téléphone à travers des papiers distribués.
 A chaque tâche effectuée, le technicien envoie un e-mail au chef de projet ou il va
l'appeler pour lui informer de l’avancement de projet.
 Chaque jour, le technicien va envoyer un suivi au client pour lui informer de
l’avancement de ses projets.
Ce processus manuel pause des problèmes de différents types et qui vont être détaillés dans la
section suivante.
1.3.2 Critique de l’existant
Les faiblesses de la situation présentée se résument dans les points suivants :

 Problèmes coté chef de projet
 Travail manuel et répétitif
 Perte de temps lors de passation des informations.
 Problèmes coté techniciens
 Un risque que le personnel oublie l’organisation des tâches ou des étapes suivantes
au cours de projet en cour.
 Mauvaise enchainement des processus de travail.
5
 Le suivi s’effectue manuellement sur les papiers.

 Problèmes de liaison entre les différentes taches exécutées au projet.
 Problèmes coté Client
 Retard de livraison au client.
 Problèmes de suivi de projet de la part de client.
 L’ancien processus non automatisé comporte nombreuses étapes, et bien souvent, les
données sont enregistrées en retard
 Une faible base de données pour le stockage des informations et des projets.
 Exigence d’un grand frais de communication pour informer les clients.
1.3.3 Solutions proposées
Dans cette partie nous proposons une solution pour éliminer toutes les difficultés rencontrées.
Pour cela nous allons créer une application informatique qui permet de :
 Gérer les suivis des projets.
 Limiter le suivi manuel et par conséquent limiter les erreurs.
 Assurer une meilleure qualité de suivi des différent processus de travail.
 Développer une nouvelle méthode de suivi des Campagnes de communication.
1.4 Présentation de projet

1.4.1 Contexte
Dans le cadre de notre préparation au diplôme de Licence Appliqué en Informatique de gestion,

nous avons été amenés à effectuer un stage de fin d'étude. Notre projet a pour finalité de
concevoir puis développer une application web Intranet pour le suivi de compagne de
communication. Cette application va permettre au chef de projet de suivre les employés, les
tâches effectuées, ainsi l'état du projet en temps réel.
1.4.2 Objectifs de l’application
Les principaux objectifs de l’application à développer sont essentiellement :

 Eviter l’utilisation des papiers.
 Faciliter d’utilisation de l’application.
 Assurer le suivi des processus de travail en temps réelle aux différents acteurs liés au
projet.
6
 Répondre exactement aux besoins de l’entreprise.

 Automatiser l’organisation de groupe dans l’enchainement de travail de campagne.
 Diminuer les erreurs de communication entre les personnels et les clients.
 Diminuer les charges téléphoniques et les papiers distribués.
 Assurer une bonne qualité de travail.
 Assurer la sécurité d’information.
1.5 Planification de stage

Le tableau ci-dessous présent La planification prévue pour la réalisation du notre projet durant la
période du stage.
Mois Janvier Février Mars Avril Mai

Semaine 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2
Recherche et
X X X X X X X X X X X
documentation
Etude Préalable X X X X
Spécification et
analyse des X X X X
données
Conception X X X X
Implémentation X X X X X X X X
Test et
X X
validation
Elaboration du
X X X X X X X X X X X X X
rapport
Tableau 1.2 : Planning prévisionnel
1.6 Conclusion
Dans ce premier chapitre nous avons présenté le cadre général de notre stage suivi d’une étude
de l’existant à fin de préciser les objectifs à atteindre.
En effet, l’étude de l’existant nous à permis de préparer une bonne conception a fin de rependre à
nos besoins.
7
Après cette étude, nous passons à la phase de spécifications fonctionnelles qui identifie les
utilisateurs et les fonctionnalités de notre application.
8
Chapitre 2 :
Spécification
et analyse des
besoins
Chapitre 2 : Spécification et analyse des besoins

2.1 Introduction
En se basant sur l’étude préalable définie dans le chapitre précédant, nous visons maintenant à
formuler les besoins de l’utilisateur de façon à rendre plus claire les principales fonctionnalités
de l’application à développer.
Dans ce chapitre, nous commençons en premier lieu par présenter nos choix méthodologiques.
Ensuite, nous identifions les besoins fonctionnels et non fonctionnels de notre application. Enfin,
Nous clôturons ce chapitre par la modélisation des différents besoins fonctionnels à travers des
diagrammes de cas d’utilisation, de séquence et d’activité.
2.2 Méthodologie de conception

Cette section, sera reversée pour présenter les différents choix méthodologiques que nous avons
opté ainsi que des justifications.
2.2.1 Choix de processus de devloppement

Un cycle de vie est un ensemble d’étapes nécessaire au développement, à la diffusion et à
l'utilisation d'un logiciel. Par extension, désigne aussi le reste de vie d'un logiciel fini jusqu'à son
abandon par son éditeur.
Ainsi, nous avons choisi un processus de développement utilisant le cycle en cascade ceci
consiste à faciliter la planification des étapes et des délais d'une façon simple et logique.
Nous pouvons représenter le modèle en cascade par la figure ci-dessous :
Figure 2.1 : Modèle en cascade
10
Le principe de modèle en cascade est de découper le projet en phases distinctes sur le principe du
non-retour. Lorsqu’une phase est achevée, son résultat sert de point d'entrée à la phase suivante.
L'avantage de ce modèle est de proposer au fur et à mesure une démarche de réduction des
risques, en minimisant au fur et à mesure l'impact des incertitudes.
Néanmoins, cette démarche, a l'inconvénient d'exclure l'utilisateur dès la phase de conception.
Le contrôle qualité significatif survient alors en fin de projet, et, à ce moment, si l'utilisateur
s'aperçoit que le système ne répond pas correctement aux besoins exprimés, il peut être trop tard.
Le modèle en cascade est adapté aux projets de durée inférieure à l'année, sur des projets à forte
composante réglementaire, comme les projets de back-office [1].
2.2.2 Choix de l’approche objet
L'approche orientée objet est une méthode de modélisation basée sur une représentation abstraite
des entités du monde réel. Cette méthode regroupe les données et les traitements sur ces données
au sein d'une entité unique [2].
Pour la conception de notre application, nous avons choisi l'approche objet. En effet, cette
approche présente plusieurs avantages, à savoir :
 Meilleure modularité : les communications entre objets sont réalisées par le biais
d’opérations d’interface.
 Meilleure sécurité : le code de chaque méthode ne s’applique que sur les données de
l’objet. Certaines parties de l’objet ne sont pas accessibles pour certains (et n’ont pas
d’ailleurs à être connues).
 Meilleure réutilisabilité : les objets considérés comme des composants réutilisables
appropriés vu leur indépendance.
 Meilleure conception : les données et les méthodes sont spécifiées en même temps.
 Meilleure lisibilité : les données et les méthodes sont décrites au même endroit.
 Meilleure portabilité : les parties masquées pourront être modifiées sans que l’utilisateur
n’ait à changer son code puisqu’il n’a pas directement accès à celles-ci. C’est ici que l’on
pourra mettre des points dépendant des machines.
2.2.3 Choix du langage de modélisation
UML (Unified Modeling Language) est un langage formel et normalisé en termes de

modélisation objet qui donne une modélisation graphique issue dans la notation employé dans
différentes méthodes orientées objets.
11
 UML est une notation pas une méthode.

 UML est un langage de modélisation objet.
 UML convient pour toutes les méthodes objet [3].
Ainsi, peut-on dire que le choix d’UML dans la conception du projet repose sur le fait qu’il est :
 un langage sans ambiguïtés
 un langage universel pouvant servir de support pour tout langage orienté objet
 un moyen de définir la structure d'un programme
 une représentation visuelle permettant la communication entre les acteurs d'un même
projet
 une notation graphique simple, compréhensible même par des non informaticiens.
2.3 Analyse des besoins

La phase d'analyse et de conception est un procédé qui a pour objectif de permettre de formaliser
les étapes préliminaires du développement d'un système afin de rendre ce développement plus
fidèle aux besoins du client. Pour ce faire, on part d'un énoncé informel (le besoin tel qu'il est
exprimé par le client, complété par des recherches d'informations auprès des experts du domaine
fonctionnel, comme les futurs utilisateurs d'un logiciel), ainsi que de l'analyse de l'existant
éventuel (c'est-à-dire la manière dont les processus à traiter par le système se déroulent
actuellement chez le client).
La phase d'analyse permet de lister les résultats attendus, en termes de fonctionnalités, de
performance, de robustesse, etc. L’analyse du sujet nous a permis de cerner les fonctionnalités à
fournir. Les besoins ainsi dégagés ont été classés en besoins fonctionnels et non fonctionnels.
2.3.1 Identification des principaux acteurs
Un acteur, au sens UML, représente le rôle d'une entité externe (utilisateur humain ou non)
interagissant avec le système. Il est représenté par un bonhomme en fil de fer (en anglais stick
man). On représente généralement à gauche l'acteur principal (idéalement il y en a un seul), et à
droite les acteurs secondaires. Il est à noter qu'un utilisateur peut être amené à jouer plusieurs
rôles vis-à-vis du système et à ce titre être modélisé par plusieurs acteurs.
L'objectif poursuivi par les cas d'utilisation est de permettre de décrire, dans des documents
lisibles par tous, la finalité des interactions du système et de ses utilisateurs.
Alors nous avons pu identifier nos acteurs du système envisagé et qui sont essentiellement :
12
 Administrateur : C’est le responsable de l’application qui a tous les droits

 Chef de projet : C’est le responsable de groupe est qui affecte et divise les tâches au groupe
des technicien.
 Technicien : C’est la personne qui fait avancer les processus de projet pour atteindre les
résultats prédéfinis
 Le Client : C’est propriétaire de projet qui a besoin de s’assurer de l’exécution et de la bonne
qualité du rendu de son projet.
2.3.2 Besoins fonctionnels
Les besoins fonctionnels sont directement liés aux tâches à réaliser, et doivent être transparents
plus que possible face aux utilisateurs.
De ce fait, les besoins principaux à accomplir sont :
 Permettre le suivi de projet par le chef de projet et le client.
 Diviser les processus de travail entre les techniciens de différents services.
 Affecter cheque tâche ou campagne d’un projet au technicien adéquat.
 Garantir l’avancement de travail de chaque projet par le technicien consacré ou le chef de
projet ou l’administrateur.
 Garantir l’interactivité et la collaboration entre les différents utilisateurs.
Alors cette application sert à réaliser certaines fonctionnalités, ces fonctionnalités sont
catégorisées selon l’acteur en quatre grandes familles :
a- Fonctionnalités d’administrateur
Gérer utilisateur ; l’administrateur c’est le seul acteur qui peut gérer les différents
utilisateurs, créer ou modifier ou supprimer un utilisateur.
Gérer les projets ; il peut créer, modifier ou supprimer un projet, comme il peut aussi
créer, modifier, supprimer une campagne ou une liste des tâches relié à un projet.
Avancer l’état de projet (campagne ou tâche)
b- Fonctionnalité de chef de projet
Gérer les projets ; il peut créer, modifier ou supprimer un projet, comme il peut aussi
créer, modifier, supprimer une campagne ou une liste des tâches relié à un projet.
c- Fonctionnalité de technicien
Consulter les différents projets (l’état d’avancement)
13
d- Fonctionnalité de client
Consulter son projet (l’état d’avancement)
2.3.3 Besoins non fonctionnels
Ces besoins traduisent des exigences qui, bien qu’elles ne nuisent pas au bon fonctionnement de
l’application, sont caractérisées comme un bon signe quant à l’efficacité de l’application.
Les principaux besoins non fonctionnels de notre futur système seront essentiellement :
 Sécurité : L’utilisation de l’application doit être sécurisée par l’implémentation d’un
système authentification des utilisateurs par un Login et un mot de passe. Ainsi, au
niveau du serveur il faut définir des droits d’accès stricts et protéger le serveur des abus.
 Ergonomie de l’application : L’application doit assurer une ergonomie en ce qui
concerne :
 La simplicité des interfaces
 Respect la charte graphique de la société.
 La facilité de la navigation entre les interfaces
 La performance : Notre application doit être performante, c'est- à- dire à travers ses
fonctionnalités, elle devrait répondre à toutes les exigences des usagers d’une manière
optimale.
 Disponibilité : L’application doit être aussi disponible sur le net pour tous les acteurs et à
tout moment.
 Réutilisabilité : Notre application doit permettre la réutilisation et l’évolution. C’est pour
cela, nous visons à concevoir un ensemble de classes cohérentes, et facilement
réutilisables.
14
2.4 Modélisation des besoins fonctionnels

2.4.1 Diagramme de cas d’utilisation général
La figure 2.2 présente le diagramme de cas d’utilisation général de notre application
<<include>>
Gérer comptes
Administrateur <<include>>
Gérer Messagerie
<<include>>
Gérer projets
S'identifier
Chef de projet
<<include>>
Consulter projets
Client
Technicien
<<include>>
Gérer campagnes
Figure 2.2 : Diagramme de cas d’utilisation général
15
 Description des cas d’utilisation
Acteur Cas d’utilisation Description
Ce cas d'utilisation permet à l'administrateur de consulter,

Gérer utilisateurs
ajouter, modifier et supprimer un utilisateur
Gérer projets
créer, modifier et supprimer des projets.
Administrateu
r Gérer campagnes
avancer, créer, modifier et supprimer des campagnes.
Ce cas d’utilisation permet à l’administrateur de
Gérer messagerie composer, supprimer, consulter et envoyer des messages
aux autres utilisateurs
Ce cas d'utilisation permet au chef de projet de consulter,
Gérer projets
créer, modifier, arrêter et supprimer des projets.
Ce cas d'utilisation permet au chef de projet de consulter,
Gérer campagnes
Chef de projet avancer, créer, modifier et supprimer des campagnes.
Ce cas d’utilisation permet au chef de projet de composer,
Gérer messagerie supprimer, consulter et envoyer des messages aux autres
utilisateurs
Ce cas d'utilisation permet au technicien de consulter les
Consulter projets
différents projets en cours.
Ce cas d'utilisation permet au technicien de consulter ou
Gérer compagne
Technicien avancer une campagne.
Ce cas d’utilisation permet au technicien de composer,
utilisateurs
Client Consulter projet Ce cas d'utilisation permet au client de consulter ses
16
projets à distance.
Ce cas d’utilisation permet au client de composer,
utilisateurs
Tableau 2.1 : Description de cas d’utilisation général
A ce stade, nous avons illustré les différents besoins fonctionnels de différents utilisateurs à
travers un diagramme de cas d’utilisation général. Nous allons essayer, dans la section suivante,
de raffiner chacun des cas d’utilisation pour bien analyser ces besoins.
2.4.2 Diagrammes de cas d’utilisation détaillés
Dans cette section, nous allons détailler chacun des cas d'utilisation présenté précédemment.
2.4.2.1 Diagramme de cas d’utilisation « S’identifier »
Le diagramme de cas d’utilisation « S’identifier » est illustré par la figure ci-dessous :
Administrateur
S'identifier
Chef de projet Client
Technicien
Saisir le Mot_passe
Saisir login
<<include>> <<include>>
Figure 2.3 : Description cas d’utilisation « S’identifier »
17
 Fiche description du cas d’utilisation « s’identifier »
Sommaire d’identification
Titre : S’identifier
But : Ce cas permet à l’acteur d’accéder à l’application en saisissant les paramètres de
connexion.
Acteur : Administrateur, Chef de projet, Technicien et Client.
Version : 1.0
Responsable : Bahri Sofien
Date Création : 29/02/2013 Date Mise à jour : 18/03/2013
Description des enchainements
Pré-condition :
 l’Acteur possède déjà un compte
Déclenchement : ce cas commence lorsque l’Acteur accéder à l’application.
Enchainement nominal :
1. l’acteur saisit ses paramètres de connexion (login, mot de passe)
2. Le système vérifie la validité des données saisies
3. Le système affiche la 1ère interface de l’application
Post conditions :
 l’Acteur peut accéder à l’application
2.4.2.2 Diagramme de cas d’utilisation « Gérer Utilisateur »
Le diagramme de cas d’utilisation «Gérer Utilisateur» est illustré par la figure ci-dessous :
18
Modifier utilisateur
Suprimer utilisateur
Gérer utilisateur
Administrateur
Ajouter utilisateur Recherche utilisateur
Figure 2.4 : Diagramme de cas d’utilisation « Gérer Utilisateur »
 Fiche description du cas d’utilisation « Gérer Utilisateur »
Titre : Gérer Utilisateur
But : Ce cas permet à l’administrateur de créer, modifier ou supprimer un Utilisateur.
Acteur : Administrateur.
Version : 1.0
Pré-condition :
 Administrateur est authentifié.
 [modifier, supprimer utilisateur] : L'Utilisateur est enregistré déjà dans le système.
Déclenchement : ce cas commence lorsque l’Administrateur accéder à l’interface de
« Gérer utilisateur ».
Ajouter utilisateur Modifier utilisateur Supprimer utilisateur
1. L’administrateur saisit les 1. L’administrateur choisit le 1. Le système affiche la
informations concernant type d'utilisateur liste des utilisateurs
19
cet utilisateur et confirme. (technicien, chef projet ou 2. L’administrateur

2. Le système vérifie les client). sélectionne l’utilisateur à
champs saisis. 2. le système recherche tous supprimer et clique sur
3. Si l'utilisateur existe dans les utilisateurs associés au le lien "supprimer"
la base des données alors type choisi. 3. le système demande la
le système exécute 3. l'administrateur choisit un confirmation de
[Alternatif 1: utilisateur utilisateur pour modifier suppression
existant] son compte. 4. l'administrateur confirme
4. Le système enregistre les 4. le système vérifie les la suppression
données saisies données saisies. 5. Le système supprime
5. Le système enregistre les l’utilisateur
données saisies
Post conditions :
 Ajouter utilisateur: l’utilisateur est crée.
 Modifier utilisateur : les données d’utilisateur sont modifiées.
 Supprimer utilisateur: l’utilisateur est supprimé
Enchainement alternatifs :
[Alternatif 1 : utilisateur existant] : Le système affiche le message "Utilisateur existant", retour
au point 1 de l’enchaînement nominal
2.4.2.3 Diagramme de cas d’utilisation « Gérer Projet »
Le diagramme de cas d’utilisation «Gérer Projet» est présenté par la figure ci-dessous :
20
consulter les projets supprimer les projets
Modifier les projet
Gérer les projets
Administrateur
<<extend>>
créer projet créer tâche
<<extend>>
chef de projet
créer campagne
créer campagne Google créer campagne SMS
créer campagne facebook créer Maquette
créer campagne E-mailing
Figure 2.5 : Diagramme de cas d’utilisation « Gérer Projets »
 Fiche description du cas d’utilisation « Gérer Utilisateur »
Titre : Gérer Projet
But : Ce cas permet au chef et à l'administrateur de projet de créer, modifier, supprimer
ou consulter un projet.
Acteur : Chef de projet, Administrateur
Version : 1.0
Pré-condition :
21
 la modification et la suppression sont appliquées sur des projets existants déjà.

Déclenchement : ce cas commence lorsque un de ces acteur veulent gérer un projet.
Modifier les Projets Supprimer les Projets

Créer Projets
1. l’acteur accéder à 1. L’acteur Sélectionne un projet 1. L’acteur Sélectionne un
l’interface de 2. Le système affiche l’interface projet
nouveau projet de projet 2. L’acteur clique sur le
2. il saisit les données 3. L’acteur Modifie des données bouton « Supprimer
et clique sur 4. Le système Vérifie les projet »
enregistrer nouvelles données 3. Système demande la
3. Si les paramètres 5. Le système effectue les confirmation de l’acteur
sont invalides, le modifications 4. L’acteur confirme
système va exécuter 5. Le système supprime le
[Alternatif 1 : projet
paramètre invalide].
4. Le système crée le
nouveau projet.
Post conditions :
 Nouveau Projet : Le projet est crée.
 Modifier Projet : Le projet est modifié.
 Supprimer Projet : Le projet est supprimé.
Enchainement alternatifs :
[Alternatif 1 : paramètre invalide] : Le système affiche le message « Saisir le nom du projet »,
retour au point 1 de l'enchaînement nominal
2.4.2.4 Diagramme de cas d’utilisation « Gérer Campagne »
22
Le diagramme de cas d’utilisation «Gérer Campagne» est présenté par la figure ci-dessous :
<<include>>
Consulter Campagne Crérer Campagne
Administrateur
Créer Projet
Gérer Campagne
chef de projet
technicien Supprimer Modifier Avancer Campagne
Figure 2.6 : Diagramme de cas d’utilisation « Gérer Campagne »
 Fiche description du cas d’utilisation « Gérer Campagne »
Titre : Gérer Compagne
But : Ce cas permet à l’acteur de consulter ou avancer l'état d'une compagne.
Acteur : Technicien, Administrateur, Chef de projet.
Version : 1.0
Pré-condition :
 Le projet associé à la compagne existe déjà.
Déclenchement : ce cas commencé lorsque l'acteur accède à une compagne et demande au
système de gérer la compagne.
23
Consulter la campagne
Avancer la campagne
1. L’utilisateur accède à la page « Projets en 1. L’utilisateur accède à la page « Projets en
cours » cours »
2. Il choisi une campagne 2. Il choisi une campagne
3. Cliquer sur le bouton (+) pour avancer 3. Cliquer sur le bouton de suppression pour
l’état de la campagne supprimer la campagne
4. Le système réfléchi automatiquement et 4. Le système affiche un message de
activer la modification d’état. confirmation
5. Si l’utilisateur clic ’ok’ alors le système
supprimer la campagne
6. Si non le système ne supprimer pas la
campagne.
Post conditions :
 Avancer campagne: l’état de la campagne se progresse.
 Arrêter la campagne: la campagne est arrêtée.
2.3 Diagramme de séquence

Le Diagramme de Séquence Système est une version «simplifiée» du diagramme de séquence
(de conception). Il est utilisé pour compléter la description textuelle d'un cas d'utilisation par une
description graphique. Il permet de décrire, sous forme d’une séquence messages, les interactions
entre les acteurs et le système [3].
24
2.3.1 Diagramme de séquence de cas d'utilisation « s'identifier »
Le diagramme de séquence de cas « s’identifier » peut être representé par la figure ci-dessous.
Identification
Système BD
Utilisateur
loop [Champ vide]

Saisir Login+ Mot de pass
Vérification des champs

Message d'erreur
Login + Mot de pass
Vérification des données
alt Succée
Parrametres correctes
accés autorisé
Echec Paramétre incorrectes
accés non autorisé
Figure 2.7 : Diagramme de séquence de cas d'utilisation «s'identifier»
25
 Scénario
L’acteur saisit son login et son mot de passe, pour pouvoir accéder à l'application. Le système
vérifie la validité des paramètres saisis. Si les paramètres saisis sont valides, l’accès est autorisé,
si non un message d'erreur est affiché.
2.3.2 Diagramme de séquence de cas d'utilisation « ajouter utilisateur »
La figure 2.9 ci-dessous présente le diagramme de séquence de cas d’utilisation « ajouter

utilisateur »
26
Ajouter Utilisateur
Interface Ajout Utilisateur BD
Administraeur
loop [champs incorrects]
Remplir les champs

Verification
Message d'Eurreur
alt Utilisateur inexistant Envoi des données
Ajout effectué
Message "ajout avec succés"
Utilisateur existant
Ajout non effectué
Message "Utilisateur existant"
Figure 2.8 : Diagramme de séquence de cas d'utilisation «Ajouter utilisateur»
 Scénario
L’Administrateur accède à l’interface d’ajout d’un utilisateur et remplit le formulaire d’ajout

d’un utilisateur. Le système vérifie la validité des champs saisis. Si les champs sont valides, une
vérification de l’existence d’utilisateur est effectuée. Si l’utilisateur existe, un message d'erreur
sera affiché à l'administrateur si non, l'enregistrement de ce nouvel utilisateur est effectué.
2.4 Diagramme D’activité

Le diagramme d'activités fait partie des diagrammes peu connus que propose UML. Pourtant, il
est très utile et dispose d'un spectre d'utilisation très large. Il permet de décrire toutes sortes de
27
processus : des processus industriels, des processus métier, le déroulement d'un cas d'utilisation
ou encore un algorithme. Je vous présenté donc quelque diagrammes d’activité concerné notre
application [4].
2.4.1 Diagramme d’activité de cas d'utilisation «s'identifier»
La figure ci-dessous présente le diagramme d’activité de la phase d’identification
Utilisateur Système
Afficher la page d'identification
Saissir login+mot de passe
Decision_1
Afficher message d'erreur [champs vide]
[champs non vide]
vérifier paramètre
[paramètres non valides]
Decision_2
[paramétres valides]
Afficher page d'accueil
Figure 2.9 : Diagramme d’activité «s'identifier»
28
 Scénario
Le système affiche le formulaire d’authentification. L’acteur saisit son login et mot de passe.
Le système vérifie les paramètres de connexion saisies, s’ils sont valides, le système affiche la
page suivante si non il réfléchi la page d’identification.
2.4.2 Diagramme d’activité de cas d'utilisation «Supprimer Campagne»
La figure ci-dessous illustre le diagramme d’activité de cas de supprimer une campagne
29
Utilisateur Système
Afficher la liste des campagnes
supprimer une campagne
Afficher un message d'autorisation
Decision_1
[Non Ok]
[Ok]
Supprimer la campagne
Figure 2.10 : Diagramme d’activité «Supprimer Campagne»
 Scénario
Dans ce cas l’utilisateur demande accéder à la campagne précise, et demande de supprimer cette
campagne. Alors le système affiche une fenêtre de confirmation. Si l’utilisateur taper «ok », le
système supprimer la campagne et réfléchi la page en cour. Si non il réfléchi la page sans
supprimer.
2.5 Conclusion
L’étude présentée ci-dessus constitue « le quoi » de notre projet, dans laquelle nous avons
analysé les besoins fonctionnels et non fonctionnels relatifs à notre application. Cette phase nous
30
permet de mettre le premier pas sur le chemin de la conception afin de s’approcher de plus en
plus de l’image finale de notre application. Le chapitre suivant sera consacré à la conception de
notre application
31
Chapitre 3 :
Conception
Chapitre 3 : Conception

3.1 Introduction
Tout logiciel robuste, fiable et évolutif nécessite l'adoption d'une bonne méthodologie de
conception. En effet, une conception adéquate permet de décrire de manière non ambiguë, le plus
souvent en utilisant un langage de modélisation, le fonctionnement futur du système, afin d'en
faciliter la réalisation. Dans ce chapitre, nous allons présenter la conception qui mettra l’accent
sur les différents classes formant l’application et traitera l’interaction entre les différents objets
de l’application.
3.2 Conception détaillée

Afin de modéliser notre application et en se basant sur les spécifications fonctionnelles, on aura
recours aux vues offertes par l'UML
En fait, ce langage do modélisation offre une manière élégante de représenter le système selon
différent vues complémentaire grâce aux diagrammes. Une vue est constituée d’une ou plusieurs
diagrammes. On distingue deux types de vues :
 La vue statique, représente le système physiquement. Cette vue est constituée des
diagrammes suivants :
 Diagramme de classe
 Diagramme d’objets
 Diagramme de composant
 Diagramme de déploiement
 La vue dynamique, montre le fonctionnement du système. Ses diagrammes sont :
 Diagramme de séquence
 Diagramme de collaboration
 Diagramme d’état de transitions
 Diagramme d’activité
3.2.1 Vue Statique
On identifie à ce stade l'aspect statique de notre système qui n'est autre que l'aspect physique que
ce soit de point de vue matériel ou logiciel. Pour se faire on va présenter notre diagramme de
classe.
33
3.2.1.1 Diagramme de classe
Le diagramme de classes est un schéma utilisé pour présenter les classes et les interfaces des

systèmes ainsi que les différentes relations entre celles-ci. Ce diagramme fait partie de la
partie statique d'UML car il fait abstraction des aspects temporels et dynamiques.
La figure ci-dessous représente le diagramme de classe de notre application
1..1
gérer 0..*
Administrateur Utilisateur
- user : String - user : String Messages
- Mot_passe : String - Mot_passe : String - Id_msg : Integer
- Nom_utilisateur : String - Nom_utilisateur : String - Sujet : String
- Prenom_utilisateur : String 1..1 - Prenom_utilisateur : String
1..1 1..1 - Continue : String
- E-mail : String gérer - E-mail : String
gérer - Date_envoi : Date
- N_telephone : Integer 1..* - N_telephone : Integer - adr_destination : String
- Type : int - Type : int
+ envoyer ()
+ s'identifier () + s'identifier () + consulter ()
+ deconnecter () + deconnecter () + recevoir ()
+ céer () + céer () ...
+ Modifier () + Modifier ()
+ Supprimer () + Supprimer ()
... ...
0..1
gérer
Chef de projet
Clients Techniciens
1..1
1..*
gérer
associé
0..1
Consulter 1..*
0..*
Projet
- Ref_projet : Integer
1..* - Nom : string
0..* + créer () 1..1

+ modifier ()
E mailing + supprimer ()
...
- Base : String
- NB_envoi : Integer 1..1
0..*
SMS tâche
- Base : String - Ref_taches : Integer
- NB_envoi : Integer Campagne - nom_tache : String
- Ref_campagne : Integer - tache : String
- Nom compagne : String - date début : String
- Date début : Date - etat : int
- date fin : Date + créer ()
Maquette - Description : String + modifier ()
- état : String + supprimer ()
+ créer () + afficher etat ()
+ modifier () + Avancer etat ()
+ supprimer ()
Facebook + afficher etat ()
0..*
- Budget : double + Avancer etat ()
- NB_jours : Integer + afficher campagne ()
- NB_clics : Integer + avancer campagne ()
Google
- Budget : Double
- Nb_jours : Integer
- NB_clics : Integer
Figure 3.1 : Diagramme des classes
34
a) Description des classes
Les différentes classes indiquées dans le diagramme sont le résultat d’une décomposition plus
ou moins détaillée du système global. Dans ce qui suit, nous présentons une description brève
pour chaque classe :
 Classe Administrateur
Cette classe permet à l'administrateur d'accéder à l'application à travers la méthode "s'identifier"
et de se déconnecter à travers la méthode "se déconnecter"
 Classe Utilisateur
C’est la classe de gestion d'un utilisateur. Elle permet de créer, modifier, supprimer un
utilisateur. Elle fournit, ainsi, des méthodes permettant à l'utilisateur de se connecter et se
déconnecter.
Cette classe est héritée par trois sous-classes et qui sont :
 Classe chef de projet
 Classe technicien
 Classe client
 Classe Projet
C’est la classe contenant les méthodes nécessaires pour la gestion d'un projet. Ces méthodes
permettent de consulter, créer, modifier et supprimer un projet
 Classe Campagne
Cette classe représente une campagne. Elle offre les méthodes permettant de gérer, modifier,
supprimer, activer et arrêter une campagne
On distingue cinq sous classes de cette classe qui sont essentiellement :
 Classe E-mailing
 Classe SMS
 Classe Facebook
 Classe Google
 Classe Maquette
 Classe Tâches
Cette classe de gestion de tache. Elle permet de créer, modifier ou supprimer une tâche.
35
 Classe Message
Cette classe permet d’envoyer, de composer, consulter et supprimer des messages.
b) Dictionnaire des données 7
 Classe Utilisateur ( le même pour la classe Administrateur )

Classe Attribut Description Type
Nom Le nom d’utilisateur String
Prenom le prénom d’utilisateur String
Utilisateu E-mail L’adresse mail d’utilisateur String
r N_télephone Numéro de télephone d’utilisateur Integer
User Le nom vertuel d’utilisateur String
Mot_passe Le mot de passe d’accès à l’application String
Tableau 3.1 : Dictionnaire des données « Classe utilisateur »
 Classe projet
Ref_projet Référence du projet Integer
Projet
Nom nom de projet String
Tableau 3.2 : Dictionnaire des données « Classe projet»
 Classe campagne
id_compagne L’identifiant de la campagne Integer
Nom_campagne Le nom de la campagne String
Date_début La date début de la campagne date
campagne
Date_fin La date fin de la campagne Date
Discription Description de la compagne String
Etat_avc l'état d'avancement de la compagne String
Tableau 3.3 : Dictionnaire des données « Classe campagne »
36
 Classe E-mailing
base Le type de la base des données String
E-mailing
Nb_envoi Le nombre des e-mail envoyés Integer
Tableau 3.4 : Dictionnaire des données « Classe E-mailing »
 Classe SMS
base Le type de la base des données String
SMS
Nb_envoi Le nombre des numéros SMS envoyées Integer
Tableau 3.5 : Dictionnaire des données « Classe SMS »
 Classe Facebook
Budget Le budget proposé pour la consommation de la Double
campagne
Facebook Nb_jours Les nombres des jours de la campagne sur Integer
Facebook
Nb_clics Nombre des clics proposé Integer
Tableau 3.6 : Dictionnaire des données « Classe Facebook »
 Classe Google
Budget Le budget proposé pour la consommation de la Double
campagne
Google Nb_jours Les nombres des jours de la campagne sur Integer
Google
Nb_clics Nombres des clics proposé Integer
Tableau 3.7 : Dictionnaire des données « Classe Google »
 Classe tâches
tâches Id_tâches L’identifient de tâches Integer
contenu Le contenu de tâche String
Date_début La date début de tâche Date
37
Date_fin La date de fin de tâche Date
Tableau 3.8 : Dictionnaire des données « Classe Tâche »
 Classe Message
Id_msg L’identifient de le message Integer
objet L’objet de message String
Messages
contenu Le contenu du message String
Date_envoi La date d’envoi de le message Date
Tableau 3.9 : Dictionnaire des données « Classe Message »
3.2.1.2 Diagramme de deploiement
Ce type de diagramme présente la disposition physique et matérielle qui compose le système et

la répartition des composants sur ses matériels.
Notre application va tourner donc sur un serveur web qui va se dialoguer avec un autre serveur
de base de données, le client va suivre l’avancement de sont projet à travers une simple
connexion internet. Le technicien et le chef de projet peuvent accéder à l’application soit à
travers l’internet soit à travers une ligne spécialisé LS, de même pour l’administrateur qui va
gérer l’application.
Serveur application
Serveur de données
application
1..1
T CP/IP (LAN) SGBD
1..1
serveur web
1..1
Internet/LS
Internet
* *
Internet/LS
Internet/LS Technicien
Client
navigateur
navigateur
1..1 1..1
Administrateur Chef de projet
navigateur navigateur
Figure 3.2 :Diagramme de déploiement
38
3.2.2 Vue dynamique
Après une modélisation statique du système, il s'agit à ce niveau de présenter son comportement
dans le temps (l'évolution d'états dans le temps) à travers le modèle dynamique.
Ce dernier va identifier les différents événements venant du monde externe et montrer
l’enchaînement dans le système que provoquent ces événements externes.
3.2.2.1 But du modèle dynamique
Le but du modèle dynamique est de :

 Trouver les relations temporelles et événementielles entre les objets.
 Définir les états des objets qui déterminent une réaction différente face à un événement.
 Trouver les actions effectuées par les objets suite à la réception d’ événements
On peut imiter le fonctionnement de notre application en se basant sur le diagramme de séquence
et le diagramme d'état du langage UML.
3.2.2.2 Diagramme de séquence
Un diagramme de séquence décrit la séquence temporelle des échanges de messages entre les
objets et l’acteur pour réaliser une certaine tâche. Il montre quels sont les objets qui participent à
l’exécution d’un cas d’utilisation et quels sont les messages qu’ils échangent d’un point de vue
temporel.
La particularité de ses diagrammes, est qu'elles privilégient la représentation temporelle à la
représentation spatiale et sont plus aptes à modéliser les aspects dynamiques du système.
39
a) Diagramme de séquence de cas d'utilisation «crée campagne»

créer campagne
:i nterface campagne :campagne
utilisateur
choisir le type de campagne
chargé le formulai re
formul aire d'ajout campagne
opt [champs i ncorrect]

saisir les données de compagne
vérification des champs

Message(champs i nval ide)
créer campagne()
enregistrement des données

campagne crée
Message(campagne crée avec succés)
Figure 3.3 :Diagramme de séquence de cas d'utilisation «créer campagne»
 Scénario
L’acteur accède à l’application pour créer une nouvelle campagne il choisir le type puis
l’interface rendre un formulaire de création, l’acteur donner les cordonnes et enregistre, si les
champs est vide l’interface affiche un message d’erreur, sinon il affiche un message de succès.
b) Diagramme de séquence de cas d'utilisation «Consulter campagne» :

Consul ter Proj et
Proj et campagne T âche
uti li sateur
demande de li ste des proj ets
chargement des données

affi cher l i ste des proj ets
sel ecti onner un proj et
l iste des campagnes
li ste des tâches
affi cher l e projet+les campagne+l es

tâches
Figure 3.4 :Diagramme de séquence de cas d'utilisation «Consulter campagne»
40
 Scénario
Lorsque l’utilisateur accéder à l’application il peut consulter les projets, il choisit le projet
concerné, le système lui affiche la liste des campagnes et la liste des tâches associées à ce projet
avec ses état.
c) Diagramme de séquence de cas d'utilisation «créer utilisateur» :
créer utilisateur
:Interface Ajout Un Compte :Technicien :Chef de projet :Client
Administrateur
opt [Champs incorrect]

Remplir Les Champs

Message D'erreur
[type=Technicien] crée utilisateur()
alt utilisateur non existant compte Technien crée
[type=Chef de projet] crée utilisateur()
compte Chef crée
[type=Client] crée utilisateur()
compte Client crée

Message "ajout avec succés"
utilisateur existant Enregistrement non valide
Enregistrement non valide
Enregistrement non valide
utilisateur existant
Figure 3.5 :Diagramme de séquence de cas d'utilisation «créer utilisateur»
41
 Scénario
L’Administrateur accède à l’interface d’ajout d’un utilisateur, il va remplir le formulaire d’ajout

d’un utilisateur, le système vérifie si les champs sont corrects, ensuite il affiche un message de
confirmation d’ajout ou un message d’erreur si l’utilisateur est existant.
d) Diagramme de séquence de cas d'utilisation «avancer campagne»

avancer cam pagne
:cam pagne
uti l i sateur
affi cher cam pag ne
éta t actuel de cam pagne affi ché
avancer cam pa gne()
cha nger etat()

cam pagne ava ncé
Figure 3.6 :Diagramme de séquence de cas d'utilisation «avancer campagne»
 Scénario
L’acteur (administrateur, chef de projet, technicien) accède pour changer l'état d'une campagne,
il demande d’avancer l’état de campagne, est ce dernier objet retourne l’état actuel. L’acteur
modifier cet état est valide puis le système enregistrer la modification est affiche le nouvel état.
e) Diagramme de séquence de cas d'utilisation «envoi message»
42
Figure 3.7 :Diagramme de séquence de cas d'utilisation «envoi message»
 Scénario
L'acteur émetteur saisit un message depuis un formulaire en indiquant l'adresse de destinataire.

Le message va être alors envoyé à la destination. Ce dernier peut alors le consulter.
3.3 Diagramme d’état

Les diagrammes d'états-transitions permettent de décrire les changements d'états d'un objet ou
d'un composant, en réponse aux interactions avec d'autres objets/composants ou avec des acteurs.
Un état se caractérise par sa durée et sa stabilité, il représente une conjonction instantanée des
valeurs des attributs d'un objet. Une transition représente le passage instantané d'un état vers un
autre. Une transition est déclenchée par un événement. En d'autres termes : c'est l'arrivée d'un
événement qui conditionne la transition. Les transitions peuvent aussi être automatiques,
lorsqu'on ne spécifie pas l'événement qui la déclenche [6].
3.3.1 Diagramme d’état «Avancer Campagne»
[nouvelle campagne] campagne ouverte [configuration] campagne configurée [test client Ok /valider campagne()] campagne validée
[test client Non] [lancement]
campagne cloturée campagne activée

[suivi campagne]
Figure 3.8 :Diagramme d’état-transition de l’objet «Campagne»
 Description
Lors de la création d’un nouveau projet ayant des campagnes, un projet campagne est crée. Cette
campagne va être configurée par l’utilisateur qui est changé d’elle une fois configurée, un test est
envoyer au client du projet. Ce dernier peut confirmer ou refuser cette configuration. Dans le cas
ou le client valide la configuration de la campagne le technicien lancer campagne qui devient
alors activée. En fonction de son état de progression. Le technicien peut avancer la campagne
jusqu'à la fin qui devient alors une campagne clôturée.
43
3.4 Conception de la base des données
3.4.1 Modèle Relationnel
Cette étape consiste à implémenter le modèle dans le SGBD, c’est-à-dire traduire dans un
langage de définition de données. Dans notre projet, nous avons respecté les règles suivantes
pour faire le passage du diagramme de classe vers le modèle relationnel.
Technique de passage :
 Une classe représentée par une table dont les colonnes sont les attributs de cette classe.
 Une association « un ou plusieurs » impliquait l’intégration de la clé de la table relative à
la classe portant la cardinalité « un » et de même à la classe portant la cardinalité «
plusieurs ».
 Une association « plusieurs à plusieurs » impliquait la création d’une nouvelle table ayant
comme clé la concaténation des deux tables relatives aux classes associées.
Ainsi, nous pouvons présenté les different tables formant notre base des données comme suite :
 Utilisateur (user, pass, Nom_utilisateur, Prenom_utilisateur, e-mail, N_telephone, Login,
type)
 Projet (ref_projet, nom_projet, #administrateur, #chef de projet, #technicien, #client)
 Campagne (ref_campagne, nom_campagne, date_début, date_fin, description, etat, base,
nb_envoi, budget, nb_jours, nb_clics, #technicien #id_utilisateur, # ref_projet)
 tâche (ref_tache, nom_tache, tache, date, etat, # ref_projet, #technicien)
 Message (id_msg, sujet, continue, date_envoi, #user)
 Projet_Utilisateur(#User, Ref_projet, Technicien, Client)
3.5 Architecture client/serveur

3.5.1 Architecture 3-tiers
Dans notre application en utilise l’architecture 3-tiers, et on a séparé la partie applicative ou

traitement de l'IHM et des données. On obtient donc les trois couches suivantes:
 la couche présentation.
 la couche application
 la couche donnée ou métier.
44
La représentation d'une architecture 3-tiers est la suivante :
Figure 3.9 : Architecture 3 tiers ou à 3 niveaux
Chacune de ces trois couches ont un rôle spécifique.

 La couche présentation est chargée du traitement de l'interaction avec l'utilisateur. C'est
un rôle d'affichage et d'interaction.
 La couche application effectue les traitements applicatifs. Elle effectue de plus le tampon
entre la présentation et les données. Elle effectue aussi les règles de gestion de
l'application
 La partie donnée stocke les données pérennes de l'entreprise ou de l’application [7].
3.5.2 Choix de l’architecture
Pour mettre en œuvre la solution retenue pour notre application, nous avons choisi l’architecture
la plus répondu dans le domaine web qui est l’architecture 3-tiers.
Ce choix est basé sur les apports et les avantages de telle architecture qui sont principalement :
1. Les requêtes clients vers le serveur sont d'une plus grande flexibilité que dans celles de
l'architecture 2-tiers basées sur le langage SQL.
2. Cette flexibilité permet à une entreprise d'envisager dans le cadre d'une architecture 3-
tiers une grande souplesse pour l'introduction de toutes nouvelles technologies.
3. D'un point de vue développement, la séparation qui existe entre le client, le serveur et
le SGBD permet une spécialisation des développeurs sur chaque tiers de l'architecture.
4. Plus de flexibilité dans l'allocation des ressources; la portabilité du tiers serveur permet
d'envisager une allocation et ou modification dynamique aux grés des besoins évolutifs
au sein d'une entreprise.
45
3.6 Conclusion
Dans ce chapitre conception, nous avons présenté la vue statique et dynamique de l’application à
développer à travers des diagrammes UML. Nous avons, ainsi, réussi à concevoir notre modèle
relationnel qui est constitué des différents tables formant notre base des données.
Cette phase facilite l’environnement la mise en place de notre application. Le chapitre suivant
met l’accent sur la phase de réalisation qui est le fruit direct de la phase de modélisation.
46
Chapitre 4 :
Réalisation
Chapitre 4 : Réalisation
4.1 Introduction
La phase de réalisation met en valeur les interfaces graphiques de l’application. Donc, nous
allons commencer tout d’abord par l’identification des choix techniques de développement. Puis,
nous allons présenter les différentes phases d’implémentation et de validation en exposant les
captures d’écrans afin de décrire le travail réalisé avec quelques explications.
4.2 Environnement de développement

Dans cette section, nous présentons les environnements matériels et logiciels utilisés dans le
cadre de notre projet.
4.2.1 Environnement matériel
Pendant les différentes phases de notre projet à savoir la documentation, la spécification des
besoins, la conception et le développement, nous disposant d’une machine ayant les
caractéristiques suivant :
 Marque : Acer
 Modèle : ASPIRE 5742G
 Processeur : Intel I3 Core (TM) CPU 2 M380 @2.53GHz
 Disque dur: 500G
 RAM: 4G
 Système d’exploitation : Windows 7 Professionnel 64bit
4.2.2 Environnement logiciel
Les principaux outils qui sont contribué à la qualité du développement sont :
Dreamweaver (CS3)
Adobe Dreamweaver (anciennement Macromedia Dreamweaver) est un éditeur de site web de

type « tel écrit tel écran
Dreamweaver fut l'un des premiers éditeurs HTML de type tel écrit tel écran, mais également
l'un des premiers à intégrer un gestionnaire de site (CyberStudio GO Live étant le premier). Ces
48
innovations le propulsèrent rapidement comme l'un des principaux éditeurs de site web, aussi
bien utilisable par le néophyte que par le professionnel [8].
WampServer (Serveur de gestion des bases des données)
WampServer (anciennement WAMP5) est une plateforme de développement Web de

type WAMP, permettant de faire fonctionner localement (sans se connecter à un serveur externe)
des scripts PHP. WampServer n'est pas en soi un logiciel, mais un environnement comprenant
deux serveurs (Apache et MySQL), un interpréteur de script (PHP), ainsi que phpMyAdmin pour
l'administration Web des bases MySQL [8].
Zend Framework
Le Zend Framework est un Framework pour PHP 5. Il est distribué sous la Licence BSD

Modifiée. Le Zend Framework, aussi nommé ZF, a été développé dans le but de simplifier le
développement Web tout en recommandant les bonnes pratiques et la conception orientée
objets en offrant des outils aux développeurs. ZF permet aussi d'utiliser nativement le principe de
MVC (Modèle-Vue-Contrôleur) mais ne l'oblige pas [8].
Microsoft Office Word
Microsoft Office Word est un logiciel de traitement de texte. Il est considéré comme le
programme central de Microsoft Office. Il domine le marché des logiciels de traitement de texte.
Son format par défaut est le format " .doc "
Dans les versions plus récentes, comme Word 2003, il supporte aussi des fichiers dans un format
basés sur le XML. Word est aussi disponible dans certaines versions de Microsoft Works Suite.
Il est disponible sur Windows et Macintosh [9].
PowerAMC
PowerAMC est un logiciel de modélisation (modeleur) de Sybase. En 2006, il inclut les

modélisations de bases de données (MPD, MCD), UML, modélisation de traitements
Merise (MCC, MOT, MCT) modélisation de processus métier [8].
49
4.3 Patron de conception

4.3.1 Modèle MVC
A fin de développer notre application, nous avons recours à l’architecture Modèle/ Vue/
Contrôleur (MVC).
En effet « MVC » est une architecture et une méthode de conception pour le développement
d'applications logicielles qui sépare le modèle de données, l'interface utilisateur et la logique de
contrôle.
Ce modèle d'architecture impose la séparation entre les données, les traitements et la
présentation, ce qui donne trois parties fondamentales dans l'application finale : le modèle, la vue
et le contrôleur [10].
 Rôle du Modèle
Le Modèle représente le comportement de l'application : traitements des données,

interactions avec la base de données, etc. Il décrit les données manipulées par
l'application et définit les méthodes d'accès.
 Rôle de la Vue
La Vue correspond à l'interface avec laquelle l'utilisateur interagit. Les résultats

renvoyés par le modèle sont dénués de toute présentation mais sont présentés par les
vues. Plusieurs vues peuvent afficher les informations d'un même modèle. Elle peut
être conçue en html, ou tout autre "langage" de présentation. La vue n'effectue
aucun traitement, elle se contente d'afficher les résultats des traitements effectués
par le modèle, et de permettre à l'utilisateur d'interagir avec elles.
 Rôle du Contrôleur
Le Contrôleur prend en charge la gestion des évènements de synchronisation pour

mettre à jour la vue ou le modèle. Il n'effectue aucun traitement, ne modifie
aucune donnée, il analyse la requête du client et se contente d'appeler le modèle
adéquat et de renvoyer la vue correspondante à la demande.
50
Figure 4.1 : Le pattern MVC
4.4 Choix du langage de programmation
HTML5
HTML5 (HyperText Markup Language 5) est la prochaine révision majeure d'HTML (format de
données conçu pour représenter les pages web).Cette version est en développement en 2012.
HTML5 spécifie deux syntaxes d'un modèle abstrait défini en termes de DOM : HTML5et
XHTML5. Le langage comprend également une couche application avec de nombreuses API,
ainsi qu'un algorithme afin de pouvoir traiter les documents à la syntaxe non conforme [8].
CSS 3
Le CSS3 est tout simplement un langage (Cascading Style Sheets). Pas comme le patois, mais un
langage codé qui est utilisé pour définir l’aspect d’un site ou d’un blog. Il gère par exemple la
couleur du fond de la page, les images, la couleur et le type de police de caractère. Dans chaque
site, ou blog comme ici chez Over-Blog, le css3 est un petit fichier rempli de texte et de codes
dans lequel se définissent les aspects visuels généraux [11].
JavaScript
JavaScript est un langage de programmation de scripts principalement utilisé dans les pages web
interactives. C'est un langage orienté objets à prototype, c'est-à-dire que les bases du langage et
ses principales interfaces sont fournies par des objets qui ne sont pas des instances de classes,
51
mais qui sont chacun équipés de constructeurs permettant de générer leurs propriétés, et
notamment une propriété de prototypage qui permet d'en générer des objets héritiers
personnalisés [8].
PHP 5
PHP est un langage de programmation informatique essentiellement utilisé pour produire à la

volée des pages web dynamiques. Dans sa version 5 lancée en juillet 2004, PHP s’est imposé
comme le langage de référence sur le web en raison de sa simplicité, de sa gratuité et de son
origine de logiciel libre.
Les compétences en développement PHP, développeurs PHP et ingénieurs de développement
PHP, sont très recherchées par les entreprises qui l’utilisent de plus en plus dans le cadre de
création de pages web dynamiques ainsi que dans le cadre de langage interprété de façon locale
[12].
JQuery
JQuery est une bibliothèque JavaScript libre (on parle également de Framework JavaScript libre)
développée initialement par John Régis et qui est aujourd'hui maintenue et mise à jour par la
communauté jQuery Team. Le Framework JavaScript jQuery codé rapidement et simplement des
traitements à base de code JavaScript pour dynamiser et améliorer l'ergonomie sites internet [13].
4.5 Système de gestion de la base de données relationnel
MYSQL
MySQL est un système de gestion de base de données. Selon le type d'application, sa licence est
libre ou propriétaire. Il fait partie des logiciels de gestion de base de données les plus utilisés au
monde, autant par le grand public (applications Web principalement) que par des professionnels,
au même titre que Oracle ou Microsoft SQL Server. [8]
52
PHPMyAdmin
PhpMyAdmin (PMA) est une application Web de gestion pour les systèmes de gestion de base
de données MySQL réalisée en PHP. Il s'agit de l'une des plus célèbres interfaces pour gérer une
base de données MySQL sur un serveur PHP. De nombreux hébergeurs, qu'ils soient gratuits ou
payants, le proposent ce qui permet à l'utilisateur de ne pas avoir à l'installer [8].
4.6 Enchainement des programmes

4.6.1 Organigramme la partie de l’Administrateur
La figure ci-dessous illustre le menu principal de l’administrateur :
Figure 4.2 : Menu principale de la partie administrateur

a
e
h
o
Ié
S
F
b
lG
53
tt
N
m
T
u
p
ti
ê
fi
d
iA
W
C
2
D
c
n
t
E
v
y
M
r
s
g
f
k
jq
â
B
O
4.6.2 Organigramme de la partie de Chef de projet
La figure ci-dessous illustre le menu principal de Chef de projet :
Figure 4.3 : Menu principale de la partie Chef de projet
4.6.3 Organigramme de la partie de Technicien
Le menu principal du technicien peut être présenté par la figure ci-dessous :
Figure 4.4 : Menu principale de la partie Technicien

y
é
D
O
2
B
E
W
ê
A
h
â
T
tt
q
lM
G
k
b
iF
s
S
C
g
m
jt
r
p
v
u
N
o
a
c
fi
ti
n
e
Id
54
4.6.4 Organigramme de la partie de Client
Nous pouvons représenter le menu principal du client par la figure suivante :
Figure 4.5 : Organigramme de la partie Client
4.7 Présentation des interfaces utilisateurs

4.7.1 Interface d’identification
Tout d’abord, l’interface de démarrage est celle de l’authentification :
Figure 4.6 : Aperçu de l’interface d’identification

d
a
n
h
t
i
o
é
I
ti
p
m
g
T
u
s
E
W
C
2
D
M
c
e
fi
j
â
r
B
O
L’authentification est une étape primordiale par la quelle chaque utilisateur de notre système doit
y passer pour accéder à l’application. Cette phase assure, en effet, la sécurité de l’application en
demandant l’accès à l’application, l’utilisateur se voit dans l’obligation de s’authentifier à travers
son compte. Il saisit alors, ses paramètres de connexion et valide par la clique sur le
bouton « connexion ». Le système vérifie l’existence de ce compte dans sa base des données.
Si l’utilisateur est identifié dans la base, il accède à l’application selon son mode d’accès fixé par
l’administrateur. Une fois les données sont valides, la page d’accueil de l’utilisateur est chargée.
55
4.7.2 Interface de création d’ un nouvel utilisateur
Cette figure présente l’interface de la création d’un nouvel utilisateur :
Figure 4.7 : Aperçu de l’interface « Créer un nouvel utilisateur »
L’administrateur c’est la seul personne qui peut gérer les comptes des utilisateurs, alors il
accéder pour créer un nouvel utilisateur. Il attribut un login et un mot de passe et remplis les
champs des cordonnées nécessaires lié à cet utilisateur et choisi le type d’accès à l’application
(Chef de projet, Technicien ou Client) puis il clique sur le bouton « enregistrer ».
4.7.3 Interface de création d’ un projet
Cette figure illustre l’interface de création d’un projet :
Figure4.8 : Aperçu de l’interface « Créer projet»
Cette figure représente la phase de création des projets, pour notre application c’est une étape
très importante et simple, car l’utilisateur ne peut pas créer une campagne ou une liste des tâches
avant de créer un nouveau projet. Alors le chef de projet ou l’administrateur accède à la page
« Nouveau Projet » et saisit le nom de projet puis donne un nom de client et enfin cliquer sur le
bouton « créer un nouveau projet » pour valider et enregistrer ce projet.
56
 Message de validation
Le 1er message « enregistrement avec succès » est un message de validation lorsque l’utilisateur
saisit le nom de projet et le nom de client correctement.
 Message d’erreur
Le 2eme message « saisir le nom de projet » c’est un message d’erreur s’affiche lorsque
l’utilisateur a donné des cordonnes non valide ou laissé les champs vide.
4.7.4 Interface de création d’une campagne
La figure ci-dessous présente l’interface de création d’une compagne :
Figure 4.9 : Aperçu de l’interface « Créer campagne »
Cette figure représente l’interface « Créer campagne ». L’utilisateur peut accéder à cette page
pour créer une nouvelle campagne. En premier lieu, il choisit le type de campagne à créer, puis il
remplit les champs vides et choisit un technicien et un projet et il peut aussi écrire des
commentaires dans le champ de description puis il clique sur le bouton « enregistrer » pour créer
cette nouvelle campagne.
57
 Message d’erreur
Figure 4.10 : Aperçu de l’interface « Message d’erreur »
Si l’utilisateur n’a pas rempli tout les champs et cliqué sur le bouton « Enregistrer », un message
d’erreur « Veuillez renseigner ce champ » s’affiche automatiquement à l’utilisateur.
4.7.6 Consulter les projets
La figure ci-dessous illustre l’interface des projets en cours :
Figure 4.11 : Aperçu de l’interface « Consulter les projets »
Cette interface est la plus importante dans notre application. Elle présente la liste des projets en
cours. Tout fois l’utilisateur choisi un projet exacte, le système s’affiche la liste des campagnes
et la liste des tâches existe sous ce projet avec les états qu’ils se présentent sous la forme de barre
de progression.
58
 Si l’utilisateur peut modifier la campagne, il clique sur le bouton modifier pour ouvrir
une autre page de modification.
 Si l’utilisateur peut avancer l’état de la campagne, il doit cliquer sur le bouton vert et
amélioré l’état de la campagne en cours.
4.7.7 Interface de « Avancer Tâche »
Cette figure présente l’interface d’avancement les tâches d’un projet :
Figure 4.12 : Aperçu de l’interface «Avancer Tâche»
Tant que le technicien termine une tâche de la liste, il doit accéder à cette interface « projets en
cours » puis il choisi un projet précis et clique sur le bouton, alors le système va afficher une
fenêtre portant les tâches de la liste avec des boutons radio, le technicien va cliquer sur la tâche
terminer et le système va récupérer la modification d’état et avancer la barre de progression
automatiquement.
4.8 Conclusion
Ce chapitre présente la dernière étape pour mettre en réalité toute la théorie précédente. Son
objectif est de décrire notre application. C’est pourquoi nous avons mis l’accent sur les étapes de
réalisation du projet par l’explication de contenu de quelques pages.
59
Conclusion et Perspectives
Conclusion et Perspectives
Ma mission a consisté en la conception et la réalisation d’une application de gestion des projets.
L’application réalisée sera utilisée par les employés concernés de WEB 2 COM et ces clients,
elle leur donnera la possibilité de gérer les interventions d’une façon plus pratique et plus facile
que la gestion actuelle.
Tout au long de ce projet, nous avons acquis un ensemble de compétence sur divers plans.
Sur le plan pratique, ce projet nous a donné la possibilité d’approfondir, nos connaissances en
Programmation PHP, HML… nous a offert la possibilité de mieux maitriser le langage de
modélisation UML. Cette méthode de conception offre d’excellents moyens de représentation les
cas d’utilisation, les classes, les relations entre les différentes classe et les collaborations entre les
objets.
La réalisation de ce projet a suivi plusieurs étapes. J’ai commencé par une étude préalable pour
bien présenté l’environnement du projet. Ensuite dans le deuxième chapitre on a analysé et
spécifié les besoins. Lors de la phase de la conception, j’ai présenté les différents
diagrammes UML pour mieux comprendre la communication entre les différents objets du
projet. Enfin, la phase réalisation, j’ai mis en œuvre notre solution.
Notre stage fut l’occasion de s’initier à de nouvelles technologies tout en découvrant

l’environnement de WEB 2 COM. Enfin, cette expérience a aiguisé mess capacités d’analyse et
de synthèse et a surtout fortifié ma motivation, ma détermination et mon ambition.
60
Webliographie
Webliographie
[1] http://www.umc.edu.dz/vf/coursLigne/MSI/Modele_developpement_logiciel.html
[2] http://tecfa.unige.ch/staf/staf-i/gorga/staf2x/classPHP/introobjet.php
[3] http://www.math-info.univ-paris5.fr
[4] http://omangez.free.fr
[5] http://merise.developpez.com
[6] http://uml.free.fr
[7] http://www-igm.univ-mlv.fr
[8] http://fr.wikipedia.org
[9] http://www.techno-science.net/?onglet=glossaire&definition=526
[10] http://awerpi.olympe.in/maiscestquoilecss-chapitre2/
[11] http://www.html5-css3.fr/css3/introduction-css3
[12] http://books.google.tn/books/about/PHP_5_avancé.html
[13] http://www.yoja-web.com/fr/javascript/jquery-presentation
61

Rapport PFE

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

Rapport PFE

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Conception et développement d’une application web de gestion des

LIEU DU STAGE : WEB 2 COM

ELABORE PAR : SOUS LA DIRECTION DE :

NOBEL EL HOUSSINE BOUBAKER

Année Universitaire 2012/2013

Veuillez tous agréer mes vifs sentiments de respect.

1.3 Etude de l’existant.........................................................................................................................5

1.4 Présentation de projet....................................................................................................................6

1.5 Planification de stage.....................................................................................................................7

2.3 Analyse des besoins.....................................................................................................................11

2.4 Modélisation des besoins fonctionnels........................................................................................14

2.3 Diagramme de séquence..............................................................................................................22

2.4 Diagramme D’activité.................................................................................................................24

3.2 Conception détaillée....................................................................................................................28

3.3 Diagramme d’état........................................................................................................................38

3.4 Conception de la base des données..............................................................................................39

3.5 Architecture client/serveur..........................................................................................................39

4.3 Patron de conception...................................................................................................................45

4.4 Choix du langage de programmation...........................................................................................46

4.7 Présentation des interfaces utilisateurs........................................................................................50

Liste Des Figures

Liste Des Tableaux

Le premier chapitre intitulé «étude de projet » est dédié à la présentation de cadre général de

Ensuite, et dans la troisième chapitre « Conception », nous présentons une modélisation

CHapitre 1 : Etude Préalable

1.2 Présentation de l’organisme d'accueil

Le personnel du « web 2 com » est organisé en équipes.

 Huit consultants dont un expert en commerce électronique et en NTIC et deux en

1.2.2 Adresse de l’entreprise

4ème étage - Immeuble BOUHAJEB. Boulevard

Téléphone (+216)73 82 09 62 – (+216)73 82 16 54

Site web www.web-2-com.com

Tableau 1.1 : Adresse de l’entreprise

1.2.3 Services offerts

 Community Management / Recrutement des Fan

Organigramme de l’organisme d’accueil « WEB-2-COM »

Figure 1.1 : Organigramme de l’organisme d’accueil « WEB-2-COM »

L’organisme de « WEB-2-COM » se compose de quatre principaux départements :

1.3 Etude de l’existant

1.3.1 Description de l’existant

1.3.2 Critique de l’existant

Les faiblesses de la situation présentée se résument dans les points suivants :

 Le suivi s’effectue manuellement sur les papiers.

1.3.3 Solutions proposées

1.4 Présentation de projet

Dans le cadre de notre préparation au diplôme de Licence Appliqué en Informatique de gestion,

1.4.2 Objectifs de l’application

Les principaux objectifs de l’application à développer sont essentiellement :

 Répondre exactement aux besoins de l’entreprise.

1.5 Planification de stage

Mois Janvier Février Mars Avril Mai

Tableau 1.2 : Planning prévisionnel

Chapitre 2 : Spécification et analyse des besoins

2.2 Méthodologie de conception

2.2.1 Choix de processus de devloppement

Figure 2.1 : Modèle en cascade

2.2.2 Choix de l’approche objet

2.2.3 Choix du langage de modélisation

UML (Unified Modeling Language) est un langage formel et normalisé en termes de

 UML est une notation pas une méthode.

2.3 Analyse des besoins

2.3.1 Identification des principaux acteurs

 Administrateur : C’est le responsable de l’application qui a tous les droits