|
Dédicaces
A mon père Nasser El Dine et ma mère
Fatheya
A qui je dois ce que je suis
Qu'ils trouvent dans ce
travail,
le fruit de leurs sacrifices consentis pour mon
éducation,
l'expression de mon amour et ma gratitude pour la
bienveillance avec laquelle ils m'ont
toujours entouré.
Que Dieu
leur préserve bonne santé et longue vie.
A mes trois
frères Amine, Souheil et Hakou
A mes chers amis Souheil et Meyssa qui
m'ont tant aidé et soutenue pour effectuer ce travail.
A tous mes
meilleurs ami(e)s.
Remerciements
Il m'est spécialement agréable, d'exprimer toute ma
reconnaissance envers les personnes qui de près ou de loin m'ont
apporté leur soutien dans la réalisation de ce projet.
Au premier rang mon encadrant Monsieur Taieb
Mohamed, son aide, ses conseils précieux, ses critiques
constructives, ses explications et suggestions pertinentes qui m'ont
donné un coup d'aide pour réaliser mon application
convenablement, ainsi que Monsieur Leslie Sauvage de m'avoir
accordé la chance d'effectuer mon stage au sein de leur entreprise
Myiweb.
Je tiens à remercier mon superviseur à l'Ecole
Nationale des Sciences de l'Informatique Monsieur Tarak
chneyna, souhaitant qu'il trouve ici l'expression de mon gratitude
pour sa patience, sa disponibilité, ses critiques, son assistance et
suivi incessant par ses directives.
Je remercie de même ma famille pour leur grande
attention, leur grand soutien et encouragement tout au long de
l'évolution de ce travail, et de l'énorme intérêt
qu'ils ont montré envers ce sujet. Enfin ma gratitude s'exprime pour les
membres de jury pour avoir accepté de juger mon travail.
Table des matières
|
Introduction générale
1 Cadre Général
|
1
3
|
|
1.1
|
Présentation générale de l'organisme
|
3
|
|
1.2
|
Présentation du cadre du sujet
|
4
|
|
|
1.2.1 Critique de l'existant
|
4
|
|
|
1.2.2 Les solutions proposées
|
5
|
|
|
1.2.3 La messagerie Web 2.0
|
6
|
|
|
1.2.4 La Solution retenue et le travail demandé
|
9
|
|
|
1.2.5 Cycle de développement
|
9
|
|
2
|
Étude Théorique
|
11
|
|
2.1
|
Le service de messagerie
|
11
|
|
|
2.1.1 Définitions
|
11
|
|
|
2.1.2 Les différents agents d'un serveur de messagerie
|
12
|
|
2.2
|
Structure générale et format d'un message
|
12
|
|
|
2.2.1 Structure d'un message
|
12
|
|
|
2.2.2 Les formats standards de messages : la norme MIME
|
14
|
|
|
2.2.3 Les principaux types de MIME
|
15
|
|
|
2.2.4 Les types de codage
|
15
|
|
2.3
|
Les différents protocoles utilisés
|
15
|
|
|
2.3.1 Le protocole Simple Mail Transfert Protocol (SMTP)
|
16
|
|
|
2.3.2 Les protocoles Post Office Protocol (POP) et Internet
Message Access
|
|
|
|
Protocol (IMAP)
|
16
|
|
|
2.3.3 Le protocole Secure Socket Layer (SSL)
|
17
|
|
3
|
Analyse et spécification des besoins
|
19
|
3.1 Analyse Fonctionnelle 19
3.1.1 Les besoins de l'internaute 19
3.1.2 Les besoins de l'administrateur 21
3.2 Analyse Non Fonctionnelle 21
3.3 Spécification détaillée 22
3.3.1 Les diagrammes de cas d'utilisation 22
3.3.2 Diagrammes de séquences 26
4 Conception 35
4.1 Conception architecturale 35
4.1.1 Architecture trois-tiers 35
4.1.2 Architecture MVC 37
4.2 La correspondance entre le modèle MVC et l'application
39
4.3 Conception détaillée 40
4.3.1 Conception de la base de données 40
4.3.2 Décomposition en paquetage 42
4.3.3 Diagrammes des classes 43
4.3.4 Cinétique de l'application 49
5 Réalisation 51
5.1 Environnement de travail 51
5.1.1 Environnement matériel 51
5.1.2 Environnement logiciel 51
5.2 Choix techniques 52
5.2.1 Choix d'Aptana 52
5.2.2 Choix du PHP5 (PHP Hypertext Preprocessor) 52
5.2.3 Choix d'AJAX 53
5.2.4 Script SHELL 53
5.2.5 Choix de Mysql 53
5.3 Diagramme de déploiement 54
5.4 Implémentation 55
5.4.1 Interfaces de l'application 55
5.5 Chronogramme 63
Netographie 66
Annexes 68
A Le protocole LDAP 68
A.1 Introduction à LDAP 68
A.2 Présentation de LDAP 68
A.3 L'arborescence d'informations (DIT) 69
A.4 Les attributs des entrées 69
A.5 Consulter les données 70
B RSS - Syndication de contenu 71
B.1 Introduction au RSS 71
B.2 Utilisation de canaux RSS 71
B.3 Proposer un fll RSS 72
B.4 Exploiter les flls RSS sur un site 72
Liste des figures
1.1 Du Web 1.0 au Web 2.0 7
1.2 Le modèle Incrémental 10
2.1 Acheminement d'un message électronique 13
2.2 La couche protocolaire TCP/IP 16
2.3 Pile protocolaire TCP/IP avec SSL 17
3.1 Diagramme de cas d'utilisation de gestion des e-mails 23
3.2 Diagramme de cas d'utilisation des services secondaires
24
3.3 Diagramme de cas d'utilisation de l'administrateur 26
3.4 Diagramme de séquence de navigation entre les pages
sécurisées 27
3.5 Diagramme de séquence de l'authentification d'un
utilisateur 28
3.6 Diagramme de séquence de l'inscription d'un internaute
29
3.7 Diagramme de séquence de présentation des
courbes de statistique 30
3.8 Diagramme de séquence de la modification d'un profil
31
3.9 Diagramme de séquence d'envoi des e-mails 32
3.10 Diagramme de séquence de calcul des statistiques
33
3.11 Diagramme de séquence de la planification du robot
d'envoi 33
4.1 Les couches d une architecture trois tiers 36
4.2 Interactions entre le modèle, la vue et le
contrôleur[N9] 38
4.3 L'application en MVC 39
4.4 Modèle Entité Association 41
4.5 Diagramme de paquetage 42
4.6 Diagramme de classe : Gestion des interfaces 44
4.7 Diagramme de classe : Gestion des données 46
4.8 Diagramme de classe : gestion des processus 48
4.9 Diagramme de transition de la partie client 49
4.10 Diagramme de transition de la partie administrative 50
5.1 Diagramme de déploiement 54
5.2 Interface d'authentification de l'internaute 55
5.3 Interface d'inscription rapide 56
5.4 Interface d'inscription complète 57
5.5 Interface d'accueil 58
5.6 Interface de la boite de réception 59
5.7 Interface du Carnet d'adresse 60
5.8 Interface du calendrier 61
5.9 Interface de gestion des paramètres 62
5.10 Chronogramme 63
Liste des tableaux
|
1.1
|
Comparaison le type d'usage
|
5
|
|
1.2
|
Comparaison selon les caractéristiques techniques
|
6
|
|
1.3
|
Comparaison selon sur le plan technique [N2]
|
8
|
|
A.1
|
Les principales opérations de LDAP
|
70
|
Introduction générale
I
L ne fait désormais plus aucun doute que les
technologies de l'information et de la communication représentent la
révolution la plus importante et la plus innovante qui a marqué
la vie de l'humanité en ce siècle passé. En effet, loin
d'être un éphémère phénomène de mode,
ou une tendance passagère, ces technologies viennent nous
apporter de multiples conforts à notre mode de vie, car
ils ont révolutionné le travail des individus par leur
capacité de traitement d'information, d'une part, et de rapprochement
des dimensions espace/temps, d'une autre.
Parmi ces TIC (Technologies de l'information et de la
communication), la messagerie électronique est rapidement
développée dans les organisations aux cours de ces dix
dernières années, par sa facilité d'utilisation et son
utilité perçue. Désormais, elle représente l'outil
de travail le plus utilisé.
Voulant profiter des divers avantages de cette technologie, la
société Myiweb a décidé d'offrir à ses
clients (plus de six milles inscris) un service de messagerie.
C'est dans ce cadre que s'intègre ce projet qui
consiste dans l'étude, la conception et le développement d'un
système de messagerie électronique destinée au public. Le
but principal de ce service est de garantir l'écriture ou la lecture des
courriers et de permettre aux utilisateurs d'accéder facilement à
leurs comptes.
Puisque l'administration de cette application de messagerie est
importante, nous avons conçu à développer une application
web qui permet de gérer tout le système.
Le présent rapport s'articule autour de cinq chapitres.
Dans le premier chapitre, nous présentons le cadre général
de notre application et les différentes solutions proposées en
partant d'une étude approfondie de l'existant. Le deuxième
chapitre, s'intéresse à l'étude des applications de
messagerie électronique ainsi les différents protocoles de
communication. Nous consacrons le troisième chapitre à la partie
analyse et spécification d'opportunité qui comporte une
illustration des besoins fonctionnels et non fonctionnels et une
spécification en se basant sur le langage UML(Unified Modeling
Language).
réalisation, précise l'environnement du travail
et présente les principales interfaces de l'application. Finalement nous
clôturons le rapport par une conclusion générale qui
présente le bilan de ce projet et les éventuelles perspectives.
Des annexes nécessaires pour une meilleure compréhension du
contenu et pour un meilleur repérage des mots clefs sont aussi
disponibles.
Introduction
Dans le cadre de la préparation à
l'intégration au milieu professionnel, ce stage a été
lancé. Il s'agit d'un projet de fin d'études de l'École
Nationale des Sciences de l'informatique(ENSI).Ce projet s'est
déroule au sein de Myiweb en une période de
quatre mois.
Dans ce chapitre nous mettons notre travail dans son contexte.
En premier lieu nous présentons une vue globale sur l'organisme
d'accueil, ensuite nous introduisons brièvement le sujet en expliquant
le travail demandé.
1.1 Présentation générale de
l'organisme
Myiweb est une entreprise
spécialisée dans l'édition et la mise en oeuvre de
logiciels et de progiciels fondé en France en 2002 sous le nom du
CyberCreate. Elle poursuit ses activités en Tunisie en
juin 2008 sous le nom de Myiweb.
Elle conçoit, développe et commercialise des
solutions Extranet et Intranet qui aident à développer
graduellement ses activités dans le domaine de chat et de messagerie.
Cette entreprise mène depuis plusieurs années
des actions visant à l'expérimentation et au déploiement
des outils de Messagerie Instantanée et l'Internet Relay Chat dans son
réseau de communication virtuelle et de messagerie.
Elle a dominé le secteur de chat par une architecture
web fermée. En effet, son développement commercial a
été accéléré par son réseau de
rencontre dans le site web Chat-Land. Etant donné que l'activité
de l'entreprise est totalement orientée dans le développement et
l'amélioration de qualité de service offerte par son site,
MYIWEB a adopté une organisation souple adaptée
aux enjeux de l'entreprise, formée de sept équipes :
· Staff AJAX (Notre équipe)
Améliore durablement la qualité de service offerte par
le site de l'entreprise. Il corrige les bugs découverts, conçoit
et développe des applications Intranet et Extranet.
· Staff JAVA Suivre l'évolution
des technologies java, développe des modules optimisant l'Applet,
cherche des solutions efficaces réduisant les problèmes java
rencontrés par les chateurs.
· Staff TCL Surveille les serveurs IRC
de l'entreprise, développe des robots intelligents et animateurs des
salons de chat. Il se charge aussi de l'implémentation des modules de
statistiques sur IRC.
· Staff Marketing Concevoir des
stratégies et des outils commerciaux augmentant le nombre de
connectés et augmentant le chiffre d'affaire de l'entreprise.
· Staff Service contrôle qualité
Teste et vérifie la stabilité et la conformité de
toutes les applications développées avec les exigences des
cahiers de charge.
· Staff Référencement Adapte
des stratégies gardant un bon référencement du site dans
les annuaires de l'internet.
· Staff juridique Gère le dossier
juridique de l'entreprise (les contrôles, les ressources humaines, les
différents noms de domaine, les abus sur le site, etc.)
1.2 Présentation du cadre du sujet
1.2.1 Critique de l'existant
Actuellement, l'entreprise Myiweb utilise le
système de messagerie Afterlogic. Il s'agit d'un client webmail
Open Source, basé sur la nouvelle technologie AJAX et un SGBD de type
MySQL. Il est indéniable que cette solution peut satisfaire d'une part
les besoins de l'entreprise et de l'internaute d'une autre.
Cependant, il existe plusieurs contraintes de tenir cette
solution. En premier lieu, elle est assez lente de point de vue temps
d'exécution. Elle n'est pas capable de servir un grand nombre
d'internautes. Également, elle est ni stable et ni maintenable.
Par ailleurs, cette solution ne possède pas une
interface d'administration et manque de confidentialité de certains
comptes. En second lieu, l'entreprise paye plus de cinq milles euro par an pour
corriger les bugs de ce webmail.
Le but de ce projet est, ainsi, d'étudier et de
développer une application de mailing accessible par internet. Pour ce
faire il faut d'abord étudier les différentes solutions possibles
et les comparer pour connaitre les points forts et faibles de chacune.
1.2.2 Les solutions proposées
Il existe deux solutions possibles pour notre
problème, la première consiste dans un client léger (une
messagerie web) tandis que la deuxième est un client lourd (un logiciel
de messagerie). En dépit des points communs qu'ont ces deux
alternatives, elles diffèrent l'une de l'autre. La principale
différence entre un webmail et un logiciel de messagerie est la suivante
:
Lors de l'utilisation d'une messagerie Web, par exemple un
compte Yahoo! Mail, nous pouvons simplement accéder
à ce site, à l'aide d'un navigateur et à partir de
n'importe quel ordinateur disposant d'une connexion Internet, autrement dit
dans le monde entier.
Par contre l'utilisation d'un logiciel de messagerie est plus
compliquée et elle nécessite un niveau peu avancé en
informatique. D'abord l'utilisateur doit installer ce logiciel, est le
configure avec les serveurs IMAP et SMTP. Nous notons à titre d'exemple
des logiciels de messagerie << Microsoft Outlook/Outlook Express,
Eudora ou Netscape Mail>>
1.2.2.1 Comparatif entre les clients de
messagerie
Il existe plusieurs logiciels de courrier
électronique. Tous ces derniers sont semblables pour ce qui est des
fonctions essentielles (écrire, envoyer et recevoir des e-mails). Les
différences se font notamment sur les points suivant :
· La plateforme supportée (Windows, Mac ou
Linux).
· Le prix.
· La lourdeur du programme et la facilité
d'utilisation.
· Quelques fonctions avancées telles que la
planification des tâches, le partage d'agenda ou la gestion de listes de
diffusion. Enfin chacun a son propre style et sa propre interface.
Nous avons comparé les principaux logiciels, selon le
type d'usage et les caractéristiques techniques qui nous paraissent les
plus importantes.
Type d'usage
|
Logiciels de messagerie
|
Usage normal
|
Windows Live Mail
|
Thunderbird
|
Usage poussé
|
The Bat!
|
|
IncrediMail
|
Usage professionnel
|
Outlook
|
Pegasus Mail
|
|
Tableau 1.1 -- Comparaison le type d'usage
|
Win
|
Mac
|
Linux
|
Prix
|
IMAP
|
Confid
|
RSS
|
Cal
|
News
|
Windows Live Mail
|
X
|
|
|
g
|
X
|
|
X
|
X
|
X
|
Outlook Express
|
X
|
X
|
|
g
|
X
|
|
|
|
X
|
Outlook
|
X
|
X
|
|
p
|
X
|
X
|
X
|
X
|
|
Thunderbird
|
X
|
X
|
X
|
g
|
X
|
|
X
|
X
|
X
|
Eudora
|
X
|
X
|
|
g
|
X
|
|
|
|
|
FoxMail
|
X
|
|
|
g
|
X
|
X
|
|
|
|
The Bat!
|
X
|
|
|
p
|
X
|
|
|
|
|
IncrediMail
|
X
|
|
|
g/p
|
X
|
|
|
|
|
Pegasus Mail
|
X
|
|
|
g
|
X
|
|
X
|
|
|
Opera Mail
|
X
|
X
|
X
|
g
|
X
|
|
|
|
X
|
Postbox
|
X
|
X
|
X
|
p
|
X
|
|
|
X
|
|
|
Tableau 1.2 -- Comparaison selon les
caractéristiques techniques
· Confid : protection des comptes ou des mails par mot de
passe.
· Cal : fonction calendrier- agenda.
· g :gratuit.
· p : payant.
1.2.3 La messagerie Web 2.0
D'abord nous introduisons le web2.0 et les nouveaux avantages
des applications web. 1.2.3.1 Le web 2.0
Initialement, le monde du web était restreint à
des pages web dites statiques autrement dit à contenu presque constant
ou simplement Web1.0. Ceci satisfaisait les besoins de l'internaute qui se
connectait à internet pour consulter des informations et rarement pour
en ajouter lui-même. Le web 1.5 ou web dynamique fut apparut comme une
première évolution à travers des pages
générées à partir d'une base de données en
constante mise à jour. Une première évolution qui a
ultérieurement offert le fameux Web 2.0 ou plus proprement appelé
le Web Social.
La figure(1.1) illustre bien l'évolution du web1.0 au
web 2.0 depuis les années 90 jusqu'aux années 2000. Nous
constatons une notable évolution du flux d'informations, du nombre
d'internautes et plus précisément ceux qui contribuent à
la construction des données, et un taux d'échange saillant
[N1].
Figure 1.1 -- Du Web 1.0 au Web 2.0
1.2.3.2 Comparatif entre les messageries web
existant
Personne ne peut nier ou même négliger le grand
progrès du service web de messagerie électronique ces
dernières années, tant au point de vue fonctionnalités
qu'au point de vue ergonomie. Les raisons de cet essor sont les miracles des
technologies nouvellement utilisées dans le Web2.0, comme le
Javascript et ses déclinaisons parmi lesquelles le fameux
AJAX.
En effet, ces innovations ajoutent des fonctionnalités
proches d'une application de messagerie. Des courriels qui s'affichent d'un
simple clic, sans qu'il ait besoin de recharger entièrement la page, la
possibilité d'effectuer des glisser-déposer à la souris
d'un dossier à l'autre, la généralisation des actions
accessibles par un clic droit de la souris : tout semble désormais
permis dans ce navigateur Web qui était, il n'y a pas si longtemps que
ça, si statique.
Au cours d'une étude comparative, nous visons les
trois leaders du Web : Yahoo, Microsoft et Google. Cette
comparaison entre les webmail publique est basée sur le plan technique,
l'ergonomie, l'efficacité, le design et les fonctions
additionnelles[N2] :
les PDA1 (iPhone, telephone mobiles de 3G), leurs
capacités de stockage et des services divers tels que le service
autorisant la redirection automatique.
Webmail
|
POP
|
IMAP
|
SMTP
|
Red
|
Mob
|
iPhone
|
PJ
|
Cap
|
Yahoo! Mail
|
X
|
|
X
|
X
|
X
|
X
|
25Mo
|
Illimitée
|
Gmail
|
X
|
X
|
X
|
X
|
X
|
|
25Mo
|
7 Go
|
Hotmail
|
X
|
|
X
|
|
X
|
|
10Mo
|
1Go
|
|
Tableau 1.3 -- Comparaison selon sur le plan
technique [N2]
· POP : boîte consultable avec un logiciel de
messagerie, par le protocole POP.
· IMAP : boîte consultable avec un logiciel de
messagerie, par le protocole IMAP.
· SMTP : service doté d'un serveur SMTP.
· Red. : Service autorisant la redirection automatique
(transfert ou forwarding) des messages vers une autre adresse e-mail. Pratique
si vous devez changer d'adresse.
· Mob. : le webmail dispose d'une version adaptée
pour téléphone mobile.
· iPhone : une application iPhone dédiée est
disponible.
· PJ. : taille maximale des pièces jointes à
l'envoi.
· Cap. : capacité maximale (messages et
pièces jointes) stockée sur le compte.
· Ergonomie :
L'ergonomie a pour objectif de s'assurer que ce qui
apparaît sur l'écran, via l'interface graphique, est
compréhensible pour l'utilisateur, voire agréable.
Gmail : En arrivant sur le marché en
2004, Google a joué la carte de l'innovation, en privilégiant la
simplicité et en remplaçant le classement des courriels par
dossiers par un système plus souple d'étiquettes. Tout aussi
efficace, cette organisation peut cependant déstabiliser.
Yahoo : inspire ses interfaces classiques
d'un logiciel de messagerie en autorisant l'ouverture simultanée de
plusieurs messages, les clics droits de la souris et les
glisserdéposer.
Microsoft : l'agencement des fenêtres,
volets et bandeaux de publicité sème la confusion. Et les
redimensionnements de page s'avèrent catastrophiques. La plupart des
usagers avouent d'ailleurs préférer l'ancienne version
Hotmail[N2].
· Design:
Il faut ici vraiment parler de l'interface de Windows Live
Hotmail (le webmail de Microsoft), ce service intègre des
désignes et des effets artistiques, il nous offre la possibilité
de personnaliser les couleurs des fonds, les emplacements des composants et les
styles de navigation entre les pages. Au contraire de celle de Gmail, qui n'est
pas renversante, mais elle a le mérite d'être claire, propre et
cohérente. Nous avouons un petit faible pour l'interface de Yahoo! Mail
bêta, qui ne fait aucune faute de goût: sobre
1. Un PDA (Personal Digital Assistant, littéralement
assistant numérique personnel, aussi appelé organiseur) est un
ordinateur de poche composé d'un processeur, de mémoire vive,
d'un écran tactile et de fonctionnalités réseau dans un
boîtier compact d'extrêmement petite taille.
et élégante.
· Fonctions inédites :
L'apport du webmail2.0 ne se limite heureusement pas à
l'interface. Certaines fonctionnalités, comme la correction
orthographique directement depuis le champ de saisie des messages, ont ainsi
fait leur apparition. C'est Microsoft qui propose l'outil le plus
évolué dans le domaine, puisque le correcteur agit en temps
réel comme dans Word, alors qu'il faut demander son intervention chez
les concurrents après avoir tapé son texte. Autres fonctions : la
lecture de fils RSS (Yahoo!) ou l'intégration d'un service de chat
(Gmail). Chacun affiche ainsi sa petite particularité.
1.2.4 La Solution retenue et le travail
demandé
Nous avons choisi le webmail plutôt qu'une solution
logicielle car ses avantages sont multiples. Il s'agit tout d'abord la
liberté d'accéder à vos mails depuis n'importe quel poste,
n'importe quel FAI (Fournisseur accès Internet), n'importe quel
pays dans le monde. C'est aussi la sécurité de savoir ses
données (pièces jointes) et sa correspondance stockés sur
des serveurs à distance.
Notre but est l'étude, la conception et le
développement d'une application web de messagerie destinée au
public.
Ce système doit, en premier lieu, fournir toutes les
fonctionnalités de base d'un webmail telles
que l'envoie et la
réception des e-mails. Pourtant, il doit mettre à la disposition
de l'utilisateur
d'autres services additionnels pour que notre
système pour faire puisse entrainer les internautes.
En second lieu, il doit avoir la capacité de
gérer un grand nombre des connectés en même temps, pour
cela il faut prendre en considération les règles d'optimisation
afin de réduire le temps de réponse et d'alléger la charge
des serveurs de l'entreprise.
En outre, notre webmail doit avoir un espace d'administration
qui facilite la gestion des ressources telles que les comptes utilisateurs et
les boites mails, ainsi que l'impression des courbes de statistique, la
configuration du système, la distribution de charge entre les serveurs
d'envois et le filtrage des flux entrant et sortant (antispameur).
1.2.5 Cycle de développement
Nous avons choisi le modèle Incrémental pour
gérer le cycle de vie de notre projet parce qu'il permet de gérer
les projets de développement de grands systèmes. Il
découpe le système en domaines qui sont traités
individuellement sur le modèle en cascade.
Figure 1.2 -- Le modèle Incrémental
Conclusion
Tout au long de ce chapitre, nous avons essayé de
mettre au point le cadre général de notre travail. Pour ce faire
nous avons tout d'abord précisé l'organisme d'accueil qui
s'avère un élément fondamental dans l'environnement du
projet et dont s'ensuit une étude comparative entre les solutions du
mailing existantes. Finalement nous avons exposé la Travail
demandé.
|
CHAPITRE2
|
|
|
Étude Théorique
|
Introduction
L'échange de courriers électroniques est
certainement l'un des plus vieux et des plus utilisés de tous les
services offerts sur Internet. Dans ce chapitre, nous allons faire
l'état de l'art de ce service. Une première partie sera
consacrée à la définition de quelques notions relatives au
service de messagerie, sa structure et les différents agents
intervenants. En une seconde partie, nous allons nous intéresser aux
différents protocoles régulant la messagerie
électronique.
2.1 Le service de messagerie 2.1.1
Définitions
Un service de messagerie, dans sa forme la plus basique, est
un service permettant essentiellement l'échange de messages textuels
entre les différents utilisateurs enregistrés (ayant une adresse
électronique valide) et connectés à un réseau
informatique, que ce soit en local ou sur internet.
Mais, actuellement, les services de messagerie sont beaucoup
plus riches et présentent beaucoup plus de fonctionnalités;
à savoir l'intégration des pièces jointes (joindre un
fichier quelconque au message envoyé), la gestion du courrier
indésirable (les spams) et la manipulation des listes de diffusion
(permettre l'envoi multiple).
Cet échange de messages peut s'effectuer en
différé, c'est-à-dire il n'est pas nécessaire que
le destinataire soit connecté au moment de l'envoi, son message sera
enregistré sur un serveur et il pourra le consulter
ultérieurement. On parle à ce moment de la messagerie
électronique simple.
Par ailleurs, l'échange peut aussi se faire en temps
réel et on parle à ce moment de la messagerie
instantanée.
logiciel qui assure les différentes fonctionnalités
du service de messagerie. Dans la partie suivante nous allons présenter
les différents agents constituant un service de messagerie.
2.1.2 Les différents agents d'un serveur de
messagerie
2.1.2.1 Le Mail User Agent (MUA)
Le MUA est un programme qui sert à lire, écrire,
répondre, recevoir des messages [B1]. Il présente
généralement une interface graphique riche à la
disposition de l'utilisateur. Le MUA ne permet pas de transférer le
message au destinataire, pour cela il fait appel à un MTA.
2.1.2.2 Le Mail Transfert Agent (MTA)
Le MTA est un programme dédié à la
transmission des messages entre utilisateurs que ce soit en local ou sur des
machines distantes. En général on a un seul MTA par
machine[B1]. Un MTA reçoit, habituellement par le protocole
SMTP 1, les emails envoyés soit par des clients de messagerie
électronique (MUA), soit par d'autres MTA. Son rôle est de
redistribuer ces courriers à des Mail Delivery Agent (MDA) et/ou
d'autres MTA.
Parmi les principaux MTA on trouve Qmail, Postfix, Sun ONE
Messaging Server, Send-mail et Sendmail Switch (version commerciale de
Sendmail).
2.1.2.3 Le Mail Delivery Agent (MDA)
Un Mail Delivery Agent marque la fin de l'acheminement du mail
vers la destination[B1]. C'est le MDA qui reçoit le message du
MTA et se charge de le placer dans la boite aux lettres de l'utilisateur. Il
doit donc gérer les éventuels problèmes tels qu'un disque
plein ou une boite aux lettres corrompue et doit impérativement signaler
au MTA toute erreur de délivrance. Parmi les MDA connus nous citons :
Procmail2, maildrop, etc. La figure (2.1) présente le chemin
suivi par un message
2.2 Structure générale et format d'un
message
2.2.1 Structure d'un message
Les messages électroniques échangés
obéissent à une structure bien définie. Ils sont
organisés en trois parties, à savoir : L'entête : elle
comporte plusieurs informations générales mais très utiles
lors de l'envoi du message. Voici quelques exemples des champs de
l'entête :
1. Le Simple Mail Transfer Protocol (littéralement
<< Protocole simple de transfert de courrier >>),
généralement abrégé SMTP, est un protocole de
communication utilisé pour transférer le courrier
électronique vers les serveurs de messagerie électronique.
2. Procmail est un outil permettant principalement de filtrer
des messages électroniques
Figure 2.1 -- Acheminement d'un message
électronique
· Le champ FROM : contient l'adresse
source du message.
· Le champ RECEIVED : chaque machine qui
reçoit un message ajoute son adresse dans ce champ.
· Le champ DATE : contient la date d'envoi
du message.
· Le champ TO : contient la liste des
destinataires séparés par des virgules.
· Le corps : il contient les
données utiles, c'est à dire le contenu du message à
transmettre. Il doit être impérativement séparé de
l'entête par une ligne vide. Il faut faire attention à ne pas
insérer des caractères non imprimables tels que les espaces ou
les tabulations sinon la structure du message sera erronée.
· L'enveloppe : par analogie avec
l'enveloppe du courrier traditionnel, elle contient
essentiellement des informations concernant le destinataire
et l'expéditeur. Si le message est destiné à plusieurs
destinataires, chacun a sa propre enveloppe mais la même entête et
le même corps du message. L'enveloppe est envoyée
séparément du reste du message. Elle sert à router le
message vers une destination bien déterminée.
2.2.2 Les formats standards de messages : la norme
MIME
Pour des raisons de compatibilité, plusieurs normes
ont été élaborées afin d'uniformiser la structure
des messages et de définir des formats standards. Parmi ces standards
nous citons Multipurpose Internet Mail Extension ou MIME. Les principaux
apports du standard MIME [N3] sont :
· Possibilité d'avoir plusieurs objets
(pièces jointes) dans un même message.
· Une longueur de message illimitée.
· L'utilisation de jeux de caractères (alphabets)
autres que le code ASCII.
· L'utilisation de texte enrichi (mise en forme des
messages, polices de caractères, couleurs, etc.)
· Des pièces jointes binaires (exécutables,
images, fichiers audio ou vidéo, etc.) comportant éventuellement
plusieurs parties.
MIME utilise des directives d'entête spécifiques
pour décrire le format utilisé dans le corps d'un message, afin
de permettre au client de messagerie de pouvoir l'interpréter
correctement :
· MIME-Version : Il s'agit de version du
standard MIME utilisée dans le message. Actuellement seule la version
1.0 existe.
· Content-type : Décrit le type et
les sous-types des données.
· Content-Transfer-Encoding :
Définit l'encodage utilisé dans le corps du message.
· Content-ID : Représente un
identificateur unique de partie de message.
· Content-Description : Donne des
informations complémentaires sur le contenu du message.
· Content-Disposition : Définit les
paramètres de la pièce jointe, notamment le nom associé au
fichier grâce à l'attribut filename.
2.2.3 Les principaux types de MIME
Le type MIME, utilisé dans l'entête
Content-Type, est utilisé pour typer les documents attachés
à un courrier[N3]. Les principaux types de données,
appelés parfois " types de données discrets ", sont les suivants
:
· text: données textuelles
lisibles. text/rfc822 [RFC822] ; text/plain [RF646] ; text/html [RF854].
· image: données binaires
représentant des images numériques image/jpeg , image/gif ,
image/png.
· audio : données numériques
sonores audio/basic; audio/wav.
· video : données vidéos :
video/mpeg.
· application : données binaires
autres; application/octet-stream; application/pdf
2.2.4 Les types de codage
Pour transférer des données binaires, MIME propose
cinq formats de codage pouvant être utilisé dans l'entête
Transfer-encoding:
· 7bit : format texte codé sur 7
bits (pour les messages non accentués).
· 8bit : format texte 8 bits.
· quoted-printable : format
Quoted-Printable, recommandé pour les messages utilisant un alphabet
codé sur plus de 7 bits (présence d'accents par exemple).
· base64 : format Base 64,
recommandé pour l'envoi de fichiers binaires en pièce jointe.
· binary: format binaire.
2.3 Les différents protocoles
utilisés
Figure 2.2 -- La couche protocolaire TCP/IP
2.3.1 Le protocole Simple Mail Transfert Protocol
(SMTP)
C'est un protocole de communication utilisé pour
transférer le courrier [N4] vers les serveurs de messagerie
électronique. Il est dédié exclusivement à l'envoi
des messages vers un serveur mais pas à la réception. Comme son
nom l'indique, il s'agit d'un protocole simple à utiliser.
On doit commencer par spécifier l'expéditeur du
message puis, la ou les destinations. Après vérification de leur
existence, le corps du message est transféré. SMTP utilise par
défaut le port 25 pour ses échanges.
Le logiciel sendmail est l'un des premiers serveurs de
messagerie électronique à utiliser SMTP. Aujourd'hui, la
quasi-totalité des clients email peuvent utiliser SMTP pour envoyer
leurs messages.
2.3.2 Les protocoles Post Office Protocol (POP) et
Internet Message Access Protocol (IMAP)
Bien qu'ils assurent la même finalité, leurs
manières de procéder par défaut diffèrent. Pour
POP, il se connecte au serveur, télécharge tout les messages sur
la machine locale en les marquant comme nouveaux messages, les efface du
serveur et se déconnecte. L'utilisateur peut alors consulter ses
messages hors connexion.
Pour IMAP, la consultation des messages se fait sur le serveur,
rien n'est téléchargé en local et rien n'est effacé
du serveur sauf suite à la demande explicite de l'utilisateur.
2.3.3 Le protocole Secure Socket Layer (SSL)
Á la différence des protocoles
précédents, SSL n'est pas spécifique aux applications de
messagerie. Il s'agit d'un protocole de sécurisation des communications
sur un réseau informatique, notamment internet. En effet, avec le
développement d'internet et l'apparition de nouveaux domaines
d'activités assez sensibles tels que les transactions bancaires et le
e-commerce, le besoin d'une communication confidentielle et
sécurisée s'est fait sentir. Dès lors, plusieurs
mécanismes et protocoles de sécurisation ont vu le jour. L'un des
premiers à être développé et des plus
répandus aujourd'hui est SSL.
Développé à l'origine par Netscape
3, il a été nommé TLS pour Transport Layer
Security par l'IETF (Internet Engineering Task Force) après le
rachat du brevet de Netscape en 2001. Par abus de langage on parle aujourd'hui
de SSL pour désigner indifféremment SSL ou TLS. Le protocole SSL
s'intercale entre la couche transport et la couche application de la pile
protocolaire TCP/IP (figure 2.3).
Figure 2.3 -- Pile protocolaire TCP/IP avec SSL
3. Netscape est une entreprise d'informatique
américaine qui a été pionnière du World Wide Web
avec son navigateur Web Netscape Navigator. L'entreprise a existé
uniquement de 1994 à 2003, et en tant que filiale d'AOL à la
fin.
Situé au dessous de la couche applicative, SSL peut
être utilisé indépendamment du type d'application. Il peut
être utilisé au dessous de http pour sécuriser simplement
des pages inter-net, au dessous de SMTP, IMAP ou POP pour sécuriser les
échanges de messagerie,etc.
Bref, c'est un protocole de sécurisation de toute sorte
de trafic de données sur un réseau. SSL fonctionne suivant un
mode client-serveur. Il fournit quatre objectifs de sécurité
importants :
· L'authentification du serveur.
· La confidentialité des données
échangées (session chiffrée).
· L'intégrité des données
échangées.
· De manière optionnelle, l'authentification du
client avec un certificat numérique.
Pour son fonctionnement, SSL utilise une combinaison de
systèmes de cryptologie4 à clé
symétrique et à clé publique. Le premier système
est beaucoup plus rapide mais le second offre un meilleur niveau de
sécurité. Ainsi, SSL tire profil des deux. Une session SSL
commence avec un échange de messages appelé la phase de "
handshake ". Cette phase permet, en premier temps, au serveur de s'authentifier
auprès du client moyennant sa clé publique, puis le client et le
serveur coopèrent pour produire une clé symétrique qui
sera utilisée pour crypter, décrypter tout les échanges de
la session en cours.
Conclusion
Ainsi nous avons fait le tour des différents
éléments théoriques impliqués dans la
réalisation d'une solution de messagerie. Nous avons commencé par
présenter qu'est ce qu'un service de messagerie électronique, son
architecture et les différents agents intervenant dans son
fonctionnement. Nous avons ensuite étudié le format d'un message
électronique et présenté le standard MIME qui normalise la
structure et le codage des messages. Et finalement, nous avons
présenté une multitude de protocoles intervenant dans les
communications entre les différents agents du service de messagerie.
Maintenant, il reste à voir les différents outils technologiques
offerts pour la réalisation d'une telle solution.
CHAPITRE3Analyse et spécification des
besoins
Introduction
Afin de garantir la réussite et l'efficacité de
notre projet, il faut à ce stade du travail définir avec
précision la bordure de la solution à développer. Ceci
inclut l'énumération des différents services que notre
système est supposé offrir aux différents utilisateurs.
Dans ce chapitre, nous commençons par définir
les besoins fonctionnels et non fonctionnels de notre solution. Puis, en se
basant sur cette analyse, nous dégageons une spécification
détaillée de la solution retenue.
3.1 Analyse Fonctionnelle
Nous distinguons deux types des acteurs : L'internaute et
l'administrateur. Nous présentons dans ce qui suit les besoins de chaque
type d'acteur
3.1.1 Les besoins de l'internaute
Le client doit pouvoir jouir des fonctionnalités
suivantes :
· S'authentifier selon le Protocol LDAP 1
(Lightweight Directory Access Protocol).
· Récupérer le mot de passe oublié. Si
l'internaute oublie son mot de passe, il sera automatiquement redirigé
vers une page de récupération de ce dernier.
· Envoyer des messages selon le protocole POSTFIX 2.
1. Voir annexes
2. Postfix est un serveur de messagerie électronique
et un logiciel libre développé par Wietse Venema et plusieurs
contributeurs. Il se charge de la livraison de courriers électroniques
(courriels) et a été conçu comme une alternative plus
rapide, plus facile à administrer et plus sécurisée que
l'historique Sendmail.
· Joindre plus qu'un fichier de types différents.
· Composer des messages en html.
· Sauvegarder automatiquement des mails et des contacts
dans des dossiers personnalisés.
· Envoyer des e-mails à des adresses multiples (TO,
CC et BCC).
· Organiser et personnaliser les dossiers de messagerie.
· Glisser-déposer (drag 'n drop) de message d'un
répertoire à un autre.
· Marquer les messages (lu/non lu/pièce
jointe/récent).
· Recevoir et visualiser des messages à travers le
protocole IMAP avec un rafraichissement automatique de la boite de
réception.
· Créer des carnets d'adresse (Adresse book)
interactifs (Enregistrement automatique des contacts, création des
groupes, importation et exportation des carnets d'adresse de différents
formats).
· Créer et partager un agenda personnel ou un agenda
d'un groupe.
· Convertir les e-mails en des taches ou des
rendez-vous.
· Avoir un service de messagerie Instantanée.
· Avoir un espace de profil où le client peut mettre
des informations supplémentaires telles que ses photos et son statut.
· Avoir l'accès aux profils de ses amis.
· Avoir un moteur de recherche sur les profils dans les
serveurs IM (Instant messaging) propre à l'entreprise Myiweb
ainsi que sur les autres serveurs existants.
· Intégrer des informations provenant des autres
sites grâce aux flux RSS (Rich Site Summary) , c'est la technologie qui
permet d'exporter automatiquement les nouveautés diffusées sur un
site choisi précédemment.
· Avoir un affichage de la météo via le web
service "The Weather Channel Interactive" 3.
3.1.2 Les besoins de l'administrateur
Toujours après authentification, l'administrateur devra
avoir accès aux opérations suivantes :
· Installer et configurer le webmail : L'administrateur
peut consulter les fichiers de configuration à travers des interfaces
web et y introduire les modifications nécessaires selon ses besoins sans
tenir compte de la régénération des fichiers de
configurations ni du redémarrage de service.
· Gérer les noms des domaines sachant que
l'administrateur peut créer plus qu'un domaine.
· Faire un "mapping" d'adresse. En effet,
l'administrateur peut créer un alias sur une boite aux lettres de telle
sorte que les mails qui sont envoyés vers cette boite sont
redirigés vers la boite alias.
· Contrôler manuellement la sécurité.
En d'autre termes, l'administrateur peut effectuer un filtrage implicite sur
des domaines ou également des adresses IP (Internet
Protocol).
· Gérer les comptes des inscrits.
· Offrir la possibilité de créer des boites
aux lettres pour les utilisateurs tout en fixant un quota sur disque.
· Supprimer des boites aux lettres.
· Modifier le quota d'une boite aux lettres.
· Créer un nouveau groupe et associer un utilisateur
au groupe désiré.
· Avoir une liste noire dans laquelle il met les adresses
IP correspondant à des clients indésirables.
3.2 Analyse Non Fonctionnelle
Un besoin non fonctionnel est une restriction ou une
contrainte qui pèse sur un service du système, telle que les
contraintes liées à l'environnement et à
l'implémentation, les exigences en matière de performances, les
dépendances de plate-forme, la facilité de maintenance,
l'extensibilité et la fiabilité.
· L'ergonomie des interfaces:
La solution doit présenter une interface ergonomique
englobant toutes les fonctionnalités
offertes. La manipulation de
l'interface ne doit pas nécessiter des connaissances poussées
en informatique, elle doit être simple et claire afin de
s'adapter aux connaissances informatiques de notre utilisateur.
· Robustesse et maintenabilité :
L'application doit permettre le stockage des informations
concernant tous les internautes inscrits et les différents traitements
utiles pour le fonctionnement correct, ainsi qu'assurer une gestion exhaustive
des erreurs.
· Sécurité :
Notre application doit garantir à l'utilisateur
l'intégrité des données c'est-à-dire qu'elles
gardent leur forme et leur contenu original. En outre, elle doit
protéger la confidentialité en assurant la validité de
l'identité de l'utilisateur. Ceci peut se faire entre autres par le
moyen d'un mot de passe assurant le contrôle d'accès. Notre
système doit également certifier la disponibilité qui
s'avère primordiale pour bon fonctionnement.
· Fiabilité et rapidité :
Notre système doit garantir la rapidité et la
fiabilité de la recherche des informations, ainsi qu'une gestion
optimale des ressources.
3.3 Spécification
détaillée
Afin de détailler les besoins
précédemment spécifiés, une bonne réflexion
autour du développement de notre application par un langage de
modélisation comme l'UML (Unified Modeling Language)
s'avère nécessaire. Nous utilisons alors dans la suite les
diagrammes des cas d'utilisation et les diagrammes de séquences comme
moyens de notre spécification.
3.3.1 Les diagrammes de cas d'utilisation
Les diagrammes de cas d'utilisation illustre les relations
entre les cas d'utilisation du système et l'ensemble des acteurs qui
agissent sur le système[B2]. Ainsi ces diagrammes permettent de
décrire le comportement du système de point de vue
utilisateur.
Une première réflexion pour La
réalisation des diagrammes de cas d'utilisation pour
notre
application, nous amène à distinguer entre deux acteurs :
L'internaute et l'administrateur.
3.3.1.1 Diagramme de cas d'utilisation de
l'internaute
Pour des raisons de visibilité, nous avons opté
pour la séparation des cas d'utilisation pour les fonctions principales
(voir figure 3.1) et un autre pour les fonctions secondaires (voir figure
3.2).
Figure 3.1 -- Diagramme de cas d'utilisation de
gestion des e-mails
La gestion des e-mails: La
fonctionnalité principale du système est l'échange des
messages. Ainsi, un utilisateur peut écrire un message et l'envoyer
directement à la liste des destinations choisies, dans ce cas il peut
aussi en garder une copie (l'enregistrer), il a également la
possibilité d'écrire un message et l'enregistrer pour un envoi
ultérieur. Une fois un message reçu, l'utilisateur peut
visualiser son contenu (le lire) et éventuellement envoyer une
réponse. Il doit pouvoir distinguer entre les messages lus et les
messages non lus. Un utilisateur gère aussi sa boite aux lettres en
créant ses propres dossiers personnels et en y archivant ses messages
à sa
guise. Évidemment, il peut déplacer les mails
de la boite de réception vers un dossier ou les déplacer d'un
dossier à un autre. Il peut, par ailleurs, supprimer des mails
temporairement (vers la corbeille) ou définitivement.
Figure 3.2 -- Diagramme de cas d'utilisation des
services secondaires
Les services secondaires : Pour que notre
webmail procure plus d'interactivité, il faut qu'il fournisse d'autres
fonctionnalités additionnelles, utiles et pratiques telles que le carnet
d'adresse, le calendrier, l'espace profil, la météo et les news.
L'utilisateur peut créer un carnet d'adresse qui lui permet de conserver
des informations sur des personnes ou des groupes.
Chaque entrée du carnet d'adresses comprend, au moins,
le pseudonyme d'une personne ou d'un groupe et son adresse électronique
complète. Le carnet d'adresses permet également d'inclure un
pseudonyme dans la liste des destinataires, et d'envoyer un nouveau message.
L'internaute éprouve également le besoin d'un calendrier
personnalisable, performant et simple à utiliser. Le calendrier est
imprimable ou exportable vers le format PDF (Portable Document
Format).
Il lui permet de gérer facilement tous ses rendez vous
et ses taches, et de bien organiser le planning d'une journée, d'une
semaine ou d'un mois complet. Affin de lui garantir une communication plus
rapide et conviviale, un utilisateur a une liste des amis qu'avec les quels il
peut échanger des messages instantanés. Bien évidemment
tous les cas d'utilisations cités dans figure 3.2 requièrent au
préalable une phase d'authentification. Un utilisateur sans compte
valide n'a accès à aucun service.
Pour obtenir la météo en temps réel
d'une ville donnée, l'utilisateur doit sélectionner la ville, le
Web service
Weather.com retourne alors les
données météo qu'il fait présentement dans la ville
choisie.
Enfin l'internaute a la possibilité de suivre les
actualités dans les domaines qui lui intéressent (politique,
monde, société, sports, écologie), consulter et rechercher
dans des différentes sources d'information.
La technologie RSS permet de concentrer les sources
d'information et de filtrer les données pour ne garder que les
informations utiles. Pour ce faire, l'utilisateur mentionne simplement
l'adresse URL du fichier RSS de chaque site, et définit les filtres afin
que celui-ci n'affiche que les articles intéressants 4.
3.3.1.2 Diagramme de cas d'utilisation de
l'administrateur
L'administrateur est un utilisateur distingué. Il
jouit, exclusivement des privilèges différents de celle de
l'internaute. Il est le seul à pouvoir filtrer les comptes utilisateurs.
Certaines informations sont modifiables uniquement par l'administrateur tel que
les noms de domaines, les valeurs de quota et les configurations des
serveurs.
Les privilèges de l'administrateur lui accordent aussi
le droit exclusif de configurer le robot d'envoi. Il est à noter que les
différentes tâches que l'administrateur est supposé
réaliser s'accomplissent intégralement sur le serveur. Bien
évidemment, l'administrateur doit être aussi identifié par
un login et un mot de passe (voir la figure 3.3).
Figure 3.3 -- Diagramme de cas d'utilisation de
l'administrateur
3.3.2 Diagrammes de séquences
Ces diagrammes sont la représentation graphique des
interactions entre les acteurs et le système selon un ordre
chronologique. Ces interactions sont ainsi montrées dans le cadre d'un
scénario d'un diagramme des cas d'utilisation et ils ont pour but de
décrire comment se déroule les actions entre les acteurs ou
objets[B2].
Ainsi, plusieurs diagrammes de séquences peuvent
être représentés pour décrire le déroulement
des différentes actions entre nos acteurs. D'autre coté,
plusieurs diagrammes de séquences peuvent se rassembler, nous nous
contenterons alors de présenter uniquement les diagrammes de
séquences distincts.
3.3.2.1 Scénario de navigation entre les pages
sécurisées
Le diagramme de séquence intitulé <<
navigation entre les pages sécurisées >> et
illustré par la figure 3.4 clarifie bien le scénario d'une
navigation sécurisée entre les pages protégés
telles que la page d'authentification. Le navigateur joue le rôle de
l'intermédiaire entre l'internaute et notre système. Il constitue
la plateforme qu'à travers laquelle le client exprime sa volonté
d'exécuter une action. En contre partie, c'est au système de
lancer les différentes requêtes et d'en renvoyer le
résultat à travers le navigateur.
Le client initie le scénario d'une navigation par la
demande d'une page html. Le navigateur envoie ainsi une requête https
à la couche ssl (Secure Socket Layer) ayant le rôle
de chiffrer et de protéger la confidentialité des données
qui. A son tour, cette couche lance une connexion du serveur Apach5.
Ce dernier se charge de trouver la page demandée et de la renvoyer au
navigateur ou elle s'affiche au client.
Figure 3.4 -- Diagramme de séquence de
navigation entre les pages sécurisées
5. Apache HTTP Server, souvent appelé Apache, est un
logiciel de serveur HTTP produit par l'Apache Software Foundation. C'est le
serveur HTTP le plus populaire du Web. C'est un logiciel libre avec un type
spécifique de licence, nommée licence Apache.
3.3.2.2 Scénario de l'authentification d'un
utilisateur
Figure 3.5 -- Diagramme de séquence de
l'authentification d'un utilisateur
L'accès au système se fait par le biais d'une
adresse mail et d'un mot de passe. Ainsi, lors de l'appel de l'application, la
page d'authentification se charge. L'utilisateur saisie ses paramètres
personnels qui, après la validation, sont envoyés par l'objet
<<Auth-session >> vers l'objet <<Pear-db
>>.
Ce dernier a comme rôle de filtrer et d'exécuter
la requête. Par la suite, deux cas de figure se posent : L'échec
ou la réussite de l'authentification. Dans le premier cas, l'internaute
sera directement rediriger vers la page << mot-passe-oublier
>>, à travers cette page il peut récupérer son
mot de passe en répondant à son question de
sécurité. S'il a encore échouer l sera automatiquement
rediriger vers la page d'inscription.
3.3.2.3 Scénario de l'inscription d'un
internaute
L'internaute doit choisir un des deux types d'inscription,
rapide ou complète. Une inscription rapide consiste à remplir un
formulaire qui demande le minimum d'informations, telles que le nom,
l'âge et le sexe. Cependant, une inscription complète exige des
informations additionnelles, telles que la question secrète et sa
réponse, une photo, le numéro de téléphone.
Figure 3.6 -- Diagramme de séquence de
l'inscription d'un internaute
3.3.2.4 Présentation des courbes de
statistique
Figure 3.7 -- Diagramme de séquence de
présentation des courbes de statistique
L'administrateur peut consulter les différentes
statistiques effectuées sur plusieurs événements tels que
les trafics d'envoi et de réception des e-mails, le pourcentage des
clients actifs et les taux d'envoi du robot.
Pour faciliter cette tache, nous avons consacré toute une
interface dédiée à la représentation des courbes de
statistiques d'une manière plus lisible et compréhensible que les
tableaux.
Derrière cette interface, il existe un traitement
effectué par les objets Collecteur, Statcompteur et
Analiseur-courbe.
Le Collecteur est responsable de la collection des informations
prévenant d'une base de données ou des fichiers log.
Le stat-compteur a le rôle de centraliser les
calculs ainsi que d'effectuer les opérations convenables pour avoir des
résultats utiles à l administrateur.
3.3.2.5 Scénario de la modification d'un
profil
Figure 3.8 -- Diagramme de séquence de la
modification d'un profil
L'utilisateur a la possibilité de modifier ses
informations personnelles. Pour ce faire, il saisit les changements à
effectuer et en validant le changement, ses paramètres seront
modifiés automatiquement sans l'intervention de l'administrateur.
3.3.2.6 Scénario d'envoi des e-mails
Ce diagramme de séquence illustre les interactions
d'un utilisateur avec le système lors de l'envoi d'un message.
Après l'écriture d'un message, l'utilisateur choisit les
destinataires qui peuvent être choisis depuis le carnet d'adresses. Lors
de la confirmation d'envoi d'un message, le serveur SMTP/POP vérifie
l'existence du destinataire et stocke le message dans un répertoire soit
la boite de réception du destinataire.
Figure 3.9 -- Diagramme de séquence d'envoi
des e-mails
3.3.2.7 Scénario de calcul des
statistiques
L'administrateur peut consulter les statistiques
effectuées sur les activités de l'internaute. Nous tenons par
exemple dans la figure 3.10, le robot envoi des e-mails à l'internaute.
Lorsque l'internaute ouvre sa boite de réception, nous détectons
les actions qu'il effectue, telles que l'ouverture, le déplacement ou la
suppression de cet e-mail. L'administrateur a l'intérêt de savoir
tous ces types d'actions donc nous les sauvegardons.
Figure 3.10 -- Diagramme de séquence de calcul
des statistiques
3.3.2.8 Scénario de la planification du robot
d'envoi
Figure 3.11 -- Diagramme de séquence de la
planification du robot d'envoi
ce dernier. L'objet <<crontab>>
est une instance de la classe responsable de l'interaction entre ces deux
acteurs. Cette classe simule les crontab6 sur le système
linux.
Conclusion
Dans ce chapitre, nous avons cerné les objectifs du
système cible. Ces objectifs doivent tenir compte des problèmes
de la solution existante. Cette phase va nous utile pour bien élaborer
le modèle de conception de l'application. Dans le prochain chapitre nous
aborderons la partie conception décrivant la modélisation des
besoins exprimés dans cette section.
6. Crontab est le nom du programme sous Unix (ou Linux) qui
permet d'éditer des tables de configuration du programme cron. Par
extension, on appelle souvent cron (ou cron job en anglais) toute application
lancée à horaire fixe.
Introduction
Après avoir achevé la phase d'analyse et
spécifications, nous entamons maintenant la phase de conception. Cette
étape s'avère primordiale pour le déroulement du projet et
à pour but de détailler les tâches à entreprendre
ainsi que de préparer le terrain pour l'étape de
réalisation.
Pour ce faire, nous présentons une conception
générale de l'application suivie d'une conception plus
détaillée présentant le schéma de la base de
données utilisée. Ensuite nous détaillons les
différents modules de l'application aussi bien que les relations entre
ces modules moyennant un diagramme de paquetage et un diagramme de classe.
Enfin, nous exposons la cinétique de l'application.
4.1 Conception architecturale
Tout système d'informations nécessite la
réalisation de trois groupes de fonctions : le stockage des
données, la logique applicative et la présentation. Ces trois
parties sont indépendantes l'une de l'autre : nous pouvons ainsi
modifier la présentation sans modifier la logique applicative.
La conception de chaque partie doit également être
indépendante. Toutefois la conception de la couche la plus basse est
utilisée dans la couche supérieure.
Ainsi, la conception de la logique applicative se base sur le
modèle de données, alors que la conception de la
présentation dépend de la logique applicative.
4.1.1 Architecture trois-tiers
Le principe d'une architecture trois-tiers consiste à
séparer la réalisation des trois parties vues
précédemment (stockage des données, logique applicative et
présentation)[N5].
permettant la réalisation classique d'un système
en architecture trois tiers sont les suivants :
· Système de base de données relationnel
(SGBDR) pour le stockage des données.
· Serveur applicatif pour la logique applicative.
· Navigateur web pour la présentation.
Figure 4.1 -- Les couches d une architecture trois
tiers
4.1.1.1 Couche de présentation
La présentation est la partie la plus
immédiatement visible par l'utilisateur. Au niveau de cette couche se
fait l'enregistrement, la récupération et la gestion des
données persistantes dans une base de données.
4.1.1.2 Couche Services
Cette couche réunit les traitements techniques, non
fonctionnels qui sont pris en charge par le Framework de
développement.
4.1.1.3 Objets métiers
Ces objets font le travail essentiel lié au domaine de
l'application. Ils nécessitent les traitements techniques, non
fonctionnels de la couche service pour gérer la sécurité,
le transactionnel, la concurrence.
4.1.1.4 La couche de persistance
Elle est composée de la base de données. Le
plus souvent on y ajoute une couche qui effectue la correspondance entre les
objets et la base de données. Souvent cette couche sert aussi de cache
pour les objets récupérés dans la base de données
et améliore donc les performances.
4.1.1.5 Avantages de l'architecture trois tiers
L'application trois tiers présente divers avantages à
savoir :
· La logique applicative est déplacée au
niveau du serveur d'application mais reste
programmée à l'aide
des mêmes technologies liées aux bases de données
relationnelles.
· L'application trois tiers présente divers
avantages à savoir : La logique applicative est déplacée
au niveau du serveur d'application mais reste programmée à l'aide
des mêmes technologies liées aux bases de données
relationnelles.
· La facilité de déploiement.
L'application en elle même n'est déployée que sur la partie
serveur (serveur applicatif et serveur de base de données). Le client ne
nécessite qu'une installation et une configuration minime. En effet, il
sufit d'installer un navigateur web compatible avec l'application pour que le
client puisse accéder à l'application. Cette facilité de
déploiement aura pour conséquence non seulement de réduire
le coût de déploiement mais aussi de permettre une
évolution régulière du système. Cette
évolution ne nécessitera que la mise à jour de
l'application sur le serveur applicatif.
· L'amélioration de la sécurité.
Avec une architecture trois-tiers l'accès à la base n'est
effectué que par le serveur applicatif. Ce serveur est le seul à
connaitre la façon de se connecter à cette base. Il ne partage
aucune des informations permettant l'accès aux données, en
particulier le login et le password de la base. Il est alors possible de
gérer la sécurité au niveau de ce serveur applicatif, par
exemple en maintenant la liste des utilisateurs avec leurs mots de passe ainsi
que leurs droits d'accès aux fonctions du système. On peut
même améliorer encore la sécurité par la mise en
place d'une architecture réseau interdisant totalement l'accès au
serveur de base de données pour les utilisateurs finaux[N6].
4.1.2 Architecture MVC
Le modèle MVC (Model/View/Controller) est un
schéma de programmation qui prend en compte toute l'architecture d'un
programme et classe les différents types d'objets qui composent
l'application dans 3 catégories:
4.1.2.1 La vue
ne doit être effectué dans cette partie. Mais, en
contre partie ils affichent les résultats provenant des objets "model"
et s'assurent que ces données sont correctement
affichées.[N7]
4.1.2.2 Le modèle
Les modèles représentent les données de
l'application (les bases de données en faisant par-tie) et
définissent la logique de manipulation de ces données. C'est dans
cette partie que vont s'effectuer les traitements, on ne s'occupe absolument
pas de la mise en forme mais bien des données seules. Dans une
application respectant les règles du modèle MVC, les
données les plus importantes seront encapsulées dans les objets
modèles.[N7]
4.1.2.3 Le contrôleur
Le contrôleur gère l'interaction avec
l'utilisateur. Ainsi c'est dans cette partie que va se réaliser
l'interaction entre la vue et le modèle. En effet, les objets
contrôleur reçoivent les requêtes utilisateur puis
détermine quelles parties des objets vues et modèles sont
requises. Ils constituent donc l'intermédiaire entre les deux autres
types d'objets.[N7]
4.1.2.4 Avantages du modèle MVC
Le modèle MVC impose donc une séparation totale
entre le traitement, l'interface et la communication entre ces deux parties.
Cela permet d'avoir non seulement des objets réutilisables pour d'autres
applications, mais aussi de pouvoir faire évoluer aisément son
programme. Ainsi, si l'on souhaite modifier sa base de données il suffit
de revoir son "model" et cela est valable pour le cas ou l'on souhaite changer
d'interface. Les 3 parties du model MVC sont réellement autonomes.
Aucunes d'elles ne s'occupent du fonctionnement de l'autre.[N8]
4.2 La correspondance entre le modèle MVC et
l'application
Grâce à la séparation en couches, la
souplesse, la maintenance et le développement de l'application se
trouveront grandement améliorés. Dans ce cadre, la figure 4.3 met
en évidence la conformité de notre application vis-à-vis
du modèle MVC. Le serveur SMTP/POP (couche métier) qu'on a
implémenté à l'aide des sockets 1, qui sont des
points de connexion pour la communication client-serveur, reçoit deux
types de requêtes.
· Le premier type consiste à la gestion des
messages à l'aide de PHPMAILER 2. Le Serveur
stocke les messages dans le disque dur qui est l'un des parties de la couche de
persistance.
· Le deuxième type consiste en des requêtes
SQL afin de garantir les différentes fonctionnalités
d'administration. Le serveur traite ces requêtes à l'aide de l'API
(Application Programmable Interface) Pear.MDB2 » 3 et
réalise les modifications dans la base de données.
Figure 4.3 -- L'application en MVC
1. Il s'agit d'un modèle permettant la communication
inter processus (IPC - Inter Process Communication) afin de permettre à
divers processus de communiquer aussi bien sur une même machine
qu'à travers un réseau TCP/IP.
2. La librairie PHPMailer permet d'envoyer des courriers
électroniques depuis une application PHP. Lorsqu'elle est
configurée pour utiliser la commande sendmail, une
vulnérabilité au niveau de la validation des champs saisis permet
l'exécution de code arbitraire à distance.
3. L'extension PEAR DB fournit une gamme de fonctions de
gestion de base de données permettant d'utiliser le même code quel
que soit la base de données. Cela permet, si vous décidez de
changer de BDD de ne pas être obligé de modifier de nouveau tous
vos scripts. Un simple changement de variable vous permettra de passer de MySQL
à Oracle par exemple.
4.3 Conception détaillée
Dans cette partie nous commençons par définir en
détail la base de données. Nous présentons par la suite
les différents modules du système avant d'exposer les diagrammes
des classes. Nous finissons par introduire la cinétique de
l'application.
4.3.1 Conception de la base de données
Le schéma 4.4 explique la conception de la base en
illustrant les relations entre les tables. L'entité USER
décrite par un id et un e-mail, le nom et le prénom de
l'internaute ainsi qu'un mot de passe pour l'authentification contient
également d'autres informations supplémentaires.
L'internaute peut consulter sa boite aux lettres (via la table
Mail), son calendrier (via la table
Calendrier) ainsi que le carnet d'adresse (via la table
Carnet-adresse).
Il peut également configurer des paramètres tels
que le langage et les couleurs du fond (par le biais de la table
Configuration), ou bien consulter l'historique des
commentaires. En outre, il peut créer ou joindre des groupes (via la
table Associa-groupe-client).
L'administrateur à son tour peut consulter certaines
tables à travers des interfaces web pour contrôler et gérer
l'application.
Présentation des tables:
· Table Mailbox : regroupe la liste des
boites de réception des clients.
· Table Mail: sauvegarde les emails
échangés par les internautes.
· Table Joindre : contient la liste des
jointures des fichiers de chaque utilisateur.
· ]Table Fichier : regroupe les fichiers
échangés entre les différents utilisateurs.
· ]Table Commentaire : enregistre les
commentaires et les statuts de chaque utilisateur.
· Table Calendrier : contient les
événements créés par les utilisateurs.
· Table Carnet-adresse : regroupe les
listes des contacte de chaque internaute.
· Table Configuration: sauvegarde les
paramètres de l'application choisis par l'utilisateur.
· Table Associa-groupe-client :
Représente l'association groupe client.
· Table Groupe : Contient la liste des
groupes utilisateur.
· Table Session: Sauvegarde la session
utilisateur.
Figure 4.4 -- Modèle Entité
Association
4.3.2 Décomposition en paquetage
Pour passer à la conception, nous nous fondons sur les
principes de l'approche orientée objet. À cet effet, nous passons
d'une structuration fonctionnelle via les cas d'utilisation, à une
structuration objet via les classes et les paquetages.
Vu le nombre de classes candidates défini dans notre
application, il s'avère important de les découper en paquetages
pour mieux comprendre le rôle global de chaque partie et faciliter la
maintenance du code. Pour identifier les paquetages, nous nous sommes
basés sur deux critères : cohérence et
indépendance.
Concernant le premier critère, nous avons
essayé de regrouper les classes qui ont une forte corrélation
entre elles et qui appartiennent au même domaine fonctionnel. Elles
doivent rendre des services de même nature aux utilisateurs. Tandis que
pour le deuxième critère, nous avons essayé de minimiser
les dépendances entre les paquetages en minimisant au maximum le nombre
de relations qui les traversent. Le diagramme de paquetage de notre application
est représenté dans la figure 4.5.
Figure 4.5 -- Diagramme de paquetage
· Package gestion des sources de données : il
comprend les interfaces de connexion, d'ajout et de suppression des sources de
données.
· Package gestion des processus : représente le
noyau de l'application, il regroupe les classes qui gèrent les actions
exécuté par l'utilisateur tel que l'envoie des e-mails.
· Package gestion des interfaces : C'est le module qui
contient tout ce qui est nécessaire pour la gestion des interfaces web
et la génération des templates.
4.3.3 Diagrammes des classes
La modélisation statique permet d'identifier,
d'affiner et de compléter les différentes classes relatives aux
paquetages de la section précédente. Elle consiste à
rechercher les relations entre les classes et les compléter par leurs
attributs spécifiques. Le diagramme de classes est le point central dans
un développement orienté objet. Dans ce paragraphe, on va
présenter les diagrammes de classes par composant.
4.3.3.1 Package gestion des interfaces
Ce diagramme de classe, présenté par la figure
4.6, illustre la couche présentation (View) de notre
application, dont le but est de simplifier la création et la
modification des interfaces. Ce motif répond à la
problématique de génération des Template. Par
conséquence, notre client peut par un simple clique de modifier et de
personnaliser son propre interface.
Nous notons aussi que l'un des avantages les plus important
de la séparation de cette couche c'est que le processus de
génération des interfaces devient plus optimisé est non
redondant ce qui réduit le temps de réponse.
Voici une description de quelques classes de ce diagramme :
· La classe Html-composant : C'est la
classe mère des différents composants graphiques tels que
Html-select, Html-table et Html-textarea.
· La classe Face-html : C'est la classe
qui modélise les différentes interfaces de notre application, il
est composé par des instances de la classe
.Html-composant».
· La classe Template : Cette classe
regroupe tous les vues de l'application.
· La classe Navigateur : Puisque les
applications web2.0 souffrent des problèmes de compatibilités
avec les différents types de navigateur (Internet explorer, FireFox et
googleChrome) donc cette classe teste la compatibilité par la
méthode .test-compatibilité».
Figure 4.6 -- Diagramme de classe : Gestion des
interfaces
4.3.3.2 Package Gestion des données
Ce package présente la couche persistances des
données, elle modélise la façon de traitements des
ressources et l'interaction avec la base de données.
Le but de cette couche est d'assurer la gestion souple et
facile des données, garantit leur intégrité et d'adapter
l'application sur n'importe quelle source des données. Elle offre des
méthodes pour mettre à jour ces données (insertion,
suppression, changement de valeur). Elle offre aussi des méthodes pour
récupérer ces données.
Voici une description de quelques classes de ce diagramme :
· La classe Mdata-base : c'est la
classe principale qui gère la connexion à n'importe quel type de
base de données (Mysql, PostegerSQL, Oracle, etc), également elle
possède des méthode de gestion des enregistrements.
· La classe Output: Dans le cas ou les
sources de données sont des fichiers structuré tels que des
fichiers xml ou des fichiers json, cette classe a pour mission de fournir une
lecture et écriture simple de données.
Figure 4.7 -- Diagramme de classe : Gestion des
données
4.3.3.3 Package gestion des processus
Cette couche prend en charge la gestion des
événements d'interaction entre les packages « gestion des
données » et «gestion des interfaces ». Elle
reçoit tous les requêtes de l'utilisateur et exécute les
actions convenables.
Par exemple, si une action d'envoie d'un e-mail est
déclenché, la classe « mailler » reçoit
cette requête, ill'analyse sa structure, puis la classe « SMTP
» prendre la charge d'envoie grâce à la méthode
« send-mail ».
Ce module regroupe les classes suivantes :
· La classe Mailler : C'est la classe
singletons, nous avons besoin d'exactement une unique instance pour coordonner
les opérations dans notre système. Nous avons
implémenté ce singleton en écrivant une méthode qui
crée une instance uniquement s'il n'en existe pas encore. Sinon elle
renvoie une référence vers l'objet qui existe déjà.
Le constructeur de cette classe doit être privé.
· Les classes << IMAP
>> et << SMTP >> :
Ces deux classes présentent les deux protocoles d'envoi et de
réception. Elle contient des appels aux différentes commandes
déjà implémenté dans ces deux derniers.
· La classe
<<LDAP>> : Présente les
méthodes d'authentification des utilisateurs selon le protocole LDAP
(voire annexe).
· La classe <<
Mail>> : Cette classe permet de traiter les e-mails
entrants et sortants.
· La classe << Calender
>> : Cette classe permet de gérer les calendriers des
clients.
· La classe << Meteo
>> : C'est la classe responsable à la consultation de
webservice du météo et l'affichage des résultats.
· La classe << Feed-Rss
>> : En communiquant avec les différents serveurs des
flux RSS (Voir Annexe), cette classe ramène les informations et les
news, pour les afficher sur la page d'accueil de l'internaute.
Figure 4.8 -- Diagramme de classe : gestion des
processus
4.3.4 Cinétique de l'application
Nous présentons la cinétique de l'application par
le baise d'un diagramme de transition.
4.3.4.1 Diagramme de transition de la partie
client
Lors du lancement de l'application, l'utilisateur est
redirigé vers la page d'authentification pour accéder à
profil. S'il n'est pas déjà inscrit il sera appelé
à s'inscrire via la page d'inscription rapide ou la page d'inscription
complète. Étant authentifier, et depuis la page d'accueil, le
client peut accéder aux différentes fonctionnalités du
système. Il aura la possibilité de consulter sa boite de
réception en temps réel, d'envoyer un e-mail à destination
unique ou multiple. Il peut également gérer son calendrier,
convertir des e-mails en rendez-vous, partager des événements
avec des amis et être notifié d'une tache planifié. Comme
il possède un carnet d'adresse pour collecter les informations et les
cordonnées de ses contacts, l'ajout des amis et la suppression des
informations redondons sera automatique.
Figure 4.9 -- Diagramme de transition de la partie
client
4.3.4.2 Diagramme de transition de la partie
administrative
d'envoi, te configurer le robot. Il peut configurer les
serveurs ou restaurer d'anciennes configurations. S'il opte pour le
paramétrage, il a le choix entre la gestion des privilèges
utilisateur ou le paramétrage du compte Admin.
Depuis l'interface dédiée à la gestion des
clients, il peut les gérer individuellement ou au sein des groupes
Figure 4.10 -- Diagramme de transition de la partie
administrative
Conclusion
Tout au long de ce chapitre, nous avons
développé la conception de notre application afin d'avoir le
passage souple et facile à l'étape suivante. Pour ce faire, nous
avons présenté en premier lieu l'architecture trois tiers ainsi
que le modèle MVC. En second lieu, nous avons décrit
l'architecture de notre application. Puis nous avons mis en exergue la base de
données en exposant le modèle entité association. Ensuite
nous avons présenté les diagrammes des classes. Finalement nous
avons présenté la cinétique de l'application par des
digrammes de transitions.
CHAPITRE5Réalisation
Introduction
Ce chapitre constitue l'âme du processus de
développement du logiciel et a pour objectif la mise en oeuvre de chacun
des modules décrits dans le chapitre précédent. Nous
consacrons la première partie à la présentation de
l'environnement de l'application. Par la suite, nous exposerons quelques
interfaces homme machine qui concordent avec les fonctionnalités du
système. Enfin, nous décrivons le chrono-gramme.
5.1 Environnement de travail
5.1.1 Environnement matériel
Nous avons eu besoin d'un petit parc informatique
(réseau local assez développé : trois machines minimum et
un serveur) pour les tests initiaux. Par la suite, une connexion Internet pour
chacun suffira.Des connections à débit différent nous
permettront de connaître les performances de l'application. Dans tous les
cas, il nous faudra un serveur, tournant sous Unix, assez performant
(multiprocesseur, grande capacité de mémoire vivre) pour
supporter tous les utilisateurs connectés ainsi qu'une connexion
Internet assez puissante.
Pour le développement nous avons utilisé une
machine à puissance moyenne : un PC de bureau Pentium dual-core avec 2Mo
de mémoire cache et 2Go de mémoire vive.
5.1.2 Environnement logiciel
Le long de la phase de développement, nous avons
utilisé l'environnement logiciel suivant :
· Système d'exploitation :
Microsoft Windows XP Pro SP2, Debian 4.0 version server.
· Outils de développement : Aptana
Studio 1.5 (développement PHP5, AJAX).
· Serveur d'application : Apache 2.2.
· Data Base Server : MYSQL Server 5 pour
la gestion de la base de données.
· Conception et modélisation en UML 2.1 :
Power AMC v11: est un outil de conception
et de modélisation d'applications informatiques. Il
permet aussi la modélisation des bases de données et la
génération du code à partir des données de
modélisation.
· Redaction du rapport Texmaker est un
éditeur LaTeX libre et gratuit. Il intègre un éditeur
spécialisé facilitant la rédaction des documents LaTeX et
le moyen de les compiler rapidement.
5.2 Choix techniques
Choisir un IDE (Integrated Development Environment),
constitue une étape critique du projet puisque ce choix entraînera
ou non des gains en temps et en effort, donc en coût de
développement. Nous avons opté pour Aptana Studio comme
environnement de développement pour l'application. Durant ce cycle de
développement, nous avons eu recours à cinq principaux outils
à savoir PHP5, MySQL, Shell, Ajax, JAVA Script et sa
célèbre librairie jQuery comme outils de travail.
5.2.1 Choix d'Aptana
Aptana est un Environnement de Développement
Intégré multi-plateforme et orienté JavaScript.
Doté d'une interface claire et entièrement personnalisable ainsi
que d'aides à la saisie du code (Javascript, HTML et CSS), le programme
facilitera le développement des applications web et nous fera gagner un
temps précieux. Les plugins d'Aptana fournis permettent le
développement PHP, Ruby on Rails, XML/XSL, pour la plateforme Adobe AIR,
pour les iPhone etc.
5.2.2 Choix du PHP5 (PHP Hypertext
Preprocessor)
PHP 5 est sorti en juillet 2004. Il propose un nouveau moteur,
Zend Engine II, optimisé pour les nouvelles fonctionnalités que
nous lui connaissons, notamment l'approche objet.
Sa popularité ne cesse d'augmenter. Sa souplesse et sa
grande simplicité d'utilisation séduisent un très grand
nombre de développeurs.
En revanche, exploiter l'étendue de ses
possibilités nécessite, au même titre que n'importe quelle
plate-forme de développement complète, de bonnes connaissances
théoriques.
PHP est une plate-forme composée d'un langage de
programmation très complet et de nombreux outils pour le
développement. Elle s'adapte très rapidement aux technologies
émergentes et se voit de plus en plus utilisée dans des
développements web dynamiques professionnels et Open
Source.[N10]
Nous présentons dans ce qui suit ses
caractéristiques principales :
· Un très bon compromis entre fiabilité et
rapidité d'exécution;
· Une plate-forme avant tout spécialisée
pour le développement de sites web dynamiques de toute taille.
· Une plate-forme pratique et complète
adaptée aux applications en ligne de commande.
· Un langage procédural et un langage orienté
objet.
· Un outil très complet, doté de nombreuses
fonctionnalités, extensions et bibliothèques. PHP 5 et ses
nouveautés propulse PHP dans le monde des plates-formes d'entreprises
comme .Net ou J2EE.
5.2.3 Choix d'AJAX
Ajax est un acronyme pour Asynchronous JavaScript and XML
(<< XML et Javascript asynchrones >>) et désignant une
solution informatique libre pour le développement de pages dynamiques et
d'applications Web.
Le principal attrait d'Ajax réside dans le rendu
dynamique des pages et une interactivité qui n'est pas sans rappeler le
mode d'interaction du client lourd. L'avènement des interfaces riches
(Rich Internet Application) permet au Web de fournir des sites
associant une interactivité plus riche, jusque là
réservée au client lourd, tout en gardant une facilité de
consultation qui leur sont propres.
Pour expliquer le concept d'AJAX en quelques mots, il s'agit
de permettre l'échange d'informations entre le navigateur web (sur le
poste de l'utilisateur) et le serveur web (chez l'hébergeur) sans
recharger l'ensemble de la page web utilisée. Ces échanges
s'effectuent de façon asynchrone (le mode synchrone est aussi possible)
à l'aide de fonctions développées en langage
Javascript[B7].
5.2.4 Script SHELL
Le shell n'est pas qu'un simple interpréteur de
commandes, mais dispose d'un véritable langage de programmation avec
notamment une gestion des variables, des tests et des boucles, des
opérations sur variables, des fonctions.
Nous avons recoure à utiliser cet outil parce que nous
avons besoin d'exécuter des appels système sur le serveur par
exemple la planification des processus d'envois en masse des e-mails.
5.2.5 Choix de Mysql
MySQL est très facile à faire évoluer et
à administrer. Il prend en charge les API (Application Programming
Interface) clients de nombreux langages de programmation (Perl, C, PHP,
etc) ce qui permet d'écrire facilement les programmes clients qui
doivent accéder aux données d'une base MySQL.
Le besoin d'une base de données, est motivé non
seulement par le besoin de servir des documents créés de
manière dynamique mais aussi d'accéder quotidiennement à
des informations en modification constante, à laide d'une interface
simple et unifiée, d'un serveur de base de données MySQL et des
scriptes PHP.
5.3 Diagramme de déploiement
Ce diagramme indique l'organisation matérielle de
l'application à concevoir, il spécifie les composants
nécessaires à notre application. Dans notre cas nous avons besoin
d'un serveur SMTP pour l'envoie des e-mails et un serveur POP pour la
consultation des boites de réceptions.
L'entreprise possède des serveurs ultra puissant qui ont
la capacité de supporté le trafic d'un grand nombre
d'internaute[B2].
Figure 5.1 -- Diagramme de déploiement
5.4 Implémentation
L'interface graphique s'avers sans aucun doute la partie la
plus cruciale dans une application web. Elle contribue à la construction
de la première impression qu'à l'internaute du système. En
effet, elle constitue un critère qui peut crées la
différence entre deux applications web bien qu'elles aient les
mêmes fonctionnalités.
5.4.1 Interfaces de l'application
La figure 5.2 illustre l'interface qui s'affiche à
l'internaute désirant jouir des fonctionnalités de notre
système. S'il dispose déjà d'un compte, il n'a qu'à
fournir ses paramètres, à savoir mot de passe et nom utilisateur,
pour accéder à son profile. Dans le cas contraire, l'internaute
est invité à s'inscrire gratuitement à notre
réseau. Ceci peut se faire de deux manières distinctes soient
inscription rapide et inscription complète. Le premier mode
d'inscription est présenté par la figure 5.3
Figure 5.2 -- Interface d'authentification de
l'internaute
Comme le montre la figure citée, l'inscription rapide
est restreinte à un nombre réduit de champs dans le formulaire
d'inscription. Notre but par ceci est de faciliter l'inscription de
l'internaute ainsi que lui inciter à avoir un compte dans notre
réseau d'une manière simple et rapide. Cependant son profile
reste incomplet suite à une telle opération. Il sera
ultérieurement invité à compléter les informations
manquantes.
Figure 5.3 -- Interface d'inscription rapide
La liste exhaustive des champs à remplir est
présentée dans la figure 5.4. Cette figure illustre l'interface
qui apparait à l'utilisateur dans le cas d'une inscription rapide. Elle
exige des informations supplémentaires telles que le prénom, le
pays, la réponse sur une question secrète, etc.
Évidemment, l'internaute doit valider l'inscription par l'acceptation
des règles d'utilisation et de la confidentialité.
Figure 5.4 -- Interface d'inscription
complète
Dans le cas ou l'utilisateur est déjà un membre
de notre réseau, il accède à son profile après
l'authentification. Une page d'accueil lui est ainsi affichée 5.5. Cette
dernière contient un espace de partage des statuts et des commentaires.
Elle contient également une zone qui indique par le biais des icones
significatives l'état météorologique d'une ville
donnée (température maximale, minimale, diurne et nocturne). Au
dessous, elle inclut une barre d'actualité qui est entièrement
personnalisable.
Figure 5.5 -- Interface d'accueil
Depuis cette page l'internaute peut, d'un simple click,
consulter le courrier reçu. Comme l'illustre la figure 5.6, les messages
sont tries selon leur ordre de réception. Un message est
représenté par son objet, son émetteur, sa date de
réception ainsi que les éventuels fichiers joints. Il peut
être marqué comme lu ou suivi. Par respect aux règles
d'ergonomie, notre application fournit une navigation aisée par
l'intermédiaire des onglets.
Figure 5.6 -- Interface de la boite de
réception
La figure 5.7 montre l'aspect d'un carnet d'adresses. Ce
dernier contient la liste des amis tries selon un critère donné
(nom, prénom ou groupe). L'internaute peut effectuer la recherche d'un
ami bien déterminé. Lorsqu'il clique sur le nom d'un contact,
toutes les informations lui concernant (nom, adresse e-mail, photo, etc) seront
affichées à droite. Il peut ainsi modifier ces informations
déplacer le contact vers un groupe, lui envoyer un message ou lui
supprimer de sa liste.
Figure 5.7--Interface du Carnet d'adresse
L'outil calendrier est l'espace offert à l'internaute
pour y mettre et planifier ses taches. Elles seront ultérieurement
consultées sous la forme d'événements (voir figure 5.8).
Cet affichage peut se faire par jour, par semaine, par mois ou même par
années.
Figure 5.8 -- Interface du calendrier
Afin de satisfaire le client, nous mettons à sa
disposition un espace pour paramètre l'application. Comme le clarifie la
figure 5.9, l'utilisateur peut adapter selon ses préférences,
l'interface, l'affichage du courrier et des messages, les paramètres du
serveur, etc. Nous garantissons ainsi une application personnalisable et
paramétrable.
Figure 5.9 -- Interface de gestion des
paramètres
5.5 Chronogramme
Ce projet a été réalisé du 8
février au 8 juin 2010. Nous avons tout d'abord commencé par une
étude approfondie de l'existant pour pouvoir comprendre les besoins et
débuter le travail. Ensuite, après avoir dégagé et
compris ce qui est demandé, nous avons pu relever les besoins
fonctionnels et non fonctionnels. Puis nous avons entamé la phase de
conception et implémenté le module demandé après
avoir passé par une phase de documentation sur les technologies à
utiliser. Dans un souci d'organisation et afin de mener à bien le
projet, nous avons établi un chronogramme détaillé des
différentes tâches qui constituent le projet.
Figure 5.10 -- Chronogramme
Conclusion
Dans ce chapitre, nous avons présenté
l'environnement de développement matériel et l'environnement
logiciel avec lesquels ce projet a été réalisé.
Nous avons présenté aussi une vue de l'application finale via
quelques imprimés d'écrans ainsi que le chronogramme des
tâches accomplies durant ce travail.
Conclusion générale
C
E projet était une bonne occasion pour sortir du cadre
théorique et appliquer les connaissances acquises lors des études
universitaires dans un environnement réel de travail qui nous a permis
d'initier dans le domaine professionnel et d'apprendre plusieurs attitudes et
habitudes sociales telles que le travail en groupe et la collecte
d'informations pour extraire les besoins des acteurs du
système à mettre en oeuvre ainsi que les règles de
communication au sein d'une hiérarchie administrative stricte.
Sur le plan technique, ce travail nous a fait découvrir de
nouveaux concepts et technologies liées aux applications Web2.0 et les
architectures des webmail.
Le profit essentiel étant d'apprendre comment utiliser
une technologie existante et la faire intégrer dans notre application en
respectant des contraintes temporelles qui ne sont pas toujours simples
à respecter.
La contrainte de temps ainsi évoquée nous a
empêchés d'ajouter d'autres fonctionnalités à notre
application qu'on a estimée faisables techniquement, parmi lesquels nous
citons la possibilité d'intégrer notre application sur les
appareils mobiles telles que les PDA (Personal Digital Assistant), les
Iphone1 et les Ipad 2, ajouter un espace de partage des
médias tels que les livres et les vidéos ainsi que d'optimiser le
code afin de réduire le temps de réponse.
Dans ce rapport nous avons développé cinq
chapitres. Dans le premier, nous avons présenté le cadre
général de notre application et les différentes solutions
choisies vis-à-vis la problématique dégagée. Dans
le deuxième chapitre nous avons étudié les
différents protocoles et techniques utilisés dans la construction
d'un client web de messagerie électronique ainsi que la structure
générale d'un message électronique. Ensuite, l'analyse
fonctionnelle et non fonctionnelle ainsi que la spécification des
besoins ont été élaborées dans le troisième
chapitre. La partie conception a été analysée dans le
quatrième chapitre. Nous avons clôturé le rapport par la
partie réalisation renfermant les principales interfaces de
l'application.
1. L'iPhone est une famille de smartphones conçue et
commercialisée par Apple Inc. depuis 2007.
2. L'iPad est un micro-ordinateur développé par
Apple. Il consiste en un écran tactile multitouch de type capacitif
(jusqu'à onze doigts simultanément) et est dépourvu de
clavier, ce qui le définit comme un tablet PC de type ardoise.
Bibliographie
[B1] B. Costales, G. Jansen et C. Assmann, "Sendmail ",
O'Reilly, Etats Unis d'Amérique , 2007.
[B2] Jim Conallen, "Concevoir des applications Web avec
UML", Eyrolles, Septembre 2000.
[B3] Julie Denouël-Granjon, "Les interactions
médiatisées en messagerie instantanée", s.n, 2008.
[B4] Meredith G. Farkas, "Social software in libraries
: building collaboration, communication, and community Online", Information
Today, Inc., 2007.
[B5] Knut Andreas Ruud, "User experience design
patterns for Web 2.0 applications", K.A. Ruud, 2009.
[B6] Brice-Arnaud Guérin, "PHP 5, MySQL 5, AJAX:
entraînez-vous à créer des applications professionnelles",
2007.
[B7] Nicholas C. Zakas, Jeremy McPeak, Joe Fawcett,
"Professional Ajax", John Wiley and Sons, 2007.
[B8] Jean-Noël Anderruthy, "Web 2.0 :
révolutions et nouveaux services d'Internet", Editions ENI, 2007.
Netographie
[N1]
www.journaldunet.com/solutions/0601/060105-tribune-sqli-web-20.shtml
(consulté le 03/02/2010).
[N2]
www.arobase.org/gratuit/webmails-2.0.htm
(consulté le 03/07/2010).
[N3]
www.commentcamarche.net/contents/courrier-electronique/mime.php3
(consulté le 03/02/2010).
[N4]
www.arobase.org/ecole/smtp.htm
(consulté le 10/02/2010).
[N5]
www.msdn.microsoft.com/fr-fr/embedded/bb404133.aspx
(consulté le 25/04/2010).
[N6]
www.astove.com/dossiers/applications-mobiles.pdf
(consulté le 8/03/2010).
[N7] //
webilus.com/wp-content/uploads/2007/10/mvc
consulté le 01/06/2010).
[N8]
www.lafabrick.com/labz/reflex/images/MVCReflex
(consulté le 17/03/2010).
[N9]
www.grappa.univ-lille3.fr/polys/frime/sortie002.html
(consulté le 07/04/2010).
[N10]
http://www.php.net (consulté le
15/04/2010).
Annexes
|
ANNEXEA
|
|
|
Le protocole LDAP
|
A.1 Introduction à LDAP
LDAP (Lightweight Directory Access
Protocol), est un protocole standard permettant de gérer des
annuaires, c'est-à-dire d'accéder à des bases
d'informations sur les utilisateurs d'un réseau par
l'intermédiaire de protocoles TCP/IP.
Les bases d'informations sont généralement
relatives à des utilisateurs, mais elles sont parfois utilisées
à d'autres fins comme pour gérer du matériel dans une
entreprise.
Le protocole LDAP, développé en 1993 par
l'université du Michigan, avait pour but de supplanter le protocole DAP
(servant à accéder au service d'annuaire X.500 de l'OSI), en
l'intégrant à la suite TCP/IP. A partir de 1995, LDAP est devenu
un annuaire natif (standalone LDAP), afin de ne plus servir uniquement à
accéder à des annuaires de type X500. LDAP est ainsi une version
allégée du protocole DAP, d'où son nom de Lightweight
Directory Access Protocol.
A.2 Présentation de LDAP
Le protocole LDAP définit la méthode d'accès
aux données sur le serveur au niveau du client, et non la manière
de laquelle les informations sont stockées.
Le protocole LDAP en est actuellement à la version 3 et
a été normalisé par l'IETF (Internet Engineering Task
Force). Ainsi, il existe une RFC pour chaque version de LDAP, constituant un
document de référence :
· RFC 1777 pour LDAP v.2 standard
· RFC 2251 pour LDAP v.3 standard
Ainsi LDAP fournit à l'utilisateur des méthodes
lui permettant de :
· se connecter
· se déconnecter
· rechercher des informations
· comparer des informations
· insérer des entrées
· modifier des entrées
· supprimer des entrées
D'autre part le protocole LDAP (dans sa version 3) propose
des mécanismes de chiffrement (SSL) et d'authentification (SASL)
permettant de sécuriser l'accès aux informations stockées
dans la base.
A.3 L'arborescence d'informations (DIT)
LDAP présente les informations sous forme d'une
arborescence d'informations hiérarchique appelée DIT (Directory
Information Tree), dans laquelle les informations, appelées
entrées (ou encore DSE, Directory Service Entry), sont
représentées sous forme de branches. Une branche située
à la racine d'une ramification est appelée racine ou suffixe (en
anglais root entry).
Chaque entrée de l'annuaire LDAP correspond à un
objet abstrait ou réel (par exemple une personne, un objet
matériel, des paramètres, etc).
Chaque entrée est constituée d'un ensemble de
paires clés/valeurs appelées attributs.
A.4 Les attributs des entrées
Chaque entrée est constituée d'un ensemble
d'attributs (paires clé/valeur) permettant de caractériser
l'objet que l'entrée définit. Il existe deux types d'attributs
:
· Les attributs normaux : ceux-ci sont les attributs
habituels (nom, prénom, ...) caractérisant l'objet
· Les attributs opérationnels : ceux-ci sont des
attributs auxquels seul le serveur peut accéder afin de manipuler les
données de l'annuaire (dates de modification, etc).
Une entrée est indexée par un nom distinct (DN,
distinguished name) permettant d'identifier de manière unique un
élément de l'arborescence.
Un DN se construit en prenant le nom de
l'élément, appelé Relative Distinguished Name (RDN,
c'est-à-dire le chemin de l'entrée par rapport à un de ses
parents), et en lui ajoutant l'ensemble des nom des entrées parentes. Il
s'agit d'utiliser une série de paires clé/valeur permettant de
repérer une entrée de manière unique. Voici une
série de clés généralement utilisées :
· uid (userid), il s'agit d'un identifiant unique
obligatoire.
· cn (common name), il s'agit du nom de la personne.
· givenname, il s'agit du prénom de la personne.
· sn (surname), il s'agit du surnom de la personne.
· o (organization), il s'agit de l'entreprise de la
personne.
· u (organizational unit), il s'agit du service de
l'entreprise dans laquelle la personne travaille.
· mail, il s'agit de l'adresse de courrier
électronique de la personne (bien évidemment). Ainsi, on appelle
schéma l'ensemble des définitions d'objets et d'attributs qu'un
serveur LDAP peut gérer. Cela permet par exemple de définir si un
attribut peut posséder une ou plusieurs valeurs. D'autre part, un
attribut nommé objectclass permet de définir les attributs
étant obligatoires ou facultatifs.
A.5 Consulter les données
LDAP fournit un ensemble de fonctions (procédures) pour
effectuer des requêtes sur les données afin de rechercher,
modifier, effacer des entrées dans les répertoires.
Voici la liste des principales opérations que LDAP peut
effectuer :
|
Opération
|
Description
|
|
Add
|
Ajoute une entrée au répertoire
|
|
Bind
|
Initie une nouvelle session sur le serveur LDAP
|
|
Compare
|
Compare les entrées d'un répertoire selon des
critères
|
|
Delete
|
Supprime une entrée d'un répertoire
|
|
Extended
|
Effectue des opérations étendues
|
|
Rename
|
Modifie le nom d'une entrée
|
|
Search
|
Recherche des entrées d'un répertoire
|
|
Unbind
|
Termine une session sur le serveur LDAP
|
Tableau A.1 -- Les principales opérations de
LDAP
|
ANNEXE1E3
|
|
|
RSS - Syndication de
contenu
|
B.1 Introduction au RSS
Le standard RSS représente un moyen simple d'être
tenu informé des nouveaux contenus d'un site web, sans avoir à le
consulter.
Le format << RSS >> (traduisez << Really
Simple Syndication >>) permet ainsi de décrire de façon
synthétique le contenu d'un site web, dans un fichier au format XML,
afin de permettre son exploitation par des tiers. Le fichier RSS, appelé
également flux RSS, canal RSS ou fil RSS, contenant les informations
à diffuser, est maintenu à jour afin de constamment contenir les
dernières informations à publier.
Basiquement, un fil RSS est un fichier contenant le titre de
l'information, une courte description et un lien vers une page décrivant
plus en détail l'information. Cela permet à un site web de
diffuser largement ses actualités tout en récupérant un
grand nombre de visiteurs grâce au lien hypertexte permettant au lecteur
de lire la suite de l'actualité en ligne.
Les sites proposant un ou plusieurs fils d'actualités au
format RSS arborent parfois un des logos suivants :
B.2 Utilisation de canaux RSS
Il existe typiquement deux façons d'utiliser RSS :
· L'utilisation des fils RSS par un
particulier pour son information personnelle. Il est alors
nécessaire de disposer d'un outil spécifique, appelé
<< lecteur RSS >> ou encore << agrégateur RSS
>>, afin d'exploiter les fils RSS. Ainsi, l'utilisateur d'un lecteur RSS
peut consulter en un seul endroit les dernières actualités de
dizaines, et parfois de centaines
de sites web, sans avoir à les visiter et sans avoir
à communiquer d'informations personnelles.
· L'utilisation des flls RSS par un webmaster
afin de syndiquer du contenu, c'est-à-dire
publier automatique sur son propre site diverses informations
émanant d'autres sites.
B.3 Proposer un fll RSS
Pour proposer un flux RSS sur son site et mettre ainsi une
partie de son contenu à disposition des autres webmasters, il suffit de
créer un script chargé de récupérer les
informations à inclure dans le flux RSS et de les écrire dans un
fichier XML au format RSS.
B.4 Exploiter les flls RSS sur un site
N'importe quel webmaster, pour peu qu'il dispose des outils
adéquats, peut ainsi utiliser le flux RSS d'un autre site web afin
d'afficher automatiquement sur son site les informations mises à sa
disposition. Qui plus est, dans la mesure où les informations sont au
format XML, il est possible de personnaliser l'affichage des données
selon sa propre charte graphique et il est également possible
d'agréger de multiples fils RSS au sein d'une même page: on parle
ainsi de <<syndication de contenu>>.
Afin d'exploiter un fil RSS proposé par un site, il est
nécessaire de disposer d'un outil capable d'analyser le XML (un parseur
XML) afin de le convertir en XML. Il existe un grand nombre d'outils dans la
plupart des langages permettant d'exploiter facilement des canaux RSS. L'outil
MagPie RSS permet par exemple de parser les fils RSS, quelle que soit la
version du standard utilisée, avec un simple script en langage PHP.
| 
