Table des matières
Introduction générale ...................................................................................................................... 8
Chapitre.1 Présentation générale ............................................................................................. 11
1.1 Introduction ................................................................................................................... 11
1.2 Présentation de l’organisme d’accueil ........................................................................ 11
1.3 Problématique ............................................................................................................... 12
1.4 Solution proposée ......................................................................................................... 12
1.5 Conclusion .................................................................................................................... 13
Chapitre.2 Etat de l’art ............................................................................................................. 15
2.1 Introduction ................................................................................................................... 15
2.2 Etude comparative ........................................................................................................ 15
2.2.1 Interopérabilité ....................................................................................................... 15
2.2.2 SOA ......................................................................................................................... 15
2.2.3 Deux vues d’intégration L’EAI et L’ESB ............................................................ 16
2.2.4 Comparaison entre Les EAI sur le marché ........................................................... 27
2.3 Choix de méthodologie : .............................................................................................. 31
2.3.1 Comparaison entre les différentes méthodologies ............................................... 31
2.3.2 Choix de méthodologie .......................................................................................... 33
2.3.3 2TUP ....................................................................................................................... 33
2.4 Conclusion .................................................................................................................... 34
Chapitre.3 Spécifications et analyse des besoins .................................................................... 36
3.1 Introduction ................................................................................................................... 36
3.2 Etude préliminaire ........................................................................................................ 36
3.2.1 Cahier des charges : ............................................................................................... 37
Page 1

3.3 Branche fonctionnelle .................................................................................................. 41
3.3.1 Capture des besoins fonctionnels .......................................................................... 41
3.3.2 Analyse ................................................................................................................... 58
3.4 Branche technique ........................................................................................................ 64
3.4.1 Capture des besoins techniques ............................................................................. 64
3.4.2 Conception générique ............................................................................................ 69
3.5 Conclusion .................................................................................................................... 84
Chapitre.4 Conception .............................................................................................................. 86
4.1 Introduction ................................................................................................................... 86
4.2 Conception préliminaire ............................................................................................... 86
4.2.1 Vue dynamique du système ................................................................................... 86
4.2.2 Vue statique de système ......................................................................................... 90
4.3 Conception détaillée ..................................................................................................... 93
4.3.1 Les Design patterns ................................................................................................ 93
4.3.2 Vue dynamique de système ................................................................................... 95
4.3.3 Vue statique de système ....................................................................................... 104
4.4 Conclusion .................................................................................................................. 108
Chapitre.5 Réalisation ............................................................................................................ 110
5.1 Introduction ................................................................................................................. 110
5.2 Environnement du travail ........................................................................................... 110
5.2.1 Environnement matériel ....................................................................................... 110
5.2.2 Environnement logiciel ........................................................................................ 110
5.2.3 Architecture de la solution ................................................................................... 111
5.3 Principales étapes de réalisation ................................................................................ 113
5.3.1 La phase de préparation ....................................................................................... 113
5.3.2 La phase de développement ................................................................................. 113
Page 2

5.3.3 La phase d’intégration.......................................................................................... 118
5.4 Les problèmes rencontrés........................................................................................... 119
5.5 Quelques aperçus ........................................................................................................ 119
5.6 Chronogramme ........................................................................................................... 123
Conclusion générale .................................................................................................................... 124
Page 3

Liste des figures
Figure 1:Architecture de l’EAI .................................................................................................... 18
Figure 2: Les architecture d’un EAI ............................................................................................ 20
Figure 3: L’ESB dans l’entreprise ............................................................................................... 21
Figure 4: L’architecture d’un ESB ............................................................................................... 24
Figure 5: Evolution des technologies d’intégration .................................................................... 24
Figure 6 : Comparaison entre les différents produits sur le marché .......................................... 30
Figure 7 : Projection d’XP et de 2TUP sur la matrice du RUP .................................................. 32
Figure 8 : Les phases de processus 2TUP ................................................................................... 34
Figure 9 : Situation de l'étude préliminaire dans 2TUP .............................................................. 36
Figure 10 : L’interaction entre Biztalk et les différents composants ......................................... 38
Figure 11 : Diagramme de contexte dynamique 1/2 ................................................................... 40
Figure 12 : Diagramme de contexte dynamique 2/2 ................................................................... 41
Figure 13: Diagramme de cas d’utilisations de gestion de mails ............................................... 43
Figure 14 : Diagramme de cas d’utilisation de gestion de calendrier ........................................ 44
Figure 15 : Diagramme de cas d’utilisation d’envoie d’un fax .................................................. 45
Figure 16 : Diagramme de cas d’utilisation de gestion des contacts ......................................... 46
Figure 17 : Diagramme de cas d’utilisation d’envoie d’un SMS ............................................... 47
Figure 18 : Diagramme de cas d’utilisation de gestion du disque virtuel ................................. 48
Figure 19 : Diagramme de cas d’utilisation de gestion de notes................................................ 49
Figure 20 : Diagramme de cas d’utilisation de gestion des applications................................... 50
Figure 21 : Diagramme de cas d’utilisation de participation dans forum ................................. 51
Figure 22 : Diagramme de cas d’utilisation de gestion des documents ..................................... 52
Figure 23 : Diagramme de cas d’utilisation de consultation d’actualités .................................. 53
Figure 24 : Diagramme de cas d’utilisation de discuter avec la messagerie instantanée ......... 54
Figure 25 : Diagramme de cas d’utilisation de gestion des tâches ............................................ 55
Figure 26 : Diagramme de classes participantes ......................................................................... 56
Figure 27 : Le découpage en paquetages ..................................................................................... 59
Page 4

Figure 28 : diagramme de classe des utilisateurs et groupes ...................................................... 60
Figure 29 : Situation de la capture des besoins techniques dans 2TUP..................................... 64
Figure 30 : L’interaction d’un EAI avec les différentes applications, serveurs et bases de
données .......................................................................................................................................... 65
Figure 31 : Diagramme de cas d’utilisations techniques ............................................................ 67
Figure 32 : Les composants de Biztalk server 2006 R2 ............................................................. 72
Figure 33 : L’architecture de Biztalk server ................................................................................ 74
Figure 34 : Receive pipeline ......................................................................................................... 78
Figure 35 : Send pipeline .............................................................................................................. 79
Figure 36 : Le framework .NET ................................................................................................... 81
Figure 37: Mécanisme d'envoie d'un mail ................................................................................... 82
Figure 38 : Diagramme de séquence de consultation d’une boite de mails .............................. 87
Figure 39 : Diagramme de séquence de l’ajout d’un contact ..................................................... 88
Figure 40 : Diagramme de séquence d’ajout d’une tâche .......................................................... 89
Figure 41 : Diagramme de classe de gestion de mails ................................................................ 90
Figure 42 : Diagramme de classe de gestion de contacts ........................................................... 91
Figure 43 : Diagramme de classe de gestion de tâches............................................................... 92
Figure 44 : Architecture de Singleton .......................................................................................... 94
Figure 45 : Architecture de façade ............................................................................................... 95
Figure 46 : Diagramme de séquence détaillé de consultation des mails ................................... 95
Figure 47 : Diagramme de séquence détaillé de l’ajout d’un contact ........................................ 97
Figure 48 : L’orchestration de l’ajout d’un nouveau contact ..................................................... 98
Figure 49: Un cas de mapping...................................................................................................... 99
Figure 50 : Diagramme de séquence détaillé d’importation d’une liste de contacts .............. 100
Figure 51 : Diagramme de séquence détaillé d’ajout d’une tâche ........................................... 101
Figure 52: l'orchestration des tâches .......................................................................................... 103
Figure 53 : Diagramme de classe détaillé de gestion de mails................................................. 104
Figure 54 : Diagramme de classe détaillé de gestion de contacts ............................................ 106
Figure 55 : Diagramme de classe détaillé de gestion de tâches ............................................... 108
Figure 56: Architecture de la solution ....................................................................................... 111
Figure 57: Diagramme de déploiement ..................................................................................... 112
Figure 58 : Interface d’authentification ..................................................................................... 120
Page 5

Figure 59 : Interface de gestion de mails ................................................................................... 120
Figure 60 : Interface d’affichage de mail .................................................................................. 121
Figure 61 : Interface de gestion de contacts .............................................................................. 121
Figure 62 : Interface d’exporter et importer les contacts .......................................................... 122
Page 6

Liste des tableaux
Tableau 1: Les fonctions d’un EAI .............................................................................................. 19
Tableau 2 : Les fonctionnalités d’un ESB ................................................................................... 23
Tableau 3 : Comparaison entre ESB et EAI ................................................................................ 26
Tableau 4 : Evolution parallèle des ESB et des EAI .................................................................. 27
Tableau 5 : Vue sur le marché des solutions SOA en 2006 ....................................................... 28
Tableau 6 : Comparaison entre les différents EAI sur le marché .............................................. 29
Tableau 7 : Comparaison entre les différentes méthodologies .................................................. 32
Page 7

Introduction générale
De nos jours, les informations sont de plus en plus dispersées, les systèmes pour les gérer de
plus en plus hétérogènes et complexes. Chaque entreprise adopte sa propre stratégie, par
conséquent, ses propres choix techniques.
Entre systèmes, formats et plates-formes hétérogènes, la communication se trouve souvent
freinée.
Pour faire face à ces freins « technologiques », la réponse la plus simple était de bricoler des
interfaces spécifiques à chaque application et les connecter point à point.
Cette « solution » peut paraître judicieuse quand on parle d’une entreprise dont le système
d’information est simple et indépendant. Mais l’est-elle vraiment quand le système se ramifie,
que les applications se multiplient et que les interfaces croient au fur et à mesure des besoins ?
Va-t-on contourner le problème de la même manière lorsqu’on parlera d’un échange
interentreprises ou inter ministères?
Comme on peut s’en douter, ces bricolages « fait-maison » ne sont en fait qu’un
contournement du problème et non une solution à long terme ou à grande échelle.
L'interopérabilité devient un impératif dès lors que l'on ne raisonne pas à très court terme.
C’est bien dans ce cadre que s’inscrit notre projet de fin d’étude qui consiste en la conception
et la réalisation d’un bureau virtuel. Ce travail ne constitue en fait qu’un cas parmi tant
d’autres dans lesquels on peut appliquer les fondations de l’interopérabilité.
Ainsi, on pourra voir à terme de la conception, une application représentant un bureau virtuel
dont tous les composants sont parfaitement interopérables. Ce qui rendra le bureau virtuel
plus ouvert, extensible et maintenable.
Page 8

Le présent rapport comporte quatre chapitres :
Le premier est consacré à la présentation du cadre générale du projet, l’étude de l’existant, et
le travail demandé. Ensuite nous allons nous focaliser sur les spécifications et l’analyse des
besoins
Dans le troisième chapitre, nous présentons la conception des différents modules de
l’application développée.
Dans le quatrième chapitre, nous décrivons la réalisation de notre application à travers ses
interfaces. Nous donnons aussi un aperçu sur l’environnement de travail de travail et un
diagramme de gant représentant notre avancement au cours du temps.
Page 9

CHAPITRE 1
Présentation générale
1. Introduction
2. Présentation de l’organisme d’accueil
3. Problématique
4. Solution proposée
5. Conclusion
Page 10

Chapitre.1 Présentation générale
1.1 Introduction
Dans le cadre de notre formation d'ingénieurs informaticiens à l’Ecole Supérieure Privée
d’ingénierie et de Technologies, nous avons eu l'occasion d’effectuer notre projet de fin
d'études au sein d’ESPRITec en collaboration avec le Centre National d’Informatique. Le
projet consiste en la conception et la réalisation d’un bureau virtuel dans un environnement
favorisant l’interopérabilité et l’intégration des différents modules.
Dans ce chapitre, nous présentons le cadre général de notre projet, c’est à dire l’organisme
d’accueil : ESPRITec et CNI.
1.2 Présentation de l’organisme d’accueil
Dans cette section nous allons présenter les organismes où nous avons effectué notre projet
de fin d’études.
 ESPRITec :
ESPRITec est un organisme fondé au sein d’ESPRIT afin de mener des projets de recherche
en informatique et en télécommunication .
 CNI :
Le Centre national d’informatique a comme objectif principal de renforcer la communication
et l’échange électronique au sein de l’Administration publique au niveau central, régional et
local et améliorer l’efficacité de ses services en direction des citoyens et des entreprises en
développant des services à distance.
Le CNI a joué un rôle important dans :
Page 11

 La planification et l'organisation du secteur de l'informatique en Tunisie et la
préparation et le suivi des travaux des Plans Nationaux Informatiques (PNI)
 La rationalisation de l’acquisition de matériels, de produits et de services
informatiques par l’Administration et les entreprises publiques
Il est important de noter que l’un des principaux champs d’intervention du CNI est
l'administration électronique qui est considérée parmi les objectifs prioritaires du onzième
plan quinquennal de développement économique et social de la Tunisie ( 2007-2011) dans le
domaine des TIC.
1.3 Problématique
L’utilité principale d’un bureau virtuel est de faciliter la vie des employés, de fournir un
nombre de fonctionnalités qui vari selon le poste de l’utilisateur comme la gestion de mails,
gestion de tâches, calendrier partagée…
En effet, le CNI envisage deux chemins pour implémenter ce bureau virtuel, soit elle
développe intégralement la solution soit elle utilise des applications existantes comme une
application qui sauvegarde et liste des tâches assignées. On peut voir que cette solution
présente une fonctionnalité de notre bureau virtuel, donc il dégage de ce qu’il précède que la
deuxième stratégie consiste à communiquer des applications existantes développées en
différents langages avec notre bureau virtuel au lieu de tout développer et on a opté pour ce
choix pour deux raisons, en fait le développement d’une application complète ne sera pas
rentable en terme de temps qui se traduit en perte d’argent pour l’entreprise comme le
développement intégrale peut être condamné à un échec donc pour minimiser les risques
d’échec de l’application on opte pour l’utilisation des fonctionnalités existantes.
1.4 Solution proposée
Pour arriver à nos fins et connecter les différentes applications existantes, serveurs, bases de
données et notre bureau virtuel, nous pouvons penser à connecter ces derniers par des
connexions point à point. Cependant le problème qui se pose dans ce cas est la complexité de
cette architecture, les connexions redondantes, la difficulté de maintenance, la difficulté
Page 12

d’intégrer d’autres applications dans le futur. D’où nous avons pensé à une 2éme alternative
qui comble les défaillances de la première solution et qui consiste à l’utilisation d’un
middleware qui va jouer le rôle d’un serveur d’intégration qui va communiquer tout les
applications hétérogènes, les bases de données et les serveurs et va centraliser le flux passants
entre eux et ajouter des règles métiers sur les données échangés.
En effet, pour des raisons de sécurité le CNI n’a pas pu nous communiquer ses applications
existantes ce qui nous pousse à développer quelques fonctionnalités nous-mêmes sur des
différentes plateformes pour mettre en évidence le rôle prépondérant du serveur d’intégration
dans notre projet. Bien que la finalité de ce projet n’est pas le développement de tous les
modules relatifs au bureau virtuel mais la compréhension et la mise en place d’un
environnement d’interopérabilité permettrait aux sociétés intéressées de tirer profit de
l’application réalisée et l’adapter à ses besoins.
Ainsi au point de vue réalisation, on ne sera pas amené à réaliser tous les modules, la
principale tâche étant l’exploitation du potentiel du middleware dans les quelques modules
réalisés. Malgré que la conception et la réalisation n’aient pas pour but d’être totale, l’analyse
quant à elle doit l’être.
1.5 Conclusion
Ce chapitre nous a servi à mettre le projet dans son cadre. En effet, notre projet de fin
d’études est effectué en collaboration avec le CNI. Il a consisté en l'implémentation et
l’intégration des modules composants le bureau virtuel dans un contexte d’interopérabilité.
Dans le chapitre suivant, nous introduirons des concepts nécessaires à la compréhension de ce
projet à savoir : Une étude comparative entre ESB et EAI ainsi que la comparaison et le choix
de la méthodologie.
Page 13

CHAPITRE 2
Etat de l’art
1. Introduction
2. Etude comparative
3. Choix de méthodologie
4. Conclusion
Page 14

Chapitre.2 Etat de l’art
2.1 Introduction
Dans ce chapitre, nous allons présenter quelques notions et quelques technologies qui vont
servir à mieux comprendre notre sujet, d’autre part nous allons fais des études comparatifs
pour justifier nos choix.
2.2 Etude comparative
2.2.1 Interopérabilité
En informatique, l’interopérabilité est la capacité qu’a un système à fonctionner avec d’autres
systèmes existants ou potentiels sans aucune limitation de mise en œuvre ou d’accès. Elle ne
se limite pas au fait que ces systèmes peuvent fonctionner ensemble (dans ce cas on parlera de
compatibilité) mais du fait qu’on sait pourquoi ils le peuvent. Pour ce faire, chaque système
doit avoir une interface qui doit être connue, c'est-à-dire qu’elle suit une (ou plusieurs)
norme(s). Les normes sont ainsi le pilier de base de l’interopérabilité.
2.2.2 SOA
L'architecture orientée services (Service Oriented Architecture en anglais) est une forme
d'architecture de médiation qui est un modèle d'interaction applicative qui met en œuvre des
services (composants logiciels) avec une forte cohérence interne (par l'utilisation d'un format
d'échange pivot, le plus souvent XML) et des couplages externes « lâches » (par l'utilisation
d'une couche d'interface interopérable, le plus souvent un service web WS-*).
Le service est une action exécutée par un « fournisseur » (ou « producteur ») à l'attention d'un
« client » (ou « consommateur »), cependant l'interaction entre consommateur et producteur
est faite par le biais d'un médiateur (qui peut être un bus) responsable de la mise en relation
des composants. Le service étant à grandes mailles, il englobe et propose les fonctionnalités
des composants du système. Ces systèmes peuvent aussi être définis comme des couches
applicatives. L'architecture orientée services est une réponse très efficace aux problématiques
Page 15

que rencontrent les entreprises en termes de réutilisabilité, d'interopérabilité et de réduction de
couplage entre les différents systèmes qui implémentent leurs systèmes d'information
2.2.3 Deux vues d’intégration L’EAI et L’ESB
L’intégration d’applications désigne d’un coté les processus et d’un autre les progiciels
permettant ainsi d’automatiser les échanges entre différentes applications d’une entreprise ou
différents systèmes d’information d’entreprises différentes. Les applications et les entreprises
peuvent donc échanger des données, des messages et collaborer à l’aide de processus
communs.
Les plates-formes utilisées relient les applications hétérogènes du système d’information
autour d’un bus logiciel commun, chargé du transport des données.
Les principaux facteurs poussant au développement de la mise en place de plates-formes
d’intégration dans les entreprises sont:
La composition souvent très hétérogène du système d’information de l’entreprise qui
complique la tâche de maintenance et de communication entre les différents composants,
pouvant même présenter un obstacle dans l’exploitation des données et de potentiel de ces
différents systèmes, d’où le besoin d’une plateforme d’intégration pour faciliter la
communication et la maintenance des passerelles existantes entre ces systèmes.
Les événements ou changements structurels qui poussent les entreprises à augmenter la
flexibilité et la réactivité de leur système d’information, d’où la généralisation des besoins
d’intégration entre les applications de production (ERP) de logistique (SCM) de relation client
(CRM).
La conception de l’architecture du système d’information comme un ensemble organisé et
évolutif de services fortement couplés. L’approche SOA (Service-Oriented Architecture)
redéfinit l’intégration d’applications.
Page 16

2.2.3.1 Une étude comparative entre l’EAI et l’ESB
a- L’EAI
L'Intégration d'applications d'entreprise ou IAE (en anglais Enterprise Application
Intégration, EAI) est une architecture inter logicielle permettant à des applications
hétérogènes de gérer leurs échanges. Sa particularité est d’échanger les données en pseudo
temps réel.
Par extension, l'acronyme EAI désigne un système informatique permettant de réaliser cette
architecture en implémentant les flux inter applicatifs du système d'information [1].
En effet, de nos jours les entreprises ne cessent d’évoluer leurs architectures physique et
logicielle ce qui peut constituer une contrainte pour l’équipe qui doit intégrer le nouveau
composant. Elle doit ainsi développer une interface de mappage entre ce dernier et les autres
points ce qui engendre un gaspillage de temps. De ce fait les entreprise ont eu recours aux
architectures EAI qui présentent un point de connexion entre les différentes entités.
Une solution d'EAI est destinée à intégrer les applications selon un principe de couplage
faible, où les applications peuvent s’améliorer et fonctionner indépendamment les unes des
autres. Un des principaux bénéfices de l’EAI est que l’entreprise peut faire évoluer en douceur
son système d’information en s’appuyant au maximum sur l’existant.
Une plate-forme EAI est construite suivant un schéma standard :
 Des connecteurs, servant d'interface entre l'EAI et les applications. Ils scrutent les
évènements de l'application et transmettent les données associées vers l'EAI (ou fournissent à
l'application les données provenant de l'EAI). Ces données sont appelées ASBO (application
specific Business Object) car elles reflètent les données de l'application (nom du champ,
format...). Un connecteur touche généralement à tout ou à une partie des aspects suivants:
authentification, gestion des conversations, contexte de sécurité, transactionnel, gestion des
droits, etc...
 Les ASBO qui proviennent (ou dirigées vers) des connecteurs passent par une
opération de Mapping pour convertir les données spécifiques aux applications
(ASBO) en données standards à l'EAI : les BO (Business Object).
Page 17

 Les BO réfléchissent ainsi le modèle de donnée global des informations des différents
processus de l'entreprise. Ils sont alors transmis à des opérations appelés
collaborations qui reflètent la logique de traitement à appliquer sur un BO avant de
l’envoyer à une application cible.
 Un middleware asynchrone, qui gère la livraison asynchrone garantie des messages sur
les applications connectées au courtier de messages (message broker). Des aspects de
sécurité sont également contrôlés par cette couche.
 Un gestionnaire de processus, apte d'orchestrer les échanges de messages inter
applicatifs dans le but d'exécuter des processus métiers. La présence d'un outil de
workflow humain devient de plus en plus une nécessité au sein de l’entreprise.
 Un gestionnaire de services, capable d'appliquer des services à valeur ajoutée qui sont du
ressort de l'architecture d'intégration et non du fonctionnel des applications (ex: routage,
transformation de messages, transcodification, etc.)
 Un référentiel, responsable de la cohésion et du paramétrage des composants déployés
dans la solution EAI.
 Une console d'administration, garantissant la supervision de fonctionnement des
composants techniques de la solution EAI, ainsi que les processus métiers.
Figure 1:Architecture de l’EAI
Page 18

Cette plate-forme d'intégration assure les quatre types de fonctions suivants:
Tableau 1: Les fonctions d’un EAI
Routage Autrement dit, en fonction d'événements préalablement définis,
un logiciel d'Intégration récupère les données d'une application,
Transformation puis les routent vers leur destination (une autre application),
après les avoir préalablement converties dans un format adéquat.
Connecteurs (aux
A cette fin, il met en œuvre :
applications)
- un serveur d'intégration qui comprend un moteur de règles et
un gestionnaire de messages (pour le routage et la
transformation)
- des connecteurs (pour dialoguer avec les applications)
Transport - et un MOM (middleware orienté messages) pour transporter
les messages. Quasiment tous les fournisseurs d'Intégration
disposent de leur propre MOM même si la plupart du temps les
plates-formes d'Intégration sont déployées sur des MOM déjà
installés dans l'entreprise.
La gestion des processus métiers (BPM, pour Business Process Management) prolonge les
quatre fonctions de l'Intégration. Le BPM introduit une couche d'abstraction où l'information
traitée n'est plus une donnée ou un flux technique d'une application vers une autre mais un
processus métier. A travers le logiciel de BPM, un architecte métier définit un processus qui
sera traduit en flux techniques, lesquels sont transmis au serveur d'intégration à des fins de
paramétrage. Dans la réalité, ce n'est pas vraiment une surprise, tout n'est pas aussi transparent
et automatique. Passer les informations du BPM au serveur d'intégration demande des
interventions humaines pour, achever le paramétrage technique.
L’EAI peut implémenter l’une des deux architectures suivantes le "Hub and spoke" et le
'Network Centric".
Page 19

 L'architecture "Hub and spoke"
C'est le modèle centralisé de l'Intégration. Dans ce cadre tout passe par un "hub" central.
Aucun flux n'est possible sans l’intercession de ce hub. Quand une application envoie un
message, ce dernier est transmis à destination du hub. Le référentiel (la base où sont stockées
les règles de routage et de transformation) est donc lui aussi centralisé. L'avantage d'une telle
architecture saute aux yeux: l'administration est grandement facilitée. En revanche la gestion
de la charge s'avère complexe dans ce type d'environnement: la seule solution consiste en
effet à multiplier les hubs sur les différents segments du réseau, sachant qu'il faudra veiller à
synchroniser les règles stockées sur ces différents nœuds. L'administration devient alors
moins aisée.
 L'architecture "Network Centric"
Il s'agit cette fois de la version décentralisée de l'implémentation de l'Intégration. Des
référentiels de règles et des gestionnaires de messages sont distribués sur l'ensemble des
nœuds (point de connexion à une application). Quand une application émet un message, ce
dernier est traité par le référentiel du nœud correspondant afin que les applications abonnées à
ce type de messages le reçoivent. Avec ce type d'architecture, la charge est donc
naturellement répartie sur l'ensemble des nœuds.
On peut voir ici les différentes architectures :
ARCHITECTURE HUB & SPOKE ARCHITECTURE NETWORK CENTRIC
Figure 2: Les architecture d’un EAI
Page 20

Nouvelle vision pour L’EAI :
 La prise en compte de systèmes hors de l’entreprise (partenaires, fournisseurs), il s’agit du
support du B2B (Business to Business Integration).
 L’utilisation des services Web. Il s’agit de la standardisation de l’utilisation des services
Web, ce qui permet d’y accéder plus facilement depuis n’importe où, rendant plus aisé le
commerce sur Internet.
b- L’ESB :
Un (Enterprise Service Bus) est une solution d’intégration implémentant une architecture
parfaitement distribuée, et fournissant des services comme la transformation des données ou
le routage basé sur le contenu CBR(Content-Based Routing), ainsi qu’une interopérabilité
accrue par l’utilisation systématique des standards comme XML, les Web Services et les
normes WS-*.
L’ESB est une solution packagée qui permet de mettre en œuvre la SOA 1
Figure 3: L’ESB dans l’entreprise
1
Source : Nouvelles technologies pour l’intégration: les ESB EBM Websourcing Janvier 2006
Page 21

D’après M. Roy Schulte de la société Gartner inc, "L'ESB est une nouvelle architecture qui
exploite les services web, les systèmes orientés messages, le routage intelligent et la
transformation. L'ESB agit comme une colonne vertébrale légère et omniprésente de
l'intégration à travers laquelle les services logiciels et les composants applicatifs circulent".
Les ESB sont les héritiers directs des EAI, ils reprennent les particularités architecturales des
solutions d'EAI, les ESB se focalisent sur les fonctions d'interconnexions et de médiation, et
s'appuient pour cela sur un ensemble de standards et respectent certaines mesures parmi
lesquelles on peut citer :
 Au niveau de la connectivité, des standards comme les services Web pour gérer les
communications synchrones, J2EE et .NET. Ces solutions de Sun pour J2EE et Microsoft
pour .NET sont les environnements d’architecture distribuée dominants à l’heure actuelle.
J2EE apporte la portabilité du seul langage Java sur de nombreuses plates-formes, alors
que .NET apporte la portabilité de nombreux langages, mais seulement en environnement
Windows sur hardware Intel.
 XML pour définir les formats des messages.
 Au niveau des transformations, les standards choisis sont XSLT et Xquery.
 Au niveau de la sécurité, on s’appuie sur SSL (Secure Socket Layer) et LDAP
(Lightweight Directory Access Protocol). Ce dernier s’appuie directement sur TCP/IP
 JMS (Java Message Service) pour adresser la communication asynchrone avec les MOM.
 JCA (Java Connector Architecture) pour la connexion aux progiciels et systèmes
exotiques (ERP, CRM, Mainframes, etc.)
 Les applications sont déployées selon l’architecture SOA et le déploiement est
grandement facilité, le coût de possession est réduit.
On peut donc dégager de ce qui précède que L’ESB est une plate-forme d’entreprise qui met
en œuvre des interfaces standardisées au niveau des communications, de la connectivité, des
transformations, de la portabilité et de la sécurité.
Synthèse des fonctionnalités
Le tableau suivant synthétise les principales fonctionnalités que l'on peut attendre d'un ESB :
Page 22

Tableau 2 : Les fonctionnalités d’un ESB
Connectivité Supporte de multiples protocoles de transport synchrone ou
asynchrone. Il faut voir l'ESB comme un "super-connecteur". Son
rôle est de se connecter à tout type de ressources ou fournisseurs
de services. C'est grâce à cela qu'il permet une exposition en
couplage lâche de fournisseurs de services.
Routage Permet d'effectuer des routages de message basés sur des règles (de
contenu, de contexte, etc.). Idéalement ce routage s'appuie sur un
annuaire, sur un registre de services et éventuellement sur un moteur
de règles.
Médiation Adapte le format des messages, le protocole, effectue des
transcodifications entre l'appelant et l'appelé.
Exposition de services Transforme en service(s) un composant ou un traitement d'une
application qui ne le peut pas facilement.
Agrégation simple de Effectue des agrégations simples de services de niveau N pour
services construire des services de niveau N+1. Si l'agrégation est complexe on
préférera utiliser un moteur d'orchestration.
Traitement d'événements Permet la création des règles de corrélation et de jointure
complexes d'événements.
Contrat de service Permet la définition des contrats de services : SLA, niveau de
QoS, gestion des priorités, sécurisation des messages (signature et
cryptage), garantie de la livraison et de l'intégrité des messages.
Supervision et audit Offre des fonctions d'audit, de traçabilité, de mesure, d'administration
et d'exploitation qui permettent le suivi des traitements. Selon la qualité
de l'implémentation, cette fonctionnalité sera déléguée à un outil tiers.
L'architecture
L'Enterprise Service Bus possède une architecture en bus qui l'oppose à l'architecture hub and
spoke des EAI. Ceci fait de l'ESB une solution hautement distribuée. Les composantes de
cette architecture sont illustrées sur la figure suivante :
Page 23

Figure 4: L’architecture d’un ESB
c- Comparaison entre l’EAI et l’ESB
Dans cette partie, nous allons nous attarder sur les points de convergences et de divergence
des deux technologies : l’EAI et l’ESB.
Pour ce faire, nous commençons par donner un aperçu sur l’évolution des différentes
approches d’intégration depuis les années 80.
Figure 5: Evolution des technologies d’intégration
Les produits de type ESB semblent bien adaptés à l’implémentation de projets EAI de taille
moyenne, concernant des chaînes d'intégration qui impliquent des ressources non critiques. Ils
intéressent également les PME (petites et moyennes entreprises) pour leur faible coût d'achat
Page 24

et les standards qu'ils exploitent, notamment XML, de plus en plus utilisé comme format
d’échange de données au sein des solutions métier. Cependant les ESB présentent des
faiblesses inévitables à l'absence de normes touchant à l'orchestration des processus et la
sécurisation des échanges de flux XML. Avant de faire un choix définitif, il convient de
procéder à un test de performances.
Coût d'achat
Le coût global de la mise en œuvre d'une solution de type ESB reste très inférieur à celui des
solutions traditionnelles d'EAI. Cette économie découle d'une coté des prix relativement bas
pratiqués par les éditeurs d'ESB et d'autre part de l'utilisation de technologies standards, qui
participe efficacement dans la diminution du montant de la facture lorsque l'entreprise fait
appel à des compétences externes pour développer ses projets d'intégration.
Une approche encore en devenir
L'ESB endure de l'absence de normes définitives, précisément en matière de description de
processus (orchestration, gestion des exceptions et des erreurs...) et de sécurité, surtout
lorsque les échanges de données impliquent l'entreprise et ses partenaires. Dans l’attente de
l'arrivée de normes définitives, les éditeurs impliquent des solutions transitoires, une
concession de poids par rapport aux objectifs initiaux de l'approche ESB.
Le respect des standards
Parmi les technologies sur lesquelles repose l'approche ESB, XML est l’un de principaux
standards utilisés. L'adoption de ce langage simplifie les échanges entre l'entreprise et ses
partenaires. L'exploitation des services web facilite l'intégration de composants applicatifs
hétérogènes. Le middleware JMS permet de passer naturellement d'une architecture en mode
point à point à un bus d'échanges fonctionnant en mode dynamique.
L'intégration avec l'existant
L'ESB repose sur un système d'échange de messages éprouvé : le middleware orienté message
(MOM). Les solutions développées en Java, et qui respectent la norme JMS, montrent des
performances répondant aux attentes des entreprises. L'utilisation de JMS en interne par les
différents composants de l'outil ESB constitue également un gage de performances et
Page 25

d'ouverture. Les standards JMS, JCA, services web facilite énormément l'intégration d'un bus
applicatif de type ESB avec un existant, la plupart des éditeurs de produits d'EAI fournissant
déjà des solutions de connectivité compatibles avec ces normes.
Le tableau ci dessous montre mieux les points de différence entre l’EAI et l’ESB
Tableau 3 : Comparaison entre ESB et EAI
L’apparition des ESB, plus adaptés par leur architecture de services à l’évolution vers SOA, a
poussé les éditeurs d’EAI / BPM pour améliorer leurs produits. Ils ont suivi le mouvement en
changeant l’appellation de leurs offres en incitant l’évolution technique de leurs plates-formes
pour prendre en compte les standards (XML, Web Services, JMS, etc.) et répondre à certaines
exigences liées aux architectures SOA comme la virtualisation des services, la sécurisation
des appels, l’équilibrage de charge entre services, etc.
Les ESB aussi ont étalé leur couverture fonctionnelle et offrent ainsi des fonctions
d’orchestration des services, voire de gestion de processus. Quant aux éditeurs de solutions
d’EAI/BPM, ils ont compris l’importance du mouvement d’évolution des Systèmes
d’Information vers les architectures SOA et ont continué d’enrichir leur offre en proposant
des outils de gouvernance SOA.
Page 26

Tableau 4 : Evolution parallèle des ESB et des EAI
2.2.3.2 Choix de Middleware :
Pour conclure, les éditeurs de L’EAI essaient de combler leurs défaillances et ne tardent plus
à adopter l’approche SOA, les web service et les différents standards. Ceci nous pousse à
choisir un EAI pour l’implémentation de notre projet vu la richesse de fonctionnalités comme
le BMP, l’orchestration et la console d’administration offerte ce qui peut nous faciliter la
tâche. Dans la partie suivante nous allons effectuer une comparaison entre les EAI présents
dans le marché.
2.2.4 Comparaison entre Les EAI sur le marché
2.2.4.1 Vue sur le marché
Le Marché de l’EAI décolle avec celui de l’e-business. Les entreprises visent la performance
et la présence continuelle dans le marché ce qui les pousse à développer de nombreuses offres
sur le web. Avec l’accroissement de nombre des services online, l’amélioration de leurs
applications déjà existantes devient indispensable.
Les applications e-business suscitent le besoin d’intégration pour que toutes les informations
restent cohérentes et disponibles.
Page 27

Pour ce motif, les entreprises intègrent leurs applications en achetant les EAI des éditeurs de
logiciels qui voient à leur tour en l’EAI, un marché plutôt prometteur. Ceux-ci passent des
accords de partenariat avec d’autres éditeurs, par exemple Siebel qui a signé un accord
d’intégration avec IBM. D’autre rachètent carrément les éditeurs possédant les applications
manquantes, c’est notamment le cas pour de nombreuses entreprises : Nortel rachète Clarify,
Lucent rachète Mosaix. Ces applications EAI sont ensuite proposées aux entreprises clientes.
C’est alors que les entreprises éditrices commencent à créer leur propre offre globale, comme
par exemple, Sybase Neonsoftare, IBM Crossworlds, Sopra Viewlocity. Une explosion dans
le monde de middleware et l’EAI apparaît en 1999, bien que la notion d’intégration existe
depuis 1997. Selon une étude menée par la Business Intelligence en 1999, 54% des
entreprises estiment qu’avec la croissance de l’e-business, le manque de communication entre
applications leur ferait défaut.
De cette effervescence autour de l’EAI, apparaissent de nombreux acteurs, tels que
SeeBeyond, Tibco …, d’autres éditeurs généralistes comme le cas de Microsoft s’introduisent
dans le marché de l’EAI avec son serveur Biztalk.
Tableau 5 : Vue sur le marché des solutions SOA en 2006
BEA 60 %
IBM 43 %
Microsoft 31 %
Oracle 30 %
SUN 21 %
SAP 12 %
Tibco 12 %
WebMethods 10 %
[2]
Page 28

2.2.4.2 Etude comparative
Vu le grand nombre d’éditeurs de l’EAI sur le marché, nous allons cerner notre choix entre 3
leaders pour choisir le plus convenable entre eux dans notre contexte. Le tableau suivant est
un tableau comparatif présentant les caractéristiques des trois éditeurs étudiés, à savoir :
IBM, Microsoft et Sybase – Neonsoftware :
Tableau 6 : Comparaison entre les différents EAI sur le marché
Websphere process Biztalk (Microsoft ) Unwired orchestrator
server ( IBM ) ( Sybase )
Mise en place et complexe facile facile
paramétrage
Connecteurs plusieurs plusieurs peu
BPM(business intégré intégré Non intégré
process management)
Prix 500000 € 39 000 € 125 000 €
2.2.4.3 Choix de L’EAI
L’offre de IBM semble être la solution la plus complète sur le marché, offrant un des
services adaptés à notre projet. Cependant, le prix excessif de produit l’élimine de la liste
(500000€).
Pour ce qui est de l’offre de Sybase, on remarque plusieurs failles au sein de système tels que
le manque de gestion de workflows, la non intégration du MOM dans la Couche transport, le
mode synchrone non permis, pas d’interface graphique pour mapping, peu de connecteur, pas
de notion de profils d’utilisateurs. Tous ces inconvénients nous décourage de l’utiliser.
Finalement, BizTalk propose un middleware riche en fonctionnalités, un grand nombre
Page 29

d’adaptateurs qui assurent la communication avec les composants hétérogènes, une interface
d’administration BAM qui facilite la tâche de contrôle , une gestion complète de processus
(orchestration, mapping…). De plus, il présente la meilleure offre des prix des EAI sur le
marché offrant le prix le plus convenable et il ne cesse d’évoluer.
En effet, BizTalk est nouveau par rapport aux autres EAI produisant depuis 2000 6 versions.
Chacune de ses versions offre plus de fonctionnalités.D’autre part, il s’installe dans nos jours
comme l’un des leaders de EAI et pour des raisons de stabilité que nous avons choisi BizTalk
2006 R2 car le Biztalk 2009 a lancé une version beta. La figure suivante montre l’importance
de BizTalk au sein de marché d’EAI.
Voici un zoom sur le marché de l’EAI :
Figure 6 : Comparaison entre les différents produits sur le marché
Page 30

2.3 Choix de méthodologie :
2.3.1 Comparaison entre les différentes méthodologies
Beaucoup de gens pensent que le développement d’un logiciel se limite à la partie codage. Or
la phase codage est une phase parmi plusieurs dans le cycle de vie d’un logiciel et si on
néglige ces derniers les problèmes et les bugs ne vont pas tarder à flotter sur la surface.
Dès les années 70, le développement de logiciels connaissait des problèmes. Il n'y avait pas de
méthodologie et de norme ce qui donna bien souvent des systèmes de qualité douteuse. Les
systèmes de nos jours sont beaucoup plus évolués que cette période ce qui peut poser des
problèmes graves. Le génie logiciel tente à l'aide de processus, analyse, méthode et norme de
remédier à ce problème. Les dépassements de budget et de temps sont monnaie courante dans
le développement d'application. Voila les principes de base du génie logiciel qui tente de
corriger ces problèmes.
Le but du développement de logiciel est de produire un logiciel de qualité. Plusieurs critères
essaient de définir la qualité d'un logiciel.
De ce fait, nous sommes obligés de suivre une méthodologie de développement pour assurer
une meilleur qualité pour notre logiciel. En effet, ls processus de développement régit les
activités de production du logiciel selon deux aspects.
L’aspect statique qui représente le processus en termes de tâches à réaliser.
L’aspect dynamique qui représente la dimension temporelle du processus.
On va entamer une comparaison entre les différents processus de développement pour choisir
le mieux adapté à notre projet. Vu le nombre important de méthodologies, on va se limiter à
une comparaison entre le RUP, 2TUP et XP qui sont très utilisés dans les entreprises.
Page 31

Tableau 7 : Comparaison entre les différentes méthodologies
Méthodologie Description Points forts Points faibles
RUP Promu par Rational. -Itératif. -Coûteux à personnaliser :
Le RUP est à la fois une -Spécifie le dialogue batterie de consultants.
méthodologie et un entre les différents -Peu de place pour le code
outil prêt à l’emploi intervenants du projet. et la technologie.
(documents types -Propose des modèles de
partagés dans un documents pour des
référentiel Web). projets types.
Cible des projets de
plus de 10 personnes.
2TUP S’articule autour de -Itératif. -Plutôt superficiel sur les
l’architecture. -Fait une large place à la phases situées en amont et
Propose un cycle de technologie et à la en aval du
développement en Y. gestion du risque. développement : capture
Cible des projets de -Définit les profils des des besoins, gestion du
toutes tailles. intervenants, les changement.
livrables, les plannings, -Ne propose pas de
les prototypes. documents types.
XP Ensemble de bonnes -Itératif et simple à -Ne couvre pas les phases
pratiques de mettre en œuvre en amont et en aval au
développement (travail -Fait une large place aux développement : capture
en équipe, transfert de aspects techniques. de besoins, maintenance...
compétences…) -Innovant: -Assez flou dans sa mise
Cible des projets de programmation en duo en œuvre
moins de 10 personnes
Figure 7 : Projection d’XP et de 2TUP sur la matrice du RUP
Page 32

Cette figure nous montre l’étendue des différentes méthodologies sur le cycle de vie d’un
logiciel. En effet, le RUP traite les différentes phases : les spécifications de besoins, la
conception, le développement et les tests. Le 2TUP néglige un peu la première partie et L’XP
se focalise sur la phase de développement.
2.3.2 Choix de méthodologie
D’après ce tableau comparatif, on a tendance à éliminer le RUP qui néglige la technologie et
les contraintes techniques présentant une grande partie de notre projet. Par ailleurs, on inhibe
l’XP qui néglige, pour sa part, l’étude fonctionnelle et la capture des besoins fonctionnels et
techniques. De plus, une grande importance est accordée dans l’XP au développement aux
dépens de la phase de conception où seront introduites les différentes interactions entre nos
composants et notre middleware.
Par voie de conséquence, nous optons pour le processus 2TUP pour plusieurs raisons. D’une
part il accorde une grande importance à la technologie ce qui nous convient parfaitement,
d’autre part le 2 TUP est une méthode en Y constituée de 2 branches l’une fonctionnelle et
l’autre technique. ces dernières peuvent évoluer en parallèle et s’adaptent facilement à
l’évolution au sein de l’entreprise. En effet lorsque la technologie change ou évolue la
branche technique peut être traitée à part et réintégrée dans le projet. D’autre part, en cas
d’ajout de fonctionnalités à notre projet, la branche fonctionnelle peut être traitée seule sans
toucher à l’autre branche ce qui constitue une méthodologie souple et adaptable aux différents
environnements de travail.
2.3.3 2TUP
Il dégage de ce qui précède qu’on va suivre le processus 2TUP (2 track unified process,
prononcez "toutiyoupi") qui est un processus de développement logiciel qui implémente le
Processus Unifié.
Le 2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques des
aspects fonctionnels. Il commence par une étude préliminaire qui consiste essentiellement à
identifier les acteurs qui vont interagir avec le système à construire, les messages
qu'échangent les acteurs et le système, à produire le cahier des charges et à modéliser le
Page 33

contexte (le système est une boîte noire, les acteurs l'entourent et sont reliés à lui, sur l'axe qui
lie un acteur au système on met les messages que les deux s'échangent avec le sens). Le
processus s'articule ensuite autour de 3 phases essentielles:
 Une branche technique
 Une branche fonctionnelle
 Une phase de réalisation
[3]
[4]
Figure 8 : Les phases de processus 2TUP
2.4 Conclusion
Dans ce chapitre, nous avons passé en revue les différentes notions nécessaires à la
compréhension de notre sujet, et nous avons mené une étude comparative entre les différentes
technologies et les différents produits afin de faire le meilleur choix de notre environnement
de travail. Le chapitre suivant portera sur le processus 2TUP, la méthodologie qui nous
semble la plus adaptée à notre projet.
Page 34

CHAPITRE 3
Spécifications et
analyse des besoins
1. Introduction
2. Etude préliminaire
3. Branche fonctionnelle
4. Branche technique
5. Conclusion
Page 35

Chapitre.3 Spécifications et analyse des besoins
3.1 Introduction
Dans ce chapitre, nous allons entamer la phase de spécification et d’analyse des besoins. Nous
allons présenter en premier l’étude préliminaire dans laquelle on parcourra le cahier de
charge. Puis on abordera la branche fonctionnelle suivie de la branche technique.
3.2 Etude préliminaire
L'étude préliminaire est la toute première étape de notre processus de développement. Elle
consiste à effectuer un premier extrait des besoins fonctionnels et opérationnels, en utilisant
principalement le texte, ou des diagrammes très simples.
Figure 9 : Situation de l'étude préliminaire dans 2TUP
Dans cette étape on doit définir les entités externes et leurs interactions avec le système.
Page 36

3.2.1 Cahier des charges :
3.2.1.1 Présentation du projet:
Le CNI, centre national d’informatique, est un établissement public qui adopte plusieurs
projets de recherche dont notre projet qui s’intitule bureau virtuel administratif.
Le CNI est constitué de plusieurs départements qui communiquent ensemble, chaque
département ayant ses propres besoins. C’est dans ce cadre que l’idée de création de bureau
virtuel est née. .En effet nous comptons réaliser une interface pour chaque employé où il peut
accéder à ses outils bureautiques, les logiciels dont il a besoin , où il peut sauvegarder ses
documents ou les partager dans l’intranet , communiquer avec les autres employés via un
forum ou une messagerie instantanée, consulter sa calendrier , la modifier selon ses besoins et
même la partager avec ses collègues , utiliser sa boite mail, gérer ses contact …
3.2.1.2 Grands choix techniques:
Afin de maîtriser les risques, nous allons utiliser une approche itérative et incrémentale,
fondée sur le processus en Y.
Dans le cadre de son orientation vers les projets de recherche, CNI a choisit BIZTALK pour
réaliser notre projet. Ce serveur d’intégration répond parfaitement à nos besoins.
D’autre part, nous avons opté pour les choix techniques clés suivants pour notre projet :
-la modélisation objet avec UML.
- les architectures 3-tiers avec SGBDR.
- la plate-forme .NET (avec C#, ASP.NET) et les potentialités de XML pour l’échange de
flow entre les applications, la base de donnée et un ESB.
-une base de données SQL server 2005.
Page 37

La figure suivante montre la disposition de notre environnement matériel et logiciel :
Figure 10 : L’interaction entre Biztalk et les différents composants
3.2.1.3 Recueil des besoins fonctionnels:
Après une phase de recherche et consultation de représentant de CNI, nous avons pu dégager
ce cahier de charges préliminaire.
Utilisateur : il a plusieurs tâches à faire :
-Tout d’abord il doit s’authentifier pour accéder à son bureau virtuel
- Il peut accéder à ses outils bureautiques tels qu’Excel, Word, power point, calculatrice …
- Il peut gérer son propre calendrier : il peut créer un nouvel événement, fixer une réunion
qui peut être obligatoire pour quelques uns et optionnelle pour d’autres… donc l’utilisateur
peut inviter ses subordonnés, créer une tâche à faire qu’il peut accorder à ses subordonnés.
D’autre part, il peut détruire les anciens événements situés dans une plage de temps.
L’utilisateur peut voir le contenu d’autres calendriers en demandant le droit d’accès de ses
Page 38

collègues, et peut aussi superposer 2 calendriers pour pouvoir identifier le temps libre partagé
entre les 2 employés.
-Il peut gérer ses contacts, il peut ajouter un contact, le partager avec d’autre utilisateurs, il a
la possibilité d’ajouter une liste ou il peut intégrer tout ses contacts.
-L’utilisateur a aussi accès à sa boite à lettre pour consulter ses mails, il peut envoyer un
message accompagné d’une pièce jointe, il peut organiser ses email sous des dossiers. Il est
capable d’archiver ses messages dans des fichiers textes. Il peut rechercher des anciens
messages suivant la date ou le titre, comme il peut supprimer ceux qui n’a plus besoin.
-L’employé peut organiser ses documents : après le chargement de ses documents, il a la
possibilité de les organiser dans des dossiers puis il peut les partager avec les autres
utilisateurs. Chaque employé peut agir sur les documents des autres selon les privilèges
donnés par l’administrateur, il dispose également du droit de recherche des fichiers dont il a
besoin.
-Il peut écrire ses notes et les organiser dans des dossiers.
-L’employé peut communiquer avec ses collègues à travers un forum et une messagerie
instantanée. En effet, il peut accéder à des salons dans le chat suivant les groupes et
communiquer avec les autres.
-L’utilisateur peut envoyer des SMS à un destinataire ou à plusieurs en même temps. Comme
il peut envoyer et recevoir des fax.
- L’employé doit disposer d’un disque virtuel où il peut sauvegarder ses documents. Cet
espace est propre à lui, personne ne peut accéder à ses documents sans son autorisation.
-L’utilisateur peut participer à des activités extra professionnelles.
-Finalement, l’employé peut accéder à ses outils de travail suivant son département (Les
logiciels dont il a besoin suivant sa spécialité).
Administrateur : il gère les profils des utilisateurs, affecte les privilèges suivant les postes
des employés, donne les modules dont a besoin chaque utilisateur. Il gère aussi les groupes
suivant les départements.
Page 39

3.2.1.4 Identification des acteurs :
Un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur, dispositif
matériel ou autre système) qui interagissent directement avec le système étudié.
Dans notre cas on identifie l’utilisateur humain qui peut être un employé ou l’administrateur.
Employé : peut consulter son bureau virtuel, gérer ses outils, communiquer avec ses
collègues, accéder à sa boite mail, son calendrier, son disque virtuel, partager ses documents.
Administrateur : gérer les profils des utilisateurs, les groupes et les privilèges.
3.2.1.5 Identification des messages :
Un message représente la spécification d'une communication unidirectionnelle entre objets
qui transporte de l'information avec l'intention de déclencher une activité chez le récepteur.
Nous représentons dans le diagramme de contexte ci-après l’interaction entre les acteurs et le
système mettant en évidence les messages échangés.
Remarque : Etant donné que l’employé peut faire beaucoup de tâches, nous allons créer
plusieurs instances d’utilisateurs pour mettre en évidence les différentes interactions avec le
système.
employé:employé4 employé:employé5
sauvegarder
dans le chargement
disque virtuel, , téléchargement
affectation
employé:employé3
des privilèges. employé:employé6
envoye un message
dans le chat
envoie mail
document
créer événement/réunion
/tâche dans son calendrier
appel d'outils
Bureau virtuel
employé:employé2 employé:employé7
liste des contacts
appel de l'application ajoute un contact
écrire message
dans le forum
employé:employé8
employé:employé1
employé:employé9
Figure 11 : Diagramme de contexte dynamique 1/2
Page 40

employé:employé12
date d’une activité
employé:employé11
envoye document
par le fax confirmation
admin:admin1
gérer les modules
aquittement
Bureau virtuel
liste des utilisateurs
listes des groupes ajouter, supprimer,
envoye SMS modifier groupe
employé:employé10
ajouter, modifier,
supprimer utilisateur admin:admin2
admin:admin3
Figure 12 : Diagramme de contexte dynamique 2/2
L’étude préliminaire a pour but de collecter les besoins fonctionnels et techniques initiaux,
d’identifier les acteurs, les messages et de mettre en évidence l’interaction des acteurs avec le
système comme étant une boite noire.
3.3 Branche fonctionnelle
3.3.1 Capture des besoins fonctionnels
Cette phase représente un point de vue « fonctionnel » de l’architecture système. Par le biais
des cas d’utilisation, nous serons en contact permanent avec les acteurs du système en
vue de définir les limites de celui-ci, et ainsi éviter de trop s’éloigner des besoins réels
de l’utilisateur final.
Page 41

3.3.1.1 Identification des acteurs :
Un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur, dispositif
matériel ou autre système) qui interagissent directement avec le système étudié. Dans notre
cas, l’utilisateur humain est identifié comme étant soit un employé ou l’administrateur.
Employé : peut consulter son bureau virtuel, gérer ses outils, communiquer avec ses
collègues, accéder à sa boite mail, son calendrier, son disque virtuel, partager ses documents.
Administrateur : gérer les profils des utilisateurs, les groupes et les privilèges.
3.3.1.2 Identification des cas d’utilisations
a. Liste préliminaire des cas d’utilisations
L’identification des cas d’utilisation une première fois, nous donne un aperçu des
fonctionnalités futures que doit implémenter le système. Pour constituer les cas d’utilisation,
il faut considérer l'intention fonctionnelle de l'acteur par rapport au système dans le
cadre de l'émission ou de la réception de chaque message. En regroupant les intentions
fonctionnelles en unités cohérentes, on obtient les cas d'utilisations.
Cas d’utilisation Acteur principal, acteurs Message(s) émis/reçus par les
secondaires acteurs
Utiliser une application Utilisateur émet : nom de l’application
Utiliser les outils Utilisateur émet : nom de l’outil
Gérer le calendrier Utilisateur émet : créer
événement/réunion/tâche
Gérer les contacts Utilisateur émet : ajoute un contact
reçoit : liste des contacts
Gérer les documents Utilisateur émet : chargement,
téléchargement
reçoit : document
Gérer la boîte mail Utilisateur émet : envoie mail
Utiliser le forum Utilisateur émet : écrit message
Gérer le disque virtuel Utilisateur Emet : sauvegarder, affectation
des privilèges.
Echanger messages avec Utilisateur émet : le message lui-même
Page 42

membres
Envoyer des SMS Utilisateur émet : message
reçoit : acquittement
Envoyer des fax Utilisateur émet : document
Participer aux activités extra- Utilisateur émet : date d’une activité
professionnelles reçoit : confirmation(s)
Utiliser la calculatrice Utilisateur émet : des opérations
reçoit : résultat(s)
Gérer les modules administrateur émet : nom du module
Gérer les groupes administrateur émet : ajouter, supprimer,
modifier groupe.
reçoit : listes des groupes
Gérer les utilisateurs administrateur émet : ajouter, modifier,
supprimer utilisateur.
reçoit :liste des utilisateurs
Description des cas d’utilisations
<<include>>
introduire l'adresse de destinataire
envoyer mail
<<include>>
ecrire message
<<extends>>
ajouter fichier jointe
<<extends>>
supprimer message
<<extends>> recherche par date
gérer sa boite mail
utilisateur <<extends>>
rechercher mail
recherche par nom
<<extends>>
<<extends>>
sauvegarder mail recherche par destinataire
ajouter un contact
ajouter liste
<<extends>>
gérer liste de contact
<<extends>>
<<extends>>
<<extends>>
supprimer un contact
editer liste
<<extends>>
<<extends>>
éditer un contact
supprimer liste
Figure 13: Diagramme de cas d’utilisations de gestion de mails
Page 43

Description de « gérer boite mail »
Identification
Nom du cas: gérer sa boite mail
But : L’utilisateur peut gérer sa boite mail, il peut envoyer des mails accompagnés de pièces jointes. Il
peut agir sur ses messages en les supprimant, les sauvegardant. Il peut chercher des anciens mails. Il a le
droit d’ajouter des dossiers pour organiser ses mails et il peut gérer sa liste de contacts.
Acteurs : L’employé qui consulte sa boite mail.
Pré conditions : -l’utilisateur doit être authentifié.
-l’utilisateur doit avoir son compte mail.
Post-conditions : selon l’action faite par l’utilisateur, s’il a envoyé un mail on aura un mail envoyé.
Ajouter tâche
Gérer tâche
Supprimer tâche
Gérer réunion Modifier tâche
utlisateur Ajouter réunion
Aj outer tâche
évennement
Supprimer réunion
Modifier réunin
modifier évennement
supprimer évenement
ajouter évennement
Figure 14 : Diagramme de cas d’utilisation de gestion de calendrier
Page 44

Description de «gérer le calendrier »
Identification
Nom du cas: gérer le calendrier
But : L’utilisateur peut gérer son calendrier en ajoutant, supprimant ou modifiant soit les événements, soit
les tâches ou les réunions.
Acteurs : L’utilisateur qui veut consulter ou modifier son calendrier
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : -un événement, une tâche ou une réunion est crée, modifié ou supprimé.
envoyer à un destinataire
Envoyer un fax envoyer à plusieurs destinataires
Utilisateur
<<extends>>
envoyer une pièce jointe
Figure 15 : Diagramme de cas d’utilisation d’envoie d’un fax
Page 45

Description de envoyer un fax
Identification
Nom du cas: envoyer un fax
But : L’utilisateur peut envoyer un fax à un destinataire ou à plusieurs. Ce fax peut être accompagné d’ une
pièce jointe.
Acteurs : L’employé qui veut envoyer un fax.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : un fax envoyé.
supprimer un contact
ajouter un contact
éditer un contact
<<extends>>
<<extends>> créer liste de contacts
<<extends>> <<extends>>
gérer liste de contact
utilisateur <<extends>>
éditer liste de contacts
<<extends>>
<<extends>>
<<extends>>
<<extends>>
exporter contacts
supprimer liste de contacts
importer contacts
chercher un contact
chercher un contact par societe
chercher un contact par nom
chercher un contact par liste
Figure 16 : Diagramme de cas d’utilisation de gestion des contacts
Page 46

Description de « gérer ses contacts »
Identification
Nom du cas: gérer ses contacts.
But : L’utilisateur peut gérer sa liste de contact en ajoutant des listes où il peut organiser ses contacts, il
peut également modifier ces listes ou les supprimer. D’autre part il peut ajouter des contacts, les modifier ,
les supprimer, les exporter, les importer ou rechercher un contact selon des critères .
Acteurs : L’employé qui veut gérer sa liste de contact.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : -un contact est crée, modifié ou supprimé.
b- une liste de contact est crée modifiée ou supprimée
introduire num destinataire
<<includes>>
envoyer SMS à une personne
<<includes>>
gérer les contacts
introduire message
envoyer SMS
<<include>>
Utilisateur
<<include>>
envoyer SMS à plusieurs
<<include>>
choisir les numero des destinataires
Figure 17 : Diagramme de cas d’utilisation d’envoie d’un SMS
Page 47

Description de « envoyer un SMS »
Identification
Nom du cas: envoyer un SMS
But : L’utilisateur peut envoyer un SMS à un destinataire ou à plusieurs.
Acteurs : L’employé qui veut envoyer un SMS.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : un SMS envoyé.
l'authentification
partager un document
creer Dossier Web
<<include>>
<<extends>>
<<include>>
copier un document
<<extends>>
gérer son disque virtuel
utilisateur
<<extends>>
<<extends>>
<<extends>> <<extends>> déplacer un document
creer un document
supprimer un document renomer un document
Figure 18 : Diagramme de cas d’utilisation de gestion du disque virtuel
Page 48

Description de « gérer disque virtuel »
Identification
Nom du cas: gérer son disque virtuel
But : L’utilisateur peut créer son propre disque virtuel à travers la création de Dossier Web. Ensuite il peut
organiser ses documents, les créer, les sauvegarder, les déplacer, les modifier, les partager avec d’autres
utilisateurs, les supprimer.
Acteurs : L’employé qui veut utiliser un disque virtuel où il peut sauvegarder ses documents.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : Selon l’action d’utilisateur on peut avoir un document sauvegardé, supprimé, modifié ou
partagé.
créer une note
<<extends>> supprimer une note
<<extends>>
Gérer notes <<extends>>
modifier une note
utilisateur
<<extends>>
<<extends>> organiser les notes
déplacer les notes
Figure 19 : Diagramme de cas d’utilisation de gestion de notes
Page 49

Description de « gérer les notes »
Identification
Nom du cas: gérer les notes
But : L’utilisateur peut créer des notes où il peut introduire des remarques, des memoriums. Il peut
modifier des notes, les déplacer, les supprimer, les organiser dans des dossiers.
Acteurs : L’employé qui veut écrire ses notes.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : Selon l’action d’utilisateur on peut avoir une note modifiée, supprimée, crée, déplacée
dans un dossier.
Utiliser application
ajouter application(s)
Utilisateur
Gérer les applications supprimer application(s)
Administrateur
<<extends>>
donner privilèges
Figure 20 : Diagramme de cas d’utilisation de gestion des applications
Page 50

Description de « gérer les applications »
Identification
Nom du cas: gérer les applications.
But : L’utilisateur peut utiliser les applications qui lui ont été assignées par l’administrateur. Ce dernier ne
peut pas voir celles dont il n’a pas le privilège. Quant à l’administrateur, il a la possibilité de gérer, soit en
ajoutant, en supprimant ou en donnant les privilèges aux utilisateurs.
Acteurs : L’employé qui veut utiliser une application.
L’administrateur qui, à part la possibilité d’utiliser les applications existantes, peut administrer celles-ci.
Pré conditions : -l’utilisateur/administrateur doit être authentifié.
Post-conditions : Selon l’action on peut avoir une application ajoutée, supprimée ou tout simplement
lancée .
Exporter sujet(s)
<<extends>>
Utiliser forum
Utilisateur
<<extends>>
Participer a un sujet
Supprimer sujet
Administrateur
Figure 21 : Diagramme de cas d’utilisation de participation dans forum
Page 51

Description de « utiliser forum »
Identification
Nom du cas: utiliser forum.
But : L’utilisateur peut utiliser un forum soit en y participant, soit en exportant un sujet. L’administrateur
peut quant à lui supprimer un sujet s’il juge nécessaire.
Acteurs : L’utilisateur qui veut exploiter un forum.
Pré conditions : -l’utilisateur/administrateur doit être authentifié.
Post-conditions : Selon l’action on peut modifier le contenu d’un forum en y participant, l’exporter ou le
supprimer.
Envoyer par mail
<<extends>>
Spéçifier accèssiblité
Spéçifier chemin
<<include>>
<<include>>
Partager document
Charger un document
Gérer les documents
Télécharger un document
utlisateur
Chercher un document Entrer critère(s) de recherche
<<include>>
Organiser les documents
<<extends>> <<extends>>
<<extends>>
<<include>>
Détruire document Renommer document Déplacer vers un dossier Créer dossier
Figure 22 : Diagramme de cas d’utilisation de gestion des documents
Page 52

Description de « gérer les documents »
Identification
Nom du cas: gérer les documents.
But : L’utilisateur peut effectuer plusieurs opérations sur les documents : chargement, téléchargement,
recherche, organisation et partage.
Acteurs : L’employé qui veut gérer ses documents.
Pré conditions : -l’utilisateur/administrateur doit être authentifié.
Post-conditions : Selon l’action on peut avoir un nouveau document ou agir sur un document existant.
Actualités intra entreprise
Consulter actualités
Utilisateur
Actualités extra entreprise <<include>> Définir le(s) domaine(s)
Figure 23 : Diagramme de cas d’utilisation de consultation d’actualités
Page 53

Description de « consulter actualités »
Identification
Nom du cas: consulter actualités.
But : Les utilisateurs ont la possibilité de consulter les actualités de leur entreprise ainsi que celles du
monde. Chaque utilisateur pourra choisir les domaines ou les sites qui l’intéressent et cette fonction lui
apportera les nouveautés si elles existent. L’administrateur quant à lui aura le privilège de gérer les
actualités de l’entreprise.
Acteurs : L’employé qui veut être en alerte des actualités.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : Selon l’action on peut voir les actualités intra ou extra entreprise.
Définir le pseudo
<<i ncl ude>>
Discuter
<<i ncl ude>>
Utilisateur
Spéçifier le canal
Supprimer un canal
Gérer les canaux
Administrateur
Ajouter un canal
Modifier un canal
Figure 24 : Diagramme de cas d’utilisation de discuter avec la messagerie instantanée
Page 54

Description de « Discuter avec un collègue »
Identification
Nom du cas: Discuter avec un collègue.
But : Les utilisateurs du bureau virtuel peuvent s’échanger des messages dans le cadre de leur entreprise à
travers des canaux de discussion créée par l’administrateur. L’administrateur a bien évidement des
privilèges comme la création, la suppression ou la modification des caractéristiques du canal.
Acteurs : L’employé qui contacter un collègue sans se déplacer.
L’administrateur pour gérer les canaux.
Pré conditions : -l’utilisateur doit être authentifié.
Post-conditions : Selon l’action on peut soit entrer en communication avec un collègue soit influer sur la
gestion des canaux.
supprimer une tache
ajouter tache personnelle
ajouter une tache
Utilisateur
ajouter tache assignée
modifier une tache
Figure 25 : Diagramme de cas d’utilisation de gestion des tâches
Page 55