Rapport PFE Karim ZIKY

2013
Projet de fin d’étude

Pour l’Obtention du Titre
Ingénieur d’État en Informatique

Option
Génie Logiciel
Sujet
Développement d’une plate-forme pour la

vente des espaces d’hébergement et des
noms de domaine.
Soutenu par : Karim ZIKY
Sous la direction de :
Mr. Youssef BALOUKI

Mr Abdelaziz AZIF
Année Universitaire 2012-2013

Dédicace
A ma chère mère que j’adore, à mon cher père que j’aime

Un Grand merci…sans vous je ne serais pas entrains d’écrire ces
mots.
A mes frères et sœurs.
Je vous remercie infiniment pour votre soutient, votre présence
pour me soutenir dans des moments déficèles.
A tous les membres de ma famille.
A tous mes amis
A tous ceux que j’aime
A tous ceux qui m’aiment
Je dédie ce travail…
Projet fin d’étude 2012/2013 1

Remerciements
Au terme de ce travail, je tiens à exprimer ma profonde gratitude et mes sincères remerciements à

Mr. Abdelaziz AZIF qui m’a donné la permission de passer ce stage au sein de la société Info Pro, qui m’a
assuré les conditions favorables pour réussir ce stage.
Je tiens à remercier également mon encadrant Mr. Youssef BALOUKI pour son encadrement, ses
conseils et directives pertinentes durant toute la période de mon stage.
Mes plus vifs remerciements s’adressent aussi à tout le cadre professoral et administratif de la
formation Cycle d’Ingénieur Génie Logiciel à la FST de Settat, pour leur patience et savoir qui nous a
illuminés durant ces trois années de formation.
En fin, mes remerciements et gratitudes vont aussi à ma famille qui m’a offert la tendresse et le
soutien.

Résumé
Ce document est le fruit de mon travail dans le cadre du projet de fin d’étude effectué
au sien de la société Info Pro, ayant comme sujet la réalisation d’une application web (back
front office) pour la vente des espaces d’hébergement et des noms de domaine. Le front office
est sous forme d’un portail web dont les rôles est de présenter les produits et les services de la
société sur le marché web (e-commerce), aussi il donne aux clients (fidèles ou les nouveaux
prospects) la possibilité de valider leurs commandes en ligne. Le back office permet à la
société de gérer ses services et produits (pack d’hébergement web et noms des domaines),
ainsi que la gestion des commandes des clients.
Pour élaborer le projet, dans un premier lieu, j’ai commencé par une recherche globale
sur le fonctionnement et les procédures de vente des espaces d’hébergement et les noms du
domaine dont j’ai tiré les exigences fonctionnel qui sont validés par le directeur de la société.
Dans un deuxième lieu j’ai effectué une conception détaillée par la modélisation en UML 2.
En fin, j’ai adopté les technologies (Zend : Framework du PHP5, jqWidget : Framework
jQuery & ajax, HTML5, CSS3, wampserver : serveur d’applicetion Apache et SGBD MySql)
dans la phase de développement.
Mots clés : Zend Framework, jqWidget, Info Pro, Hébergement, Nom de Domaine,
Back office, Front office, e-commerce.

Abstract
This document is the fruit of my work of end of study project done within the Info Pro
Corporation, having as subject the realization of a web application (back office and front
office) of areas hosting and domain names for sale. Front-office is in the form of a web portal
which roles is to present the products and services of the company on the web market (e-
commerce) , also it gives to clients (faithful or new leads) to place orders online. The back
office allows the company to manage its services and products (web hosting and domain
names), as well as the management of customer orders.
To develop the project, in a first place, I started by a global search on the functioning
and procedures for sale of accommodation spaces and the domain names. Through this search,
I drew the functional requirements that are validated by the work meter. In a second, I did a
detailed modelling in UML 2 design. In the end, I have adopted the technologies (Zend:
Framework of PHP5, jqWidget: Framework jQuery & ajax, HTML5, CSS3,
wampserver: applicetion Apache and DBMS MySql server) in the development phase.
Keywords: Zend Framework, jqWidget, Info Pro, Hosting, Domain Name, e-commerce,
Back office, Front office.

Liste des abréviations
Abréviation Désignation
FSTS Faculté des Sciences et Techniques de Settat
PHP Hypertext Preprocessor
UML Unified Modeling Language
CRUD Create, Read, Update, Delete
SGBDR Système de Gestion de Base de Données relationnel
URL Uniform Resource Locator
IHM Interface homme machine
XML Extensible Markup Language
HTTP HyperText Transfer Protocol
JSON JavaScript Object Notation
AJAX Asynchronous JavaScript and XML
TIC Technologies de l’Information et de la communication
MVC Model View Controller
IDE Integrated Development Environment
ND Nom de Domaine
UP Unified Process
XP eXtreme Programming
CGV Conditions Générales de Vente
RT Responsable Technique = manager
Sté Société
DOM Document Object Model
RIA Rich Internet Application

ORM Object-relational Mapping
POO Programmation Orientée Objet
RS Raison Social
XSS Cross-site Scripting

Table de figures
Figure 1 : L’organigramme de Info Pro………………………………………………..……..13
Figure 2 : la valeur ajoutée du projet…………………………………………………..……..15
Figure 3 : Planning du projet………………………………………………………...………..16
Figure 4 : Diagramme d’acteurs……………………………………...………….....................20
Figure 5 : Diagramme de contexte statique……………………………….………………….21
Figure 6 : Diagramme de cas d’utilisation…………..………………………………………. 23
Figure 7 : Diagramme de séquence boite noire du use case
« Règlement des nouvelles commandes »……………………………..…………………….. 30
Figure 8 : Diagramme de séquence boite noire du use case « Paiement annuel »……………30
Figure 9 : Diagramme de séquence boite noire du use case « authentification/inscription

client»…………………………………………………………………………………………31
Figure 10 : Diagramme de séquence boite noire du use case « Commander packs

d’hébergement»+ « valider les commandes»………………………………………………... 32
Figure 11 : Diagramme d’activité système du use case « Commander pack

d’hébergement»+ « exécuter et valider la commande»……………………………...……… 33
Figure 12 : Diagramme de transaction vue globale pour le back office…………………….. 34
Figure 13 : Diagramme de transaction vue globale pour le front office…………………….. 34
Figure 14 : Diagramme de classe………………………………………………………….… 35
Figure 15 : diagramme boite blanche du cas d’utilisation « commander packs
d’hébergement »………………………….............................................……………………..37
Figure 16 : Diagramme de classe de conception…………………………………………...…38
Figure 17 : architecture en couche selon le modèle MVC……………………………………41
Figure 18 : scénario d’une attaque de type XSS (réf : « Zend Framework bien développer en
PHP »figure 11-1, p 205)……………………………………………………………………..52
Figure 19 : interface d’authentification des utilisateurs de back office………………………54
Figure 20 : Interface d’accueil de l’administrateur…………………………….......…………55
Figure 21 : Interface permettant la gestion des utilisateurs………………………...…………55
Figure 22 : Fenêtres ajouter/modifier utilisateur…………………………...…………………56

Figure 23 : Page pour la gestion des clients et leurs factures…………………...…………….56
Figure 24 : sélection multicritère des clients………………………………………………....57
Figure 25 : sélection des facture selon « numéro facture »…………………………………...57
Figure 26 : interface de gestion des produits…………………………………………………58
Figure 27 : Interface de gestion des nouvelles commandes…………………………………..58
Figure 28 : Interface des règlements annuels…………………………………………………59
Figure 29 : histogramme d’évolution de chiffre d’affaire d’Info Pro………………………...60
Figure 30 : Nombre des commandes par domaine……………………………………………60
Figure 31 : nombre des commandes par packs d’hébergement………………………………61
Figure 32 : Page d’accueil du portail web…………………………………………………….61
Figure 33 : page des packs d’hébergement…………………………………………………...62
Figure 34 : Page des domaines………………………………………………………………..62
Figure 35 : formulaire d’authentification et d’inscription du client…………………………..63
Figure 36 : formulaire de récupération d’un nouveau mot de passe………………………….64
Figure 37 : formulaire de changement de mot de passe………………………………………64
Figure 38 : Formulaire de détail panier……………………………………………………….65
Figure 39 : Formulaire de la validation du panier…………………………………………….65

Liste des tableaux
Tableau 1 : Exigences de front office…………………………………………………….......19
Tableau 2 : Exigences de back office…………………………………………………………19
Tableau 3 : Intentions des acteurs de front office…………………………………………….22
Tableau 4 : Intentions des acteurs de back office…………………………………………….22
Tableau 5 : Description textuel du haut niveau du use case «Commander/Transférer
des noms de domaine(ND) »………………………………………………………………….24
Tableau 6 : Description textuel du haut niveau du use case «Commander des packs
d’hébergement »………………………………………………………………………………24
Tableau 7 : Description textuel du haut niveau du use case «Valider la Commande »………25
Tableau 8 : Description textuel du haut niveau du use case «Gérer le paiement annuel»……25
Tableau 9 : description textuelle bas niveau d’use case
« Commander des noms de domaine (ND) »…………………………………………………26
Tableau 10 : description textuelle bas niveau d’use case « Commander des packs
d’hébergement»………………………………………………………………………………27
Tableau 11 : description textuelle bas niveau d’use case « Règlement annuel»……………..27
Tableau 12 : scénario nominal du cas d’utilisation « commander nom de domaine »
+ « valider la commande»…………………………………………………………………….27
Tableau 13 : Scenario nominal « commander packs d’hébergement»+ « valider les

commandes»…………………………………………………………………………………..28
Tableau 14 : Arborescence des fichiers de l’application front office………...………………48
Tableau 15 : Code source de quelques classes modèles……………………………………...50

Table des matières
Introduction générale............................................................................................................... 11
1. Contexte général du projet .................................................................................................. 13
1.1. Présentation de l’organisme d’accueil : InfoPro ....................................................... 13
1.1.1. Info Pro : ............................................................................................................. 13
1.1.2. Organigramme de la Sté:.................................................................................... 13
1.1.3. Activités proposées : .......................................................................................... 13
1.2. Présentation du projet............................................................................................... 14
1.2.1. Contexte général ................................................................................................ 14
1.2.2. Objectifs du projet.............................................................................................. 15
1.3. Conduite du projet..................................................................................................... 16
1.3.1. Méthode de génie logiciel adopté : UP-XP ........................................................ 16
1.3.2. Planification du projet ........................................................................................ 16
2. Conception et modélisation en UML ................................................................................ 19
2.1. Phase d’inception : Recensement et définition des besoins ..................................... 19
2.1.1. Les exigences : .................................................................................................... 19
2.1.2. Les acteurs : ........................................................................................................ 19
2.1.3. Diagramme de contexte statique : ..................................................................... 20
2.1.4. Intention d’acteur : ............................................................................................ 21
2.1.5. Diagramme des cas d’utilisation : ...................................................................... 22
2.1.6. Description textuelle de haut niveau ................................................................. 24
2.2. Phase d’analyse ......................................................................................................... 25
2.2.1. Description textuelle de bas niveau ................................................................... 26
2.2.2. Description complète du use case, avec ses différents scénarios : ................... 27
2.2.3. Diagramme de séquence boîte noire : ............................................................... 30
2.2.4. Diagramme d’activité système : ......................................................................... 33
2.2.5. Diagramme d’interaction vue global : ................................................................ 33
2.2.6. Diagramme de class d’analyse : ......................................................................... 35
2.2.7. Contrats d’opération de LARMAN ...................................................................... 36
2.2.8. Diagramme de séquence boite blanche............................................................. 36
2.3. Phase de conception : diagramme de classe de conception..................................... 38
3. Plateforme de développement et implémentation.......................................................... 41
3.1. L’architecture de l’application ................................................................................... 41

3.2. Choix technologique .................................................................................................. 42
3.2.1. Le langage PHP5 ................................................................................................. 42
3.2.2. Utilisation d'un Framework ................................................................................ 43
3.2.3. Bibliothèque jqWidgets ...................................................................................... 46
3.3. Implémentation & codage ......................................................................................... 46
3.3.1. La structure des fichiers selon le modèle MVC .................................................. 46
3.3.2. Implémentation des classes modèles ................................................................ 48
3.4. Aspect sécurité .......................................................................................................... 50
3.4.1. En quoi consiste la sécurité sur le Web ? ........................................................... 50
3.4.2. Solutions de sécurité de Zend Framework......................................................... 51
3.4.3. Exemples d’attaques courantes ......................................................................... 52
3.5. Captures écran ........................................................................................................... 54
3.5.1. Capture écran back office .................................................................................. 54
3.3.2. Capture écran du portail web : front office ........................................................... 61
Conclusion générale ................................................................................................................. 66
Références ................................................................................................................................ 67
ANNEXES................................................................................................................................... 68

Introduction générale
Au Maroc, les premières offres des services d’hébergement datent du début des années
2000, Info Pro propose ce service à ses client depuis 2004, elle était parmi les entreprises
professionnelles qui ont couvert le marché marocain. Ce qui lui a permet d’avoir une gamme
clientèle très importantes sans investir généreusement en publicité. Récemment, répondant à
l’importante évolution des TICs (Technologies de l’Information et de la Communication)
dans presque tous les secteurs : économique, social et commercial (e-commerce et e-
marketing : ces deux secteurs sont devenus le centre des préoccupations des entreprises).
Ainsi les sociétés compétentes dans le domaine d’hébergement web sont de plus en plus
spécialisées, performantes et concurrentes. Ce qui conduit Info Pro à penser à développer sa
stratégie de vente et de prospection des nouveaux clients : c’est le sujet de mon projet de fin
d’étude cycle d’ingénieur.
Le but du projet est de lancer un portail web permettant aux internautes qui cherchent
un fournisseur des noms de domaine ou un hébergeur pour leurs sites web de trouver
rapidement Info Pro, et d’interagir avec elle par le biais de ce portail, en envoyant des
commandes en toute simplicité, clarté, rapidité et sécurité. Outre son utilité en faveur des
clients, cette application permet aussi par sa partie Back-office au personnel d’Info Pro de
suivre et de gérer les commandes des clients, les packs d’hébergement et les NDs, aussi elle
permet à l’administrateur la gestion utilisateurs et la consultation des tableaux de bord. .
Ce rapport est réparti en 3 séquences, la première s’intéresse à donner une vision

globale sur le sujet à réaliser on présentant l’organisme d’accueil et en explorant les alentours
du sujet, la deuxième décrit les étapes de conception et de formulation de la solution de notre
problématique, quant à la dernière partie de réalisation consiste à présenter la solution conçue
d’une manière plus technique.

Chapitre 1
Contexte générale du projet
Ce premier chapitre introductif va présenter en premier lieu

l’organisme de l’accueil et le besoin qui nous a amené à
réaliser le présent projet et un planning décrivant les
différentes étapes qu’on doit effectuer avant l’arrivée à
l’objectif souhaité.

1. Contexte général du projet
1.1. Présentation de l’organisme d’accueil : InfoPro
Info Pro est une société spécialisé dans le domaine de développement des logiciels,
installation réseaux et hébergement des sites web. Elle propose aussi des formations sur des
applications de gestion (EBP, Siel, Sage…).
1.1.1. Info Pro :
Raison sociale…………….INFO PRO
Forme juridique…………..SARL
Date de création ………….1997
Capital ……………………400.000 DH
1.1.2. Organigramme de la Sté:
Effectif personnel de l’entreprise est sept personnes, repartis sur les services suivants :
Administration, développement, et technique.
Figure 1 : L’organigramme de Info Pro
1.1.3. Activités proposées :

Info Pro dispose d’une grande gamme de Solutions et de Services TIC qui couvrent les
besoins des Clients, recueillent et analysent leurs exigences pour leur développement, leurs

mises en place et leur maintenance ultérieures. Cette expérience a également servi à offrir
des solutions et des services spécifiques à quelconque secteur d’activité :
i. Web :
 Hébergement et nom de domaine.

 Création et intégration de sites web statiques et dynamiques ;
 Mise à jour de contenu ;
 Création de blogs, forums et formulaires en ligne ;
 Référencement web ;
ii. Réseau :
 Installation du réseau (câblage réseau et Telecom) ;

 Configuration et installation du serveur ;
 Formation du personnel ;
 Maintenance technique sur place ;
iii. Logiciels & applications :
 Logiciels de gestion intranet (ex : EBP)

 Conception et réalisation de logiciel personnalisé ;
 Formation, consultation ….
1.2. Présentation du projet

1.2.1. Contexte général
Vue la concurrence que connu le domaine d’hébergement et la vente des noms du

domaine, Info Pro est appelé à professionnaliser et à faciliter l’accès de ses clients à ses
gamme de produits pour garder une place parmi les acteurs de ce domaine. Dans cette
optique, le projet de création de cette plateforme de vente est entamé.
Info Pro a adopté dès sa création en 1997 une politique de marketing classique, la
commercialisation de ses produits et services se fait par le déplacement de ses clients jusqu'à
le siège de la société à Aïn Sebaa à Casablanca, cela handicape ses transactions d’une manière
notable. La prospection des nouveaux clients connait aussi des grandes difficultés vue que
cette opération se fait soit par son réseau de clients (bouche à oreille), les brochures,
dépliants…, alors que ses méthodes sont moins efficaces au terme du nombre d’éventuels
clients qui peuvent être sollicités. Ainsi en adoptant ses techniques classiques, la prospection
des clients se limite dans l’espace des activités de l’entreprise, alors qu’elle peut explorer
d’autre ville.

La réalisation de ce projet pourra combler ses lacunes au niveau de la commercialisation
des produits d’Info Pro, aussi au niveau de la prospection des nouveaux clients.
La nécessité de réaliser une application qui pourra répondre aux besoins de la société soit
au terme de la facilitation des transactions avec les clients (rôle de la partie front office), mais
aussi pour une bonne gestion des commandes des clients auprès de l’administration (rôle de la
partie back office).
1.2.2. Objectifs du projet
Cette plate-forme pour la vente des espaces d’hébergement, donnera à la société Info Pro
un grand élan afin d’améliorer la relation entreprise-client et d’assurer une gestion
professionnelle des commandes. Ainsi ce projet a plusieurs objectifs répartis comme suit :
Commercial :
 Une meilleure vulgarisation de la gamme de produits proposés.
 Un accès rapide et pratique au catalogue des services, et un envoi facile des

commandes par net.
 La publicité, et prospection des clients à une grande échelle.
Administration des commandes :
 Gestion professionnelle des commandes (traitement des nouvelles commandes et

rappel du paiement annuels des commandes).
 Réalisations des statistiques sur les actions de l’entreprise.
 Archivage informatisé de l’historique commercial de l’Info Pro.
La figure suivante schématise les deux volets importants du projet :
Figure 2 : la valeur ajoutée du projet

1.3. Conduite du projet
1.3.1. Méthode de génie logiciel adopté : UP-XP
Le travail dans le cadre d’une démarche (méthode) de génie logiciel est indispensable
pour la réussite des grandes et moyennes projets informatiques et le choix d’un processus
adéquat de développement varie selon différents facteurs (Ex : l’importance, la complexité, la
priorité et l’innovation du projet, ainsi que la taille, la compétence, l’expérience et la
motivation de l’équipe impliquée dans le projet). Après une étude comparative entre les
méthodes les plus connues (UP, RUP, 2TUP, XP…), j’ai inspiré ma méthodologie de travail
dans les concepts de la méthode hybride UP-XP incrémentiel et itératif, basé sur l’UML,
guidé par les cas d’utilisation et piloté par les risques du projet qui doivent être détectés et
contournés au plutôt possible, en focalisant sur le code et le maître d’ouvrage et en
minimisant le temps consacré à l’étude préliminaire et la modélisation préalable avant le
commencement de la réalisation de la première itération.
L’objectif de la démarche UP-XP est de pouvoir réaliser un logiciel orienté objet

évolutif et ayant l’aptitude de s’adapter aux éventuels changements que peut connaître le
métier de l’entreprise à l’avenir (nouveaux produits, la clientèle ciblé…).
1.3.2. Planification du projet

La planification est parmi les phases d'avant-projet. Elle consiste à prévoir le
déroulement du projet tout au long des phases constituant le cycle du projet. Grâce aux
réunions tenues avec l’encadrant au sein de Info Pro, nous avons été éclairés sur les
différentes étapes du projet ainsi que leur séquencement.
La durée de stage est trois mois (du 04 avril au 04 juillet), ce qui nous donne presque
70 J*H de travail sur le projet. Notre travail était organisé comme le montre le diagramme de
Gantt suivant :
Figure 3 : Planning du projet

Conclusion
Durant ce premier chapitre qui vise à situer le contexte général du projet, nous avons
commencé par la présentation de l’organisme d’accueil Info Pro. Ensuite, nous avons
présenté le projet en étalant ses objectifs, la conduite du projet et le planning élaboré. Le
prochain chapitre sera réservé à l’analyse et la conception du projet.

Chapitre 2
Analyse et modélisation en UML
Le présent chapitre va aborder l’analyse et la conception

UML de l’application

2. Conception et modélisation en UML
2.1. Phase d’inception : Recensement et définition des besoins
Cette phase ayant comme objectifs l’identification des principaux acteurs interagissant
avec le système et les fonctionnalités attendues de celui-ci.
2.1.1. Les exigences :

Dans un premier temps, nous allons lister l’ensemble des exigences collectés à travers
les recherches réalisés sur quelques sites d’hébergement des sociétés ayant l’activité similaire
à celle d’Info Pro. Les deux tableaux ci-dessous représentent successivement les exigences ou
les fonctions du système dans sa partie front et les fonctions de l’application de gestion
administrative. Toutes les fonctions son étiquetées par des numéros de références, chaque
« R » est une exigence (Requirement).
Référence Fonction
R1 S’inscrire via une commande / S’identifier
R2 Vérifier la disponibilité d’un nom de domaine
R3 Commander un nom de domaine
R4 Transférer un nom de domaine vers les services de la société
propriétaire du système
R5 Consulter la liste des plans d’hébergement proposée
R6 Commander un plan d’hébergement
R7 Payer les frais annuels
Tableau 1 : Exigences de front office
Référence Fonction
R8 Valider une commande (nom domaine, hébergement)
R9 Envoyer un message de rappel
R10 Régler le paiement des nouvelles commandes
R11 Régler le paiement annuel des commandes
R12 Créer/supprimer un utilisateur (RT)
R13 Donner des droits d’accès à un utilisateur
R14 Gérer les plans d’hébergement (Ajouter/supprimer/Modifier plan
d’hébergement)
R15 Bloquer/Débloquer un compte client
Tableau 2 : Exigences de back office
2.1.2. Les acteurs :

Un acteur représente un rôle joué dans le système par un être humain, processus ou
autre applications qui peuvent consulter et/ou modifier directement l’état du système, par
émission et/ou réception des messages éventuellement porteurs de données. L’accès de
chaque acteur au système est limité par des droits d’accès définit au préalable. Les acteurs

que nous avons identifiés à partir de la description des fonctionnalités ci-dessus sont les
suivants :
Administrateur : La personne qui supervise toutes les fonctionnalités du système,

notamment la gestion des utilisateurs (cette tâche est géré uniquement par lui-même), alors
que la gestion des produits, des clients, et des commandes, peuvent être confiées en cas de
nécessité au responsable technique.
Responsable Technique (RT) : La personne qui se charge du métier de vente des produits et
des services de la société, elle a presque tous les droits de l’administrateur, excepte la gestion
des utilisateurs.
Client : la personne qui s’inscrit avec un login et mot de passe.
Visiteur : Tous les internautes qui peuvent visiter le portail web de l’application.
Le diagramme suivant illustre les différents acteurs et les associations qui les lient entre eux :
uc Actors
RT
Administrateur
Visiteur Client
Figure 4 : Diagramme d’acteurs
Le RT peut utiliser les fonctionnalités de l’administrateur, chose qui est indiqué par
l’association d’héritage au niveau du diagramme d’acteurs.
2.1.3. Diagramme de contexte statique :

Ce diagramme complète le diagramme d’acteurs pour montrer les interactions des
acteurs avec le système, en apportant plus éclaircissement sur les cardinalités des différents
acteurs et leurs exigences. Une cardinalité représente le nombre d’instance d’un acteur qui
interagit avec le système au même moment.
Ce diagramme nous permet de préciser la nature de l’application : Multi-utilisateurs par

rapport aux interactions des acteurs à un instant donné. D’où vient le choix du système réparti
(application web).

analysis Stakeholders
- Valider une demande (nom

domaine, transfert, hébergement)
- Activer / Désactiver un Abonnement

- Bloquer/Débloquer le compte d'un
client
Administrateur RT
- Créer / Supprimer un compte utilisteur( -Ajouter / Modifier / Supprimer un
Manager) plan d'hébergement
- Bloquer / Débloquer un compte utilisteur(

Manager)
- Donner / Enlever un role à un utilisateur
Gestionaire
d'hébergement
- S'identifier
- Désabonner
- Renouveler l'abonnement
- Demander un nom de domaine

- Demander de Transferer un nom de
- Consulter la liste des plans d'hébergement domaine
proposé - Demander un plan d'hébergemnt
- Vérifier la disponibilité d'un nom de - Consulter l'etat de paiement(les

domaine factures réglées / non réglées)
- Régler une facture
- S'inscrire
Visiteur
Client
Figure 5 : Diagramme de contexte statique
2.1.4. Intention d’acteur :

A cette itération, nous affermissons les exigences déjà relevées ci-dessus en intentions
d’acteurs. Une intention d’acteur est une unité de fonctions cohérentes qui réalise un service
de bout en bout, avec un déclenchement, un déroulement et une fin. Les deux tableaux ci-
dessous représentent respectivement les intentions des utilisateurs du portail web et les
intentions des utilisateurs administratifs :
Ce premier tableau illustre le regroupement des fonctions du système par l’intention des
acteurs qui interagissent avec le front office, à savoir les clients et les simples visiteurs :
Référence Fonction L’intention Acteur

d’acteur
R1 S’inscrire via une commande / S’authentifier Visiteur /
S’authentifier Client
R2 Vérifier la disponibilité d’un nom de Réserver un nom Visiteur /
domaine de domaine Client
disponible
R3 Commander un nom de domaine Réserver un nom Client
de domaine
disponible
R4 Transférer un nom de domaine vers les Transférer le Client
services de la société propriétaire de fournisseur du
système domaine

R5 Consulter la liste des plans d’hébergement Commander plan Client
proposée d’hébergement
R6 Commander un plan d’hébergement Commander un Client
plan
d’hébergement
R7 Régler les frais annuels Régler la facture et Client
valider la
commande
Tableau 3 : Intentions des acteurs de front office
Ce deuxième tableau illustre le regroupement des fonctions du système par l’intention des
acteurs interagissant avec le back office, à savoir l’administrateur et le RT :
Référence Fonction Intention Acteur

d’acteur
R11 Régler les frais annuels Régler et revalider Administrateur,
la commande RT
R12 Envoyer un message d’annonce ou de Annonce /rappel Administrateur,
rappel RT
R13 Créer/supprimer un utilisateur Gérer les Administrateur
(manager=RT) utilisateurs
R14 Donner des droits d’accès à un Gérer les Administrateur
utilisateur utilisateurs
R15 Gérer les services Gérer les services Administrateur,
(Ajouter/supprimer/Modifier un plan RT
d’hébergement)
R16 Bloquer/Débloquer un compte client Gérer les comptes Administrateur,
client RT
R17 Valider les commandes Valider les RT
commandes
Tableau 4 : Intentions des acteurs de back office
2.1.5. Diagramme des cas d’utilisation :

Les cas d'utilisation permettent de représenter le fonctionnement du système vis-à-vis de
l'utilisateur : c'est donc une vue du système dans son environnement extérieur. Le diagramme
ci-dessous regroupe tous les cas d’utilisation à compléter par notre système, divisé en trois
zones par acteur afin de cerner les services offerte par le système à chaque type d’acteurs (les
cas d’utilisations qui cernent les acteurs administratifs sont cadrés par le bleu, ceux qui
cernent les clients inscrits sont cadrés par le vert et ceux qui cernent les visiteurs non-inscrits
sont encadrés par le jaune). Tous les cas d’utilisation administratifs et des clients nécessitent
(extend) l’authentification, alors que les visiteurs qui ne sont pas encore inscrits ont la
possibilité de : consulter les packs d’hébergement et les domaines proposés à la vente, vérifier
la disponibilité d’un nom de domaine avant de le commander et aussi s’inscrire par le biais
d’une commande.

Les prochaines diagrammes UML traiteront seulement les cas d’utilisation les plus
compliqués.
uc Primary Use Cases
S'authentifier
Client
Responsable Technique Gérer packs et NDs
(RT)
Transferer un nom de
Commander un nouv eau domaine
Créer pack/ND nom domaine
Supprimer pack/ND
Modifier pack/ND
Commmander un
domaine
«Pre-condition»
{Si le client ne dispose
pas préalablement
d'un nom de domaine
disponible à pointer sur
l'espace
d’hébergement
«extend» commandé}
Administrateur exécuter et v alider la
commande
«include» {manque domaine}
Paiement en ligne
Gérer le règlement des
«extend» Commander un pack
factures
d'hébergement
Géstion des clients

Consulter les serv ices
proposés (plans
d'hébergement)
Consulter les
nouv elles
Bloquer/Débloquer commandes
/Supprimer Client
Vérifier la disponibilité d'un nom
de domaine Visiteur
Rappel sur l'expiration de la

commande
S'inscrire v ia une
commande
Géstion des comptes

utilisateur
Créer/Supprimer
utilisateur
Donner/Enlev er rôle Bloquer/Débloquer

utilisateur l'utilisateur
Figure 6 : Diagramme de cas d’utilisation

2.1.6. Description textuelle de haut niveau
Après le regroupement de l’ensemble des exigences sous forme des uses case, dans ce
chapitre nous décrirons ces derniers en précisons certains informations (objectif, acteur
principal, événement déclencheur, version et terminaison). La version permet de mettre en
évidence l’aspect itératif de la démarche UP-XP qu’on a adopté :
Nom de l’Use Case : Commander/Transférer des noms de domaine(ND).
Objectif : Réserver un ou plusieurs NDs disponible.
Acteur Principal : Client.
Acteurs secondaires : Administrateur, RT.
Evènement déclencheur de l’Use Case : Commande de la part d’un client inscrit.
Version : 0.0
Terminaison du Use case : la création des lignes commande.
Tableau 5 : Description textuel du haut niveau du use case «Commander/Transférer des noms de
domaine(ND) »
NB : Pour transférer un nom de domaine déjà réservé ailleurs, et si le client désire

le transférer et l’enregistrer chez la société propriétaire du système, il doit suivre les mêmes
étapes que la commande d’un nouveau ND.
Nom de l’Use Case : Commander des packs d’hébergement
Objectif : Acheter une ou plusieurs solutions d’hébergement proposées par la société
Acteur Principal : Client
Evènement déclencheur de l’Use Case : Commande de la part d’un client inscrit.
Version : 0.0
Terminaison du Use case : la création des lignes commande.
Tableau 6 : Description textuel du haut niveau du use case «Commander des packs d’hébergement »

Nom de l’Use Case : Valider la Commande
Objectif : Valider les commandes réglées
Acteur Principal : RT
Evènement déclencheur de l’Use Case : Une commande non-validée.
Version : 0.0
Terminaison du Use case : Offrir un Cpanel, un ND ou les deux au client.
Tableau 7 : Description textuel du haut niveau du use case «Valider la Commande »
Nom de l’Use Case : Gérer le paiement annuel.
Objectif : Enregistrer le paiement des frais annuels.
Acteur Principal : Administrateur, RT.
Acteurs secondaires : Client.
Evènement déclencheur de l’Use Case : expiration du paiement annuel + le client a payé

les frais annuels.
Version : 0.1
Terminaison du Use case : paiement annuel effectué.
Tableau 8 : Description textuel du haut niveau du use case «Gérer le paiement annuel»
Cette description succincte représente une introduction à la phase d’analyse. Elle sera
détaillée par une autre description textuelle de bas niveau.
2.2. Phase d’analyse

Dans cette phase nous allons analyser chaque fonctionnalité attendue du système en
examinant les scénarios nominaux, alternatifs et exceptionnels. Puis on trace les diagrammes
de séquence boite noire, d’activité système et d’interaction vue globale qui consolident les
différente scénarios possibles pour les cas d’utilisations les plus importants. Vers la fin de
cette phase nous réaliserons le diagramme de classe d’analyse qui contiendra les entités métier
et les associations entre eux et qui sera traduit en modèle physique de la base de données.

2.2.1. Description textuelle de bas niveau
Cette description permet de décrire profondément les fonctionnalités de l’application pour
un usage déterminé de l’utilisateur en précisant le contexte (précondition et post condition) de
déroulement des uses cas.
Nom de l’Use Case : Commander des noms de domaine (ND).
Acteurs secondaires : Administrateur, Responsable Technique.
Evènement déclencheur de l’Use Case : Commande auprès du client inscrit.
Rôle du use case : le client envoie une commande d’un ou plusieurs ND, via le portail
web (front office) vers le système back office (administration), qui le validera par la suite
si le paiement est réglé.
Terminaison du Use case : Le client reçoit la réponse de sa commande.
Références croisées des exigences : R2, R3, R4.
Préconditions : Le client est inscrit et s’authentifier (objet session est instancié).
Post-conditions : Une nouvelle commande est créée.
Tableau 9 : Description textuelle bas niveau d’use case « Commander des noms de domaine (ND) »
Nom de l’Use Case : Commander des packs d’hébergement.
Acteurs secondaires : Administrateur, Responsable Technique.
Evènement déclencheur de l’Use Case : Commande auprès d’un client inscrit.
Rôle du use case : Le client envoie une commande d’un ou plusieurs packs
d’hébergement, du portail web (front office) vers le système back office, qui le validera
par la suite si le paiement est réglé.
Terminaison du Use case : Le client reçoit la réponse de sa commande via sa boite

Email.
Références croisées des exigences : R5, R6.
Préconditions : Le client est inscrit et s’authentifier (objet session est instancié)

Post-conditions : Nouvelles commandes créées.
Tableau 10 : Description textuelle bas niveau d’use case « Commander des packs d’hébergement»
Nom de l’Use Case : Règlement annuel.
Acteur Principal : RT
Evènement déclencheur de l’Use Case : Expiration du règlement annuel + le client a

payé les frais annuels.
Rôle du use case : Enregistrer le règlement des frais annuels.
Terminaison du Use case : paiement annuel est effectué.
Références croisées des exigences : R11.
Préconditions : Commande en attente du règlement annuel.
Post-conditions : Règlement annuel de l’année courante, renouvellement de la

commande.
Tableau 11 : description textuelle bas niveau d’use case « Règlement annuel»
2.2.2. Description complète du use case, avec ses différents scénarios :

Dans les tableaux ci-dessous, nous décrivons le déroulement des scénarios nominaux de
certains cas d’utilisation.
Action des acteurs Action du système
1) Le client/visiteur saisit un nom de 2) Le système vérifie la disponibilité des

domaine et les extensions désirées. combinaisons (nom, extension) et
rend le tableau des résultats,
distinguant les combinaisons
disponibles et non disponibles.
3) Le client ajoute les combinaisons 4) Le système affiche le panier avec la

(nom, extension) désirées au possibilité d’en supprimer, rajouter
panier. d’autres lignes de commande ou bien
valider le panier.
5) Le client valide le panier 6) Le système affiche deux boutons :
-Paiement.
-Envoie la commande au back

office.

7) Le client choisit un mode de 8) Le système affiche la nouvelle
paiement. commande en attente de validation au
back office.
9) Cas d’utilisation paiement.
10) Le R.T. consulte les nouvelles

commandes.
11) Le R.T. valide les commandes.

12) Le système envoie un message de
confirmation de la commande au
client
13) Le client reçoit la réponse de sa

commande par email.
Tableau 12 : scénario nominal du cas d’utilisation « commander nom de domaine »+ « valider la

commande»
Nous avons enchainé dans le tableau ci-dessus deux cas d’utilisation « commander
nom de domaine » qui rend le service au client et « valider la commande » qui rend le service
au responsable technique, car le deuxième cas complète le premier. Nous n’avons pas
fusionné entre les deux cas d’utilisation, vue la séparation chronologique et au niveau de
l’acteur principal qui déclenche chacun d’entre eux.
Action des acteurs Action du System
1) Le système affiche les packs

d’hébergement
2) Le client choisit un pack 3) Le système récupère l’ID du pack

d’hébergement proposé par la sélectionné et affiche les détails avec
Sté. le bouton « Commander »
(optionnel) ;
4) Le système affiche la première étape :

commander, transférer ou saisir (s’il
est déjà pris) un nom de domaine
disponible.
5) Le client saisit un ND ou bien

commande un autre (voir cas
d’utilisation commander nom de 7) Le système ajoute le pack
domaine). d’hébergement et le nom domaine
correspondant au panier. Puis donne
6) Le client clique sur l’étape les possibilités, soit de recommander,
suivante supprimer ou valider le panier ;

8) Le client choisit recommander
(répète même scénario 1)6)).
9) Le client choisit valider le

panier. 10) Le système affiche deux boutons :
-Paiement.
-Envoie la commande au back office.
11) Le client choisit un mode de 12) Le système affiche sur le back office
paiement (voir cas d’utilisation une nouvelle commande en attente de
paiement) validation, ainsi que le mode de
paiement.
13) Cas d’utilisation paiement
14) L’administrateur ou R.T

consulte les nouvelles
commandes, il vérifie si le
paiement est effectué, il valide
les commandes réglées. En fin il
crée les packs d’hébergement
commandés et envoie les
paramètres des Cpanels (Url,
login et mot de passe) aux
emails des clients concernés
15) Le client reçoit dans sa boite

email les paramètres du Cpanel.
Tableau 13 : Scenario nominal « commander packs d’hébergement»+ « valider les commandes»
Idem que le tableau précédent nous avons regroupé dans ce dernier tableau
l’enchainement de deux use cases, à savoir « commander packs d’hébergement » et « valider
les commandes »
Les enchaînements alternatifs :
A1 : le client n’est pas authentifier ou bien n’est pas inscrit.
Le point de démarrage est 2 du scénario nominal.
3. le déroulement du cas d’utilisation « s’inscrire »
Le scénario nominal reprend au point 3 (ou 4 car 3 est optionnel).

2.2.3. Diagramme de séquence boîte noire :
Ce diagramme permet de représenter les échanges entre les utilisateurs et le système
informatique d’une manière ordonnée chronologiquement sans montrer comment les
composantes (objets) internes de ce système collaborent pour rendre les services demandés,
car nous ne savons pas encore ses classes. Ci-après quelques principaux diagrammes de
séquence qui décrivent le déroulement du cas d’utilisation précédemment cités.
Figure 7 : Diagramme de séquence boite noire du use case « Règlement des nouvelles commandes »
Figure 8 : Diagramme de séquence boite noire du use case « Paiement annuel »

Figure 9 : Diagramme de séquence boite noire du use case « authentification/inscription client»
La figure suivante illustre le diagramme de séquence boite noire des uses case
« Commander pack d’hébergement» et «valider la commande» en se basant sur la description
textuel du scénario nominal définit précédemment.

Figure 10 : Diagramme de séquence boite noire du use case « Commander packs
d’hébergement»+ « valider les commandes»

2.2.4. Diagramme d’activité système :
Le diagramme d’activité est composé d’un flux de nœuds d’activité système représenté
par des cadres, des flèches qui schématisent les transitions entre les activités, ainsi enrichi par
des conditions de vérification.
Dans l’organigramme ci-dessous, nous allons étudier les activités faites par le système
pour enregistrer la commande d’un pack d’hébergement en prenant en considération le
paiement en ligne.
act Diagramme d''activ ité système du use case cmd pack d''hébr
Vérification de
Affichage des packs
l'inscription/authentification
d'hébergement
du client
début
Affichage des 3
Non Oui
possibilités d'av oir un ND
Inscription du client disponible
iscription/authentification OK ?
OK
NO
Saisie du ND Transfert d'un ND Commande d'un ND
échec
Création d'une commande

en attente de paiement
Annuler
L'aj oute d'un pack au

Recommander
panier. Affichage du
panier
paiement classique
Validation
Non Affichage des modes de du panier
Paiement OK ?
paiement
Paiement en ligne
Oui
Création d'une commande

réglée et v alidée
informer le client et
l'admin/RT
Fin nominale
Figure 11 : Diagramme d’activité système du use case « Commander pack

d’hébergement»+ « exécuter et valider la commande»
2.2.5. Diagramme d’interaction vue global :

Un diagramme d’interaction vue global permet de représenter l’ensemble des
transactions du système afin de donner une vue globale des fonctionnalités du système. Ce
diagramme peut être vu comme un menu principal de l’application.

Les deux diagrammes ci-dessous représentent successivement, celui du back-office et
celui de front-office :
sd diagramme d intéraction v ue global back
Début
Géstion des packs

d'hébergement Géstion des commandes Gestion des utilisateurs
client
Géstion du paiement
T erm i ner Non

?
Oui
Fi n
Figure 12 : Diagramme de transaction vue globale pour le back-office

sd diagramme d intéraction v ue global front
Début
Commande des packs Commande des ND Transfert des ND Consult des serv ices
d'hébergement
Regler la commande
T erm i ner ? Non
Oui
Fi n
Figure 13 : Diagramme de transaction vue globale pour le front-office

2.2.6. Diagramme de class d’analyse :
Le diagramme de classe d’analyse permet de découvrir tous les objets métier qui
constituent notre système et le rendre un système « boite blanche ».
L’analyse approfondie des fonctionnalités du système nous a permis d’identifier

l’ensemble des entités métier et les associations entre eux.
class System
Client
- id: int
- email: varchar2(100)
- password: varchar2(30)
- RS: varchar2(30) User
- nom: varchar2(30)
- id: int
- prenom: varchar2(30)
- login: varchar2(20)
- adresse: varchar2(150)
- codePostal: varchar2(10)
- nom: varchar2(50)
- ville: varchar2(30)
1 - prenom: varchar2(50
- tel: varchar2(15)
- role: varchar2(20)
1 1
posséder
correspondre
0..1 LigneCommande
1..* - id: int

Panier - dateCommande: Date
- dateExperation: Date
- total: double
- nomDomaine: varchar2(70)
- valide: boolean
1 0..1
1
0..*
étendre
0..*
0..*
1
LignePanier
LigneFacture
- produit: Produit
- nbrProduits: int - montant: double
0..1 1..*
1 1
Produit 1 0..*
- id: int
Facture
- libelle: varchar2(15)
- description: varchar2(50) - numFacture: varchare2(10)
- fraisVente: float - dateFacture: date
- fraisAnnuel: float
- disponible: boolean
Propriete
Domaine PackH
- idPropriete: int
* * - categorie: varchar2(20)
- isBarre: boolean
- textePropiete: varchar2(50)
Figure 14 : Diagramme de classe

2.2.7. Contrats d’opération de LARMAN
Jusqu’à ce point-là, nous nous intéressons de décrire ce que fait le système sans décrire
comment il le fait. Les contrats de LARMAN vont nous permettre de décrire les changements
d’états du système (c'est-à-dire les changements sur les objets et leurs associations).
Nous allons établir le contrats d’opération « ValiderCommande(idCmd) » du use case

« valider la commande » :
Nom : ValiderCommande(idCmd)
Responsabilités : valider une commande : Réserver le pack d’hébergement.
Exigences : R17 pour le cas d’utilisation « commander packs d’hébergement ».
Notes : Le RT peut valider une commande même s’elle n’est pas payée.
Préconditions : Une commande en attente de validation est créée.
Post condition : L’état de la commande devient « valide ».
2.2.8. Diagramme de séquence boite blanche
Dans cette paragraphe on se limitera de construire un seul diagramme boite blanche du

cas d’utilisation « commander packs d’hébergement », mettant l’accent sur la chronologie de
l’envoi des messages entre les entités (classes d’analyse) et le client (l’acteur principal). Ce
qui nous permettra de décortiquer et de dévoiler comment les composants de notre code
source se collaborent pour réaliser la fonctionnalité attendue de ce use case.

Figure 15 : diagramme boite blanche du cas d’utilisation « commander packs d’hébergement »

2.3. Phase de conception : diagramme de classe de conception
Dans cette phase nous nous contentons de réaliser le diagramme de classe de
conception. Il sera déduit essentiellement de diagramme de classe d’analyse et de séquence.
C’est évident que chaque classe persistante possède des opérations CRUD (create, remove,
update et delete). Ces opérations CRUD et d’autres de sélection plus avancées sur la base de
données sont héritées automatiquement à partir de la classe mère Zend_Db_Table.
class System
Client
- i d: i nt
- emai l : varchar2(100) User
- i d: i nt
- RS: varchar2(30)
- l ogi n: varchar2(20)
- nom: varchar2(30)
- prenom: varchar2(30)
- nom: varchar2(50)
- adresse: varchar2(150)
- prenom: varchar2(50
- codePostal : varchar2(10)
- rol e: varchar2(20)
- vi l l e: varchar2(30)
1
- tel : varchar2(15)
1
1
posséder
correspondre
0..1
LigneCommande
Panier
- i d: i nt
- total : doubl e - dateCommande: Date
- l i gnes: Li gnePani er[] 1..* - dateExperati on: Date
- nomDomai ne: varchar2(70)
+ aj outerProdui t(i dProdui t) : voi d - val i de: bool ean
+ edi tNbProdui t(nbrProdui t, i dProdui t) : voi d
+ edi tNDomai ne(i dProdui t, newDN) : voi d + getAl l NewCmd() : commande[]
+ //getters() + getCmdExp() : commande[]
étendre
+ //setters()
1
1 0..*
payer
correspondre
0..* 0..*
LignePanier LigneFacture
- produi t: Produi t correspondre - montant: doubl e

- nbrProdui ts: i nt
- nDomai ne: Stri ng
1..*
+ aj outer(i nt) : voi d
+ //getters()
+ //setters()
1 0..*
0..1
Facture
1 1
- numFacture: varchare2(10)
Produit - dateFacture: date
PackH
- i d: i nt + i mpri mer(i dFacture) : voi d
- l i bel l e: varchar2(15) + addLi gne(i dLi gne) : voi d
- descri pti on: varchar2(50) + removeLi gne(i dLi gne) : voi d
*
- frai sVente: fl oat
- frai sAnnuel : fl oat 0..*
- di sponi bl e: bool ean *
1
Propriete
- i dPropri ete: i nt ModePaiement

- categori e: varchar2(20)
Domaine - i dMode: i nt
- i sBarre: bool ean
- l i bel l e: varchar2(30)
- textePropi ete: varchar2(50)
Figure 16 : Diagramme de classe de conception

Conclusion :
Dans ce chapitre, nous avons élaboré les différents diagrammes des trois
phases de la modélisation UML, à savoir la phase d’inception, la phase d’analyse et la
phase de conception.
Cette conception sera implémentée dans le dernier chapitre en utilisant le

langage PHP5 (POO) et à l’aide de son Framework : Zend.

Chapitre 3
Plateforme de
développement et implémentation
Cette dernière partie de notre rapport présente les

différentes technologies utilisées pour le développement,
l’aspect sécurité et quelques aperçus écran qui décrivent
l’application dans son état final de déploiement

3. Plateforme de développement et implémentation
3.1. L’architecture de l’application
La première question qui s'est posée pour la réalisation de la partie technique du projet a
été de choisir une architecture pour l'application. L’évolutivité, la réutilisabilité et
l’adaptation aux nouvelles mutations sont parmi les contraintes d’un produit logiciel de
qualité. De ce fait, le choix d’une architecture répartie en couches pour les raisons suivantes :
- Séparer les interfaces graphiques et le modèle ou le métier de l’application : C’est-à-

dire que ces interfaces ne doivent pas contenir des traitements ;
- Assurer l’indépendance entre le code source de l’application et SGBD utilisé ;
- Toute évolutivité ou mutation que connaîtra l’application, au niveau de la présentation

ou du métier, se fera facilement et rapidement, sans qu’il y ait un grand changement sur le
code source ;
C’est pour ces raisons nous cherchons à construire une architecture en couche selon le
modèle MVC :
 Couche des données (Modèle).
 Couche des interfaces home machine (Vue).
 Couche logique de contrôle (Contrôleur).
Grossièrement, cela permet une séparation entre les traitements de données et la présentation.
Figure 17 : architecture en couche selon le modèle MVC.

Modèle :
Le modèle représente les structures de données. Typiquement, les classes modèles

contiennent des fonctions qui aident à récupérer, insérer et mettre à jour des informations de
la base de données (CRUD).
Vue :
La vue correspond à l'interface avec laquelle l'utilisateur interagit. Elle se présente

sous la forme d'un template représentant l'interface, mais sans les données. A ce niveau, on a
intégré la bibliothèque jQWidgets (définit par la suite) pour rendre l’interface graphique plus
interactive avec les contrôles JavaScript, les composantes/styles pratiques de HTML5/CSS3 et
la synchronisation des données avec la technologie AJAX.
Contrôleur :
Il gère l'interface entre le modèle et le client. Il va interpréter la requête de ce dernier pour

lui envoyer la vue correspondante. Il effectue la synchronisation entre le modèle et les vues.
3.2. Choix technologique

Pour le développement nous avons utilisé les outils suivants :
 IDE : netBeans 7.3 ;
 Outils de développement : Extension de navigateur « Chrome » pour diagnostiquer les

messages d’erreurs javaScript ;
 Zend version 1.12 : framework de PHP 5 (MVC, ORM, Authentification, layout,

ACL, navigation, Zend_PDF);
 jqWidgets : Une bibliothèque de l’HTML5, CSS3, Javascript, jQuery et comporte la

technologie AJAX ;
 serveur : WampServer :
 Serveur d’applications : Apache version 2.2.22 ;
 serveur de la base de données MySQL version 5.5.24 ;
3.2.1. Le langage PHP5

PHP (PHP HyperText PreProcessor) est un langage de programmation. Sa principale
application se situe au niveau de la gestion des sites web dynamiques.

PHP est à l’origine un langage de script conçu spécifiquement pour agir sur les
serveurs web. En ajoutant quelques lignes de PHP à une page HTML, le serveur exécute les
instructions correspondantes pour écrire du code HTML à la place. Le résultat (le code HTML
initial ajouté à celui produit par PHP) est envoyé au navigateur.
Le développement de PHP 5 a été entamé en 2002, mais c’est l’année 2003 qui a été la
plus active. L’objectif était double : d’une part, rendre PHP plus professionnel, mais
également le simplifier.
La première version stable de PHP 5 a fait son apparition en 2004. Les versions 5.1 et
5.2, quant à elles, sont respectivement sorties en 2005 et 2006. Par rapport à la version 4, les
principales nouveautés sont :
• l’intégration du Zend Engine 2, qui amène une prise en charge complète de la

programmation orientée objet ;
• la refonte de la prise en charge de XML ;
• la simplification des principales tâches courantes.
• l’apparition d’un socle commun pour la gestion des appels aux bases de données : PHP Data
Object (PDO).
3.2.2. Utilisation d'un Framework

Un framework ou kit de développement est un espace de travail modulaire, c'est-à-dire
une suite d'outils et de bibliothèques qui facilitent et accélèrent le développement d'un
logiciel. Il contient toutes les fonctions de base utiles au développement d'un type de
programme, et permet donc de ne pas avoir besoin de ré-écrire les mêmes fonctions à chaque
programme créé. Il en existe dans tous les langages de programmation.
Parmi les frameworks Web, je me suis plus particulièrement intéressée aux

frameworks Web PHP. Dans leur grande majorité, ils sont conçus sur le modèle MVC, ce qui
permet de structurer les données. Ils imposent un cadre et des normes de développement qui
permettant une programmation propre et modulaire.
De plus, depuis la version 5 de PHP, qui introduit la Programmation Orientée

Objet(POO), il est beaucoup plus facile et intuitif de programmer des systèmes modulaires.
3.2.2.1. Comparatif des principaux framework PHP
Il existe de nombreux framework PHP open-source, c'est à dire gratuits, librement

modifiables et distribuables. J'ai testé et étudié les plus connus pour trouver le plus adapté.
Zend Framework :
Zend Framework (ZF) est un framework open-source destiné aux développements

d'applications web et de services web avec PHP5. Le Zend Framework est construit en
utilisant 100% de code orienté-objet. La structure des composants du Zend Framework est

quelque peu unique ; chaque composant est conçu avec de faibles dépendances envers les
autres composants. Cette architecture faiblement couplée permet aux développeurs d'utiliser
les composants individuellement. On appelle souvent ce type de conception "use-at-will".
Bien qu'ils puissent être utilisés individuellement, les composants de la librairie

standard de Zend Framework forment un framework d'application web puissant et extensible
quand ils sont combinés. Le ZF offre une robuste et performante implémentation du motif
MVC, une abstraction de base de données simple d’utilisation, et un composant de formulaire
qui implémente un rendu HTML, la validation et le filtrage des données, ainsi les
développeurs peuvent consolider toutes ces opérations en utilisant une interface orienté-objet
facile d'utilisation. D’autres composants, comme Zend_Auth ou Zend_Acl, fournissent
l’authentification d’utilisateurs et l'autorisation envers les solutions de stockage de crédits
habituels.
D'autres encore, implémentent des librairies clientes pour simplifier l'accès aux
services web disponibles les plus populaires. Quel que soit le besoin de votre application,
vous avez toutes les chances de trouver un composant de Zend Framework qui peut être
utilisé pour réduire drastiquement votre temps de développement avec une base de tests
solide. Le sponsor principal du projet Zend Framework est Zend Technologies, mais un
certain nombre d'entreprises a contribué à des composants ou à des fonctionnalités
significatives du framework. Des entreprises comme Google, Microsoft et StrikeIron ont
travaillé en partenariat avec Zend pour fournir des interfaces vers des services web et d'autres
technologies qu’ils souhaitaient rendre disponible aux développeurs utilisant Zend
Framework.
Fonctions principales :
 Sécurité :
o Les requêtes en base sont protégées des injections SQL.
o Des fonctions de filtrage et de validation aident à la protection contre les

attaques de types cross-site-scripting (XSS).
 Organisation du code :
o L'organisation des répertoires et des classes suit certaines normes. On peut

ainsi construire son application par assemblages de blocs indépendants bien
organisés entre eux.
 URL simples et claires
o La forme des URL est entièrement paramétrable, ceci permet d'améliorer le

référencement de ses sites.
 Séparation MVC (Model-View-Controller)

o Le Zend Framework offre de base une architecture MVC. C'est à dire qu’il
sépare la présentation, la navigation et l'accès aux données. Cette séparation
est capitale pour un site complexe. Elle permet de réduire la complexité de
chaque partie et de faire travailler ensemble les graphistes, les développeurs
et les architectes en parallèle sans qu'ils se marchent sur les pieds.
 De nombreuses fonctions courantes deviennent faciles avec ZF :
o Moteur de recherche.
o Accès en base de données.
o Accès à des services externes.
o Authentification, droits d'accès.
Symfony :
Symfony est un Framework MVC open-source écrit en PHP 5, donc orienté objet. Ses
principales fonctionnalités sont :
• Une séparation du code en trois couches, selon le modèle MVC.
• Un système de template évolué.
• Des performances optimisées et un système de cache pour garantir des temps de

réponse optimums.
• Une gestion des url parlantes, qui permet de formater l'url d'une page indépendamment
de sa position dans l'arborescence fonctionnelle.
• Un générateur de back-office.
• Un système de gestion de langue (pour internationaliser un site).
• Une couche de mapping objet-relationnel (ORM) et une couche d'abstraction

dedonnées.
• Le support de l'Ajax.
• Une architecture extensible, permettant la création et l'utilisation de plugins.
3.2.2.2. Framework choisi
Après une forte hésitation entre le Zend Framework et Symfony, j'ai décidé d'utiliser
Zend, étant séduit par ses fonctionnalités très évoluées : rendre le PHP beaucoup plus
confortable.

3.2.3. Bibliothèque jqWidgets
jQWidgets propose une solution complète pour la construction de sites web riches et
professionnels et applications mobiles. Elle repose entièrement sur les standards ouverts et des
technologies comme HTML5, CSS3, JavaScript, jQuery et la technologie AJAX. jQWidgets
permet le développement de web réactive et aide à créer des applications et sites Web sur
ordinateurs de bureau, les tablettes et les téléphones intelligents.
Que faire avec jqWidgets ? :

 Gérer les interactions avec l’utilisateur ;
 Prétraiter les formulaires dans le navigateur du client ;
 Manipuler le DOM (Document Objet Model) ;
 Utiliser AJAX d’une manière simple ;
 Créer des applications web et mobile riches (RIA ou web 2.0)
Que ne pas faire jqWidjets ? :

 Remplacer un langage interprété côte serveur (PHP, ASP, Java…) ;
 Remplacer un rôle sécuritaire ou de validation (car c’est de langage
JavaScript interprété côte client et il est simple de le désactivé) ;
 Remplacer totalement HTML
3.3. Implémentation & codage

3.3.1. La structure des fichiers selon le modèle MVC
Le tableau suivant illustre l’arborescence des fichiers de l’application front office.
Arborescence Description
 Application.ini est un fichier de

configuration qui comporte deux
sections « dev » et « prod », ils incluent
des paramètres d’accès à la base de
données.
 Navigation.xml définit l’arborescence de
la navigation sur les différents pages de
l’application selon les droits de
l’utilisateur connecté à la session

Les classes contrôleurs représentent des liaisons
entre les classes modèles et les classes vue.
Grossièrement sert pour gérer les pages
affichées par la vue.
Il est courant que chaque page comporte des

parties communes, telles que l’en-tête et le pied
de page, le menu et les styles CSS. Zend_Layout
va nous permettre de créer un gabarit qui nous
évitera de dupliquer du code HTML d’une vue à
l’autre.
Les classes modèles persistants dans le dossier

DbTable et les classe non persistant (panier et
ligne panier).
Classe hérite la classe Zend_ACL, dont on

définit les ressources (pages de l’application) et
les droits d’y accès.
La classe GestionAccees extends

Zend_Controller_Plugin_Abstract et instancié
dans le Bootstrap(définit par la suite). Elle
contient une méthode ( preDispatch()) qui
vérifie est ce que l’expéditeur d’un requête http
a le droit d’accès à la page demandé ou non.
Cette méthode a comme attribut l’objet ACL
définit précédemment.

 L’aide d’action est une solution élégante
de factorisation du code contenu dans
les actions. C’est-à-dire, à chaque fois
qu’une section de code est amenée à être
dupliquée d’une action à l’autre, il est
utile d’employer une aide d’action.
 Les vues : les pages HTML qui
représentent les interfaces graphiques de
l’application. Chaque vue correspond à
une méthode action du contrôleur.
Bootstrap ou fichier d’amorçage : le fichier qui

initialise le « contrôleur frontal » (définit ci-
dessous)
La bibliothèque Zend décompressée
Dans le dossier public réside tous les fichiers des

style CSS, les fichiers JavaScript et les images.
Tableau 14 : Arborescence des fichiers de l’application front office.
Le contrôleur frontal(FrontController) : Est un motif de conception destiné à prendre en

charge l’analyse de toutes les requêtes du visiteur. Il est le seul et unique point d’entrée de
l’application et va orchestrer toute la suite. Il est ainsi représenté par un objet de la plus haute
importance. Comme il représente (conceptuellement) l’application à part entière, il s’agit d’un
singleton qui est initialisé dans un fichier spécial, que l’on appelle fichier d’amorçage ou
bootstrap.
3.3.2. Implémentation des classes modèles

Ce paragraphe montre l’implémentation de quelques classes modèle provenant du diagramme
de la classe d’analyse. En distinguant un exemple les classes persistantes (Produits) et deux
exemples des classes non persistantes (Ligne et Panier).

La classe Articles persistant :
La classe Ligne non persistant :

La classe panier non persistant :
Tableau 15 : Code source de quelques classes modèles.
3.4. Aspect sécurité
Ce paragraphe explique les grands axes de la sécurité du notre application. Pour cela,
nous présenterons différents types d’attaques classiques et la manière de s’en protéger avec
des composants Zend Framework relatifs à la sécurité, tels que Zend_Validate. Nous verrons
aussi l’importance des cookies et des sessions, ainsi que la manière de les sécuriser.
3.4.1. En quoi consiste la sécurité sur le Web ?
La sécurité doit faire partie intégrante du projet web. Les règles sont peu nombreuses et
très simples (à comprendre). Il s’agit de :
 valider tous les points d’entrée de l’application ;

 protéger systématiquement par des caractères d’échappement toute donnée à afficher
provenant initialement de l’extérieur ;
 maîtriser l’application en tant que « boîte noire » recevant des informations en entrée
et renvoyant des informations en sortie.
3.4.2. Solutions de sécurité de Zend Framework
Il est très important de scruter, analyser, valider ou rejeter toutes les informations qui
entrent dans l’application. Celles-ci proviennent majoritairement des tableaux superglobaux.
Ainsi, $_GET, $_POST, a fortiori $_REQUEST, $_COOKIE ou encore $_FILES peuvent
être manipulés par le client, et donc par un pirate potentiel. Zend Framework nous a fourni
deux mécanismes de vérification sur les variables et les données Entrées/Sorties :
Les validateurs :
Les validateurs sont des composants permettant de valider syntaxiquement des
données. En général, on ajoute les validateurs aux composants Zend_Form_Elements, afin
que ceux-ci soient tous scrutés et validés lors de l’envoi du formulaire. Il existe de nombreux
validateurs dans Zend Framework. Ils sont représentés par un espace Zend_Validate_* tandis
que la classe Zend_Validate sert à les chaîner. Les validateurs proposent une méthode
isValid() qui retourne un booléen getMessages(), qui retourne les messages d’erreur
éventuels, et getErrors(), qui retourne un code d’erreur.
Exemple du code : Validation d’email dans le formulaire d’enregistrement du client. Dans

premier lieu teste le format d’email s’il est valide ou pas, puis teste l’unicité de l’email dans la
base de données :
Les filtres :
Les filtres agissent comme les validateurs, à l’exception que ceux-ci vont modifier la donnée
d’entrée, au lieu de simplement retourner un booléen.
Exemple du code : validation et filtrage du nom d’utilisateur du back office :

3.4.3. Exemples d’attaques courantes
Nous allons ici présenter succinctement quelques exemples des failles de sécurité les
plus courantes et voir comment Zend Framework nous a aidé à s’en protéger.
3.4.3.1. Le Cross Site Scripting (XSS)
Le Cross Site Scripting consiste à exécuter arbitrairement du code JavaScript dans le

navigateur d’une victime. Cela permet entre autres de :
 changer la destination des formulaires de la page ;
 accéder aux cookies, et donc aux données privées de la victime ;
 ouvrir une connexion vers un site en se faisant passer pour la victime ;
 modifier le contenu de la page, en totalité ou en partie ;
 rediriger l’utilisateur ;
 avec certaines versions du navigateur Internet Explorer, il est possible
d’accéder au disque dur de la victime et de la voler massivement.
Le plus gros danger vient sans doute du fait que la victime, dans la plupart des cas, ne
s’aperçoit strictement de rien.
Figure 18 : scénario d’une attaque de type XSS (réf : « Zend Framework bien développer en
PHP »figure 11-1, p 205)
 Protection :
Il faut protéger, avec des caractères d’échappement, toutes les chaînes provenant de
l’extérieur de l’application et à destination de l’affichage dans le navigateur, de manière à
éviter l’introduction de code JavaScript. Pour ce faire, heureusement, Zend_View possède un
mécanisme de filtres permettant d’automatiser cette tâche. Et, afin d’éviter d’éventuelles
failles concernant les jeux de caractères, il faut spécifier à la vue le jeu de caractères utilisé
pour l’affichage (ex : $view->setEncoding('UTF-8');).

3.4.3.2. Injection SQL
L’injection SQL consiste, pour un pirate, à détecter une entrée mal validée et passée de
manière brute à une requête.
 Protection :
La première règle de sécurité concernant les bases de données est relative aux
utilisateurs clients de celle-ci. PHP est client du SGBD et il doit uti-liser un compte utilisateur
limité :
 ne vous connectez pas avecPHP en super-utilisateur (root);
 en parallèle, connectez-vous avec un utilisateur client ayant le moins de droits
possibles.
Par exemple, l’utilisateur MySQL que PHP utilise dans notre application ne
possède aucun droit d’administration (grant, create, drop...). Il peut uniquement lire, écrire et
supprimer des données de la base. Il n’a accès à aucune autre base de données.
Ensuite, il est nécessaire de protéger, avec une fonction d’échappement, les

caractères des données dynamiques provenant de l’utilisateur. Le composant Zend_Dbse
charge de cela. En effet, Zend Framework utilise systématiquement les requêtes préparées
pour interroger le SGBD. Aussi une conversion PHP (parsing) représente la meilleure
sécurité :
$this->fetchAll($select()->from($this, 'id')
->where('idClient = ?', (int)$idClient)
)->toArray();
3.4.3.3. Sessions et Cookies
Les sessions et les cookies sont extrêmement convoités sur le Web. Une session est
simplement un état entre un client et un serveur. De manière à ce que le serveur puisse
reconnaître ses clients, il va leur envoyer un identifiant unique à leur première connexion.
Ceux-ci vont alors se charger de renvoyer cet identifiant à chaque requête. Ainsi, la
persistance est établie, puisque le serveur peut connaître à chaque instant quel client s’est
connecté, et ainsi restaurer ses données de session.
Attaque d’une session :

L’identifiant est très souvent transmis via le serveur, matérialisé du côté du client par
un cookie. Si un pirate met la main sur le cookie d’identifiant de session d’une victime, il peut
alors s’approprier sa session, se faire passer pour elle et voler une grande partie de ses
données.
Il existe tout une panoplie de moyens pour récupérer l’identifiant de session d’un utilisateur
légitime par un pirate, le plus classique étant en utilisant JavaScript et en exploitant une faille
XSS, comme nous l’avons vu il y a peu.
 Protection :
Idéalement, la protection contre la prédiction de session nécessiterait de renouveler

l’identifiant de session à chaque requête HTTP. Ce système est lourd, car il oblige à générer
un identifiant et à renvoyer un cookie à chaque requête.

Concernant notre application, nous avons choisi une protection simple : nous
renouvelons l’identifiant de session à chaque connexion:
if ($identification->isValid()) {
// ...
// régénération de l’id de session
Zend_Session::regenerateId(); }
3.5. Captures écran

3.5.1. Capture écran back office
Dans ce qui suit, nous allons faire une illustration présentant quelques interfaces de
du back office de notre application.
2.4.1.1. interface pour l’authentification
Cette interface permet aux utilisateurs de l’application d’accéder à leurs profiles selon
leurs fonctions à savoir administrateur, manager ou responsable technique.
Figure 19 : interface d’authentification des utilisateurs de back office.
2.4.1.2. Interface d’accueil de l’administrateur
Espace administration permet la gestion complète de l’application à savoir la gestion

des utilisateurs, la gestion des clients, la gestion des produits (packs d’hébergement et les
noms de domaine), la gestion des nouvelles commandes, le paiement annuel et permet aussi
de consulter un tableau de bord qui illustre quelques statistiques sur les ventes (nombre des
commande selon la catégorie du produit, évolution du chiffre d’affaire d’INFO PRO). Cette
interface affiche le manu des fonctionnalités de l’administrateur.

Figure 20 : Interface d’accueil de l’administrateur
2.4.1.3. Interface permettant la gestion des utilisateurs
Cette interface permet l’ajout, la modification, la suppression, la recherche et

l’affichage de toutes les informations des utilisateurs de l’application.
Figure 21 : Interface permettant la gestion des utilisateurs
L’ajout d’un nouvel utilisateur et la modification des informations (login, mot de

passe, le rôle, activer/désactiver …) des ceux qui sont déjà insérés se fait respectivement par
les deux boutons « Ajouter » et « Edite ». Un clic sur l’un de ces boutons, une fenêtre sous
forme du « popupWindow » s’affiche comme représente la figure ci-dessous :

Figure 22 : Fenêtres ajouter/modifier utilisateur
Les boutons « Ajouter » et « Edit » font appel à la même fenêtre, sauf que le premier
initialise tous les champs et le deuxième remplit les champs par les anciennes informations de
l’utilisateur à modifier.
2.4.1.4. Page de la gestion des clients et leurs factures
La figure suivante illustre la page qui permet la gestion des clients aussi que l’archive
des factures du client sélectionné.
Figure 23 : Page pour la gestion des clients et leurs factures

Cette page contient deux tableaux : Liste des clients et liste des factures
correspondante au client sélectionné.
Tableau des clients : Permet la validation ou bien la suppression d’un client et facilite la
recherche avec les mécanismes de classification (ordre alphabétique) et de filtrage sur les
différents colonnes et selon plusieurs critères (ex : la figure suivante donne le résultat d’une
recherche sur les clients de la ville d’Agadir ayant id inférieur à 9, avec un ordre alphabétique
descendant du nom).
Figure 24 : sélection multicritère des clients
Le filtrage se fait en ligne et animé par l’AJAX pour fournir les résultats de la
recherche instantanément.
Tableau des factures : Affiche toutes les factures correspondantes au client sélectionné, aussi
donne la possibilité d’explorer les lignes de chaque facture. Ce tableau nous permet aussi de
faire les traitements sur les facture comme (Réglé, annuler, imprimer, supprimer des lignes
dans la facture) et bien sûr facilite la recherche et la sélection multicritères (dans l’exemple ci-
dessous : la sélection des facture du mois août 2013).
Figure 25 : sélection des facture selon « numéro facture »
2.4.1.5. interface permettant la gestion des produits (Packs & domaine)
Cette interface permet l’ajout, la suppression et la modification des produits. Les

modifications peuvent se faire en ligne (c’est-à-dire directement sur les cellules du tableau,

avec double clic sur la cellule à modifier) ou bien avec le bouton « Edit » si la modification
comporte sur plus d’une colonne pour envoyer la requête une seule fois.
Figure 26 : interface de gestion des produits
2.4.1.6. Interface de la gestion des nouvelles commandes
Dans cette interface, l’administrateur ou bien le responsable technique reçoit la liste

des nouvelles commandes envoyées par des clients (soit des nouveaux inscrits ou des clients
fidèles).
Figure 27 : Interface de gestion des nouvelles commandes

Le premier tableau de la figure ci-dessus est le résultat d’une jointure sur trois tables
de la base de données, à savoir table «LigneCommandes » (pour extraire les informations sur
la commande elle-même : référence, date commande, date expiration, nom de domaine …),
table « clients » (pour extraire les informations sur le client expéditeur de la commande) et
table « produits » (pour tirer les informations sur le produit : catégorie, libelle, prix de vente,
frais annuel). Ainsi le responsable technique peut contacter les clients expéditeurs des
nouvelles commandes pour compléter le processus de paiement. Le deuxième tableau sert à la
facturation des commandes réglées, en sélectionnant un ou plusieurs lignes de commande du
même client, puis remplissant les champs de l’en-tête de la facture à créer puis on clique sur
le bouton «Créer facture ».
2.4.1.7. Interface pour le règlement annuel des commandes expirées
De même que la page des nouvelles commandes, l’interface suivante permet le

règlement annuel des commandes expirées (ayant la date du dernier paiement est dépassé par
un an) :
Figure 28 : Interface des règlements annuels
2.4.1.7. Statistiques
Ce paragraphe illustre les graphes du tableau de bord offert par l’application aux utilisateurs
selon leurs rôles (droit d’accès) : L’admin peut voir tous les statistiques, en revanche le
responsable technique ne peut pas consulter l’évolution de chiffre d’affaire.

Figure 29 : histogramme d’évolution de chiffre d’affaire d’Info Pro
Figure 30 : Nombre des commandes par domaine

Figure 31 : nombre des commandes par packs d’hébergement
3.3.2. Capture écran du portail web : front office
2.4.2.1. Page d’accueil
Figure 32 : Page d’accueil du portail web
Cette page c’est la première page qui s’affiche aux internautes. Elle contient un slider
de la publicité et un moteur de recherche DNS qui tolère aux visiteurs de vérifier la
disponibilité d’un nom de domaine.

2.4.2.2. Page exposant les packs d’hébergement fourni par INFO PRO
La figure suivante met en vue les packs d’hébergement fournis par INFO PRO.
Figure 33 : page des packs d’hébergement
2.4.2.3. Page exposant les domaines fournis par INFO PRO
La figure suivante met en vue les domaines fournis par INFO PRO.
Figure 34 : Page des domaines

2.4.2.4. Page d’authentification
Figure 35 : formulaire d’authentification et d’inscription du client
Le client peut se connecter via le premier formulaire s’il est déjà inscrit, sinon il peut
s’inscrire dans le deuxième formulaire.
Le formulaire d’enregistrement vérifie toutes les validations des champs nécessaires

coté navigateur-client avant d’envoyer les données au serveur PHP à savoir « Apache » :
Comme les champs obligatoire, la taille limitée de certaines valeurs (login et le mot de passe
limiter entre 4 et 20 caractères). Aussi le test sur la validité l’email, le code postal et le
numéro de téléphone.
NB. L’inscription se fait via une commande.

2.4.2.5. Interface pour la récupération de mot de passe
Si le client oublie son mot de passe, il peut demander de récupérer un nouveau via le
formulaire suivant :
Figure 36 : formulaire de récupération d’un nouveau mot de passe.
Un lien de confirmation pour la saisi d’un nouveau mot de passe sera envoyé à
l’adresse émail du client après la validation de cet émail vis-à-vis à celui enregistré dans la
base de données.
2.4.2.6. Formulaire pour le changement de mot de passe
Cette interface permet de changer le mot de passe du client connecté.
Figure 37 : formulaire de changement de mot de passe

2.4.2.7. Formulaire de détail panier
Figure 38 : Formulaire de détail panier
2.4.2.5. Formulaire de la validation du panier
Figure 39 : Formulaire de la validation du panier
Conclusion :
La première partie de ce chapitre est consacré à la description de la technologie et

l’architecture appliqué dans le développement de ce projet. La deuxième partie est dédiée à
l’aspect sécurité de l’application et la dernière partie réservée à l’illustration de quelques
captures écran du produit logiciel réalisé.

Conclusion générale
Le but de mon projet de fin d’étude consiste à concevoir et réaliser une plate-forme
permettant la vente des espaces d’hébergement, noms de domaine et la gestion des
commandes.
Pour mettre en œuvre ce projet, nous avons amené, dans un premier lieu, une étude
conceptuelle du sujet afin de dégager les différents modules de cette application ainsi qu’une
étude des outils et technologies susceptibles de convenir à sa réalisation. Dans un second lieu,
nous avons fait une analyse et conception du projet en se basant sur la modélisation en UML.
Un certain nombre de diagrammes ont été élaborés afin de mieux découper le projet, ce qui a
facilité sa mise en œuvre.
Finalement, on a implémenté les différents modules de cette application. Le résultat de

cette dernière phase répond aux exigences et aux besoins déjà cités dans ce rapport.
Au cours de ce projet, j’ai eu l’opportunité de mettre en exercice, différentes

connaissances acquises durant ma carrière universitaire. De plus, j’ai pu aussi, renforcer mes
connaissances concernant différents concepts à savoir la technologie Zend PHP.
Durant la période de stage, j’ai pu aboutir aux objectifs fixés et aux recommandations
de l’organisme d’accueil. Ses résultats obtenus ont donné lieu à d’autres perspectives qui
peuvent êtres le sujet de mes futurs recherches :
 Renforcer le référencement du site web ;
 Application d’une stratégie de sauvegarde des données ;

Références
Ouvrages :
 [Taoufiq GADI, Omar EL BEGGAR, Brahim BOUSETTA], GUIDE DE LA
MODELISATION EN UML, 165p ;
 [Pascal Roques, Franck Vallée], UML en action, 398p ;
 [Julien Pauli, Guillaume Ponçon], Zend Framework Bien développé en PHP,

446p ;
 [Guillaume Rossolini] Cours de PHP 5, 164p ;
 [Site du Zéro]Réalisez votre site web avec HTML5 et CSS, 322p ;
Sites web :
 framework.zend.com/manual/1.12/fr/manual.html [Site official de Zend
Framwork]
 www.z-f.fr [La communauté francophone du Zend Framwork]
 www.zend.com [Site officiel de Zend]
 www.jqwidgets.com [Site officiel de la bibliothèque iQWidgets]
 www.developez.com [Club des développeurs]
 http://www.domainname.com/ [Exemple de site pour l’enregistrement de nom

de domaine]
 http://www.lws.fr/hebergement_web.php [Hébergement site web & Nom de

domaine]

ANNEXES
Annexe A : Exemple de la facture de paiement.
Annexe B: Packs d’hébergement web fournis par Info Pro 2013.

Annexe A
Exemple de la facture de paiement

Annexe B
Hébergement web de la Sté Info Pro 2013
Frais d'installation HT
(payable une seule fois) 100,00 100,00 100,00 200,00 300,00 300,00 500,00
Prix annuel HT* 500,00 750,00 1200,00 1600,00 2500,00 3500,00 5000,00
HÉBERGEMENT Perso Basic Startup MySQL Pro DynamiX Gold
Espace disque en Mo 120 250 400 600 1000 1500 3000
250 500 1000 1500 5000 10000 Illimite
Trafic alloué par mois en Go 6 12 24 30 36 48 60
20 40 60 100 Illimite Illimite Illimite
Hébergement de sites Web
supplémentaires non non non non non 10 Illimite
Hébergement de sous
domaines non non non non non 10 Illimite
Compte FTP principal oui oui oui oui oui oui oui
Serveur FTP personnalisé oui oui oui oui oui oui oui
Statistiques Web détaillées non oui oui oui oui oui oui
Tableau de bord Cpanel en
français oui oui oui oui oui oui oui
Support technique illimité oui
(email, téléphone et extranet) oui oui oui oui oui oui
MESSAGERIE
Adresse E-mail POP3 4 8 20 20 40 100 200
10 10 30 30 60 100 Illimite
Répondeur E-mail 4 8 20 20 40 100 Illimite
Redirection E-mail 4 8 20 20 40 100 Illimite
Liste de diffusion Mailman 2 2 2 2 2 2 Illimite
Serveur Mail POP3 & SMTP oui oui oui oui oui oui oui
Service Webmail nouveau ! oui oui oui oui oui oui oui
Antivirus intégré nouveau ! oui oui oui oui oui oui oui
Protection Anti-
Spam nouveau ! oui oui oui oui oui oui oui
EXTENSIONS
Ms FrontPage non oui oui oui oui oui oui
MULTIMÉDIA
Flash / Shockwave oui oui oui oui oui oui oui
Real Audio-Video oui oui oui oui oui oui oui
PROGRAMMATION AU NIVEAU SERVEUR
PHP 5 non oui oui oui oui oui oui
PERL 5.8.8 non oui oui oui oui oui oui
CGI-BIN non oui oui oui oui oui oui
SSI non non non oui oui oui oui
Pages d'erreurs
personnalisées non non non oui oui oui oui
Zend nouveau ! non oui oui oui oui oui oui
Python 2.2 nouveau ! non non non oui oui oui oui

BASE DE DONNÉES
MySQL 5 non non non 2 4 20 Illimite

Rapport PFE Karim ZIKY

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 Karim ZIKY

Transféré par

Droits d'auteur :

Formats disponibles

2013

Projet de fin d’étude

Ingénieur d’État en Informatique

Développement d’une plate-forme pour la

Soutenu par : Karim ZIKY

Mr. Youssef BALOUKI

Année Universitaire 2012-2013

A ma chère mère que j’adore, à mon cher père que j’aime

Projet fin d’étude 2012/2013 1

Au terme de ce travail, je tiens à exprimer ma profonde gratitude et mes sincères remerciements à

Projet fin d’étude 2012/2013 2

Projet fin d’étude 2012/2013 3

Projet fin d’étude 2012/2013 4

RIA Rich Internet Application

Projet fin d’étude 2012/2013 5

Figure 3 : Planning du projet………………………………………………………...………..16

Figure 4 : Diagramme d’acteurs……………………………………...………….....................20

Figure 5 : Diagramme de contexte statique……………………………….………………….21

Figure 6 : Diagramme de cas d’utilisation…………..………………………………………. 23

Figure 7 : Diagramme de séquence boite noire du use case

« Règlement des nouvelles commandes »……………………………..…………………….. 30

Figure 9 : Diagramme de séquence boite noire du use case « authentification/inscription

Figure 10 : Diagramme de séquence boite noire du use case « Commander packs

Figure 11 : Diagramme d’activité système du use case « Commander pack

Figure 12 : Diagramme de transaction vue globale pour le back office…………………….. 34

Figure 13 : Diagramme de transaction vue globale pour le front office…………………….. 34

Figure 14 : Diagramme de classe………………………………………………………….… 35

Figure 15 : diagramme boite blanche du cas d’utilisation « commander packs

Figure 16 : Diagramme de classe de conception…………………………………………...…38

Figure 17 : architecture en couche selon le modèle MVC……………………………………41

Figure 20 : Interface d’accueil de l’administrateur…………………………….......…………55

Figure 21 : Interface permettant la gestion des utilisateurs………………………...…………55

Figure 22 : Fenêtres ajouter/modifier utilisateur…………………………...…………………56

Projet fin d’étude 2012/2013 6

Figure 24 : sélection multicritère des clients………………………………………………....57

Figure 25 : sélection des facture selon « numéro facture »…………………………………...57

Figure 26 : interface de gestion des produits…………………………………………………58

Figure 27 : Interface de gestion des nouvelles commandes…………………………………..58

Figure 28 : Interface des règlements annuels…………………………………………………59

Figure 29 : histogramme d’évolution de chiffre d’affaire d’Info Pro………………………...60

Figure 30 : Nombre des commandes par domaine……………………………………………60

Figure 31 : nombre des commandes par packs d’hébergement………………………………61

Figure 32 : Page d’accueil du portail web…………………………………………………….61

Figure 33 : page des packs d’hébergement…………………………………………………...62

Figure 34 : Page des domaines………………………………………………………………..62

Figure 35 : formulaire d’authentification et d’inscription du client…………………………..63

Figure 36 : formulaire de récupération d’un nouveau mot de passe………………………….64

Figure 37 : formulaire de changement de mot de passe………………………………………64

Figure 38 : Formulaire de détail panier……………………………………………………….65

Figure 39 : Formulaire de la validation du panier…………………………………………….65

Projet fin d’étude 2012/2013 7

Tableau 1 : Exigences de front office…………………………………………………….......19

Tableau 2 : Exigences de back office…………………………………………………………19

Tableau 3 : Intentions des acteurs de front office…………………………………………….22

Tableau 4 : Intentions des acteurs de back office…………………………………………….22

Tableau 5 : Description textuel du haut niveau du use case «Commander/Transférer

des noms de domaine(ND) »………………………………………………………………….24

Tableau 9 : description textuelle bas niveau d’use case

« Commander des noms de domaine (ND) »…………………………………………………26

Tableau 11 : description textuelle bas niveau d’use case « Règlement annuel»……………..27

Tableau 12 : scénario nominal du cas d’utilisation « commander nom de domaine »

Tableau 13 : Scenario nominal « commander packs d’hébergement»+ « valider les

Tableau 14 : Arborescence des fichiers de l’application front office………...………………48

Tableau 15 : Code source de quelques classes modèles……………………………………...50