Memoire 636953431836401685

l
1
ï
UNIVERSITE FELIX HOUPHOUET BOIGNY
UFR de Mathématiques et Informatique
Année académique
2005-2006
MEMOIRE DE FIN DE CYCLE

Présenté devant
Togo Telecom
l'UNIVERSITE FELIX HOUPHOUET
pour obtenir le diplôme d'ingénieur des Techniques
Mention : Informatique
Spécialité : Méthode Informatiques Appliquées à la Gestion des Entreprises

par
GOGORI N'GUESSAN ETIENNE HUGUES
Filières professionnalisées MIAGE-GI

Thème:
Conception et réalisation d'un

système informatisé de gestion de
trésorerie: Cas Togo Telecom
Soutenu publiquement le 13 Mai 2009

Je jury
Président : Prof. KOUA Konin, Professeur titulaire à l'UFR-MI de l'Université

Félix Houphouët-Boigny d'Abidjan, Côte-d'Ivoire
Membres: M. BAILLY Balé, Maître Assistant à l'UFR-MI de l'Université
M. WAH Médard, Consultant en Systèmes d'informations
M. DIARRA Mamadou, Ingénieur Informaticien, Assistant à l'UFR-MI de l'Université

M. KOUASSI Florent, Ingénieur Informaticien, Chef de l'équipe de

développement projet BONS à la Gendarmerie Nationale de Côte d'Ivoire
Mémoire de fin de Cycle
Table des matières

Dédicace I
Remerciements IT
Avant propos ID
Introduction 1
Problématique 2
Partie 1: Approche méthodologique 4
Chapitre 1 : Cadre de référence 5
1 . 1- Présentation de la structure d 'accueil _ .. _ -· ·- . ..5
1.2-0rganisation et fonctionnement 5
1.3- Activités 7
Chapitre 2: Etude de l'existant 8
2.1- Description de l'existant 8
2.3- Analyse de l'existant 18
2.3- Proposition de solutions 21
Chapitre 3 : Analyse conceptuelle 22
3. 1- Présentation du thème 22
3.2- Méthode d'analyse et de conception 23
Partie 2 : Phase d'élaboration 30
Chapitre 4 : Présentation de la méthode de conception 31
4.1- lJML .31
4.2- Processus Unifié 34
Chapitre 5: Identification des besoins 37
5.1- Les principaux besoins des utilisateurs 37
5.2-Les diagrammes de cas d'utilisation 39
5.3- Spécification détaillée des besoins .46
Chapitre 6: Analyse des besoins .52
6.1- Modèle du domaine 52
6.2- Les diagrammes d'activité 75
6.3- Diagrammes d'état-transition 85
Chapitre 7: conception du système 90
7.1- Les choix technologiques 90
7 .2- Les diagrammes de classes de conception ·- 104
Partie 3: Phase de réalisation 1 16
Chapitre 8: Implémentation du système 117
8.1- Implémentation de la base de données 117
8.2- Diagramme de composants 124
8.3- Développement de l'application 127
Chapitre 9: Tests et Déploiement 130
9.1- Tests de l'application 130
9.2-Déploiement du système 130
Chapitre 10: Présentation du système 133
Conclusion 141
Lexique 142
Bibliographie .143
Webographie .143
Ingénieur MIAGE
---
Dédicace
Je rends grâce à DIEU TOUT PUISSANT pour tous ses bienfaits!

Je voudrais dédier ce travail à tous mes parents, amis et collègues qui m'ont aidé
et soutenu tout au long de ma formation et durant mon stage de fin cycle.
Particulièrement
A Mon père M. GOGORI Brou Félix
A ma mère Mme GOGORI Née YEDE N'DRI Joséphine
Que DIEU les comble de grâces, de bénédictions 1 ! !
[ tslifi
_ .
Ingénieur MIAGE
M émoire de fin de Cycle
Remerciements
Je souhaite avant tout propos, remercier le SEIGNEUR DIEU TOUT

PUISSANT, de m'avoir accordé sa grâce et l'intelligence qui m'ont permis de
réaliser ce travail
Mes remerciements vont à l'endroit de :
- Mon père et ma mère qui ont assuré moralement, financièrement et

matériellement ma formation.
- M. BORGIA Adotevi Florent : Directeur Général de Kera Telecom
Systems
- M. KOUADIO Jean Donald : Chef de Projet et Consultant à Kera telecom
Systems qui a accepté volontiers de travailler de façon collaborative avec
partagé ses connaissances avec moi lors de notre stage.
- M. KOUADIO Assi Donald Landry : Consultant à Kera telecom Systems
qui m'a recommandé au près du Directeur Général de la société.
- M. KOU AME Wa BROU Ambroise qui a bien voulu accepter de
m'encadrer lors de mon stage
- M. DIARA Mamadou: Enseignant à l'Université de COCODY qui a bien
voulu accepter de m'encadrer dans la rédaction de mon mémoire de fin de
cycle d'ingénieur MIAGE
- Et à toutes les personnes qui de près ou de loin ont participé à la
réalisation de ce projet
La réalisation de ce travail fut parfois complexe et difficile mais très bénéfique à

tout point de vue.
Merci à tous ! ! !
Ingénieur MIAGE Il
M ém oire de fin de Cycle
Avant propos
L'Université de Cocody, depuis quelques années abrite en son sein, des
filières professionnalisées en plus de ces filières classiques. Ces filières
professionnalisées, sont présentes dans plusieurs UFR (Unités de Formation et
de Recherche) de la dite Université dont l'UFR des Sciences Economiques et de
Gestion, l 'UFR Biochimie, l 'UFR des Arts et Communication ... etc. Ces filières
professionnalisées ont pour but de former des cadres professionnels et
opérationnels en entreprise en conciliant l'esprit universitaire avec celui des
entreprises, tourné vers l'obligation de résultats.
C'est dans ce cadre institutionnel, qu'ont été créées en 1999, en

collaboration avec l'IUP-MIAGE de Nantes (France), les filières
professionnalisées MIAGE (Méthodes Informatique Appliquées à la gestion des
Entreprises) et GI (Génie Informatique), au sein de l'UFR des Mathématiques et
Informatique. Avec l'intervention des professeurs de l'Université, d'enseignants
vacataires et des professionnels exerçant dans les milieux des entreprises, ces
filières assurent une formation des étudiants sur une durée de quatre (4) ans.
Cette formation donne lieu à l'obtention d'une Maîtrise en Mathématiques et
Informatique et le diplôme d'Ingénieur des techniques, option MIAGE ou GI
suite à la présentation du travail effectué lors d'un stage en entreprise,
C'est ainsi que au terme de notre formation d'ingénieur MIAGE, au sein

des filières professionnalisées MIAGE-GI de l'Université de Cocody, nous
avons effectué sur une période de 6 mois, notre stage de fin d'étude au sein de la
SSII Kera Telecom Systems.
Ingénieur MIAGE Ill

Mémoire de fm de Cycle
Introduction
Nombreuses sont les sociétés ou organisations qui rencontrent des
difficultés liées aux crises financières et à la mauvaise gestion de leurs
liquidités. Ces difficultés entrainent généralement l'incapacité de faire face aux
impôts et taxes imputés à ces entreprises. EIJes entrainent également
l'irrégularité du règlement de leurs factures et de la paie des employés. Ce qui
pourrait donc conduire à la cession ou même à la fermeture de ces entreprises.
Malgré leurs gros revenus les entreprises de Télécommunication n'en sont pas
épargnées. Le client étant leur principale source de revenue, il appartient donc à
ces entreprises de disposer de fonds nécessaires à la mise en place de services
satisfaisant la clientèle. Cela en vue d'accroitre le parc clients et d'augmenter le
RMC (Revenue Moyen par Client). D'où de maximiser leur profit puis de
s'imposer dans cet environnement concurrentiel constamment grandissant.
Il est vrai que ces entreprises doivent disposer de moyens qui leur permettront
de mener des actions en vue d'accroître leur chiffre d'affaire. Mais comment
pourront-elles y parvenir, avec cette crise financière qui mine notre société et le
constat amer de la mauvaise gestion des finances au sein de certaines
entreprises ?
C'est face à ces problèmes qu'il nous a été confié lors du projet "CapFinance",
la conception et la réalisation de "Cap'Iréso", un système informatisé de gestion
de trésorerie pour le compte de Togo Telecom. Nous tenterons donc dans la
suite de notre mémoire, d'apporter des éléments de réponse au problème posé en
procédant d'abord à une approche méthodologique. Nous aurons ensuite, une
phase d'élaboration du système à mettre en place et nous terminerons enfin par
la phase de réalisation du système.
1
Ingénieur MIAGE
Problématique
La société des télécommunications du Togo (Togo Telecom) est
composée de plusieurs directions œuvrant ensemble à la production et
l'assurance de services de qualité en matière de télécommunication. La DFC
(Direction Financière et Comptable) de Togo Telecom est la direction chargée
de la gestion de l'aspect :financier de l'entreprise. Cette direction se veut,
efficace et génératrice de valeur ajoutée. Cependant elle rencontre quelques
difficultés dans la réalisation de ses activités. En effet l'information ne circule
pas de façon automatisée, fluide et collaborative entre ses différents services. En
l'occurrence le service Budget et marchés, le service Trésorerie et le service
Comptabilité. De plus la gestion de l'information est essentiellement manuelle
au sein de ces services.
La DFC de Togo Telecom voudrait donc une gestion optimale de l'aspect

financier et comptable de la société. Cela d'abord par une planification
méthodologique et automatisée de toutes les dépenses et recettes à effectuer par
la société via l'élaboration de plusieurs projets au cours d'un exercice. Ensuite
elle voudrait 1, exécution de ces projets planifiés, tout en respectant les plages
fixées et les objectifs à atteindre concernant les dépenses et les recettes avec la
mise en œuvre de validations et de contrôles permanents. Et enfin une
comptabilisation automatique et fortement dépendante des opérations réalisées
lors de l'exécution de ces projets qui ont été élaborés.
C'est à cet effet qu'a été initié avec Kera Telecom Systems, le projet
"CapFinance" qui permettra de mettre en place un système d'information de
Gestion Financière ( comportant une suite logiciels de gestion de Budget,
Trésorerie et Comptabilité, tous les trois communiquant entre eux), en vue de
résoudre les difficultés rencontrés par la DFC, et donc de participer de façon
active et dynamique à la réalisation des objectifs et de la vision de la Direction
Générale.
Ainsi, concernant le travail qui nous a été confié, il s'agira donc de participer
à la réalisation du projet "Capf'inance" par la mise en place du logiciel de
gestion de trésorerie devant interagir de façon fluide, efficace et collaborative
avec le logiciel de gestion des budgets et le logiciel de gestion de la
comptabilité.
- que faire et comment mettre en place un tel système ?
2
Ingénieur MIAGE
.-. •.
-
- que permettra t-il de faire exactement?
- quelle méthodologie adopter pour la mise en place de ce système ?
- quelle architecture aura notre système ?
- quels outils de modélisation et de développement, allons nous utiliser?
- quels moyens et ressources cela devra-t-il nécessiter ?
C'est à ces préoccupations que nous tenterons d'apporter des éléments de

réponses dans la suite de notre mémoire.
3
Ingénieur MIAGE
Partie 1 :
Approche méthodologique
5 ---101
4
Ingmieur MIAGE
MémoiredefindeCyde
Chapitre 1 : Cadre de référence

---
1.1- Présentation de la structure d'accueil
Née en Décembre 1990 de la scission de l'OPTT en deux sociétés, Togo

Telecom est une société d'Etat dotée d'une personnalité morale et d'une
autonomie financière, avec un capital de 4 Milliard de francs CF A. Elle est
basée à Lomé ( capital de la république togolaise), et elle participe par ses
activités, avec un personnel compétent et dynamique, à l'évolution et au bon
fonctionnement de la télécommunication au sein du territoire togolais.
1.2- Organisation et Fonctionnement
Avec un effectif de plusieurs centaines de personnes, Togo Telecom est

organisée de la façon suivante :
- la Direction Générale (DG) :
Sous le control du Directeur General, elle coordonne les activités de l'entreprise,

gère l'aspect administratif et juridique de la société. Elle est aidée dans ses
tâches, par des Conseillers et des Directeurs de Départements.
- la Direction Commerciale et Marketing (DCM) :
Elle est chargée de la prospection, l'acquisition et la gestion des clients de la

société.
Elle s'occupe également de la proposition de création de nouveaux produits et

services dans le domaine des télécoms, puis de leurs ventes.
Elle est en contact permanent avec sa clientèle en vue de l'éclairer sur

l'utilisation des produits et services de la société, de recueillir les plaintes des
clients sur la qualité de leur produits ou services, et de recueillir leurs nouveaux
besoins pour d'éventuelles améliorations des produits ou services de la société.
5
Ingénieur MIAGE
- la Direction Financière et comptable (DFC) :
Elle s'occupe de tout l'aspect :financier et comptable de la société. Elle planifie

par élaboration budgétaire, toutes les entrées et sorties de fonds concernant la
société. Elle est chargée de réceptionner et de gérer tout ce qui est encaissements
au sein de la société (règlement de factures, vente de produits et services,
location de matériel et de bâtiments, règlement des factures d'interconnexion
... etc.). Elle effectue les décaissements concernant la société (règlement de
factures fournisseurs, la paie, les charges de la société, les missions ... etc.).
Elle a également en charge la gestion de la comptabilisation de toutes les entrées

et sorties de fonds de la société.
- la Direction des réseaux (DRX):
C'est le cœur de la société. Elle assure la gestion et la maintenance de tous les

équipements permettant d'effectuer la télécommunication sur le territoire
togolais. Elle s'occupe également de la création de lignes téléphoniques, le
raccordement des abonnés au réseau téléphonique, la création de services
téléphoniques, la mise à disposition de l'internet.
- la Direction des Opérateurs et des Relations Extérieurs (DOR) :
Elle assure la gestion des relations entre Togo Telecom et les autres opérateurs
de téléphonies fixes et mobiles. En effet elle s'occupe des protocoles
d'interconnexion entre le réseau téléphonique de Togo Telecom et les réseaux
téléphoniques des autres opérateurs en vue de permettre les appels
internationaux.
- la Direction des Ressources Humaines (DRR):
Elle assure la gestion des recrutements, des carrières, de la paie et des départs à
la retraite du personnel de Togo Telecom.
6
Ingénieur MIAGE
Mémoire de f"m de Cycle
----
- la Direction de la Logistique (DLG) :
Elle assure la gestion des moyens logistiques utilisés par la société pour
effectuer ses activités. Elle gère également tout le patrimoine de la société (les
bâtiments, le mobilier, le parc automobile . . . etc.)
- la Direction des systèmes d'information (DSI) :
Elle assure la gestion de l'information au sein de la société. C'est-à-dire le

stockage, le traitement et l'acheminement de l'information à travers le réseau
informatique de Togo Telecom. Elle participe à la mise en place de systèmes
applicatifs permettant de gérer de façon automatique les métiers de la société.
Elle gère également l'installation, la configuration, la maintenance des
équipements informatiques de Togo Telecom.
1.3- Activités
Togo Telecom a pour mission principale, l'équipement et l'exploitation du

service public des Télécommunications. A cet effet, elle s'occupe de:
- l'installation et l'exploitation du réseau public des télécommunications à

l'exception de celles touchant à la sécurité de l'Etat
- la fourniture de l'accès à internet
- la location de matériels et d'équipements téléphoniques
- la location de bâtiments techniques.
7
Ingénieur MIAGE
Chapitre 2: Etude de l'existant

----.
Nous percevons l'environnement informatique de Togo Telecom selon
plusieurs aspects dont: l'aspect "Réseaux", l'aspect "Matériel", l'aspect
"Logiciel" et l'aspect "Ressources Humaines". La description de l'existant
sera donc effectuée en s'appuyant sur ces différents aspects.
2.1- Description de l'existant
2.1.1- L'aspect réseaux
» Topologie du réseau
La topologie d'un réseau définie la structure de ce réseau. C'est-à-dire, la
manière dont les différents équipements du réseau sont reliés entre eux. Il existe
plusieurs topologies dont: les Réseaux en étoile, les Réseaux Token-Ring, les
Réseaux FDDI, les Réseaux Maillés, les Réseaux en bus. L'une ou l'autre de
ces topologies est ehoisie en fonction de certains critères à savoir, le débit, le
nombre d'utilisateurs maximum, le temps d'accès, la tolérance aux pannes, la
longueur de câblage et les types d'applications.
La topologie mise en place au sein du réseau de Togo Télécom est le "Réseau

en étoile". En effet, les différents équipements, ordinateurs et périphériques du
réseau de Togo Telecom sont repartis sur les différents sites de l'entreprise, mais
reliés tous de façon hiérarchique à un nœud central situé au siège. Il est à noter
que les performances d'un réseau de ce type dépendent principalement des
nœuds centraux. C'est un type de réseau relativement efficace et économique.
~ Le câblage
Le câblage du réseau de l'entreprise est toute la connectique réseau mise

en place pour relier les différents équipements de ce réseau et de transporter des
flux dinformations entre ces équipements. Le câblage de Togo Telecom a été
réalisé avec des câbles Paire torsadée RJ-45 et des Fibres optiques. Le
câblage RJ-45 est lié à la topologie des réseaux en étoiJe et permet de relier les
équipements, ordinateurs et matériels du réseau de Togo Telecom sur de petites
distances (<= 90 mètres). Il permet également de raccorder les bureaux de
l'entreprise grâce aux prises réseaux. Ce type de câblage met en évidence la
centralisation des équipements réseaux autours des locaux techniques.
Quant aux fibres optiques elles sont utilisées au sein de Togo Telecom comme
câbles de rocade. C'est-à-dire qu'elles permettent d'établir des liaisons sur de
8
Ingénieur MIAGE
longues distances. Elle permette donc d'assurer la communication entre: les

différents sites de l'entreprise.
~ Les équipements du réseau
L'infrastructure réseau de Togo Telecom est constituée d'équipements

réseaux et d'équipements de télécommunication permettant d'abord d'assurer la
communication téléphonique et le réseau internet aussi bien à l'intérieur du pays
qu'avec le monde extérieur. Cette infrastructure permet également de fournir des
installations réseaux pour des entreprises de téléphonie mobile. Elle permet
enfin d'interconnecter les différents ordinateurs, équipements et périphériques
de 1' entreprise, repartis sur toute 1' étendue du territoire togolais. Elle comprend
essentiellement :
- Les Commutateurs téléphoniques ou Autocommutateurs : ils assurent

les communications téléphoniques entre deux ou plusieurs correspondants. Togo
Telecom dispose de commutateurs de transit et d'accès, permettant d'établir les
communications téléphoniques publiques sur l'étendue du territoire togolais et
avec l'extérieur. Elle dispose également de commutateurs PABX pour les
communications privées, c'est-à-dire les communications téléphoniques à
l'intérieur de l'entreprise.
les Routeurs : matériels spécialisés et équipés de logiciels adéquats, pour

effectuer l'interconnexion et la transmission de données entre les différents sites
de l'entreprise.
- les Switches (Commutateurs réseaux): Ce sont des périphériques

réseaux centraux, des dispositifs électroniques permettant de créer des réseaux
locaux de type Ethernet au sein de l'entreprise.
- un Firewall: outil matériel et logiciel permettant d'assurer la sécurité du

réseau en interdisant ou en autorisant certaines communications réseaux selon
les règles définies dans la politique de sécurité du réseau de Togo Telecom.
9
Ingénieur MIAGE
Mémoire de fin de Cycle .---
)"" Les services réseaux
Un Intranet a été configuré et mis en place au sein de Togo Telecom. Cet

Intranet offre aux utilisateurs du réseau les services suivants :
- le DNS (Domain Name System): il est assuré par un contrôleur de

domaine tournant sur Windows 2003 Server. Il permet d'effectuer les
résolutions de nom de domaine sur le réseau de Togo Telecom.
- l'authentification : ce service permet de gérer ]'identification des

utilisateurs du réseau et les annuaires. Il est implémenté au sein de Togo
Telecom par Active Directory de Windows 2003 Server.
- la supervision du réseau : la supervision du réseau de l'entreprise est

assurée par NetCrunch 5. Cet outil performant permet d'identifier et de détecter
automatiquement tous les serveurs et les périphériques du réseau de Togo
Telecom. Il permet aussi de renvoyer des alertes et des rapports sur l'état du
réseau et des équipements.
- le stockage des fichiers: des serveurs SAN (Storage Area Network) sont
mis en place pour le stockage des fichiers de l'entreprise. Ces serveurs tournent
pour certains sous Windows 2003 Server et pour d'autres sous Linux.
- la Messagerie : Ce service assure la communication par emails au sein de

l'entreprise. Il est implémenté sous Exchange 2003, couplé avec Windows 2003
Server.
- Internet: ISA Server 2004 sert de serveur Proxy pour Togo Telecom. Il
permet de partager une connexion internet sécurisée entre les utilisateurs du
réseau. Il gère la rapidité de l'accès à internet par sa mémoire cache dynamique
et permet également de filtrer les pages internet du réseau de Togo Telecom par
les ACL (Access Control List) implémentées sur ce serveur.
:,. Schéma du réseau
Le réseau de Togo Telecom peut être représenté par Je schéma ci-

dessous:
10
Ingénieur MIAGE
Mémoire de fin de Cycle i'
=·--
Locaux
Techniques
locaux Techniques Système de médiation
Site Cacavelv
Locaux
Techniques QQQ
Serveur Web
=·--
Site Lomé Port
locaux
Techniques
Site Kara
11
Ingénieur MIAGE
2.1.2- L'aspect matériel
~ Les ordinateurs clients
Togo Telecom dispose dans son patrimoine de plus d'une centaine

d'ordinateurs clients reparti sur ses différents sites. En effets ces ordinateurs sont
ceux destinés aux employés de l'entreprise en vue d'utiliser les différents
services réseaux de l 'intranet de l'entreprise, dans l'exercice de leurs fonctions.
Ces ordinateurs sont de marques HP, DELL et COMPAQ, avec des processeurs
Pentium Ill pour une dizaine de postes, Pentium IV et M pour une centaine de
postes et Pentium Core 2 pour une trentaine de postes. Leurs capacités de
stockage varient entre 30 et 200 Go. Avec des mémoires RAM allant de 128 à
2Go.
Systèmes
Caractéristiques Marques d'exploitation
Mémoire
Affectation Processeur RAM Disque Dur -
DG (Direction Générale) 1 à 2,6GHz 512 à 2 Go 80à 300Go HP, DELL Win XP et Vista
DCM (Direction 256 Mo à COMPAQ, Win 2000, XP

commerciale) 600 MHz à 2 GHz 1,5Go 40à 200Go HP, DELL et Vista
DFC (Direction Financière 256 Mo à 1 COMPAQ, Win XP et Vista

et comptable) 600 MHz à 1 GHz Go 40à 160Go DELL
DRX (Direction des 256 Mo à 1 COMPAQ, Win XP et Vista

réseaux) 600 MHz à 1 GHz Go 40à 160Go HP
DRH (Direction des 256 Mo à 1 COMPAQ, Win XP et Vista

Ressources Humaines) 600 MHz à 1 GHz Go 40à 160Go HP
DLG (Direction de la 256 Mo à 1 Win XP et Vista

Logistique) 600 MHz à 1 GHz Go 40 à 160Go HP, DELL
DSI (Direction des 512 Mo à Win XP et Vista

systèmes d'information) 1 à 2,6GHz 1,5Go 80à300Go HP, DELL
12
Ingénieur MIAGE
~ Les ordinateurs serveurs
Les serveurs de Togo Telecom sont des ordinateurs puissants et

performants, de marque HP et DELL sur les lesquels sont implémentés et
configurés les services réseaux de l'entreprise. Ils sont une dizaine et comportent
des processeurs allant de 2 à 3,5 GHz comme vitesse de processeur et des
capacités de stockage allant de 200 à 1024 Go, avec des mémoires RAM de 1 à
4Go.
Systèmes
Caractéristiques Marques d'exploitation
Mémoire
Affectation Processeur RAM Disque Dur -
Serveur DNS et Win 2003
Authentification 3GHz 2,SGo 200Go HP Proliant Server
Serveur Messagerie et Win 2003

Internet 2GHz 2Go 200Go HP Proliant Server
Win 2003
Serveur Web 3 GHz 2Go 200Go HP Proliant Server
400 à 1024 Linux et

DELL Power
Go
Edge, HP Win 2003
Serveurs SAN (Stockage) 2 à 3 GHz 1 à 3 Go En RAID Proliant Server
Serveur de Supervision DELL Linux redhat

réseau 1GHz lGo 160Go Optiplex
400 à 1024 Win 2003

DELL Power
Go Server
Edge, HP
Serveurs de sauvegardes 1 GHz lGo En RAID Proliant
DELL Win 2003

Serveur Antivirus 1GHz lGo 160Go Optiplex Server
400 à 1024 Unix et Win

DELL Power
Go 2003 server
Serveurs de Bases de Edge, HP
données 2 à 3 GHz 2à3 Go En RAID Proliant
13
Ingénieur MIAGE
~ Les imprimantes
Nous avons sur le réseau de Togo Telecom deux types d'imprimantes: les
imprimantes réseaux et les imprimantes personnelles. Chacune des imprimantes
réseaux est connectée à une machine jouant le rôle de serveur d'impression. Et
plusieurs autres postes du réseau de l'entreprise se connectent à ces imprimantes
pour éditer leurs documents. Les imprimantes personnelles sont celles
connectées directement aux postes client de certains utilisateurs du réseau. Les
imprimantes sont de marques HP Laser Jet, HP Desk Jet et Canon.
}.> Les autres matériels
Nous avons également sur le réseau de l'entreprise, des Ordinateurs portables et

des PDA du personnel, venant se connecter au réseau de l'entreprise. Un réseau
Wifi sécurisé est configuré à cet effet pour assurer ces connexions réseaux.
2.1.3- L'aspect logiciel
}.> Les Systèmes d'exploitation
L'on distingue dans l'environnement système de Togo Telecom deux types de

systèmes d'exploitation. Les systèmes serveurs et les systèmes clients. Comme
systèmes serveur l'entreprise dispose d'Unix qui tourne sur un serveur pour le
système de médiation, Linux qui tourne sur deux serveurs, les serveurs SAN et
le serveur de supervision réseau. Nous avons également Windows 2003 Server
qui tourne sur le reste des serveurs pour le DNS, la Messagerie, le Proxy, le Web
... etc.
"}.> Les applications bureautiques
Les applications bureautiques de l'entreprise sont constituées par la suite

bureautique de Microsoft dont Microsoft Office, avec Word pour le traitement
de textes et de documents, Excel pour les tableurs et certains calculs, Outlook
qui est le client de messagerie, Power point pour les présentations avec les
diapositives, Project pour la planification et la gestion de projets et Visio pour
les diverses schématisations de l'entreprise.
14
Ingénieur MIAGE
.,--
~ Les utilitaires
Les utilitaires mis en place au sein de l'entreprise sont respectivement

l'antivirus, le logiciel de sauvegardes et le serveur de base de données.
L'antivirus implémenté au sein de Togo Telecom est Norton Antivirus. Il
permet d'assurer au mieux la protection du réseau contre les virus informatiques,
par des téléchargements réguliers des mises à jour sur le serveur d'antivirus et le
déploiement de ces mises à jour sur les postes clients configurés sur ce
serveur. Le logiciel de sauvegarde Arc Serve Backup permet grâce aux
configurations effectuées en son sein, de sauvegarder régulièrement les fichiers
et les données de l'entreprise sur des disques durs et sur des bandes magnétiques
en vue d'effectuer une restauration du système en cas de nécessité. Nous avons
également le serveur de base de données ORACLE qui permet de gérer les
bases de données de l'entreprise.
~ Les applications métiers
Concernant les applications métiers, Togo Telecom dispose de plusieurs

logiciels permettant, en interaction avec les bases de données de l'entreprise, de
gérer au mieux le système d'informations et les processus métiers de
l'entreprise. Nous pouvons citer:
- GestAb (Gestion des abonnements) : GestAb est une application de gestion

des abonnements des clients aux différents services et produits proposés par
Togo Telecom. Développée en Delphi et interagissant avec une base de données
ORACLE, cette application prend en compte tout le processus d'abonnement
des clients depuis la demande d'abonnement jusqu'à l'activation du client sur un
commutateur (la mise en service du client), en tant qu'abonné de Togo Telecom.
Cela, en passant par l'étude de la demande, la constitution de l'abonnement, le
Devis et l'édition du contrat d'abonnement.
- le système de médiation : Interconnecté avec les équipements de

télécommunication permettant de gérer tous les appels téléphoniques nationaux
ou internationaux, le système de médiation collecte, analyse et de traite tous les
CDR générés à partir de chacun des appels émis ou reçus par les abonnés de
Togo Telecom. Les CDR sont des éléments contenant toutes les informations
concernant un appel téléphonique. Nous pouvons citer entre autre : le type
d'appel (émis ou reçu), la date, l'heure et la durée de l'appel, le numéro de
l'émetteur et le numéro du récepteur de l'appel, et bien d'autres informations sur
les appels téléphoniques. Implémenté en java, et tournant sous UNIX avec une
15
Ingénieur MIAGE
base de données ORACLE, ce système, comme son nom l'indique, joue le rôle
de médiation entre les équipements de gestion des appels téléphoniques et
certaines applications de gestion de l'entreprise en l'occurrence le système de
gestion clientèle et commercial.
- Gaia: Gaïa constitue le Billings de Togo Telecom. C'est en effet, un système

de gestion commerciale et de gestion de la clientèle, permettant d'abord de
récupérer avec le système de médiation, les CDR sous forme de données lisibles,
en vue de générer la facturation, puis d'éditer les factures clients. Il permet
également la vente des produits et services de Togo Telecom ainsi que le
règlement des factures des différents clients de l'entreprise.
- Oracle Financial : c'est un progiciel intégré permettant de gérer les opérations

comptables et la paie de la société. Elle a été développée sous Oracle Forms et
fonctionne avec une base de données ORACLE.
2.1.4- Les ressources humaines
~ L'administration du réseau
Nous avons au sein de l'entreprise un administrateur réseau chargé de:
- Gérer l'infrastructure réseau de Togo Telecom (Autocom.mutateurs, Routeurs,

Switches, Hub, Firewalls, Proxies, Connectivité Internet, les réseaux privés
virtuels (VPN), Modem, Imprimantes), l'adressage IP, les configurations
réseaux, la disponibilité du réseau, ... etc.
~ L'administration système
L'administrateur système de Togo Telecom est le responsable des serveurs de

l'entreprise. Il est chargé de l'installation, le paramétrage, le maintien, les mises
à jour, et l'évolution des serveurs matériels et logiciels. Il assure également les
sauvegardes, les restaurations sur les serveurs. Il effectue les différentes
planifications et supervisions sur les serveurs. Il sert enfin de conseiller, de
support et assure la veille technologique des matériels et logiciels de type
serveur, principalement les systèmes d'exploitation.
16
Ingénieur MIAGE
Mémoire de ran de Cycle
}i> L'administration des bases de données
L'administrateur bases de données de Togo Telecom est le responsable des

données de l'entreprise et du bon fonctionnement de ses bases de données. Il est
chargé de:
- la mise en place des bases de données
- l'intégrité des données
- la sécurité des données
- les performances d'accès aux données
- l'aide au développement d'applications
- le recouvrement de données et la gestion des sinistres
- la validation et le conseil
- migration des données et mises à jour des applications
}i> La gestion des applications
Les gestionnaires des systèmes applicatifs de Togo Telecom sont des

développeurs et intégrateurs de solutions chargés de concevoir et de réaliser les
applications de l'entreprise. Ils sont également chargés d'éprouver puis de
valider les applications ou progiciels intégrés lors de leurs acquisitions au près
de SSil. Ils assurent ensuite les tâches de paramétrages et d'intégrations de ces
progiciels avec les prestataires de services.
Après avoir décri l 'environnement informatique de Togo Telecom suivant les

différents aspects énumérés ci-dessus, nous passerons dans la section sui vante à
l'analyse de cet existant.
17
Ingénieur MIAGE
Mémoire de fin de Cyde
2.2- Analyse de l'existant
2.2.1- Les forces de l'existant
Au sein de l'environnement informatique du client (Togo Telecom), l'on

note un existant présentant beaucoup d'avantages et d'atouts dont :
- une bonne implémentation des réseaux informatiques et télécom sur toute

l'étendue du territoire.
- l'on note une connectivité bien organisée et bien architecturée assurant

une bonne bande passante.
- les utilitaires utilisés sont performants en l'occurrence Oracle comme

serveur de base de données et Arc Serve backup comme utilitaire de sauvegarde.
- il est important de signifier que le parc informatique de l'entreprise est

dense avec des composantes en phase avec les nouvelles technologies, même si
l'on note par endroit quelques postes vieillissant.
- 1' on note également une bonne prise en compte de la gestion commerciale

avec le logiciel GestAb, le Système de médiation et Gaïa.
- de plus ces systèmes assurent une stabilité des données et des programmes
car ceux-ci sont gérés par le SGBD Oracle.
Cependant nous constatons quelques faiblesses dans l'existant.
2.2.2- Les faiblesses de l'existant
- nous avons d'abord un manque de communication entre le système de

gestion commerciale (Gaïa) et la partie finance (Oracle Financial), d'où l'on
enregistre parfois des différences sur les chiffres présentés par les commerciaux
et les financiers, concernant les règlements de factures et des frais
d'abonnement, puis les ventes de produits et services.
- l'antivirus Norton présente parfois quelques défaillances car l'on assiste à

des infections courantes du réseau.
- nous avons ensuite, le fait que selon les paramétrages effectués dans
Oracle Financial, ce progiciel intégré ne prend en compte que l'aspect
18
Ingénieur MIAGE
Mémoire de fln de Cycle
.,--
comptable et paie. La gestion des budgets et la gestion de la trésorerie ne sont
pas prises en compte dans le système.
- ainsi les prévisions des dépenses et des recettes, puis la gestion des entrées
et des sorties des fonds de l'entreprise, sont gérées manuellement.
Principalement la gestion de la trésorerie de l'entreprise est assurée de façon
manuelle, par les outils bureautiques de Microsoft (Microsoft Excel, Word et
Outlook), ainsi que par des registres.
- d'où un manque d'automatisation, de contrôle, d'organisation et de

planification dans la gestion de trésorerie de l'entreprise.
- nous constatons également que cela engendre la lenteur dans le traitement

des règlements des fournisseurs, le manque d'informations en temps réel et les
difficultés dans la recherche de certaines informations pertinentes et dans la
production d'états financiers.
- l'on note enfin au sein de l'entreprise, une carence au niveau des

compétences humaines concernant le progiciel intégré de gestion de
comptabilité et paie, d'où la non exploitation des éventuelles potentialités et des
performances offertes par ce système.
Face aux forces et faiblesses dégagées par notre analyse de l'existant de Togo
Telecom, nous proposerons dans la section suivante de notre mémoire, des
solutions de gestion qui vont révolutionner l'environnement informatique de
l'entreprise.
2.3- Proposition de solutions
Suite à l'analyse effectuée dans la section précédente, les solutions à

apporter à l'existant de notre client pour la résolution des problèmes énoncés ci-
dessus, vont consister à l'amélioration des systèmes logiciels déjà en
exploitation au sein de l'entreprise et l'acquisition d'une suite d'applications de
gestion des processus métiers de l'entreprise dont :
- un système de gestion financière (CapFinance) Pour la gestion des

budgets, de la trésorerie et de la comptabilité. Et aussi,
19
Ingénieur MIAGE
.,--
- un système de gestion de la chaine logistique (CapLogistique) : Pour Ja
gestion du patrimoine de l'entreprise, la gestion des achats, la gestion des stocks
... etc.
- un système de Gestion des Ressource humaines (CapRH) : Pour la gestion

des recrutements, du personnel, des carrières, de la paie . . . etc.
- une amélioration de la gestion commerciale par un CRM (CapCRM)

venant se greffer aux applications de gestion commerciales existantes.
- la mise en place de la communication entre ces différents systèmes

hétérogènes de gestion des processus métiers de l'entreprise.
Concernant le travail qui nous a été confié lors de notre stage, il s, agira donc
de participer à la mise en place d'un système d'information permettant
d'améliorer Ja gestion des processus métiers de l'entreprise. Cela par la mise en
œuvre d'un système de gestion de trésorerie prenant en compte :
- la gestion des encaissements : elle permettra de suivre tous le processus

d'encaissements de l'entreprise depuis les règlements de factures ou les ventes
de produits et services, jusqu'au transfert des fonds en banque, en passant par les
clôtures et les dépôts des encaissements.
- la gestion des décaissements : elle permettra de suivre tous le processus

de décaissements de l'entreprise, depuis l'intention de décaissement jusqu'au
règlement du bénéficiaire, en passant par la l'autorisation de décaissement et
l'établissement de la pièce de règlement.
- la gestion des comptes bancaires : elle permettra d'enregistrer tous les

mouvements effectues par l'entreprise et tous les mouvements effectues par les
banques sur ses comptes bancaires, en vue de connaitre à tout moment le solde
de ses comptes en banques et d'établir l'état de rapprochement bancaire.
- la gestion des caisses : elle permettra de gérer les règlements en espèces

et les encaissements exceptionnels
- la gestion des emprunts bancaires: elle permettra de suivre tout le

processus de gestion des emprunts bancaires effectues par l'entreprise. elle
prendra en compte les demandes d'emprunt, le plan d'amortissement, les
garanties, la réception des fonds et le remboursement de l'emprunt.
20
Ingénieur MIAGE
- la gestion des liquidités : elle permettra de consulter les prévisions et les

réalisations de trésorerie, puis de faire des comparaisons en vue de savoir si les
objectifs on été atteints. elle permettra ensuite de consulter les mouvements de
trésorerie qui on été effectues avec des totaux, puis de faire des comparaisons en
vue de savoir si l'entreprise a dépensé plus qu'elle en a encaissé. elle permettra
enfin aux décideurs de connaitre à tout moment et en temps réel la disponibilité
de chaque guichet, chaque caisse et chaque compte bancaire de l'entreprise.
D'ou le thème: "Conception et implémentation d'un système informatise de

gestion de trésorerie (cas Togo Telecom)".
21
Ingénieur MIAGE
Mémoire de fln de Cyde
Chapitre 3 : Analyse conceptuelle
Ce chapitre nous permettra d'effectuer une analyse conceptuelle du travail

que nous devons effectuer. Nous procèderons à la définition des termes
essentiels de notre thème de stage en vue de faciliter sa compréhension. Et il
sera question dans la suite de mener une étude comparative des méthodes
d'analyse et de conception les plus importantes, en vue d'en choisir une adaptée
à nos besoins.
3.1- Présentation du thème
3.1.1- Définition des termes essentiels du thème
Conception : ensemble d'actions consistant à imaginer, représenter par la

penser, organiser et élaborer des éléments
- Réalisation: ensemble d'actions consistant à mettre en œuvre, rendre réel et

effectif un ou plusieurs éléments et d'en assurer la croissance
- Système informatisé de gestion: Outils informatiques permettant d'assurer

la gestion d'un ou de plusieurs domaines de gestion bien définis, cela dans un
souci de qualité, de traçabilité de gain de temps et d'argent.
- Trésorerie : Ensemble des fonds liquides disponibles ou en circulation (pour

une entreprise, association ou organisation)
3.1.2- Reformulation du thème
Nous pouvons dire qu'à travers notre thème de stage, il sera d'abord question
d'imaginer, d'organiser et d'élaborer un outil informatique qui permettra
d'assurer la gestion des fonds liquides de l'entreprise, disponibles ou en
circulation, dans un souci de qualité, de traçabilité de gain de temps et d'argent.
Il s'agira ensuite de mettre en œuvre, de rendre réel et effectif cet outil
informatique, et enfin d'en assurer la croissance.
3.2- Méthode d'analyse et de conception
Les méthodes d'analyse et de conception fournissent une méthodologie et

des notations standards qui permettent de concevoir des systèmes logiciels de
22
Ingénieur MIAGE
qualités. Il existe plusieurs méthodes d'analyse et de conception. Elles sont

principalement classées selon deux approches :
- l'approche "Fonctionnelle" ou "Systêmâque" avec SADT, Merise,

Axial, IE ... etc.
- l'approche "Objet" avec Booch, Classe-Relation, Fusion, HOOD, OMT,

OOSE, Unified Method ou (Unified Process) ... etc.
Nous retiendrons dans le cadre de notre analyse comparative, les deux méthodes
les plus utilisées dans le monde actuel du développement de logiciels. Elles
serviront à illustrer chacune des deux approches énumérées ci-dessus (Merise
pour l'approche systémique et UP (Uni:fied Process) avec le langage de
modélisation UML pour l'approche objet. La section suivante nous permettra de
présenter les deux approches.
3.2.1- Approche systémique avec Merise
Les méthodes fonctionnelles ( également qualifiées de méthodes

structurées) trouvent leur origine dans les langages procéduraux. Elles mettent
en évidence les fonctions à assurer et proposent une approche hiérarchique
descendante et modulaire. Ces méthodes utilisent intensivement les raffinements
successifs pour produire des spécifications dont l'essentiel est sous forme de
notations graphiques en diagrammes de flots de données. Le plus haut niveau
représente l'ensemble du problème (sous forme d'activités, de données ou de
processus, selon la méthode). Chaque niveau est ensuite décomposé en
respectant les entrées/sorties du niveau supérieur. La décomposition se poursuit
jusqu'à arriver à des composants maîtrisables (voir figure ci-dessous).
L'approche fonctionnelle dissocie le problème de la représentation des données,

du problème du traitement de ces données. Sur la figure ci-dessous, les données
du problème sont représentées sur la gauche. Des flèches transversales
matérialisent la manipulation de ces données par des sous-fonctions. Cet accès
peut-être direct (c'est parfois le cas quand les données sont regroupées dans une
base de données), ou peut être réalisé par le passage de paramètre depuis le
programme principal. Le système ainsi modélisé n'est pas une simple collection
d'éléments indépendants, mais une organisation structurée de ceux-ci dans une
finalité précise.
La méthode mise en exergue au niveau de cette approche est Merise.
23
Ingénieur MIAGE
MémorredefmdeCyde
Résultant d'un projet lancé en 1977, Merise a été conçue sous l'initiative du
Ministère français de l'industrie par le CTI (Centre Technique d'Informatique) et
le Centre d'Etude Technique de l'Equipement (CETE). C'est est une méthode de
conception basée essentiellement sur une démarche méthodologique permettant
de développer de façon efficace des systèmes d'information. Merise propose:
Une approche globale du système d'information menée simultanément sur les

données et les traitements,
Une description du système d'information par niveaux: niveau conceptuel,

niveau organisationnel, niveau logique, et niveau physique,
Une description du système d'information en utilisant un formalisme de

représentation pour la description des données.
Un découpage du processus de développement en 4 étapes dont : Etude

Préalable, Etude Détaillée, Réalisation et Mise En Œuvre.
3.2.2- Approche objet avec UML
L'approche orientée objet considère le logiciel comme une collection d'objets

dissociés, identifiés, et définis par des propriétés. Une propriété est soit un
attribut, soit une méthode. La fonctionnalité du logiciel émerge alors de
l'interaction entre les différents objets qui le constituent. L'une des particularités
de cette approche est qu'elle rapproche les données et leurs traitements associés
au sein d'un unique objet. Un objet est caractérisé par plusieurs notions dont :
)," L'identité - L'objet possède une identité, qui permet de le

distinguer des autres objets, indépendamment de son état. On construit
généralement cette identité grâce à un identifiant découlant naturellement du
problème (par exemple une Banque pourra être repéré par un code, un
Encaissement par un numéro identifiant ... etc.)
)," Les attributs - Il s'agit des données caractérisant l'objet. Ce

sont des variables stockant des informations sur l'état de l'objet.
)," Les méthodes - Les méthodes d'un objet caractérisent son

comportement, c'est-à-dire l'ensemble des actions (appelées opérations) que
l'objet est à même de réaliser. Ces opérations permettent de faire réagir l'objet
aux sollicitations extérieures (ou d'agir sur les autres objets). De plus, les
méthodes sont étroitement liées aux attributs, car leurs actions peuvent dépendre
des valeurs des attributs, ou bien les modifier.
24
Ingénieur MIAGE
La difficulté de cette modélisation réside dans la création d'une représentation

abstraite, sous forme d'objets, d'entités ayant une existence matérielle
(Exemple: Banque, Guichet, Caisse ... etc.) ou bien virtuelle (Exemple :
Encaissement, Décaissement, Transfert de fonds ... etc.).
La Conception Orientée Objet (COO) est la méthode qui conduit à des

architectures logicielles fondées sur les objets du système, plutôt que sur la
fonction qu'il est censé réaliser.
La méthode mise en exergue au niveau de l'approche objet est l 'UP (Unified

Process) qui signifie processus unifié.
Le Processus Unifié UP est un processus de développement logiciel itératif et

incrémental (une itération désigne la succession des états de l'enchainement
d'activité, tandis qu'un incrément correspond à une avancée dans les différents
stades de développement), centré sur l'architecture (propose différentes
perspectives indépendantes et complémentaires, qui permettent de définir un
modèle d'architecture) et piloté par des cas d'utilisation d'UML (le processus de
développement sera centré sur l'utilisateur). C'est un patron de processus
pouvant être adapté à une large classe de systèmes logiciels, à différents
domaines d'applications, à différents types d'entreprise, à différents niveau de
compétence et à différentes taille d'entreprise. UP gère le processus de
développement par deux dimensions. La première représente les principaux
enchainements d'activités qui regroupent les activités selon leur nature. Cette
dimension rend compte de l'aspect statique du processus qui s'exprime en
termes de composants, de processus, d'activités, d'enchaînements et de
travailleurs :
- expression des besoins ;
- analyse;
- conception ;
- implémentation ;
- tests.
La seconde dimension représente le temps et montre le déroulement du cycle de

vie du processus ; cette dimension rends compte de 1 'aspect dynamique du
processus qui s'exprime en terme de cycle, de phrases, d'itérations et de jalons.
25
Ingénieur MIAGE
UP (Unified) répète un certain nombre de fois le cycle de vie du processus, qui

s'articule autour de quatre phases :
- analyse des besoins
- élaboration
- construction
- transition
3.2.3- Etude comparative
Les différences entre l'approche objet avec. UML et l'approche systémique

(fonctionnelle) avec Merise sont mises en évidence dans l'étude comparative ci-
dessous:
)i,> Points communs
L'approche classique et l'approche objet distinguent bien globalement trois

grandes étapes ans le processus de conception et de développement d'une
solution: l'analyse objet correspond au niveau conceptuel de merise, la
conception objet est proche de la modélisation logique et organisationnelle de
merise. Et enfin l'implémentation objet correspond à la réalisation dans merise
Nous allons reprendre chaque grand niveau de représentation du SI et donner un

certains nombre de précisions sur les points communs.
Le niveau de l'analyse objet ou le niveau conceptuel : dans les deux approches,

la finalité de ces premiers niveaux de description d'un SI est d'appréhender les
besoins à satisfaire et donner une description de solutions indépendamment des
considérations techniques des niveaux logiciel t physique. Autrement dit les
préoccupations traitées sont très proches malgré des concepts pas
complètements identiques au niveau conceptuel et au niveau de l'analyse objet.
Le niveau conception Objet ou le niveau logique-Organisationnel : ce niveau de

description a bien pour finalité dans les deux approches de représenter la
solution à implémenter sous l'angle de la logique informatique tant sur la partie
des données que sur celle des traitements.
26
Ingénieur MIAGE
Mémoire de ran de Cycle
Le niveau implémentation physique ou opérationnel m dans les deux approches

la préoccupation est la description physique et opérationnelle des données et
traitements.
~ Différences
Nous observons les différences entre ces deux approches au niveau des
domaines d'application, de la démarche, les données et les traitements puis
l'aspect évolution du système.
- Les domaines d'application
Merise a pour vocation de traiter les systèmes d'information des entreprises,

principalement dans le domaine de l'informatique de gestion. Le domaine de
l'informatique de gestion se caractérise en général par un grand nombre de
données à gérer et à stocker avec des traitements relativement peu complexes.
Le domaine privilégié par UML est le domaine de l'informatique technique ou

industrielle caractérisé par la gestion de composants physiques du monde réel
(} 'Informatisation des automates est représentatif de ce domaine). Dans ce type
de domaine les aspects traitements d'états et comportements des objets, prend le
pas sur la gestion des données. En plus de cet atout UML traite également sans
difficulté majeur le domaine del 'informatique de gestion.
- La démarche
Avec merise la démarche est structurée en étapes et phases dont l'étude

préalable, l'étude détaillée, la réalisation et la mise en œuvre. Il correspond en
effet au cycle de vie d'un système d'information. Et l'ensembJe des résultats
produits à chaque étape constitue le cycle de décision. Merise propose donc une
démarche en cascade, c'est-à-dire qu'une étape ne peut être entamée que si
l'étape précédente est achevée. Cela nécessite une organisation minutieuse du
projet. Dans Je cas contraire l'on pourrait noter quelques blocages ou une
lenteur dans le processus de modélisation du système d'information.
Avec le RUP basé sur UML, la démarche est itérative, incrémentale guidée par
les besoins des utilisateurs du système, et centrée sur l'architecture logicielle. La
démarche itérative permet de mieux comprendre et représenter un système
complexe. Le périmètre du système à modéliser est défini par les besoins des
utilisateurs (les utilisateurs définissent ce que doit être le système). Le but du
27
Ingénieur MIAGE
3.2.4- Choix d'une méthode d'analyse
Suite à notre étude comparative entre l'approche systémique avec Merise et

l'approche Objet avec UML, Nous opterons donc pour une méthode d'analyse
suivant l'approche Objet dont l'UP (Unified Process) tout en s'appuyant sur le
langage UML pour la modélisation, dans l'étude conceptuelle de notre système.
En effet, nous devons concevoir et réaliser un système informatisé de gestion ce
que UML permet de faire aisément. Ensuite vue les circonstances et les délais de
notre projet nous optons pour une démarche itérative, incrémentale guidée par
les besoins des utilisateurs du système. De plus nous souhaiterions organiser nos
programmes en rassemblant les données et les traitements en vue de former des
entités cohérentes, logiques et stables. Enfin nous aimerions faciliter les
éventuelles évolutions et maintenances du système.
v' Tableau récapitulatif des raisons du choix
N" Raison du choix d'UML

1 Conception et réalisation d'un système informatisé de gestion
Utilisation et mise en œuvre d'une démarche itérative, incrémentale guidée par les besoins des
2 utilisateurs du système
3 Délais de réalisation (Délais court)
Organisation des programmes en rassemblant les données et les traitements en vue de former
4 des entités cohérentes, logiques et stables, facilement manipulables et réutilisables
5 Aisance dans les éventuelles évolutions et la maintenance du système
29
Ingénieur MIAGE
Partie 2:
Phase d'élaboration
30
Ingénieur MIAGE
Chapitre 4 : Présentation de la méthode de conception
4.1 UML
La présentation d'UML et du formalisme qu'il propose sont nécessaires pour

une meilleure appréciation de ce langage.
4.1.1 Présentation d'UML
UML est la forme contractée de ''Unified Modeling Language" qui peut se

traduire par "Langage Unifié de Modélisation". C'est le résultat de la fusion de
plusieurs langages de modélisation objet dont Booch, OMT, OOSE. 11 a hérité
des points forts de ces langages précédents. Il est à présent un standard défini
par l'OMG (Object Management Group).
UML fournit en effet une notation pour la représentation graphique des éléments
de modélisation de métamodèle. II permet donc via ses diagrammes de spécifier,
construire, visualiser et décrire les artefacts d'un système logiciel.
4.1.2 Le formalisme d'UML
UML est décomposé en trois sous ensembles complémentaires qui permettent

une modélisation complète du système. Ce sont: les vues, les diagrammes et
les modèles d'éléments.
j,i, Les vues
Les vues sont les observables du système. Elles fournissent une description du
système d'un point de vue organisationnel, dynamique, temporel, architectural,
géographique, logique, etc. La description complète du système peut être
obtenue par une combinaison de toutes les vues. On dénombre cinq (5) vues qui
sont:
- La vue logique
Elle décrit l'agencement interne du système. La vue logique modélise les

éléments et mécanismes principaux du système. Elle montre comment satisfaire
les besoins des utilisateurs. (C'est le COMMENT).
31
Ingénieur MIAGE
MémorredefmdeCycle
.,--
- La vue d'implémentation
La vue d'implémentation montre l'organisation des modules en "sous-systèmes",

les interfaces des sous-systèmes et leurs dépendances (avec d'autres sous-
systèmes ou modules).
- La vue des processus
C'est la vue temporelle et technique. Elle fournit une décomposition du système

en terme de processus (tâches); donne une vue des interactions entre les
processus (leur communication), la synchronisation et la communication des
activités parallèles.
- La vue de déploiement
Cette vue décrit les ressources matérielles et la répartition du logiciel dans ces
ressources : la disposition et nature physique des matériels, ainsi que leurs
performances, l'implantation des modules principaux sur les nœuds du réseau,
les exigences en terme de performances (temps de réponse, tolérance aux fautes
et pannes ... ). (C'est le OÙ).
- La vue des cas d'utilisation
Cette vue définit les besoins des clients du système et centre la définition de
l'architecture du système sur la satisfaction (la réalisation) de ces besoins. Cette
vue établit un lien entre les quatre autres vues de l'architecture. Elle motive les
choix, permet d'identifier les interfaces critiques et force à se concentrer sur les
problèmes importants. (C'est le QUOI et le QUI).
32
Ingénieur MIAGE
~ Les diagrammes
Les diagrammes sont des éléments graphiques. Ils servent à la description des
contenus des vues. Nous distinguons treize (13) diagrammes depuis UML 2
repartis en trois groupes : les diagrammes structurels ou statiques, les
diagrammes comportementaux et les diagrammes d'interactions ou dynamiques.
- Les diagrammes structurels ou statiques
Ils sont au nombre de six (6). Ce sont:
Le diagramme de classes : Il représente 1 'ensemble des classes de notre

système et les relations entre elles.
Le diagramme d'objets: Il fournit une représentation des instances de classes

(objets) utilisées dans le système.
Le diagramme de composants : C'est la représentation des composants du

système d'un point de vue physique. Il montre comment ils sont mis en œuvre
( fichiers, bibliothèque, base de données, .. )
Le diagramme de déploiement : Il permet la représentation des éléments

matériels ( ordinateurs, périphériques, réseaux, système de stockage ... ) et la
répartition des composants du système sur ces éléments et leurs interactions
avec ceux-ci (les éléments matériels).
Le diagramme des paquetages : Il représente les dépendances entre les

paquetages.
Le diagramme de structure composite: C'est la description des relations entre

les composants d'une classe.
- Les diagrammes comportementaux ou dynamiques
Ils sont au nombre de trois (3). Ce sont :
Le diagramme des cas d'utilisation : Il fournit l'ensemble des fonctionnalités

du système en identifiant les interactions possibles entre le système et les
acteurs.
Le diagramme d'états-transitions: C'est la description sous la forme d'états

finis du comportement des différents objets.
33
Ingénieur MIAGE
Le diagramme d'activité: C'est la description sous forme de flux ou

d'enchaînement d'activités du comportement du système ou de ses composants.
- Les diagrammes d'interactions ou dynamiques
Ils sont au nombre de quatre (4). Ce sont:
Le diagramme de séquence: C'est la représentation séquentielle du

déroulement des traitements et des interactions entre les éléments du système
et/ou de ses acteurs.
Le diagramme de communication : C'est la représentation simplifiée d'un

diagramme de séquence se concentrant sur les échanges de messages entre les
objets.
Le diagramme global d'interaction: C'est une description des enchaînements

possibles entre les scénarii préalablement identifiés sous forme de diagrammes
de séquences.
Le diagramme de temps : Il sert à la description des variations d'une donnée au

cours du temps.
4.2 Le Processus Unifié
Le processus unifié (en anglais Unified Process) est un processus de

développement logiciel, itératif et incrémental, centré sur 1 'architecture, piloté
par les cas d'utilisation.
» L'objectif principal d'un système logiciel est de répondre aux besoins des
utilisateurs. Les cas d'utilisation donnent une description de ces attentes.
L'ensemble des cas d'utilisation fournit la liste des fonctionnalités complètes du
système.
» L'architecture d'un système est une description du système sous

différentes vues. Le processus unifié produit une représentation du système
sous les vues décrites par UML (la vue des cas d'utilisation, la vue logique, la
vue d'implémentation, la vue des processus et la vue de déploiement). Cette
représentation constitue l'architecture du système.
~ Avec le processus unifié le développement d'un produit logiciel ne se fait

pas d'un coup. Le projet est subdivisé en de mini projets qui constituent des
34
Ingénieur MIAGE
Mémoire de fin de Cyde
.,--
itérations. Chaque itération comprend les différentes étapes de l'enchaînement
d'activités (expression des besoins, analyse, conception, implémentation et test).
L'achèvement d'une itération donne un incrément.
Les caractéristiques du processus unifié sont fortement liées et importantes.

L'architecture définit Je contexte de travail de chaque itération. Les cas
d'utilisation quant à eux permettent d'établir les objectifs et d'orienter le travail
de chacune d'entre elles (les itérations).
Le processus unifié répète un certain nombre de fois une série de cycles.

Chaque cycle se termine par la livraison d'une version du logiciel. Un cycle
comprend quatre (4) phases qui sont : la création, l'élaboration, la construction
et la transition. Chacune de ces phases est constituée d'itérations. Nous allons
décrire ces différentes phases.
La phase de création
Elle donne une vue du projet sous forme de produit fini. Au cours de cette
phase les principaux cas d'utilisation sont présentés, une architecture générale
du système est donnée et les risques majeurs, les délais et les coûts sont
identifiés. Elle répond aux questions suivantes :
- que va faire le système pour les utilisateurs ?
- quelle sera l'architecture du futur système ?
- quels seront les délais, les coûts, les ressources et les moyens à déployer ?
La phase d'élaboration
Cette phase permet de préciser la plupart des cas d'utilisation, de concevoir

l'architecture du système. De celle-ci découlera l'architecture de référence. A la
fin de cette phase, le chef de projet doit être capable de prévoir les activités et
d'estimer les ressources nécessaires à l'achèvement du projet.
La phase de construction
Le produit est construit lors de cette phase. L'architecture de référence se

transforme en produit complet. Celui-ci (le produit) comprend tous les cas
d'utilisation que les chefs de projet, en accord avec les utilisateurs ont décidé de
réaliser pour cette version.
La phase de transition
35
Ingénieur MIAGE
.,--
Une version "bêta" du produit est livrée. Un groupe d'utilisateurs essaye le
produit afin de détecter les anomalies et les défauts. Cette phase suppose des
activités comme la formation des utilisateurs clients, la mise en œuvre d'un
service d'assistance et la correction des anomalies constatées.
A chaque cycle, les développeurs devront construire toutes les représentations

du produit logiciel afin de réussir celui-ci (le cycle). Ces représentations sont les
suivantes:
- un modèle de cas d'utilisation;
- un modèle d'analyse;
- un modèle de conception ;
- un modèle d'implémentation;
- un modèle de déploiement ;
- un modèle de test ;
- une architecture du système.
Le processus unifié est un processus de développement complet. Il fournit une

architecture du produit demandé et permet de répondre aux besoins des
utilisateurs. Son découpage en cycle permet un meilleur suivi et une maîtrise
du processus de développement.
36
Ingénieur MIAGE
Chapitre 5: Identification des besoins
5.1- Les principaux besoins des utilisateurs
5.1.1- La Gestion des Encaissements
La gestion des encaissements consiste à la collecte de fonds à partir des

clients suite à des ventes de produits ou services de la société, ou suite à des
règlements de factures concernant les abonnements et Jes communications
téléphoniques. Ces fonds sont d'abord collectés au niveau des guichets lorsque
les clients se présentent pour l'achat de produits ou le règlement de leurs
factures. Ces fonds collectés sont, après certaines vérifications de cohérences,
transférés en banque dans les comptes bancaires de la société.
Les besoins concernant la gestion des encaissements sont les suivants :
- les encaissements
- la clôture d'encaissements.
- la recette des encaissements clôturés
- le transfert en banque des recettes obtenues.
5.1.2- La Gestion des Décaissements
La gestion des décaissements consiste aux diverses sorties de fonds à

partir des caisses ou des comptes bancaires de la société. En effet, les
décaissements surviennent suite à des demandes de décaissements exprimées à
partir des achats (règlements de factures fournisseurs), des ordres de mission,
des notes de services, des retraits de dépôt de garantie, de la paie, ... etc. Ces
demandes exprimées devront suivre un processus de validation par la hiérarchie.
Ce qui conduira à l'établissement des pièces de décaissements en vue de les
remettre aux bénéficiaires. Pièces qui leur permettront de rentrer en possession
de leur du à partir des caisses ou des comptes bancaires de la société.
Les besoins concernant le processus de décaissement sont les suivants :
- enregistrement des décaissements à effectuer (les demandes de décaissement :

les factures fournisseurs, les factures d'eau et d'électricité, ... etc.).
- application des autorisations de décaissements.
37
Ingénieur MIAGE
- établissement des pièces de décaissements (chèques, ordres de virement, pièces

de caisse).
- remises des pièces de décaissements aux bénéficiaires.
5.1.3- La Gestion des Caisses
La gestion de la caisse correspond à toutes les activités intervenant dans le

processus de gestion d'acquisition de liquidités suffisante pour faire face aux
règlements en espèces des bénéficiaires de certains décaissements de la société.
Elle prend en compte également des opérations d'encaissements exceptionnels
tels que les règlements des frais d'interconnexion entre les différents opérateurs
de Télécommunication, des emprunts obligataires ... etc.
Les besoins exprimés concernant le processus de gestion des caisses sont les
suivant:
- établissement des demandes de fond pour alimenter la caisse.
- édition du journal de caisse.
- édition des pièces justificatives des recettes et dépenses de caisse.
- alimentation de caisse.
- règlements en espèces des décaissements.
- encaissements.
5.1.4- La Gestion des Comptes Bancaires
La gestion des comptes bancaires correspond à toutes les activités

intervenant dans le processus d'entrée et de sortie de fonds des comptes
bancaires de la société. Elle consiste à la création de nouveaux comptes
bancaires et à la tenue de ceux existant pour l'exploitation financière et les
épargnes de la société. Elle consiste également à la conservation des relations
permanentes entre les banques de la société en vue d'assurer le contrôle et le
suivi des comptes bancaires par l'acquisition régulière des documents relatifs à
ces comptes bancaires.
Les besoins exprimés concernant la gestion des comptes bancaires sont les
suivants:
- enregistrement des relevés des comptes bancaires de la société.
38
Ingénieur MIAGE
- enregistrement des mouvements bancaires du relevé de compte.
- édition des mouvements bancaires
- édition des états de rapprochement bancaire.
- consultation des disponibilités de chaque compte bancaire.
5.1.6- La Gestion des Emprunts Bancaires
La gestion des emprunts bancaires correspond à un ensemble de

procédures permettant à la société d'obtenir au près de la banque un prêt
financier qui lui permettra la réalisation de ses grands projets (Les projets
nécessitant beaucoup de fonds). Ces procédures consistent en effet, à des
demandes de prêts effectuées au près de la banque. Demandes accompagnées
des propositions de plan d'amortissement de l'emprunt avec ou sans intérêts, en
plus des garanties gérées par les sociétés de garantie. Ces demandes vont
ensuite être accordées par la banque, ce qui conduira à la réception des fonds
empruntés par la société sur ses comptes bancaires. La société procèdera donc
au remboursement de ces fonds à la banque.
Les besoins exprimés concernant la gestion des emprunts sont les suivants :
- enregistrement des demandes d'emprunt.
- édition d'un plan d'amortissement d'emprunt.
- soumission des demandes a la banque.
- réception des fonds de l'emprunt.
- remboursement de l'emprunt selon le plan d'amortissement.
5.2- Les Diagrammes de Cas d'utilisation
Les diagrammes de cas d'utilisation nous permettront de structurer

les besoins des utilisateurs et les objectifs de notre système de trésorerie. Les
deux symboles clés du diagramme de cas d'utilisation (Acteur et Cas
d'utilisation) son représentés dans le tableau ci-après :
39
Ingénieur MIAGE
Formalisme Description
Un acteur est soit une

~
/". personne ou un autre système
Acteur Acteur
interagissant avec le système
à modéliser.
Cas d'utilisation CS Le cas d'utilisation

correspond à un objectif du
système, motivé par un besoin
d'un ou plusieurs acteurs.
Les diagrammes de cas d'utilisation sont représentés par la figure suivante:
*
Acleur_1
Asso_2 (::::)
.J?_
/
Acteur_4
Les besoins ayant été identifiés dans la section précédente, nous procèderons
dans la suite de cette section, à l'identification des acteurs intervenant dans les
différents processus métiers de gestion de la trésorerie, et nous présenterons les
diagrammes de cas d'utilisation correspondant à ces processus.
5.2.1- Cas d'utilisation de la Gestion des encaissements
- les encaissements sont effectués par les agents de guichets. Il en est de même
pour la clôture des encaissements.
- le chef des guichets effectue ensuite la recette des encaissements clôturés.
- le chargé de la tenue des comptes bancaires effectue le transfert en banque des

recettes obtenues.
Le Diagramme correspondant est le diagramme de cas d'utilisation ci-dessous:

40
Ingénieur MIAGE
--
•
Gesti<ln des encalssaneru
Encasser
'' .......•...
·~:_,e
.
Agent Guichet .......•...
-.........
-......... l ""
~ ude>
<inchJde,.
"' - S'auheriifi er
.,.-,,7
,.,-
,.,-
.cn,é1ud•"
Diagramme de cas d'utilisation de la gestion des encaissements
5.2.2- Cas d'utilisation de la Gestion des décaissements ,.
- la secrétaire de la tresorerie enregistre les demandes décaissements
- une autorisation de décaissement est accordée par le DG, le DFC et le chef de

trésorerie, selon le montant de la demande.
- le trésorier établit une pièce de décaissement relative à un décaissement

autorisé, et remet ensuite la pièce de décaissement au bénéficiaire.
Le diagramme de cas d'utilisation concernant la gestion des décaissements est le

suivant:
41
Ingénieur MIAGE
Gestion des décaissenerts
- - l_<include>
/ 1 /
01'lfGuichal
Remellre pièce aJ bénéficiaire
Diagramme de cas d'utilisation de la gestion des décaissements
5.2.3- Cas d'utilisation de la Gestion des caisses
Le scénario ci-dessous fait une description du processus de gestion des caisses :
Les différents éléments suivants sont effectués par le caissier :
- établissement des demandes de fond pour alimenter la caisse.
- édition du journal de caisse
- édition des pièces justificatives des recettes et dépenses de caisse.
- alimentation de la caisse.
- règlements en espèces des décaissements.
- encaissements.
Le diagramme de cas d'utilisation de la gestion des caisses le suivant:
42
Ingénieur MIAGE
Diagramme de cas d'utilisation de la gestion des caisses
5.2.4- Cas d'utilisation de la Gestion des comptes bancaires
Le chargé de la tenue des comptes bancaires effectue l'enregistrement des

relevés des comptes bancaires de la société, l'enregistrement des mouvements
bancaires du relevé de compte, l'édition des mouvements bancaires et l'édition
des états de rapprochement bancaire.
Le DG, le DFC et le chef de trésorerie peuvent consulter les disponibilités de

chaque compte bancaire sur chaque banque.
Le Diagramme de cas d'utilisation de la gestion des comptes bancaires est

représenté par la figure suivante :
43
Ingénieur MIAGE
Gestion des coi)1Jles baltcaires
"- -·nclude>
--- <indude>
/ /
/
/.
<onclude>
Diagramme de cas d'utilisation de la gestion des comptes bancaires
5.2.5- Cas d'utilisation de la Gestion des emprunts bancaires
- enregistrement des demandes d'emprunt
- édition d'un plan d'amortissement d'emprunt.
- soumission des demandes a la banque
- réception des fonds de l'emprunt
- remboursement de l'emprunt selon le plan d'amortissement.
44
Ingénieur MIAGE
Ges1i<Jr1des emputs bancaires
OFC
~
Oia,gé l'l!l.alion bancaire
/
,,.,~-/
/ <induite>
/
/ /
/
/
/
Diagramme de cas d'utilisation de la gestion des emprunts bancaires
45
Ingénieur MIAGE
5.3- Spécification détaillées des besoins
Nous procéderons dans cette étape, à la description détaillée des besoins

des utilisateurs par l'élaboration de plusieurs diagrammes de séquences
systèmes venant illustrer chacun des diagrammes de cas d'utilisation effectués
dans la section 5.2 (diagramme des cas d'utilisation).
Les diagrammes de séquences permettent en effet de représenter les

collaborations entre les utilisateurs du système et les objets selon un point de
vue temporel. On y met l'accent sur la chronologie des envois de messages.
Formalisme
1 "" '.'i•t 1
Un ~cteur ''
Message ~
Ou-ée
d'activation
5.1.1- Diagrammes concernant la gestion des encaissements
La description détaillée du processus de gestion des encaissements est donnée

par le scénario suivant :
- l 'Agent de guichet effectue un encaissement. Il a en retour l'édition du reçu

d'encaissement qui est remis au client.
- il effectue ensuite avant le dépôt des recettes obtenues, la clôture de ses

encaissements. Ce qui donne lieu à l'édition du journal des encaissements.
- à partir des journaux des encaissements, le Chef de Guichets fait la recette des
encaissements clôturés par chacun des agents de guichet. A chaque recette des
46
Ingénieur MIAGE
Mémoire de fin de Cycle •.._.
_.
encaissements, nous avons un message de confirmation du bon déroulement de
la recette.
- le Chef de Guichets autorise ensuite, avec l'accord du DFC ou du Chef de

Trésorerie, le transfert de ces recettes en banque.
- les recettes obtenues à partir des encaissements, sont enfin transférées dans un
compte bancaire de la société soit par la banque ou par un trésorier.
Encalwmeot Beçtte Enœlw;ment 1 1 T,anûrt Recette
Agent_Gulc:het Olef_Guic:het Olarg6_T enu_9>mpte_Bancalre
Encaissement:
E
Edition reçu d'encaiYiement
TI
Ooture desenœlseements
Ec!iUon du journal desenc:ai-ments jJ

Effectuerreœtte
êonfirmetion recette erfectu6'e

îJ
Auto~sation tmn!fert des reœtt~s
~
Confirh'1etion autori&11tlon effedu~e
11
Diagramme de séquence de la gestion des encaissements
5.1.2- Diagrammes concernant la gestion des décaissements
Le scénario suivant donne une description détaillée du processus de gestion des

décaissements:
- la Secrétaire de la trésorerie saisit tous les décaissements à effectuer (les Objets

de décaissement : les factures fournisseurs, les factures d'eau et d'électricité, ...
etc.).
47
Ingénieur MIAGE
Mémoire de rm de Cycle
- des autorisations de décaissement sont accordées aux différents objets de

décaissements respectivement par le DG, le DFC et le Chef de trésorerie selon le
montant du décaissement à effectuer.
- un agent de trésorerie établit par décaissements autorisés une ou des pièces de

décaissements ( chèques, ordres de virements, pièces de caisses) pour chacun des
bénéficiaires des différents décaissements.
- les pièces établies sont enfin remises aux bénéficiaires.
lnlention PocaiWtmoot Qocaiwamont
Secretaire~T~rerie Autorite_Tre~rerie Tré+rier
Enregiotrement lnt.ention de dêcai&&ement

r
1 1 1
Confjnnation Enregis,,ement
~ 1 1
1
Autorisati~n du dêcai&Bmont
Confinnâtion a.utori&ation
Etablissement pièce de décaissement

1 T
1 1
Edition pièce 1" dêcai....,,nent
1-E
1
1
Re.mim pièce flU bénêficiaire
1
1
1-E
1
Confirmatio,I. remise Pfèce

1 :JJ
Diagramme de séquence de la gestion des décaissements
5.1.3- Diagrammes concernant la gestion des caisses
Le scénario ci-dessous fait une description du processus de gestion des caisses
- le caissier établit une demande de fond pour alimenter sa caisse.
- il justifie sa demande de fond par l'édition et la présentation du journal de

caisse et les justificatifs des recettes et dépenses des caisses.
- après autorisation de décaissement donnée par le DG, le DFC ou le Chef de

trésorerie selon le montant de la demande, le caissier reçoit un chèque pour
alimenter sa caisse.
48
Ingénieur MIAGE
- la caisse étant alimentée, le caissier peut procéder aux règlements des

différents bénéficiaires des décaissements en espèces.
- il est à noter que le caissier reçoit également des encaissements.
* *
1Dl~Dlhi!D Decaiaam~!l1 M~ui1~~m~ai Tmmmô~
Cel!l!lier Autorlte_~lsaement
Demande de fonds
-
- 1
- Domandc eff'cctuêe
: Edition Joumal de calsae

1
-
- 1
-- Joumal de cai!!Be
1
Autorisation alllm entatton de caisse
- 1
--
Autorisation accordée
1
Allimentation de cel95e
:
C.lase alfimcntéc J
-
1
j Dêcalsscm ent en c5Pèce

-
- 1
-- Décaf881:!'rnent cffectuëc
1
:
:
Encaissement ex.ceptionel
! - 1
~-
Enc::.a 1S5cmcnt effectué
;
1
Diagramme de séquence de la gestion des caisses
5.1.4- Diagrammes concernant la gestion des comptes bancaires
Le processus ci-dessous décrit la gestion des comptes bancaires :
- des chargés de comptes reçoivent régulièrement les relevés des comptes

bancaires de la société.
- ils les enregistrent dans le système et saisissent les mouvements bancaires y

figurant.
- ils peuvent éditer les mouvements sur chaque compte pendant une période, des
états de rapprochement bancaires . . . etc.
49
Ingénieur MIAGE
- le DFC et le chef de trésorerie peuvent donc avoir en temps réel la disponibilité

de chaque compte bancaire et plusieurs autres données concernant les comptes
bancaires.
BIDIIIIG a1uaim t.1,unuamanl Banr.aim a1oa1.1a
*
Chargé tenue qomple bancaire
1
: ,.,~~;~ ~,...•....
1
1
'1<
Relevé enregorué
~;~]
1
1
1
1
1
1
1
1
1
1
1
1
1
1 1 1
Enregî,tn,menl ol>'iralion bancaln,
tJ
1
1 1
1 1
,_ opération bancaire enregira:rée
,~ 1 1
1 1 1
1 1 1
1 1 1
1 1 1
1 1 1
1 1 1
1 1 1
1 1 1
1 1 1
1 1 1
1 1 1
1 1 1
1 1 1
1 1 1
Diagramme de séquence de la gestion des comptes ban.caires
5.1.5- Diagrammes concernant la gestion des emprunts
Le scénario suivant présente une description de la gestion des emprunts :
- le chef de trésorerie effectue une demande d'emprunt accompagnée d'un plan

d'amortissement de 1 'emprunt.
- ces éléments sont validés par le DFC et le DG
- le chargé des relations bancaires soumet ensuite cette demande et ce plan

d'amortissement à la banque. Il reçoit l'accord de la banque concernant la
validation de l'emprunt
- le charger de la tenue des comptes bancaires de la société reçoit sur l'un de ces
comptes, les fonds de l'emprunt et procède à son remboursement selon le plan
d'amortissement.
50
Ingénieur MIAGE
Mimoire de fin de Cycle
fllmli ,.. Etrpynt
Emilllllon- ~
~ :0
Soumi9on ~ la banque
1J
Fond•,.ou
Diagramme de séquence de la gestion des emprunts bancaires
51
Ingénieur MIAGE
Chapitre 6: Analyse des besoins
L'analyse des besoins est la deuxième activité du cycle de développement du

processus unifié. Au terme de cette activité, nous produirons les modèles
d'analyse comportant : le diagramme du modèle du domaine, les diagrammes
d'activité et les diagrammes d'état-transition. Dans un premier temps nous
présenterons le modèle du domaine. Nous procéderons ensuite à l'élaboration
des diagrammes d'activité. Et enfin nous terminerons notre chapitre avec les
diagrammes d'états-transitions.
6.1- Modèle du domaine
L'élaboration du modèle des classes du domaine permet d'opérer une transition

vers une véritable modélisation objet. Ce modèle nous permettra de définir les
classes qui modélisent les entités ou concepts présents dans le métier de gestion
de la trésorerie. Nous présenterons le modèle de domaine selon les différents
domaines de gestion de la trésorerie dont la gestion des encaissements, la
gestion des décaissements, la gestion des caisses, la gestion des comptes ainsi
que des emprunts bancaires.
Il est à noter que les classes du modèle de domaine ne contiennent pas

d'opérations, mais seulement des attributs. Nous procèderons à une modélisation
suivant les étapes ci-après :
- identification des entités ou concepts du domaine ;
- identification des associations entre ces entités ;
- identification des attributs de ces entités ;
52
Ingénieur MIAGE
6.1.1 Domaine de gestion des encaissements
).> Entités du domaine
Entité Description
Référent.iel
Type_Mouvement Type de mouvement
Motif_Mouvement Motif du mouvement
Piece_ Reglement Pièce de règlement
Type_Lieu_Regelement Type de lieu de règlement
Site Site de Togo Telecom
Lieu_Regelement lieu de règlement
Client Client de Togo Telecom
Mode_Reglement Mode de règlement
Piece_Recette Pièce des recettes d'encaissement
Devise Devise
Type_Banque Type de banque
Banque Banque
Compte_Bancaire Compte bancaire
Piece_Transfert_Recette Pièce de transfert des recettes d'encaissement
Exploitation
Mouvement_Tresorerie Mouvement de trésorerie (Encaissements)
Recette_Encaissement Recettes d'encaissements
Transfert_Recette Transfert des recettes d'encaissments
53
Ingénieur MIAGE
.,
nia-,~•
~ Associations entre les entités
- Plusieurs mouvements peuvent être du même type
- Plusieurs mouvements peuvent être du à un seul motif
- Plusieurs mouvements peuvent être effectués au vu d'une seule pièce.
- Plusieurs mouvements peuvent s'effectuer dans un seul lieu de règlement.
- Plusieurs mouvements peuvent être effectués par un seul client.
- Plusieurs mouvements peuvent avoir le même mode de règlement.
- Plusieurs mouvements peuvent avoir la même devise.
- Une recette d'encaissement est effectuée suite à un ou plusieurs mouvements.
- Plusieurs recettes peuvent donner lieu à une seule pièce de recette
- Plusieurs recettes peuvent être effectuées par les chèques d'une seule banque
- Un transfert en banque est effectué suite à une ou plusieurs recettes
- Plusieurs transferts peuvent être effectués vers le même compte bancaire
- Plusieurs transferts peuvent être effectués vers le même site Togo Telecom
- Plusieurs comptes bancaires peuvent être de la même banque
- Plusieurs banque peuvent être du même du type
- Plusieurs lieux de règlements peuvent être du même type
- Plusieurs lieux de règlements peuvent se trouver sur le même site
~ Attributs des entités

Attribut Description Type Taille
Type_Mouvement
code_type_mouvm Code du Type de Mouvement entier 10
libelle_type_mouvm Libelle du Type de Mouvement chaine de caractère 250
Motif_Mouvement
code_motif Code du Motif du mouvement entier 10
54
Ingénieur MIAGE
libelle_motif Libelle du Motif du mouvement chaine de caractère 250
Piece_Reglement
code_piece Code de la Pièce de règlement entier 10
libelle_piece Libelle de la Pièce de règlement chaine de caractère 250
Type_Ueu_Regelement
code_type_lieu Code du Type du Lieu de règlement entier 10
libelle_type_lieu Libelle du Type du Lieu de règlement chaine de caractère 250
Site
code_site Code du Site entier 10
libelle_site Libelle du Site chaine de caractère 250
Ueu_Regelement
code_lieu Code du Lieu de règlement entier 10
libelle_lieu Libelle du Lieu de règlement chaine de caractère 250
Oient
code_client Code du Client entier 10
nom_client Nom du Client chaine de caractère 250
prenoms_client Prénoms du Client chaine de caractère 250
Mode_Reglement
code _mode_reglement Code du Mode de Règlement entier 10
libelle_mode_reglement Libelle du Mode de Règlement chaine de caractère 250
Piece_Recette
code_piece Code de la Pièce de recette entier 10
libelle_piece Libelle de la Pièce de recette chaine de caractère 250
Devise
code_devise Code de la Devise entier 10
libelle_devise Libelle de la Devise chaine de caractère 250
SS
Ingénieur MIAGE
Type_Banque
code_type_banque Code du Type de Banque entier 10
libelle_type_ banque Libelle du Type de Banque chaine de caractère 250
Banque
code_banque Code de la banque entier 10
libelle_banque Libelle de la banque chaine de caractère 250
Compte_Bancaire
code_compte Code du Compte bancaire entier 10
numero_ compte Numéro de Compte bancaire chaine de caractère 250
Pieœ_Transfert_Recette
Code de la Pièce de transfert des

code_piece recettes entier 10
Libelle de la Pièce de transfert des

libelle_piece recettes chaine de caractère 250
Mouvement_Tresorerie
numero_mouvement Numéro du Mouvement de trésorerie entier 10
date_mouvement Date du Mouvement date 10
Montant entré dans la caisse lors du

montant_entre mouvement entier long 20
Montant sorti de la caisse lors du

montant_sorti mouvement entier long 20
mouvement_partiel Mouvement Partiel booléen 1
mouvement_national Mouvement National booléen 1
reference_piece _reglement Référence de la Pièce de Règlement chaine de caractère 10
date_piece_reglement Date de la Pièce de Règlement date 10
etat_mouvement Etat du Mouvement booléen 1
Recette_Encaissement
numero_recette Numéro de la Recette chaine de caractère 10
56
Ingénieur MIAGE
.,
Îlr;l!*lrtal•
date_recette Date de la Recette date 10
reference _piece_ recette Référence de la Pièce de la Recette chaine de caractère 10
date _piece_recette Date de la Pièce de la Recette date 10
date_debut_encaissement Date de Début des Encaissements date 10
date_fin_ encaissement Date de Fin des Encaissements date 10
montant_total_ encaissement Montant Total des Encaissements entier long 20
montant_recette Montant de la Recette entier long 20
etat_recette Etat de la Recette booléen 1
Transfert_Recette
numero_transfert Numéro du Transfert chaine de caractère 10
date_transfert Date du Transfert date 10
reference _piece_transfert Référence de la Pièce du Transfert chaine de caractère 10
numero_piece Numéro de la Pièce chaine de caractère 10
montant_tata !_recette Montant Total des Recettes entier long 20
montant_transfert Montant du Transfert entier long 20
etat_transfert Etat du Transfert booléen 1
> Modèle du domaine de gestion des encaissements
Le modèle du domaine de gestion des encaissements est représenté par la figure

suivante:
57
Ingénieur MIAGE
Mode_Reglement Devise Pie ce_Transtert_Recette

Type_!Aouvement
+ code_mode_reglement + code_devlse + code_piece . Object
+ code_type_mouvm + libelle_mode_reglement + llbelle_devise + llbelle_piece : Object
+ llbelle_type_mouvm
1 ..
Motll_Mouvement
1 ..•
+ code_motlf
+ llbelle_molif Mouvement_Treaorerie Tran&fert_Recette
+ numero_mouvement 1~ 1 + numero_recette + numero_transtert

+ date_mouvement + date_recette date_transtert
+ montant_entre + code_piece_recette + relerence_plece_tran
+ montant_aortl + relerence_plece_recette + numero_piece
+ mouvement_partlel + date_plece_recette montant_total_recette
+ mouvement_natlonal + date_debut_encaillBl!ment - montant_transtert
+ reference_plece_reglement + date_lln_encalseement - etat_transtert
+ date_plece_reglement + montant_total_encalseement
+ etat_mouvement + montant_recette
+ etat_recette
Piece_Reglement
+ code_plece · 1
+ llbelle_piece : 1
1 .. •
:,
Compte_Bancalre
Type_Lleu_Regelement Piece_Recette Banque + code_compte
Lieu_Regelement
+ code_type_lieu : &Ill: + code_plece + code_banque
+ numero_compte
+ llbelle_type_lleu : &trll
+ code_lleu : stln + llbelle_plece + libelle_banque
+ llbelle_lleu : llrir
Slte_Source
+ code_site
Client + libelle_site
+ code_clle nt
+ nom_cllent
Site .. 1 prenoms_cllent Type_Banque
+ code_slte :, - code_type_bqnaue
+ libelle_&ite : &I - libelfe_type_bqnaue
Modèle du domaine de la gestion des encaissements
58
Ingénieur MIAGE
6.1.2 Domaine de gestion des décaissements
~ Entités du domaine
Entité Description
Référentiel
Motif_Mouvement Motif du mouvement
Piece_Reglement Pièce de règlement
Type_Lieu_Regelement Type de lieu de règlement
Site Site de Togo Telecom
lieu_Regelement lieu de règlement
Beneficiaire Bénéficiaire du décaissement
Type_Beneficiaire Type de bénéficiaire
Responsable_Tresorerie Responsable habilité à autoriser des décaissements
Mode_Reglement Mode de règlement
Piece_Demande_Decaissement Pièce de demande de décaissement
Devise Devise
Banque Banque
Exploitation
Demande_Decaissement Demande de décaissement
Autorisation_Decaissement Autorisation de décaissement
Mouvement_Tresorerie Mouvement de trésorerie (Décaissements)
59
Ingénieur MIAGE
» Associations entre les entités
- Plusieurs Demandes de décaissements peuvent être dues au même motif.
- Plusieurs Demandes de décaissements peuvent correspondre à la même pièce.
- Une demande de décaissement correspond à une ou plusieurs autorisations
- Plusieurs responsables de trésorerie peuvent autoriser plusieurs demandes de

décaissements.
- Plusieurs mouvements peuvent être du même type
- Plusieurs mouvements peuvent être du à un seuJ motif
- Plusieurs mouvements peuvent être effectués au vu d'une seule pièce.
- Plusieurs mouvements peuvent s'effectuer dans un seul lieu de règlement.
- Plusieurs mouvements peuvent avoir le même mode de règlement.
- Plusieurs mouvements peuvent avoir la même devise.
- Plusieurs mouvements peuvent être effectués pour un seul bénéficiaire.
- Plusieurs bénéficiaires peuvent être du même type
- Plusieurs lieux de règlements peuvent être du même type
- Plusieurs lieux de règlements peuvent se trouver sur le même site

Type_Mowement
Motif_Mouvement
60
Ingénieur MIAGE
code_motif Code du Motif du mouvement entier 10
libelle_motif Libelle du Motif du mouvement chaine de caractère 250
Piece_Reglement
Type_Lieu_Regelement
code_type_lieu Code du Type du Lieu de règlement entier 10
libelle_ type_lieu Libelle du Type du Lieu de règlement chaine de caractère 250
Site
code_site Code du Site entier 10
libelle_site Libelle du Site chaine de caractère 250
Lieu_Regelement
code_lieu Code du Lieu de règlement entier 10
libelle_lieu Libelle du Lieu de règlement chaine de caractère 250
Bénéficiaire
code_benef Code du bénéficiaire entier 10
nom_ benef Nom du bénéficiaire chaine de caractère 250
prenoms_ benef Prénoms du bénéficiaire chaine de caractère 250
Mode_Reglement
code_mode_reglement Code du Mode de Règlement entier 10
Type_Beneficiaire
code_type_benef Code du type de bénéficiaire entier 10
libelle_ type_benef Libelle du type de bénéficiaire chaine de caractère 250
Devise
61
Ingénieur MIAGE
libelle_ devise Libelle de la Devise chaine de caractère 250
Type_Banque
libelle_type_banque Libelle du Type de Banque chaine de caractère 250
Banque
libelle_ banque Libelle de la banque chaine de caractère 250
Compte_Bancaire
numero_compte Numéro de Compte bancaire chaine de caractère 250
Responsable_Treso
Code du responsable de trésorerie

code_resp habilité à autoriser u décaissement entier 10
Noms du responsable de trésorerie

nom_resp habilité à autoriser u décaissement chaine de caractère 250
Fonction du responsable de trésorerie

fonction_resp habilité à autoriser u décaissement chaine de caractère 250
numero _ mouvement Numéro du Mouvement de trésorerie entier 10
date_mouvement Date du Mouvement date 10
Montant entré dans la caisse lors du

montant_entre mouvement entier long 20
Montant sorti de la caisse lors du

montant_sorti mouvement entier long 20
mouvement_partiel Mouvement Partiel booléen 1
mouvement national Mouvement National booléen 1
reference _piece _reglement Référence de la Pièce de Règlement chaine de caractère 10
date _piece_reglement Date de la Pièce de Règlement date 10
62
Ingénieur MIAGE
.,
'lqM(-lralf'II
etat_mouvement Etat du Mouvement booléen 1
Demande_Decaissement
numero _demande Numéro de la Recette chaine de caractère 10
date_ demande Date de la Recette date 10
montant Référence de la Pièce de la Recette chaine de caractère 10
etat_demande Date de la Pièce de la Recette date 10
etat_autorisation Date de Début des Encaissements date 10
)> Modèle du domaine de gestion des décaissements
Le modèle du domaine de gestion des encaissements est représenté par le figure

suivante:
63
Ingénieur MIAGE
- Devise
Mode_Reglement Motif_Mowement
+ code_devise
+ code_mode_reglement + code_motlf :
• libelle_devi&e Piece_Demande_DecaiEment
+ libelie_mode_reglement ,., + libelle_motif :
+ code_plece : &!ring
1
- + llbelle_piece : etring
r.,._Mo=m,m u /. 1
0 .. 1
+ code_type_mouvm -
• llbollo_eyp,_m,.,m ~
1
1.. 1 .. •
. 1
o .. •
fa.
.. .
• Mouvement_T re10rerie Demande_Decaiament
+ numero_mowement + numero_demande : String
+ date_mouvement + date_demande : String Responaable_Tre&0rerie
Piece_Reglement
+ montant_entre
+ montant_a:>rti 1 .. • -..
1 .. 1'
+ montant
+ etat_demande
:
:
String
Strtng + code_responsable : etr
+ code_piece :
+ llbelle_piece :
~
-=:-
1 .. 1
1 .. •
- + mouvement_partiel
+ mouvement_natlonal
+ etat_11utori111tlon : String
.
~ + nom_responsable : etr
+ fonction : etr
/ • •l•••œ..J>l•œ-•olomool
+ date_piece_reglement •
+ elaLmowement
Lieu_Regelement
• code Heu : llin .
• •• ,11;_11., '"'' \
1 .••
Banque
1 • ..
. , .. 1
+ code_banque
+ libelle_banque
'~,
··
1
Type_Lleu_Regelement Beneficlaire
--
.. .
+ type_code_lieu : 511 + code_beneflclalre
t type_llbelle_lieu : &Ir + nom_beneticialre
I
- prenoms_beneficlaire
1 .. 1 Compte_Bancalre
1 .. 1
,u
j. 1 + code_compte
Sile + numero_comple
• code_&ite :s Type_Banque
Type_Beneficiaire 1
+ libelle_slte : s - code_type_bqnaue
+ code_type_beneticlaire - llbelle_type_bqnaue
+ llbelle_type_beneficiaire
Modèle du domaine de la gestion des décaissements
64
Ingénieur MIAGE
Mémoire de fin de Cycle ~
6.1.3 Domaine de gestion des comptes bancaires
Entité Description
Référentiel
Type_Personne_Avis Type de personne concerné par l'avis bancaire
Type_Avis_Bancaire Type d'avis bancaire
Devise Devise
Banque Banque
Exploitation
Releve_Bancaire
Mouvement_Bancaire_Banque
Avis_Bancaire
~ Associations entre les entités
- Plusieurs Relevés bancaires peuvent correspondre à un seul compte bancaire
- Un relevé bancaire possède un ou plusieurs mouvements bancaires
- Plusieurs mouvements bancaires peuvent être du même type
- Plusieurs mouvements bancaires peuvent être effectués par Je même type de

pièce
- Plusieurs mouvements bancaires peuvent avoir la même devise
- Un avis bancaire peut avoir plusieurs mouvements bancaires

- Plusieurs avis bancaires peuvent être du même type
65
Ingénieur MIAGE
- Plusieurs avis bancaires peuvent concerner le même type de personne
:,. Attributs des entités

Type_Mouvement
Devise
Type_Banque
libelle_type_ banque Libelle du Type de Banque chaine de caractère 250
Banque
Compte_Bancaire
numero_compte Numéro de Compte bancaire chaine de caractère 250
Type_Avis
code_type_avis Code du type de l'avis bancaire entier 10
libelle_ type_avis Libelle du type de l'avis bancaire chaine de caractère 250
Releve_Bancaire
numero_releve Numéro du relevé bancaire entier 10
66
Ingénieur MJAGE
date_releve Date du relevé bancaire date 10
Date de début des mouvements du

date_debut_mouvement date 10
relevé bancaire
Date de fin des mouvements du relevé

date_fin_mouvement date 10
bancaire
Montant total des mouvements au

montant_total_debit entier long 20
débit
Montant total des mouvements au

montant_total_credit entier long 20
crédit
etat_releve Etat du relevé bancaire booléen 1
numero _mouvement Numéro du mouvement bancaire chaine de caractère 10
date_mouvement Date du mouvement bancaire date 10
numero_piece_mouvement Numéro de la pièce du mouvement chaine de caractère 10
montant_mouvement Montant du mouvement entier long 10
etat_mouvement Etat du mouvement booléen 1
Avis_Bancaire
numero_avis Numéro de l'avis bancaire chaine de caractère 10
libelle_avis Libelle de l'avis bancaire chaine de caractère 250
date_avis Date de l'avis bancaire date 10
date_operation Date de l'opération figurant sur l'avis date 10
montant_operation Montant de l'opération de l'avis entier long 20
frais_impaye Frais d'impayé en cas d'avis d'impayé entier long 20
Code de la personne concernée par

numero_personne chaine de caractère 10
l'avis
Nom de la personne concernée par

nom_personne chaine de caractère 250
l'avis
Nom de la personne concernée par

prenoms_personne chaine de caractère 250
l'avis
67
Ingénieur MIAGE
Mimoire de rm de Cyde
~ Modèle du domaine de gestion des comptes bancaires
Le modèle du domaine de gestion des encaissements est représenté par la figure

suivante:
68
Ingénieur MIAGE
C
0 ••
.:: C C
C l!! C D g
_ED D l!l CI!!
a, iQ.>GC~
•1 i .!! •• ~I [ °i l!l .,.1
e•• l~~cEe!E
.! 1 1.!!-. 10
(el E "i .s .s C .!!1 E E C
~~~~E~~glt
+ + + + + + + + +
Mémoire de fm de Cycle .----
6.1.4- Domaine de gestion des emprunts bancaires
Type_Emprunt Type d'emprunt
Motif_Emprunt Motif des emprunts
Societe_Garentie Société de garantie de l'emprunt
Type_Periode_Remoursement [Tvpe de la période de remboursement d'emprunt
Piece_Regelement Pièce de règlement
Mode_Regelement Mode de règlement
Banque Banque
Demande_Emprunt Demande de l'emprunt
Reception_Emprunt REeception de l'emprunt
Remboursement_Emprunt Remboursement de l'emprunt
~ Associations entres les entités
- Plusieurs demandes d'emprunts peuvent être du même type
- Plusieurs demandes d'emprunts peuvent avoir le même motif
- Plusieurs demandes d'emprunts peuvent être de la même société de garantie
- Plusieurs demandes d'emprunts peuvent avoir le même type de période de

remboursement
- Plusieurs demandes d'emprunt peuvent correspondre à un seul compte

bancaire
70
Ingénieur MIAGE
- Une demande d'emprunt peut donner lieu à plusieurs réceptions d'emprunt
- Une demande d'emprunt peut donner lieu à plusieurs remboursements
- Plusieurs réceptions et remboursements d'emprunt peuvent être effectués avec

le même type de pièce
- Plusieurs réceptions et remboursements d'emprunt peuvent avoir le même

mode de règlement
- Plusieurs réceptions et remboursements d'emprunt peuvent concerner le même

compte bancaire
- Plusieurs banques peuvent être du même du type

Type_Emprunt
code_type_empr Code du Type d'emprunt entier 10
libelle_type_ empr Libelle du Type d'emprunt chaine de caractère 250
Motif_ Emprunt
code_motif Code du Motif de l'emprunt entier 10
libelle_motif Libelle du Motif de l'emprunt chaine de caractère 250
Societe_Garentie
code_societe Code de la société de garantie entier 10
libelle_ societe Libelle de la société de garantie chaine de caractère 250
Type_ Periode_Remoursement
Code du Type de période de

code_ type_periode remboursement entier 10
Libelle du Type de période de

libelle_ type_ periode remboursement chaine de caractère 250
71
Ingénieur MIAGE
Mémoire de fin de Cycle •
n.z,.,...1ra,r,.
Mode_Reglement
code_mode_reglement Code du Mode de Règlement entier 10
Devise
Type_Banque
libelle_type_banque Libelle du Type de Banque chaine de caractère 250
Banque
Compte_Bancaire
numero _compte Numéro de Compte bancaire chaine de caractère 250
Piece_Regelement
Demande_Emprunt
numero_demande Numéro de la demande d'emprunt entier 10
libelle_demande Libellé de la demande d'emprunt chaine de caractère 250
date_demande Date de la demande date 10
montant_demande Montant de la demande d'emprunt entier long 20
taux_interet Taux d'intérêt de la l'emprunt réel 20
comission_garantie Commission sur la garantie entier long 20
date_debut_reception Date début de réception de l'emprunt date 10
72
Ingénieur MIAGE
date_fin_reception Date de fin de réception de l'emprunt date 10
Date de début de remboursement de

date_ debut_remboursement l'emprunt date 10
Date de fin de remboursement de

date_fin_remboursement l'emprunt date 10
etat_demande Etat de la demande d'emprunt booléen 1
etat_soumission_demande Etat de soumission de la demande booléen 1
Reception_Emprunt
numero_reception Numéro de la Réception de l'emprunt chaine de caractère 10
date_reception Date de la Réception de l'emprunt date 10
reference_piece _reception Référence de la Pièce de la Réception chaine de caractère 10
montant Montant reçu entier long 10
reference _piece_reglement Référence de la Pièce du Règlement chaine de caractère 10
date_piece _reglement Date de la Pièce du Règlement date 10
Remboursement_Emprunt
Numéro de remboursement de
numero_remboursement l'emprunt chaine de caractère 10
date_remboursement Date de remboursement date 10
montant_remboursement Montant du remboursement entier long 20
reference_piece_reglement Numéro de la Pièce de règlement chaine de caractère 10
date _piece_reglement date de la Pièce de règlement date 10
), Modèle du domaine de la gestion des emprunts bancaires : le modèle

du domaine de la gestion des emprunts bancaires et représenté par la
figure suivante :
73
Ingénieur MIAGE
Receptlon_Emprunt
+ nurnerojeceptlon
+ date_receptlon
+ reference_plece_reception
+ montant
+ reference_piece_reglement
+ date_piece_reglement
Type_Emprunt
+ code_type : String
+ libelle_type : String
Demande_Emprunt
+ numerc_demande .. 1
+ llbelle_demande
Motif_Emprunt Mode_Regelement
+ date demande
+ code_motif : dring ~ 1.: ~ + montant_demande + code_plece_regelement + code_mode_regelement
+ llbelle_motif : String 1 .. 1 + tau,c_interet + llbelle_piece_regelement + libelle_mode_regelement
+ comil&ion_garantie
+ date_debut_receptlon
+ date_fln_reception
Societe_Garentie + date_debut_remboureement
+ date_fln_remboursement
+ code_11>ciete : String
+ etat_demande
+ nom_aoclete : String
+ etat_soum1S6lon_demande
+ numero_remboureement
+ date_remboureement
Type_Periode_Remoursement
+ code_type : String
1.: + montant_remboureement
+ reference_piece_reglement
+ llbelle_type : String + date_piece_reglement
1 .. 1
Banque Type_Banque
+ code_compte
+ numero_compte
____1_•. _
1~::J
1 . .-
...i+ code_banque
+ llbelle_banque
1 •. •
1 •. 1
- +
+
code_type_bqnaue
libelle_type_bqnaue
Modèle du domaine de la gestion des emprunts bancaires
74
Ingénieur MIAGE
6.2- Les Diagrammes d'activités
Les diagrammes d'activités permettent de mettre l'accent sur les traitements. Ils
sont donc particulièrement adaptés à la modélisation du cheminement de flots de
contrôle et des données. Ils permettent ainsi de représenter graphiquement le
déroulement des Cas d'utilisation représentés par les différents diagrammes
élaborés au chapitre 5. Nous présenterons à la suite de cette section, deux (2)
Diagrammes d'activités par domaine de gestion de la trésorerie.
6.2.1- Gestion des encaissements
Nous représenterons les diagrammes d'activités concernant les cas d'utilisation

Encaisser et Clôturer Encaissements
6.2.1.l - Encaisser
Les traitements effectués pour réalisation du cas d'utilisation Encaisser sont les
suivants:
- choix du type d'encaissement
- recherche d'une vente ou d'une facture client
- au cas où cette vente ou cette facture existe on a l'affichage des

informations sur la vente ou la facture client
- sélection du mode de règlement
- saisie des informations du mode de règlement
- saisie du montant
- enregistrement de l'encaissement
- édition du reçu de l'encaissement
Le diagramme correspondant à ces traitements est représenté par la figure ci-

dessous:
75
Ingénieur MIAGE
Mémoire de fin de Cycle -----
Oioiâr Type encaimement
Rechercher Vente Rechercher Factuia client
(Non] (Non]
Aua.me vente Auœne facture
Affteher Informations Vente Afficher Informations Facture
Seledionner Mode Reglement
Saitir information Mode n,glement
Diagramme d'activité du cas d'utilisation« Encaisser»
76
Ingénieur MIAGE
6.2.1.2 - Clôturer Encaissements
Les traitements effectués pour réalisation du cas d'utilisation Clôturer

Encaissements sont les suivants :
- sélection du guichet
- recherche des encaissements non clôturés
- au cas où ces encaissements existent on a leur liste et l'affichage de leurs

informations
- saisie du montant de la clôture
- saisie des informations du mode de règlement
- vérification des critères de clôture
- au cas où ces critères sont respectés on a l'enregistrement de la clôture des

encaissements non clôturés
- édition du journal des encaissements

après:
77
Ingénieur MIAGE
----
Setectlonner Guichet
Rechercher Encai-menbl non Clotutéa
Afficher infonnations Encai-ments
Sailir Montant Clotun,
Velffleratten, de dotun,
[Non)
Annuler Clotun,
Ennogi*9r aotun,
Editer Journal des encai-ments
Diagramme d'activité du cas d'utilisation« Clôturer encaissement»
6.2.2- Gestion des décaissements
Nous représenterons les diagrammes d'activités concernant les cas

d'utilisation Autoriser Décaissement et Etablir pièce de décaissement.
6.2.2.1 - Autoriser Décaissement
Les traitements effectués pour réalisation du cas d'utilisation Autoriser

Décaissement sont les suivants :
recherche de la demande de décaissement à autoriser
78
Ingénieur MIAGE
.---
-
.
au cas où la demande recherchée existe, on a l'affichage des informations
sur la demande de décaissement
saisie des informations sur l'autorisation de décaissement
enregistrement de 1' autorisation de décaissement

dessous:
Rechercher Demande de Décai-ment
(t-bn]
Demande de Décai11SBment inexifllante
Afficher lnfonnations Demande de Décai9SBment
Saisir information Autorisation Décai9SBment
Autoriser D6caisement
Diagramme d'activité du cas d'utilisation.« Autoriser décaissement»
6.2.2.2 - Etablir pièce de décaissement
Les traitements effectués pour la réalisation du cas d'utilisation Etablir pièce de

décaissement sont les suivants :
- recherche d'un décaissement autorisé
au cas où le décaissement autorisé existe, on a l'affichage des

informations sur le décaissement autorisé, puis l'affichage des
bénéficiaires du décaissement
79
Ingénieur MIAGE
,••
__
saisie des informations de la pièce de décaissement
édition de toutes les pièces de décaissement pour chacun des bénéficiaires

dessous:
Rechercher Déc:aillll!ment Autorisé
[Non]
DécaiSEement Inexistant
Afficher lnfonnations DécaiSEement
Afficher Bénëficiaire(s} Décaillll!rnent
Saisir lnfonnations Piàce de Décaissa ment
Editer Piàce Décaillll!rnent par Bénéficiaire
Diagramme d'activité du cas d'utilisation« Etablir pièce de décaissement»
6.2.3- Gestion des caisses

Alimenter caisse et Décaisser espèce.
6.2.3.1 - Alimenter caisse
Les traitements effectués pour réalisation du cas d'utilisation Alimenter caisse

sont les suivants :
80
Ingénieur MIAGE
recherche d'une demande de fonds

--
~~-
au cas où la demande existe, on a l'affichage des informations sur la

demande
saisie des informations sur la réception des fonds
saisi du montant de l'alimentation de la caisse
validation de 1 'alimentation de la caisse

dessous:
Rechercher Demande de Fonds
[Non)
Demande lnexislante
Afficher Informations Demande
Renœigner Informations Réceptions de fonds
Saisir montant d'alimentation de la cal998
Valider Alimentation Cai91111
Diagramme d'activité du cas d'utilisation« Alimenter caisse»
81
Ingénieur MIAGE
6.2.3.2 - Décaisser espèce
Les traitements effectués pour réalisation du cas d'utilisation Décaisser espèce

sont les suivants :
- recherche de la pièce de décaissement en espèce remise par le bénéficiaire
au cas où la pièce de décaissement existe on a l' affi.chage des

informations sur le décaissement à effectuer
- édition du reçu de décaissement à remettre au bénéficiaire

dessous:
Rechercher Pièce de décaiS&ement espèce
[Non)
Pièce Inexistante
Afficher Informations Pièce
Valider décaiS1Sement espèees
Editer reçu de décalœement
Diagramme d'activité du cas d'utilisation« Autoriser décaissement»
82
Ingénieur MIAGE
6.2.4- Gestion des comptes bancaires

Recevoir Relevé Bancaire et Saisir Opération Relevé Bancaire.
6.2.4.1 - Recevoir Relevé Bancaire
Les traitements effectués pour la réalisation du cas d'utilisation Décaisser

espèce sont les suivants :
sélection du compte bancaire correspondant au relevé bancaire
- affichage des informations sur le compte bancaire
saisie des informations sur le relevé de compte
validation de la réception du relevé de compte

dessous:
Sélectionner Compte Bancaire
Afficher Informations Compte
Sai!iÎr Informations Relevè de Compte
Période non conforme
Valider Réception Relevè de Compte
••
Diagramme d'activité du cas d'utilisation« Recevoir relevé bancaire»
83
Ingénieur MIAGE
MémoiredefindeCycle
6.2.4.2 - Saisir Opération Relevé Bancaire
Les traitements effectués pour la réalisation du cas d'utilisation Saisir

Opération Relevé Bancaire sont les suivants :
sélection du compte bancaire
affichage des informations sur le compte bancaire
sélection du relevé bancaire non saisi
affichage des informations sur le relevé de compte
saisie des informations sur le mouvement bancaire
validation du mouvement

dessous:
Sélectionner Compte Bancaire
Afficher Informations Compte Bancaire
Séledionner Relevé Bancaire non Sai&i
Afficher Information& Relevé de Compte
Saisie Mouvement Bancaire
Validation Mouvement
:•'
Diagramme d'activité du cas d'utilisation« Saisir mouvements bancaires»
84
Ingénieur MIAGE
6.3- Les Diagrammes d'état-transition

----
Ce sont les diagrammes UML servant à représenter des automates à états
finis, sous forme de graphes d'états, reliés par des arcs orientés qui décrivent les
transitions. Les diagrammes d'états-transitions permettent de décrire les
changements d'états d'un objet ou d'un composant, en réponse aux interactions
avec d'autres objets/composants ou avec des acteurs.
» Formalisme
Formalisme Description
Un état se caractérise par sa durée

et sa stabilité, il représente une
[ Etat
] conjonction instantanée des
Etat valeurs des attributs d'un objet.
Transition .- Une transition représente le

passage instantané d'un état vers
un autre. Une transition est
déclenchée par un événement. En
d'autres termes : c'est l'arrivée d'un
événement qw conditionne la
transition.
Début
• Ils matérialisent le début
diagramme d'état transition
du
Fin ~ Ils matérialisent la fin du

diagramme d'état transition
Les diagrammes d'états-transition nous permettront donc de représenter les

différents états que peuvent prendre certains objets de notre système. Ils nous
permettront également de représenter les événements qui provoquent ces
changements d'état. Les diagrammes d'états-transition seront ainsi associés à
chacune des classes du système qui peuvent prendre plusieurs états lors de leur
cycle de vie. Concernant notre système de gestion de trésorerie, les objets
pouvant prendre plusieurs états proviennent des classes énumérées ci-dessous :
85
Ingénieur MIAGE
- Demande_Decaissement,
----
- Mouvement_Tresorerie,
- Recette_Encaissement,
- Transfert,Recette,
- Releve_Bancaire,
- Demande_Emprunt.
6.3.1- Classe Demande Decaissement
Une demande de décaissement à sa création prend l'état Demande

soumise. Elle change d'état après avoir été validée par les personnes qui
autorisent les décaissements. En l'occurrence le Directeur Général, le Directeur
Financier, le Chef de trésorerie. Ainsi elle passe à l'état Demande autorisée. Le
diagramme d'état transition représentant ces changements d'état du dit objet est
schématisé par la figure ci-dessous:
Demande de décaiS!il!ment soumise
<<autorisation de décai:;œment>>_________ ~
r Demande autorisée l/
Diagramme d'état-transition de la classe« demande decaissement »
6.3.2- Classe Mouvement Tresorerie
A leurs créations, les mouvements de trésoreries (Encaissements)

prennent l'état Mouvement effectué. Après clôture des encaissements, ces
mouvements passent à l'état Mouvement Clôturé. Ils peuvent dès lors faire
objet de recettes d'encaissements. Ces étapes sont illustrées par le schéma ci-
dessous:
86
Ingénieur MIAGE
Mouvement clôturê
----
<<Oôture enca7nt>>
Mouvement effectuë 1
Diagramme d'état-transition de la classe mouvement tresorerie
6.3.4- Classe Recette Encaissement
Les recettes d'encaissements sont d'abord à l'état Recette effectuée. Ils

peuvent faire objet de validation ou de refus en cas d'incohérence entre le total
des encaissements concernant la recette et le montant total de la recette. En cas
de cohérence, la recette est validée et peut être transférée en banque. En cas
d'incohérence la recette est refusée puis des vérifications sont effectuées pour
corriger ces incohérences.
Recette validée -c•:

• Recette effectui'le
1 Recette non valide 1 ..,@
Diagramme d'état-transition de la classe« recette encaissement»
6.3.5- Classe Transfert Recette
A leur création, les transferts de recettes sont d'abord à l'état Transfert

en attente. Ils changent d'état suite à la validation permettant à un agent de
trésorerie chargé du transfert des recettes vers la banque, de transférer ces
recettes dans un des comptes bancaires de la société. Ils passent alors à l'état
Transfert validé. Après que le transfert soit effectué, l'état des transferts
devient Transfert effectué. Enfin le chargé de la tenue des comptes bancaires
de la société, après réception du relevé bancaire attestant que le transfert a été
effectivement positionné sur le compte bancaire de la société, change l'état des
transferts pour les mettre à Transfert Positionné. Le schéma suivant représente
le diagramme d'état transition de la classe Transfet_Recette.
87
Ingénieur MIAGE
Tran,tert en attente
Tranlifert effectuè
Transtert politlonnè
Tranlifert validé
Diagramme d'état-transition de la classe« transfert recette»
6.3.6- Classe Releve Bancaire
Les relevés bancaires à leur réception sont enregistrés dans le système. Ils
prennent alors l'état Relevé enregistré. A la fin de la saisie des opérations
bancaires figurant sur le relevé, il change d'état et devient : Relevé saisi. Il est
ensuite consulté par le chef de trésorerie puis validé pour faire objet de
rapprochement bancaire. Il passe donc à l'état Relevé validé.
Releve bancaire validé
Releve bancaire enregittrè
ement bancaire>>
Releve bancaire saisi
Diagramme d'état-transition de la classe<< releve bancaire»
6.3.7- Classe Demande_Emprunt
A sa création une demande d'emprunt prend l'état Demande effectuée.

Accompagnée de son plan d'amortissement, elle est ensuite consultée, par la
hiérarchie dont le Chef de trésorerie, le Directeur Financier puis le Directeur
Général. Ceux-ci apportent leur validation après avoir accepté les conditions de
la demande d'emprunt. Ils peuvent également refuser la demande d'emprunt. La
demande passe alors respectivement aux états Demande Validée ou Demande
88
Ingénieur MIAGE
refusée. Après validation de la demande, elle est soumise à la banque. Elle
prend alors l'état Demande soumise. Et cette demande soumise peut être
accordée par la banque on refusée. La demande d'emprunt peut donc prendre les
états respectifs Demande accordée on Demande non accordée.
Demande d'emprunt non accordëe
ord de prèt>>
Demande d'emprunt soumise a la banque

Demande d'emprunt etfectuêe
<<Validation de la <<Soumission à 1
Demande d'emprunt validée Demande d'emprunt accordée par la banque
Diagramme d'état-transition de la classe« demande emprunt»
89
Ingénieur MIAGE
Chapitre 7: Conception du système
Précédant l'implémentation, la conception du système nous permettra d'effectuer

les choix technologiques et les modèle de conception. Ces modèles sont
composés des diagrammes de classes de conception et des diagrammes
d'interaction. Pour notre modèle, nous utiliserons comme diagramme
d'interaction les diagrammes de communication.
7.1- Les choix technologiques
7.1.1- La technologie à utiliser
Il existe de nos jours plusieurs technologies utilisées dans le monde du

développement des applications Informatiques. Avec les tendances actuelles,
nous pouvons affirmer que les technologies en vogue sont entre autre :
J2EE, .Net, XML ... etc. Nous procèderons donc, dans la suite de notre étude
technique, à une étude comparative entre ces technologies énoncées ci-dessus,
en vue d'en choisir une qui nous permettra d'aboutir à la réalisation de notre
système selon les besoins de la société, ses moyens et cela en respectant les
délais.
7.1.1.1- J2EE
Si les plates-formes Java sont aujourd'hui en passe de s'imposer sur le

marché mondial, SUN ne se satisfait pas de ce succès et pousse progressivement
la logique JAVA jusqu'au bout avec JAVA 2 Enterprise Edition (J2EE). Cette
plate-forme offre un grand nombre d'interfaces et de Framework qui répondent
aux besoins techniques des serveurs E-business d'aujourd'hui. Les serveurs
d'applications J2EE permettent de développer très rapidement des applications
complexes capables de supporter plusieurs milliers de transactions par secondes
et plusieurs centaines de milliers d'utilisateurs. En effet, avec J2EE quasiment
tout le code technique d'une application est géré par le serveur d'applications.
Celui-ci évolue indépendamment du projet et met à la disposition des utilisateurs
( développeurs, administrateurs) de plus en plus de fonctionnalités techniques
sans jamais modifier le code grâce aux spécifications J2EE. Nous pouvons
illustrer les différentes briques de l'architecture J2EE par le schéma ci-dessous:
90
Ingénieur MIAGE
Mémoire de fin de Cycle ----
JNDI JDBC JCA • .NS JAAS
MIii HOP JTS
Architecture de la plateforme J2EE
- servlets / JSP / JSF : permettent de construire un frontal Web, WAP ou

XML.
- RMI / IIOP : permettent de Faire communiquer les objets. Middleware

Synchrone
- EJB : pour la gestion des composants métiers.
- JTA / JTS : pour la gestion des transactions.
- JDBC : pour la gestion des accès base de données.
- JNDI : pour la gestion de l'annuaire des services.
- JCA: pour les connexions aux systèmes« legacy » (ERP, Mainframe)
- JAAS : pour la gestion de l'authentification et des droits d'accès.
- JMS : pour assurer une communication asynchrone. Middleware Orienté

Message.
- JavaMail: pour la gestion des mails.
Chacune de ces briques peut être choisie en fonction de critères techniques et/ou
financiers indépendamment des autres. Choisir une machine (IBM, SUN, HP,
... ), choisir un système d'exploitation (Windows, Solaris, Linux, AS400, ... ),
choisir une machine virtuelle Java (SUN, IBM, BEA, ... ), puis choisir différents
91
Ingénieur MIAGE
Mémoire de fm de Cycle .-
_ ••.•. •.
fournisseurs de service J2EE (BEA, IBM, ORACLE, BORLAND, ... ) permet

d'obtenir une configuration avec un rapport Qualité/ Prix cohérent.
7.1.1.2- Dot Net
Après s'être imposé dans le domaine des systèmes d'exploitation pour les
PC, Microsoft prépare avec .NET le système d'exploitation du Web, c'est-à-dire
une architecture logicielle au sein de laquelle des services applicatifs pourront
collaborer via Internet. L'objectif est donc de faire évoluer les solutions
Windows vers un modèle ASP ( applications hébergées) et proposer une plate-
forme logicielle sur laquelle les entreprises pourront s'appuyer pour échanger et
mettre à disposition des données et des services applicatifs. En effet Microsoft
.NET est le nom d'un ensemble de produits et de technologies informatiques de
l'entreprise Microsoft pour rendre ses applications portables ou facilement
accessibles par Internet.
Avec sa stratégie .NET, Microsoft se positionne sur le développement

d'entreprise avec les atouts nécessaires tels que : les Technologies objet et les
composants, Je XML, les Services Web, la Sécurité, la Gestion des codes
sources, les Documentations . . . etc.
Microsoft continue par ailleurs d'innover fortement sur les aspects IHM et les
aspects d'intégration avec une suite logicielle bien fournie comportant:
- les applications traditionnelles de Microsoft : les éditions de systèmes

d'exploitation et la suite bureautique de Microsoft.
- des logiciels serveurs : une gamme de solutions destinées à déployer et à

administrer les composants logiciels dans le cadre de l'architecture .NET. Entre
autres: "Application Center" qui permet de distribuer les applicatifs en mode
hébergé à des machines clientes; "Mobile Information Server" qui permet de
déployer les Services Web sur des appareils mobiles; "SQL Server" quant à lui,
stocke, retrouve et analyse des données XML structurées; "BizTalk" gère les
processus métiers et les échanges de données à l'intérieur ou à l'extérieur de
l'entreprise.
- les outils de développement avec en tête "Visual Studio .NET", qui fourni
une plate forme de développement objet avancée et riche en fonctionnalités
prêtes à l'emploi.
92
Ingénieur MIAGE
L'idée était donc de mettre en place, une nouvelle plateforme d'exécution de

--
. _.
systèmes logiciels, unique quelque soit le type d'application, et basée sur un

cœur autour du quel gravite 3 grands services dont :
- les services d'accès aux données : pour l'accès à toutes les bases de
données du marché, aux fichiers XML et autres sources de données . . . etc.
- les services de communication : pour assurer la communication avec

d'autres technologies et l'exposition de services applicatifs via les services web.
- les services de présentation: pour la réalisation d'interfaces Windows,

Web ou Mobile.
Le schéma ci-dessous permet donc de représenter ces 3 grands services gravitant

autour du noyau .NET
Services gravitant autour du Framework .Net
L'architecture de la technologie .NET est schématisée sur la figure ci-après:
93
Ingénieur MIAGE
PLINQ TPL
z
ADO.NET rn
-i
...•
ï1
0)
3
(D
~
...•
'
"7
Carnmon LilngUage lùltimtl "->
b
The .NET Framework Stack
Architecture de la plateforme .Net
- le CU: le CLI est la spécification .Net permettant d'exécuter des

programmes .Net.
- le CLR (Common Language Runtime) : c'est le cœur du Framework

.NET. Il contient le CLI (Corn.mon Language Infrastructure) et constitue tout
comme la JVM pour Java, l'environnement d'exécution des applications .Net.
Le CLR est aussi le gestionnaire de l'allocation dynamique de la mémoire
(Garbage collection), de la sécurité d'accès à l'application, de la vérification du
code, et du langage intermédiaire (IL) de .Net.
- Base Class Library: c'est une couche de l'architecture .Net, qui

rassemble des classes permettant les manipulations de chaînes de texte, la
gestion des entrées/sorties, des communications réseaux, des processus légers et
le design des interfaces utilisateur. Ces classes sont similaires à celles présentes
dans l'API Java développée par Sun Microsystems. Par exemple, la
manipulation des chaînes est disponible dans la classe String, dans les deux
langages; la différence étant qu'en Java il n'existe pas de type de base pour
manipuler les chaînes (on manipule des objets 'String'), alors qu'en .NET, le type
string (avec un 's' minuscule) a spécifiquement été défini.
- Classes d'accès aux données : Dans l'architecture .Net, c'est la couche

composée des bibliothèques de classes d'accès aux données. Nous avons
94
Ingénieur MIAGE
MémorredermdeCyde --
,_
ADO.Net, s'élevant sur les bases de l'ancien ADO (ActiveX Data Objects) utilisé
....
par les développeurs ASP, et permettant l'accès sous format XML aux interfaces
de bases de données SQL Server, ODBC, OLE DB, Oracle et Sybase, et bien sûr
aux fichiers XML. Nous avons également, les XML Classes permettent de
manipuler les données XML. On y trouve par exemple les classes XSLT
permettant la transformation d'un document XML vers n'importe quel type
d'autre document. Un autre exemple, il est très facile de charger un document
XML dans une table, et vice versa, grâce au XML sous-jacent.
- XML Web Services, Web Forms, Windows Forms : cette couche de

l'architecture .Net est utilisée pour la création de services web, de pages Web, et
d'applications Windows. Les deux premiers forment ASP.NET.
Si on pouvait reprocher par le passé à Microsoft une insuffisance patente sur les
aspects méthodologiques, l'éditeur américain, présente désormais architectures
et Framework comme autant de fondements indispensables à la qualité des
développements sur sa nouvelle plate forme. En effet, si la création des
composants objets, l'utilisation des Web Services et la création d'application en
général sont rendus toujours plus faciles, plus que jamais l'absence
d'anticipation et de conception sont autant de dangers pour les projets .Net.
./ Choix de la technologie
Après avoir passé en revue les besoins de la société, ses moyens puis, les
avantages et inconvénients des technologies énumérées ci-dessus, nous pouvons
dire que le système informatisé de gestion de trésorerie sera implémenté à partir
des technologies .Net. En effet, en plus des performances de ces technologies et
de leurs outils en évolution permanente, nous la maîtrisons mieux. Il sera donc
plus avantageux pour nous d'implémenter notre système à partir de ces
technologies dans la mesure où nous avons des délais à respecter. De plus il est à
noter que .Net est la plate forme de développement des systèmes logiciels,
utilisée au sein de notre entreprise .
Ayant effectué notre choix concernant les technologies à utiliser pour

l'implémentation de notre système, nous passerons dans la suite de notre étude
technique, aux spécifications techniques de nos serveurs d'applications et de
base de données.
95
Ingénieur MIAGE
7.1.2- Le choix de l'environnement de développement

--
-"""'
Depuis l'avènement du concept "Objets" dans le domaine du

développement d'applications, l'on a assisté à une prolifération des outils de
développements de logiciels. Il existe donc de nombreux EDI (Environnement
de Développement Intégrés) nous permettant de réaliser en peu de temps, des
applications conviviales et efficaces.
Avec les technologies DotNet et XML nous avons la possibilité de développer

notre système sous Web Matrix, SharpDevelop ou Visual Studio .Net.
7.2.2.1- Web Matrix
Web Matrix est un outil gratuit de développement web utilisant le langage

Asp.Net. Il permet de faire du Drag & Drop et génère du code, cela en vue de
faciliter le développement des applications. Hormis PHP et Jsp, Asp.net permet
de créer des applications web ou sites web dynamiques avec 1' environnement
d'exécution .Net Framework.
Il inclut un serveur web de test ( écrit en C#) dont le code source est fourni. Il
intègre également un outil de messagerie instantané "Microsoft Messenger"
pour faciliter le dialogue entre les développeurs. Il contient enfin une liste de site
internet consacré au développement web. Il est à noter que Microsoft ne fourni
pas de support pour WebMatrix. Et contrairement à Visual Studio .Net,
WebMatrix ne possède pas d'outil de débogage intégré, pas de service de
déploiement collaboratif, et ni la fonctionnalité d'IntelliSense (fonctionnalité
permettant d'accéder rapidement au code d'un langage de programmation)
En effet, WebMatrix est un EDI gratuit de Microsoft permettant de réaliser des

applications web avec le langage Asp.Net.
7.2.2. 2- SharpDevelop
SharpDevelop est un environnement de développement intégré Open

Source, permettant de faire du développement d'application en Visual Basic
.NET et en C#. Il fait parti, avec MonoDevelop des alternatives à Visual
Studio.Net de Microsoft. Comparativement à Visual Studio, SharpDevelop ne
supporte que partiellement l'explorateur de base de donnée, le débogueur est
moins abouti (pas de support de la fonction edit and continue), et il n'y a pas de
création automatique de DataSet typé, ni d'Entity Framework; le concepteur
WPF n'est pas non plus présent.
96
Ingénieur MIAGE
7 .2.2.3- Visual Studio
Visual Studio est quant à lui, un ensemble complet d'outils de

développement venant se greffer au Framework .Net pour permettre la
réalisation de plusieurs types de projets dont, les applications de Business
Intelligence, les applications Web ASP.NET, les Services Web XML, les
applications bureautiques et des applications mobiles quelque soit le langage de
programmation pris en charge par Microsoft (Vb.net, C#, J#, C++). Ces
langages permettent de mieux tirer parti des fonctionnalités du Framework
.NET, qui fournit un accès à des technologies clés simplifiant le développement
d'applications Web ASP et de Services Web XML grâce à Visual Web
Developer.
./ Choix de l'EDI
Il est clair que 1 'EDI qui sera utilisé pour le développement de notre système
de gestion de trésorerie sera Visual Studio .Net avec sa version 2005 car c'est
un EDI convivial, complet et simple d'utilisation .
7.1.3- Choix du Système de Gestion de Base de Données
De nombreux SGBD sont disponibles sur le marché. Ils offrent un vaste

panel de fonctionnalités, mais comportent également quelques faiblesses ou
inconvénients remarquables quant à leur acquisition, l'obtention de support
technique ou leur mise en œuvre. Les plus importants et ceux couramment
utilisés au sein des entreprises sont: ORACLE, SQL Server, DB2-
400, MySQL ... etc. Le choix d'un SGBD particulier parmi ceux-ci est
généralement fonction d'abord de la politique de l'entreprise concernant ses
fournisseurs, la sécurisation de ses données, le budget alloué, les compétences
déjà acquises en terme de développement et d'administration (au besoin le prix
de la formation), le système d'exploitation devant héberger le SGBD, les
architectures logicielles et matérielles. Et ensuite, la richesse fonctionnelle du
SGBDR, les ressources consommées (disques, mémoire, CPUs, Transactions par
secondes, nombre de connexions simultanées), le support technique que
l'entreprise souhaite avoir vis-à-vis de 1' éditeur, le type d'accès aux données
(OLTP, décisionnelle, reporting, mixte) et biens d'autres critères ... etc. Nous
pouvons citer :
97
lngénieu •. MIAGE
MémoiredefindeCyde
7.1.3.1- ORACLE
Oracle est un SGBDR (Système de Gestion de Bases de Données

Relationnelles), puissant et optimisé pour la gestion de gros volumes de
données (>200Go) et des traitements avec de nombreux utilisateurs (>300).
>"' Avenages d'ORACLE: Il est beaucoup avantageux d'utiliser ORACLE

comme SGBDR car nous avons avec ORACLE :
- Une richesse fonctionnelle
- Une fonction d'audit évolué
- Un Row Level Storage Security (RLSS) qui permet de ne faire apparaître

que certaines lignes des tables pour un utilisateur/une application donné.
- L'intégration LDAP, SSL, Unicode; réplication intégrée; capable de

mapper un fichier plat en table
- Le parallélisme, les caches nommés; la haute disponibilité; une grande

possibilité de tuning
- La compression des backups
- Les procédures stockés en PL-SQL (langage propriétaire Oracle, orienté

ADA) et également en JAVA ( depuis la 8.1. 7) ce qui peut s'avérer utile pour des
équipes de développement.
- Un Assistants performants via Oracle Manager Server, la possibilité de

gérer en interne des tâches et des alarmes
- La gestion centralisée de plusieurs instances
- Le concept unique de retour arrière (Flashback)
- La pérennité de l'éditeur: avec plus de 40% de part de marché
- Les réglages fins : dans la mesure où l'on connait suffisamment le moteur,

presque TOUT est paramétrable.
- L'accès aux données système via des vues, bien plus aisément
manipulable que des procédures stockées.
- Des Interfaces utilisateur remaniée et extrêmement riche, permettant le

tuning fin de requêtes par modification des plans d'exécution.
98
Ingénieur MIAGE
- Une architecture Multi-Générationnelle (MGA)
- Les Services Web et le support du XML
~ Inconvénients d'ORACLE : malgré ses nombreux avantages, ORACLE

présente quelques inconvénients dont :
- Des prix exorbitants, tant au point de vue des licences que des composants
matériels (RAM, CPU) à fournir pour de bonnes performances
- Une administration complexe, liée à la richesse fonctionnelle
- La forte demande de ressources, ce qui n'arrange rien au point précité,

Oracle est bien plus gourmand en ressource mémoire que ses concurrents, ce qui
implique un investissement matériel non négligeable. La connexion utilisateur
nécessite par exemple près de 700 Ko/utilisateur, contre une petite centaine sur
des serveurs MS-SQL ou Sybase ASE. Il est aussi Gourmand en espace disques
puisque la plupart des modules requièrent leur propre ORACLE_HOME de par
Je versionning de patches incontrôlés.
- Une porosité entre les schémas. Il est difficile de faire cohabiter de

nombreuses applications sans devoir créer plusieurs instances. Il manque
réellement la couche "base de données" au sens Db2/Microsoft/Sybase du terme.
- Méta modèle propriétaire, loin de la norme.
- Tables partitionnées, RAC ... uniquement possible à l'aide de modules

payants complémentaires sur la version
- La gestion des verrous mortels est mal conçue (suppression d'une

commande bloquante sans roll back)
- Faiblesses de l'optimiseur (ne distingue pas les pages en cache ou en

disque, n'utilise pas d'index lors de tri généraux, statistiques régénérées par
saccade ... )
- Une quantité de bugs proportionnelle à la richesse fonctionnelle, surtout

sur les dernières versions
- Gestion erratique des rôles et privilèges (pas possible de donner des droits
sur des schémas particuliers sans passer par leurs objets, désactivation des rôles
lors d'exécution de packages ... )
99
Ingénieur MIAGE
- Pas de type auto-incrément déclaratif: les séquences ne peuvent être

dédiées à une table spécifique (risque de mélange)
- Nombreuses failles de sécurités liées à J'architecture elle-même.
7.1.3.2- SQL Server
SQL Server est le SGBDR de la plateforme Microsoft. Il permet de

concevoir et d'implémenter aisément des bases de données performantes,
adaptées aux besoins des entreprises. Il propose en plus aux développeurs un
environnement de développement riche, souple et moderne permettant créer et
déployer des applications de bases de données fiables, puissantes et sûres. Il
permet également de partager des données entre diverses plates-formes,
applications et systèmes pour faciliter les connexions, tant internes qu'extemes.
~ Avantages de MS SQL Server : SQL Server présente de nombreux

avantages dont :
- Une administration aisée
- Des fonctions d'audit évoluées
- Une indépendance entre les diverses bases, facilitant l'intégration de

plusieurs applicatifs dans une même instance
- Une des bases les plus performantes sous Windows en configuration par
défaut
- Un Optimiseur statistique enrichi à flux tendu
- Réplication intégrée
- Le Clustering et le Monitoring
- Frontaux et assistants très poussés
- Langage T-SQL très convivial
- Intégration du CLR dans le moteur de base de données (Possibilité de

développer des applications de base de données en langage C#, vb.net et T-SQL)
- Sous-SELECT possible dans clause FROM
100
Ingénieur MIAGE
.,--
- Une gestion de l'indexation textuelle
- Intégration de Services Web (La prise en charge de standards ouverts,

existants ou nouveaux, tels que HTTP, XML, SOAP, XQuery et XSD
facilitera également les communications entre systèmes étendus d'entreprises
- Support du XML et XQuery
- Ordonnanceur intégré
- Outils très performant de Business Intelligence (SQL Server Analysis

Service, SQL Server Integration Service, SQL Server Reporting Service)
- Possibilité de d'implémenter des applications de base de données pour

Téléphones mobiles (avec SQL Server Mobile).
),>, Inconvénients de MS SQL Server :
SQL Server présente également des inconvénients dont :
- Distributions fortement liées au système d'exploitation
- Jungle des versions, mais fonctionnalités cantonnées dans les éditions

Enterprise, Developer et Standard
- Mono-plateforme (Microsoft Windows)
- Depuis la version 2005, plus de prise directe sur les tables système
(remplacées par de vues système)
- Pas de prise en charge du LDAP
- Toujours pas de cluster (hormis en actif-passif, en se basant sur le cluster

OS)
- Pas certifié SQLJ, pas d'intégration Java, orientation C#
- Pas d'héritage de table
- Fonctionnalités s'éloignant des normes en vigueur (CLR remplaçant Java,

fonctions dans clauses FROM, ... )
101
Ingénieur MIAGE
MémorredefmdeCyde .---
7.1.3.3- DB2-400
DB2-400 est le SGBD associé à cette gamme de minis ordinateurs

nommés AS/400, reconnu pour sa robustesse et sa grande stabilité. DB2-400
doit être considéré plus comme une surcouche de l'OS400, ce système
d'exploitation propriétaire mappant ses fichiers. Une table est donc un fichier
physique, et une vue ou un index sont des fichiers logiques. Ainsi, la
suppression d'une table peut donc se faire via un ordre SQL drop table ou via la
commande système DLTF. Un des avantages supplémentaires de l'utilisation de
l'ordre SQL est que tout objet logique associé à la table sera automatiquement
supprimé; l'ordre système quant à lui ne pourra passer avant qu'on ait
scrupuleusement supprimé les fichiers logiques associés. On en retirer les
avantages des défauts d'en environnement propriétaire, une grande stabilité. Il
est à noter que DB2-UDB for iSeries et DB2-UDB du monde
Unix/Linux/Windows n'ont en commun que leur nom. Il s'agit là de deux
produits distincts, développés par des équipes distinctes. En terme d'optimiseur,
de réplication et de couches bas niveau, rien ne les rapprochent. Même leur SQL
n'est pas 100% compatible.
7.1.3.4- MySQL
MySQL est un véritable serveur de base de données SQL multiutilisateurs et

multithreads. Il est conçu selon une configuration client/serveur. C'est un SGBD
suffisamment rapide et flexible pour gérer des historiques des images et bien
d'autres éléments du web. Les principaux objectifs de MySQL sont la rapidité,
la robustesse et la facilité d'utilisation. La base sur laquelle MySQL est
construite est un ensemble de routines qui ont été largement éprouvées pendant
des années dans des environnements de production exigeants. Même si MySQL
est encore en développement, il propose déjà un ensemble de fonctionnalités
riches et extrêmement utiles.
~ Avantages de MySQL
- Solution très courante en hébergement public
- Très bonne intégration dans l'environnement Apache/PHP
- Open Source, bien que les critères de licence soient de plus en plus
difficiles à supporter
102
Ingénieur MIAGE
MémorredefmdeCyde .-
- Version cluster depuis la version 4
- Facilité de déploiement et de prise en main.
- Plusieurs moteurs de stockage adaptés aux différentes problématiques.
~ Inconvénients de MySQL
- Ne supporte qu'une faible partie des standards SQL-92
- Support incomplet des triggers et procédures stockées
- Assez peu de richesse fonctionnelle
- Manque de robustesse avec de fortes volumétries
- Pas d'héritage de table
- Pas de vue matérialisée
- Pas d'ordonnanceur intégré
- Pas de partitionnement
- Cluster par clonage de base => impact prépondérant sur la volumétrie
./ Choix du SGBD
Vue les avantages et inconvénients que possèdent les différents systèmes de

gestion de base de données énumérés ci-dessus, nous avons opté pour
l'implémentation et le déploiement de la base de données du système de gestion
de trésorerie sous Microsoft SQL Server avec sa version 2005.
7.1.4- Récapitulatif des choix technologiques
En définitive nous pouvons affirmer que le système informatisé de gestion

de trésorerie sera réalisé avec la technologie Microsoft .Net 2.0 à partir de
l 'EDI Microsoft Visual Studio 2005 interagissant avec une base de données
implémentées sous Microsoft SQL Server 2005, le tout fonctionnant avec un
serveur web Microsoft Internet Information Server 6.0 tournant sous
Windows 2003 Server.
103
Ingénieur MIAGE
7.2- Les Diagrammes de classes de conception

----
Les diagrammes de classes de conception nous permettront de passer à la
phase d'implémentation du système. Ils viennent compléter le modèle du
domaine en ajoutant aux différentes classes les opérations correspondantes. Il est
à noter que les diagrammes de classes de conception prennent en compte les
choix technologiques. Etant donnés que notre choix ses porté vers la
technologie Microsoft .Net avec le langage vb.net, les différentes classes auront
un constructeur "new O". De plus les différentes classes de paramétrage du
système appelées classes référentiel auront toutes les même méthodes dont :
Ajouter ( ), Modifier ( ), Supprimer ( ), Lister ( ) et Afficher ( ). Nous mettrons
donc l'accent sur les méthodes des classes d'exploitation. Les diagrammes de
classes seront présentés selon les différents domaines de gestion de la trésorerie.
7.2.1- Gestion des encaissements
Les méthodes des classes du domaine de gestion des encaissements sont

présentées dans le tableau ci-dessous :
Opération Description Type Résultat Visibilité
Référentiel
new Constructeur Procédure - Publique
Ajouter Ajouter un élément Procédure - Publique
Modifier Modifier un élément Procédure - Publique
Supprimer Supprimer un élément Procédure - Publique
Lister Lister les éléments Fonction Collection Publique
Afficher Afficher un élément Fonction Objet Publique
Lister Lister les mouvements Fonction Collection Publique
Encaisser Enregistrer un Encaissement Procédure - Publique
Disponibilite Afficher la Disponibilité Fonction Chaine Publique
104
Ingénieur MIAGE
Afficher Afficher un encaissement Fonction Objet Publique
Montant_Total Afficher le Montant Total Fonction Objet Publique
Enregistrer la dôture des

Cloturer encaissements Procédure - Publique
Recette_Encalssement
Recetter Enregistrer une Recette Procédure - Publique
Lister Lister des recettes Fonction Collection Publique
Afficher Afficher une recette Fonction Objet Publique
Transfert_Recette
Transferer Enregistrer un Transfert de fonds Procédure - Publique
Lister Lister les transferts de fonds Fonction Collection Publique
Afficher Afficher un transfert un transfert Fonction Objet Publique
Le diagramme de classe de conception correspondant à ce tableau est présenté

par la figure suivante:
105
Ingénieur MIAGE
Mod11_Reglement Plece_Tnmslert_Recetta
+ code_mode_reglement + code_plece : Object

Devlœ
Type_Mouvement + libelle moda_reglement + llbelle_piece : Object
+ coda_devlse + newo : Object
+ code_type_mouvm : Objact
+ libella_deviœ
+ llbelle_type_mouvm ±
+ newO : Ob
+ new O : Objec
±
+ Ajouter O : Objec
+ Modifier O : Objec1 .. 1
Motll_Mouvement
Translert_Recette
+ code_motif Mouvement_Tresorerie
+ numero_tran&fert
+ llbelle_motlf : + numero_mouvement 1~ I • date_tran&lert
+ newO : Ot + data_mouvement Recette_Encal1&11ment + reference_plece_tran
+ Ajouter O : Ot + montant_enlnl + numero_plece
+ numero_recette
+ montant_mrtl montant_total_recette
+ data_recette
+ mouvement_partiel • montant_trandert
+ code_plece_recetta
1 .. 1 + mouvement_natlonal - etat_tranaert
+ referenoe_piece_recetta
+ code_plece : , < 1 + reference_plece_reglemant ,;::
1 1
•• + date_plece recette + new O : Object
+ llbelle_plece : 1 • + date_plece_reglement 1 . .* 1 + date_debu(::_encaisement
1 + Transferer O : Object
+ new O : Obj ·• + etat_mouvement + dat11_fin_encal1&11ment + Lister O : Object
+ Ajouter O : Obj + newo :O~eci + montant_tot11l_encai1&11m11nt + Afficher O : Object
Type_Lieu_Ragelement
+ Ll&lerO :O~eci + montant_recette
+ type_code_lleu : al + Encal1&11rO :O~eci + etat_recetta
+ type_llbelle_lleu : &lrij + Di&ponlblllte O :O~eci
+ newO : Objeci
1 . .*
+ Afficher O :O~eci
+ newo :Object + Receller 0 : Objeci
+ Montant_ Total O :O~eci
1 .. 1 + Ajouter O : Object + Ll&ter 0 : Objeci Compte_Bancalre
+ Cloturer O :O~aci
+ Afficher 0 : Object 1 ..
+ code_compte
Site
+ code site :
+ llbelle_&ite : &Il
llj 1 .. 1
1 . .' , ..• + numero_comple
+ newO :0
Site_Source
1 •. 1 + Ajouter O :0 + code_site
1 .. 1
+ newO : Ob. Plece_Recette + ModlflerO :0 + llbelle_sita
Client
+ A/outer O : Ob. + newo
Lleu_Ragalement + code_plece Banque
+ code_cllent + AjouterO
+ llbelle_piece
+ code_lleu : ain1 + nom_cllant + code_banque /?- __ 1 Type_Banque
1
+ libelle_lleu : &trin • prenom&_cllent + newO :C
+ llbelle_banque ------:::"1 . code_type_bqnaue
+ Ajouter O :C
+ newO : Obje + newO : Obj + new O :0 • libelle_lype_bqnaue
+ Ajouter O : Obje + Ajouter O : Obj 1
+ Ajouter O :0 ·· • + new O ; Object
+ Modifier O : 0 + Ajouter O : Object
±
Diagramme de classe de conception de la gestion des encaissements

106
Ingénieur MIAGE
Mémoire de fin de Cycle ••
--
7.2.2- Gestion des décaissements
Les méthodes des classes du domaine de gestion des décaissements sont

présentées dans le tableau ci-dessous :
Référentiel
new Constructeur Procédure -
Decaisser Enregistrer un décaissement Procédure - Publique
Afficher_Decaissement Afficher un Décaissement Fonction Objet Publique
Decaissement_Total Afficher Total des Décaissements Fonction Chaine Publique
Lister_ Deca issement Lister les Décaissements Fonction Collection Publique
Etablir_Piece Etablir les Pièces de décaissement Procédure - Publique
Lister les Pièces de décaissements

Lister_Piece_Etablie Etablies Fonction Collection Publique
Enregistrer Remise de Pièce de

Remettre_Piece décaissement Procédure - Publique
Lister les Pièces de décaissements

Lister_Piece_Remise Remises Fonction Collection Publique
Oemande_Oecaissement
Enregistrer une Demande de

Demander décaissement Procédure - Publique
107
Ingénieur MIAGE
Mémoire de fin de Cycle .----
Afficher une Demande de
Afficher_ Demande décaissement Fonction Objet Publique
Lister les Demandes de

Lister_ Demande décaissement Fonction Collection Publique
Autorisation_Decaissement
Enregistrer une Autorisation de

Autoriser décaissement Procédure - Publique
Lister les Autorisations de

Lister_Autorisation décaissements Fonction Collection Publique
Afficher une Autorisation de

Afficher_Autorisation décaissement Fonction Objet Publique

par la figure suivante :
108
Ingénieur MIAGE
Devise Mode_Reglement
+ code_devlse + code_mode_reglement
+ llbelle_devl&e
Motlf_Mouvement
+ llbelle_mode_reglement
+ code_motif
+ newO : Ob + new O · Object Plece_lntentlon_Decal&&ement
+ llbelle_motlf
+ new() : Obj + code_plece : string
1..1 + llbelle_plece : &trlng
Type_Mouvement , ..•. + new O : Object
+ code_type_mouvm
+ llbelle_type_mouvm
Mouvement_Tresorerie Autorlsatlon_Decaisi;ement
+ new () : Object
+ numero_mouvement + code_autorlsatlon
+ date_mouvement Demende_Decai&&ement + code_autorite_tersorerle
Plece_Reglement + montant_entre + code_lntention_decalsr,ement
+ numero_demande : Siri
+ code_piece .1 + montant_sortl + code_projet + new() : Objec
: Siri
+ llbelle_plece :1 + mouvement_partlel + Autoriser() Objec
+ code_motlf_mouvement Siri
+ mouvemenl_national + code_mode_reglement + Li&ter_Autorisatlon () Objec
+ new() : Obje Siri
+ reference_plece_reglement + code_banque + Afflcher_Autorisatlon () Objec
Siri
+ dete_plece_reglement + code_plece
+ etat_mouvement
Lleu_Regelement + new() :O~eci
+ New() 1 .. •
+ Demander() :O~ect
+ code_lleu : &tln1 + Decelsemenl O
+ Afflcher_Demande () :o~ect 1 .. 1
+ libelle_lieu : strlr + Afficher_Decalamenl O + Llster_Demande () ·o~ect
+ new () : Objec + Decal1111ement_Total ()
+ Llster_Decaissement () Autorlte_Tresorerle
+ Elabllr_Plece ()
code_autorite_tresorerle
1.! + llster_Plece_Etablle ()
• nom_autorite_tresorerle
+ Remettre_Plece O
fonction
Type_Ueu_Regelement + llsler_Plece_Remlse ()
+ new O : Object
1 .. 1 + type_code_lleu : stl
Banque + Ajouter() : Object
+ type_libelle lieu : si
1:-• + oode_benque
Site + new () : Object 1 .. 1 ~ + code_compte
+ llbelle_banque - 1 .. •
+ code_&lle : &I .. 1
+ numero_compte
+ llbelle_slte : si + new O : Obje
+ new() Obje
+ new() Ob.: Beneficlaire
+ code_beneflclalre
Type_Beneflclalre + nom_beneflcialre Type_Banque
pre noms_beneficlalre
+ code_type_beneficlalre code_type_bqnaue
+ new () : Object
• llbelle_lype_bqnaue
+ llbelle_type_beneflclalre
+ new O : Object + new () : Object
Diagramme de classe de conception de la gestion des décaissements

109
Ingénieur MIAGE
Mémoire de fm de Cycle ••
--·
7.2.3- Gestion des comptes bancaires
Les méthodes des classes du domaine de gestion des comptes bancaires

sont présentées dans le tableau ci-dessous :
Référentiel
Releve_Bancaire
Enregistrer Réception du relevé

Recevoir bancaire Procédure - Publique
Lister_ Reception Lister les relevés bancaires Reçus Fonction Collection Publique
Afficher_Releve Afficher un Relevé bancaire Fonction Objet Publique
Mouvernent_Bancaire_Banque
Enregistrer un mouvement
Enregistrer_ mouvement bancaire Procédure - Publique
Lister_ Mouvement Lister les Mouvements bancaires Fonction Collection Publique
Afficher_Mouvement Afficher un Mouvement bancaire Fonction Objet Publique
Afficher le Solde d'un Compte

Solde_ Compte_ Bancaire Bancaire Fonction Chaine Publique
Afficher le Solde concernant une

Solde_Banque Banque Fonction Chaine Publique
Avis_Bancaire
110
Ingénieur MIAGE
Mémoire de fm de Cycle .-
-lmn
Enregistrer la Réception de l'avis

Recevoir bancaire Procédure - Publique
lister_Reception lister les avis bancaires Reçus Fonction Collection Publique
Afficher_Avis Afficher un Avis bancaire Fonction Objet Publique

111
Ingénieur MIAGE
Type_Mouvement Piece_Mouvement
+ code_type_mouvemel + code_plece : stn,

+ libelle_type_mouve + libelle_plece : stri,
+ new O : Object + newO : Object
Avis_Bancaire Type_Avis_Bancaire
Releve_Bancaire
+ numero_releve + numero_avls + code_type_avis
+ libelle_avis + libelle_type_avis
+ date_releve
+ numero_mouvement + date_avls
+ date_debut_mouvement + new O : Object
+ date_fin_mouvement
+ date_mouvement + date_operatlon
+ montant_total_deblt
+ numero_piece_mouvement + montanLoperatlon
+ montant_total_credlt
+ montant_mouvement + frals_lmpaye
+ etat_releve
+ etaLmouvement + numero_personne
+ newo + nom_pellllnne
+ new O : Obje + prenoms_personne
+ Enreglstrer_mouvement O
+ Recevoir O : Obje
+ Llster_Mouvement O + newo
+ Llster_Rece ptlon O : Obje
+ Afflcher_Mouvement O + Recevoir O
+ Afficher_Reteve O : Obje Type_Personne_Avis
+ Solde_Compte_Bancalre O + Llster_Reception O
+ Solde_Banque O + Affiche r_Avis O + code_type_personne
+ libelle_type_personne
+ new O : Object
Ban(!ue
+ code_banque : Ot
+ libelle_banque : et
, ..• Type_Ban(!ue
: Object code_type_bqnaue
- libelle_type_bqnaue
+ new O : Object
Diagramme de classe de conception de la gestion des comptes bancaires
112
Ingénieur MIAGE
MémorredefmdeCyde
7.2.4- Gestion des emprunts
Les méthodes des classes du domaine de gestion des comptes bancaires

sont présentées dans le tableau ci-dessous :
Référentiel
Demande_Emprunt
Enregistrer une Demande

Demander d'emprunt Procédure - Publique
Afficher une Demande

Afficher_Emprunt d'emprunt Fonction Objet Publique
Lister_Emprunt Lister les Demandes d'emprunt Fonction Collection Publique
Lister les Emprunts

Lister_Emprunt_Rembourse Remboursés Fonction Collection Publique
Lister les Emprunts Non encore

Lister_Emprunt_Non_Rembourse Remboursés Fonction Collection Publique
Reception_Emprunt
Enregistrer une Réception de

Recevoir_Fond Fonds Procédure - Publique
Afficher une Réception de

Afficher_Reception Fonds Fonction Objet Publique
Lister_ Reception Lister les Réceptions de Fonds Fonction Collection Publique
113
Ingénieur MIAGE
Mémoire de fm de Cycle .---
Enregistrer un Remboursement
Rembourser d'emprunt Procédure - Publique
Afficher un Remboursement
Afficher_Remboursement d'emprunt Fonction Objet Publique
Lister les Remboursements

Lister_Remboursement d'emprunt Fonction Collection Publique

114
Ingénieur MIAGE
J
Receptlon_Emprunt
Type_Emprunt + numero_receptlon
+ code_type : String + date_receptlon
+ libelle type : String + reference_plece_receptlon
+ montant
+ newo : Object + reference_plece_reglement
+ Ajouter O : Object + date_plece_reglement
+ Modifier O : Object Demande_Emprunt
+ new O : Obje1
+ numero_demande + Recevolr_Fond O : Obje1
+ llbelle_demande + Attlcher_Receptlon O : Obje1
Motlf_Emprunt + date_demande + Llster_Receptlon O : Objet
+ code_motlf : string + montant_demande
+ llbelle_mollf : String + taux_lnteret
+ coml&&lon_garantle
+ newo
+ Ajouter O
:Object
: Object
~ 1.: _j + date_debut_receptlon
1 •. 1 + date_nn_receptlon
+ Modifier O : Object
A
- +
+
dete_debut_remboursement
date_fln_remboursement
Pleoe_Regelement Mode_Regelement
+ code_mode_regelement
+ code_plece_regelement
+ etat_demande
Soclete_G11rentle + llbelle_plece_regelement + llbelle_mode_regelement
+ etat_10uml&&lon_demande
+ code_10clete : String + new O : Object + new O : Object
+ newo
+ nom_soclete : String + Ajouter O : Object Ajouter O : Object
+ Demander O
+ newo O~eci + Afflcher_Emprunt O
+ Ajouter 0 O~eci + Llster_Emprunt O
+ ModlflerO O~eci + Llster_Emprunt_Remboun;e O
+ Supprimer 0 :O~eci + Llster_Emprunt_Non_Rembou
+ Ll&ter 0 :O~e~
1 .. Remboun;ement_Emprunt
.. 1
Type_Periode_Remoursement
+ numero_remboursement
+ code_type : String .. 1 + d11te_remboursement
+ llbelle_type : String + montant_remboursement
+ newo : Object Compte_Bancelre -------.---J + reference_plece_reglement
+ date_plece_reglement
+ Ajouter 0 : Object + code_compte
+ Modifier : Ob)ect + numero_compte + newo
+ Rembour&er O
+ newO : Ot + Attlcher_Rembour&ement O Type_Banque
+ Ajouter O : Ot + Llster_Rembour&ement O
+ Modifier O : Ot Banque + code_type_bqnaue
+ code_banque + llbelle_type_bqnaue
+ llbelle_banque + new O : Objec
newo : 0 + Ajouter O : Objecl
Ajouter O : 0 + Modifier O : Objeci
+ Modifier O :0 + Supprimer O : ObJecl
Diagramme de classe de conception de la gestion des décaissements

115
Ingénieur MIAGE
Mémoift de fin de Cyde --
••........
Partie 3 :
Phase d'élaboration
116
Ingénieur MIAGE
Chapitre 8: Implémentation du système
8.1- Implémentation de la base de données
Cette phase est généralement la toute première lors du procédé

d'implémentation des systèmes logiciels interagissant avec les bases de données,
car une base de données elle est le socle, le sous bassement du système. Celle-ci
est sensée offrir aux utilisateurs du système, la possibilité de stocker, de traiter et
de ressortir toutes les informations dont ils auront besoin.
8.1.1- Le schéma de la base de données
Le schéma de la base de données permet de représenter les tables de la

base de données avec toutes les relations entre elles.
Il est représenté par le schéma à la page suivante :
117
Ingénieur MIAGE
•
::
i I ••
1
t'
.c: .c:
!! !!
•••
.• > >
C
!
1-
•'"
••
ù " .
.!
o.
Q.
1
;;:•
1 •
• =
•
" .
•
D
,_, se li •
!
.! ~
•• 1
1 •
~ 1 li!
(/) !
.•
• =
li •
,_, ·' .!' li •

0 .D
u =
0 .D
ù =
\,-- •• / !
i0 ·-••......
dl
dl
tJ
C
!
.C: L
!! !! •
CD 0
ë•E 1 r.•!! r.•• i • • ,J
. -.
L. > > Cil
!! !! 'ii > •11)
ë
•E E>
E
>:s
• • •
â > > >• -=C e
<i .t:
•
Il: a C e
C
C a a 1-
dl
• :, 0
,,, a
I
CD • .D L J:
> o E 1 .D 1 e e e "O
:s E 1 • 1 •
0
::. •
1 •
o. :;• Q.
>,
•
Q _ };-
a. • • •
:,> > > c::
•' i1.~ 1-
1 1-
,_, ·' ~
i?" 1 0
::. u •
• •
u
0
·.:Cil:
(el
o.
> • = li • 1
1- li •
u
0 .D
= •
IJ ~°I
dl
ii:•
•...• 8 ~
1
•' ~
li
0
•
.D
0.(
1- u = "O
dl
11)
•
1
8
.! -
•dl
Cil
.
C
~ :,•.,.
C ;;,-
~
1--.J !a • ii C • ii
Cil
I! .!:
:, m,•
!! .!:
:, 11 ..§
J i -: :
1 1 ! a1 -::1 Cil
..
C
E•
! ! ïi ! ! dl
i
• ÏÎ
u u
C.
m•
••
u u
'dl
2
0
,_,::.
.o••
C
, .o,
C
- 1
.
-C C
••
.D
C
.D
o.••êi.
E E .
C
Ê ~:, •
E
..
•..
•
1 1
o.••o. "O
0
..
> 0 •
ëi E E dl
8, s,
::.~ El °I e• ë
!
1
o, u,
0 0 "O
•a O• •0
- li li 1 li-., E
:,
C
0
•••
- li li
11)
li u u 1- 0 0 a O 0 Cil
u u C E li u u Co;!
..c
- Co;!
•• •• ••
.C L L
!! !! !!
1- ë
•E
> > > ~:,
• o.• . •
0
.D
-•• E0 :s.,.
.\
E! -C
E "1 c 1 .!
g e~ 0 C •
1 • 1
~ :,E ~0
8ëi
ë g
•E C U
1
] I •• ( L L
!! !!
-1 ••
C
0 •• • , Lii s;,ii
:;:; > > C L L ;
C 2 e !! !! !!
• C
ë
:• .
3 -~
• o.
E
_,
w
••
> >
!
• > >
o,
• •
••
~
C
u
• °I ;.
• =• 1i
:;.
o E
0
i• •• ii.
u
•
! -C
5 li
0
u
.D
= 3 . ..,
E 1
1 •
..•, =
ü
0 ], ],
• E
.• ~ !
e
0
u -
.D 1-
8 g
li
8
O
E li
8.1.2- Enumération des tables du système
L'énumération des différentes tables de la base de données est présentée

dans le tableau ci-dessous :
Tables Description
Tables de la partie Exploitation du système
T -AUTORISATION-DECAI Table des autorisations de décaissement

SSEMENT
T-A VIS -BANCAIRE Table des demandes d'emprunt
T-DEMANDE-EMPRUNT Table des intentions de décaissement
T-DEMANDE-DECAISSE Table des mouvements bancaires effectués par

MENT la banque sur les comptes de la société
T-MOUVEMENT-BANCAi Table des mouvements effectués par la société

RE_BANQUE sur ses comptes bancaires
T-MOUVEMENT-BANCAi Table des mouvements bancaires effectués par

RE SOCIETE la banque sur les comptes bancaires de la
société
T-MOUVEMENT -TRESOR Table des mouvements de trésorerie

ERIE
T-RECEPTION-EMPRUNT Table des réceptions de fonds suite à une

demande d'emprunt
T-RECETTE-ENCAISSEM Table des recettes des encaissements effectués

ENT
T-REMBOURSEMENT -EM Table des remboursements des fonds

PRUNT empruntés à la banque
T-RELEVE-BANCAIRE Table des relevés bancaires
T-TRANSFERT-RECEITE Table des recettes encaissées
119
Ingénieur MIAGE
Tables de la partie Référentiel
T_REF_TYPE_BANQUE Table de paramétrage des types de banque
T_REF_BANQUE Table de paramétrage des banques
T_REF _AGENCE_BANQUE [Table de paramétrage des agences des banques
T_REF _COMPTE_BANCAI !Table de paramétrage des comptes bancaires

RE
T_REF_TYPE_COMPTE_B !Table de paramétrage des types de comptes

ANCAIRE bancaires
T REF SITE Table de paramétrage des sites de la société
T REF CAISSE Table de paramétrage des caisses de la société
T REF GUICHET Table de paramétrage des guichets de la société
T REF DEVISE Table de paramétrage des devises utilisées lors

des transactions financières
I
T_REF _AUTORITE_TRESO Table de paramétrage des personnes qui
RERIE autorisent les décaissements, les transferts de
fonds en banque ... etc.
T_REF_MODE_REGLEME !Table de paramétrage des modes de règlements

NT lors des mouvements de trésorerie
T REF_MOTIF_EMPRUNT [Table de paramétrage des motifs des emprunts
T_REF _MOTIF_MOUVEM !Table de paramétrage des motifs des

ENT mouvements de trésorerie
T_REF_PIECE_INTENSION [Table de paramétrage des pièces justificatives

DECAISSEMENT des décaissements
120
Ingénieur MIAGE
T-REF-PIECE-MOUVEME Table de paramétrage des pièces justificatives

NT BANCAIRE des mouvements bancaires
T_REF_PIECE_RECEITE_ Table de paramétrage des pièces justificatives

ENCAISSEMENT des recettes d'encaissements
T-REF-PIECE-REGLEMEN Table de paramétrage des pièces justificatives

T de règlements
T-REF-PIECE-TRANSFER Table de paramétrage des pièces justificatives

T ENCAISSEMENT du transfert des recettes d'encaissements
T -REF -TYPE-BENEFICIAI Table de paramétrage des types de bénéficiaires

RE des règlements effectués par la société
T-REF - SOCIETE-GARENT Table de paramétrage des sociétés permettant

IE-EMPRUNT de déposer les fonds de garantie des emprunts
T-REF -TYPE-EMPRUNT Table de paramétrage des types d'emprunts

effectués par la société
8.1.3- Mise en place de la base de données
L'implémentation de notre base de données a été effectuée d'abord par la

création d'une base de données de développement, puis la création des tables
décrites ci-dessus. Nous avons procédé ensuite à la création des index, des
fonctions et des vues. Puis à la programmation des Procédures stockées et des
triggers base de données.
~ Création des tables
Les tables sont des objets de base de données qui nous ont permis de stocker
les données du système de façon structurée et organisée, sous forme de tableaux
où les colonnes correspondent à des champs et les lignes à des enregistrements.
Les tables essentielles de notre base de données ont été créées à partir des
classes du Diagramme de classes que nous avons élaboré lors de la phase de
conception de notre système. En effet chacune des classes du diagramme
correspond à une table de la base de données. Aussi, les attributs de ces classes
121
Ingénieur MIAGE
correspondent aux champs des tables de la base de données. Et les lignes

d'enregistrement correspondent aux instances des classes donc les Objets.
~ Création des index
Nous avons implémenté des index sur les tables de notre base de données
pour en assurer les performances. En effet les index sont des objets permettant
de faciliter l'accès aux données d'une base et de les retrouver de façon efficace.
~ Création des vues
Nous avons utilisé les vues dans notre base de données comme synthèse des
requêtes d'interrogations de la base. Elles permettent en fait, d'éviter de saisir de
longues requêtes lors de la programmation base de données (les procédures
stockées). En effet les vues permettent de donner un nom à une requête pour
l'utiliser ultérieurement à chaque fois que nous en aurons besoin. Les vues de la
base de données ont été crées en fonction de chacune des tables car c'est sur
elles que s'effectueront tous les ordres Select.
~ Programmation des procédures stockées
Les procédures stockées nous ont permis d'implémenter au niveau de la base

de données, les différentes méthodes des classes de notre diagramme de Classes
élaboré dans la phase de conception de notre système. Elles correspondent en
fait aux différentes instructions SQL du Data Manipulation Language (O:ML)
dont les insertions, les modifications, les suppressions, les recherches et les
consultations. En effet, une procédure stockée est un ensemble d'instructions
SQL précompilées, stockées sur le serveur, directement dans la base de données.
Elles seront exécutées par les utilisateurs via le programme, ou encore de façon
automatisée par des événements déclencheurs ("trigger").
~ Implémentation des triggers base de données
Les triggers sont des déclencheurs permettant d'effectuer des tâches

spécifiques au niveau de la base de données. Ces tâches sont définies lors de la
programmation du trigger. Nous les avons utilisés dans notre base de données
pour mettre en place un système de "Journalisation". C'est-à-dire un système
permettant de retracer 1 'historique de toutes les transactions qui on été effectuées
par les utilisateurs via l'application. Effet ces triggers s'exécutent
automatiquement après chaque insertion, modification ou suppression des
données de la base, par un enregistrement dans une table contenant les champs
122
Ingénieur MIAGE
M émoire de fin de Cycle •
n.,...\....,.ll
suivants : l'identifiant de l'utilisateur ayant exécuté l'action, l'action exécutée, la

table concernée, la date d'exécution, les anciennes valeurs, les nouvelles valeurs.
8.1.4- Sécurisation de la base de données
Les données stockées dans notre base de données sont importantes,

sensibles et confidentielles car elles contiennent les chiffres financiers de la
société. Afin d'assurer la sécurité de ces données, nous avons d'abord procédé à
la sécurisation de l'accès à la base de données. Nous avons ensuite procédé à la
gestion de l'intégrité et des sauvegardes de ces données. Nous avons enfin mis
en place des éléments assurant la disponibilité de ces données.
}i,> La sécurisation de l'accès à la base de données
Elle est mise en œuvre d'abord par l'installation matériel du serveur de

base de données dans la salle machine car son accès est sécurisé. Ensuite cette
sécurisation de l'accès à la base de données est mise en œuvre par les stratégies
de mot de passe aussi bien au niveau du système d'exploitation du serveur qu'au
niveau de la connexion au SGBD. Enfin la sécurisation des données a été
effectuée à partir de l'attribution des droits d'accès sur les différents objets de la
base de données.
}i,> L'intégrité des données
Elle est mise en œuvre dans la programmation des procédures stockées

par des contrôles et des vérifications sur les données puis par la gestion des
transactions SQL dans toute action d'insertion ou de mise à jour des données.
Elle a été implémentée également à partir des contraintes créées sur certaines
tables de la base de données.
}i,> Les sauvegardes des données
Les sauvegardes des données sont assurées au niveau de SQL Server

2005, par l'implémentation d'un plan de maintenance permettant d'effectuer de
façon journalière la sauvegarde de la base de données de notre système. Nous
avons également de façon générale, les sauvegardes hebdomadaires et
mensuelles sur bandes ou sur disque, des données de l'entreprise par des
utilitaires de sauvegardes. Cela en vue de restaurer le système en cas de perte ou
de sinistre.
123
Ingénieur MIAGE
M émoire de fin de Cycle •--
).;- La disponibilité des données
Un système de réplication des données entre certains sites de Togo

Telecom a été mis en place via SQL Server 2005, à partir des outils de
publication et d'abonnement, en vue d'assurer la disponibilité de notre base de
données en cas de panne disque ou OS sur l'un des serveurs hébergeant les
données du système.
8.2- Le Diagram.me de composants
Le système informatisé de gestion de trésorerie, comporte plusieurs

composantes physiques propres à l'environnement de réalisation. Ces
composantes du système sont représentées à partir d'un diagramme de
composants. En effet le diagramme de composants nous permettra de décrire
l'architecture physique et statique de notre application en termes de modules :
fichiers sources, librairies, exécutables, . . . etc.
8.2.1- Les composants du système
Les différents composants de notre système sont les suivants : les fichiers
de données, un fichier de configuration, les dll, les fichiers de classes, les
interfaces utilisateurs, le fichier exécutable.
8.2.1.1 - Les fichiers de données
Ils permettront de stocker toutes les données relatives à la gestion du

système de trésorerie de façon structurée, organisée et reliées entre elles de sorte
à pouvoir les retrouver aisément. Ces données pourront être définies, manipulées
et contrôlées via un système de gestion de base de données
8.2.1.2 - Le fichier de configuration
Le fichier de configuration servira à stocker tous les paramètres de

configurations du système en l'occurrence les paramètres de connexion entre
notre système et les fichiers de données, les modes d'affichage, le répertoire des
états, . . . etc.
124
Ingénieur MIAGE
M émoire de fin de Cycle •
--·
8.2.1.3 - les DLL
Les DLL (Dynamic Library Link) sont des :fichiers compilés contenant du
code source permettant d'effectuer certaines tâches bien spécifiques. Notre
système aura une DLL nommée "App_DataAccess" qui permettra de gérer
comme son nom l'indique tout ce qui concerne l'accès de notre système aux
fichiers de données quelque soit le système de gestion de base de données. La
DLL "App_Tools" permettra quant à elle de gérer d'abord les vérifications
d'intégrité, de cohérence, et toutes autres vérifications au sein du système. Il
permettra ensuite de gérer l'affichage de toutes les boîtes de dialogue, et enfin
de gérer tout ce qui est exception.
8.2.1.4 - les fichiers de classes
Les fichiers de classes permettront d'implémenter toutes les classes

définies au niveau du diagramme de classes c'est-à-dire l'aspect fonctionnel du
système. Ils permettront également d'implémenter les autres classes de gestion
du système telles que les classes GuiManagement, UserManagement,
SystemManagement, DataManagement, DBAction.
- la classe "GuîManagement" contiendra des propriétés et des méthodes

implémentées pour la gestion des contrôles utilisateurs sur les formulaires
Windows.
- la classe "UserManagement" permettra de créer, modifier ou supprimer des

utilisateurs, leurs attribuer des droits et les consulter.
- la classe "SystemManagement" permettra d'abord d'effectuer toutes les

configurations du système (Nom de l'application, Chaine de connexion,
Répertoire des états, Fonctionnalités du système ... etc.). Elle permettra ensuite
de restaurer à partir de la corbeille, les données supprimées lors de 1 'exploitation
du système. Elle permettra enfin de consulter via le journal des transactions,
toutes les tâches qui ont été effectuées lors de 1 'exploitation du système.
- la classe "DataManagement" quant à elle permettra d'effectuer les

réinitialisations des données du système, les importations et exportations des
données du système. Elle contiendra également des propriétés et méthodes qui
permettront d'intégrer à notre système un gestionnaire de requêtes SQL.
125
Ingénieur MIAGE
- la classe "DBAction" contiendra les propriétés et méthodes qui permettront

d'effectuer certaines tache avec la base de données telles que: la récupération de
la date et l'heure du serveur, la récupération de la valeur d'un champ dans une
table à partir de son code identifiant, la génération automatique d'un code pour
chaque enregistrement . . . etc.
8.2.1.5- les interfaces utilisateurs
Les interfaces utilisateurs sont des fenêtres Consoles, Windows ou Web

qui permettront aux utilisateurs de consulter et /ou de manipuler les données du
système de gestion de trésorerie selon leurs droits. Elles correspondent aux
différents cas d'utilisation des diagrammes de Cas d'Utilisation élaboré ci-
dessus. Hormis ces interfaces nous auront le menu, l'aide et les outils du
système
8.2.1.6 - le fichier exécutable
Le fichier exécutable "App_Tresorerie.exe" est le fichier compilé qui

permettra de lancer l'exécution du système informatisé de gestion de trésorerie.
Il contiendra tous les codes sources nécessaires au bon fonctionnement du
système.
8.2.2- Le diagramme de composants
Le diagramme de composant de notre système de gestion de trésorerie est

représenté par la figure ci-dessous :
126
Ingénieur MIAGE
r--
:
:
---·----------------
Fichier de b ••~ de donnë;_s DLL !l'actes =W1 donnèes
,.... ..,.._..-~--· .,·

____..e:
.,.,.,...,.....,,..~· .,·'/
r--l
·-·-•"~•-·-- ~ an
::::.. -~-. -~~ DU; - !
Clmulnmmu Utilim@u11 Clmu :onfiÂ\lr.tio,u
lnterf:Y.:e d',uth!ntifimion lnterfëtes m!tiers j [ lnterf:ce deconfi~111otion j
Diagramme de composant du système de gestion de trésorerie
8.2- Développement de l'application
Le développement de l'application est la phase de réalisation et de mise

en œuvre des différents composants du système à partir de J 'outil de
développement que nous avons choisi lors de nos choix technologiques.
Cette phase a consisté à l'implémentation selon la technologie .Net avec le

langage Visual Basic.Net, des DLL "App_DataAccess" et "App_Tools". L'on
a procédé ensuite à l'implémentation des fichiers de classes GuiManagement,
UserManagement, SystemManagement, DataManagement, DBAction. Nous
avons également implémenté les classes de conception de la gestion de la
trésorerie au sein de la DLL "App_Business''. Nous avons enfin implémenté les
"Services Web" et les "Interfaces Utilisateurs" du système.
127
Ingénieur MIAGE
M ém oire de fin de Cycle •
,..._.ka-,i,.
Il a noté que le développement de l'application a été faite suivant l'architecture

n-tiers. En effet, les composantes du système ont été organisées et regroupées
selon cette architecture (n-tiers), qui décompose l'application en plusieurs
niveaux d'abstraction appelées couches ou briques de l'application.
L'architecture n-tiers
L'architecture n-tiers, nous propose une décomposition de l'application en

plusieurs (n) couches ou niveaux d'abstraction. Les niveaux essentiels sont:
- le niveau interface utilisateur
- le niveau métier
- le niveau de gestion de l'accès aux données
L'architecte d'un système peut ajouter d'autres niveau à son architecture d'où le
terme n-tiers. Ainsi nous avons ajouté à notre système les niveaux web services
et outils.
Les différentes couches de notre application de gestion de trésorerie, sont

représentées par le schéma suivant :
Couche d'accès aux données
Base de données
Utilisateur
Les différentes couches de l'application
8.2.1- La couche d'accès aux données (DAO)
La couche d'accès aux données est le plus haut niveau d'abstraction de

l'architecture n-tiers. Elle est en contact direct avec la base de données. C'est elle
qui sert d'interface entre la base de données et les programmes applicatifs de
notre système. Elle permet en effet d'effectuer toutes les actions vers la base de
données du système, en l'occurrence la connexion et la déconnexion avec une
128
Ingénieur MIAGE
---
base de données, puis les opérations de lectures et écritures vers la base de
données du système. Elle a été implémentée à partir d'une DLL comportant un
ensemble de classe d'accès aux bases de données du marché dont SQL Server,
Oracle, MySQL, DB2 400 ... etc.
8.2.2- La couche métier (BLL)
La couche métier est le niveau d'abstraction venant juste en dessous de la

couche d'accès aux données. Elle nous a permis d'implémenter l'aspect métier de
l'application. En effet elle contient toutes les classes permettant de gérer les
processus métiers de l'entreprise, dont la gestion des encaissements, des
décaissements, des caisses, des comptes bancaires, des emprunts, ... etc.
8.2.3- La couche de services web (WS)
Cette couche nous a permis, par la manipulation des objets métiers, de

mettre en place les fonctionnalités de l'application, puis de les exposer dans un
environnement web en vue d'être consommées par d'autres applications. Ce qui
a permis de résoudre le problème de communication entre les différentes
applications homogènes ou hétérogènes systèmes. Cela via le protocole SOAP et
la technologie XML.
8.2.4- La couche interfaces utilisateur (GUI)
Cette couche se situe au plus bas niveau d'abstraction de l'architecture de

notre application. Elle est en contact direct avec l'utilisateur. C'est l'IHM de
notre système de gestion de trésorerie. En effet elle comporte les l'interfaces
(desktop ou web) à partir desquelles les utilisateurs de notre système pourront
effectuer leurs mises à jour et leurs consultations avec la base de données de
J 'application.
8.2.5- La couche outils (Tools)
La couche outils est un ensemble de classes et DLL interagissant avec

tous les niveaux d'abstraction de l'architecture de notre application. Elle nous a
permis en effet de gérer tout ce qui est vérification au sein de l'application, de
gérer tout ce qui est exception et tout ce qui Boite de dialogue.
129
Ingénieur MIAGE
Chapitre 9: Tests et déploiement
9.1- Tests de l'application
Différents types de tests ont été effectués sur l'application de gestion de la

trésorerie de Togo Telecom. Nous avons effectués des tests fonctionnels, des
tests de robustesse, des tests de réactivité et des tests de sécurité.
Il est à noter que ces tests ont été effectués en présence des utilisateurs et
le comité de gestion du projet. Des remarques et suggestions ont été apportées
suite à ces tests. Ces remarques et suggestions ont été prises en compte avant de
passer à la phase de déploiement du système.
9.2- Déploiement du système
Le diagramme de déploiement montre la disposition physique des

différents matériels (les nœuds) qui entrent dans la composition de notre
système et la répartition des instances de composants, processus et objets qui
vivent sur ces matériels. Il nous permettra donc de modéliser l'architecture
physique du système avec ses différentes composantes.
9.2.1- Le matériel de déploiement du système
Un serveur de Bases de données, un serveur d'applications, des postes

clients, des imprimantes et toute la connectique réseaux sont les différents
éléments matériels qui nous permettront d'effectuer le déploiement de notre
système sur le réseau de l'entreprise.
- le serveur de bases de données permettra d'installer le système de gestion

de base de données et d'y implémenter la base de données du système.
- le serveur d'application jouera le rôle d'hébergeur de toutes les

composantes web du système (les pages web, les services web, ... etc.)
- c'est à partir des postes clients que les utilisateurs finaux accèderont aux
différentes fonctionnalités du système selon leurs droits d'accès.
- les imprimantes connectées généralement aux postes clients permettront

d'imprimer les documents et états disponibles dans le système.
130
Ingénieur MIAGE
- la connectique réseau de l'entreprise servira de liaison entre les différents

éléments matériels énumérés ci-dessus.
9.2.2- Le diagramme de déploiement
Se1Veur 1-P ProHant ML 370 Imprimante
OS : W ndows Se1Ver 2003

Serveur 11\eb (IIS)
.Net Framev.ork2.0
Serveur App_Tresi (.Net)
Polie Oient
OSWndowsXP
.Net Framev.ork2.0
App_ Tres:>rerie.exe
DLL_T resirerie
TCP-IP
Serveur 1-P Prollant ML370

OS: WndowsSe1Ver 2003
Baeesde données
BD_TRESO (SOL Server 2005)
Diagramme de déploiement du système de gestion de trésorerie
Le Diagramme de déploiement de notre système de gestion de trésorerie

présente un serveur de Base de données de marque HP Proliant ML 370 avec un
système d'exploitation Microsoft Windows Servet· 2003. La base de données du
système fonctionne sous le SGBD Microsoft SQL Server 2005.
Nous avons ensuite un serveur web de marque HP Proliant ML 370 avec

Microsoft Windows Server 2003 comme système d'exploitation. Ce serveur web
a été configuré avec Microsoft IIS 6.0 (Internet Information Service) et contient
le Framework 2.0 et la partie serveur du système.
131
Ingénieur MIAGE
Nous avons également les postes de plusieurs marques (HP, DELL, Compaq)
avec Windows XP ou Vista comme Système d'exploitation. C'est sur ces postes
clients que sont installés la partie cliente du système et le Framework 2.0.
Nous avons enfin la connectique réseau et des imprimantes HP pour l'édition

des pièces provenant du système.
132
Ingénieur MIAGE
.,_.,
Chapitre 10: Présentation du système
10.1- Les formulaires standards
10.1.2- Authentification
11' [Jour neriel] ~lig'~
L'écran ci-après permet de mettre
Authentification
en place un système d'authentification,
Come,aon
c'est-à-dire un mécanisme de contrôle
Identifient : 1
d'accès à l'application. Ce en y entrant ::-::::::::::::::::::::::::::::::::::::::::::::::::::::::-"
--,
,?Mot de pane: J
l'identifiant et le mot de passe de
l'utilisateur. [x Quitte, [Z Ok
10.1.3- Menu Général

L'écran ci-dessous présente le menu général. C'est à partir de cet écran
que toutes les principales actions de l'application sont effectuées. Nous avons le
choix de la fonctionnalité au niveau de la barre de menu, la consultation des
informations d'une fonctionnalité, l'exécution d'une commande concernant la
fonctionnalité selectionnée (insertion, modifiction, suppression, recherche,
affichage, édition) , l'administration du système, l'aide, les informations sur
l 'utilisateur connecté.
f [î.lt,a,al} ~ 1 j ~ ill !) loloo-

[L :t,J [-·
Uldi
..J NO.J'!"elU
C> Moddn
X s,o:,m,,,
-~
Soal<o
o;...,.
SN.
Po:lo.
..•..
NIA
NIA
NIA
lERA-HUGEIIENNE
------------------------------~1 ::; !!'!~
:,il~
133
Ingénieur MIAGE
10.2- Le Référentiel
Le référentiel nous permet d'effectuer le paramétrage du système.

Concernant les écrans du référentiel de l'application, nous mettrons l'accent sur
la gestion des banques : type de banque, banque, compte bancaire et type de
compte bancaire.
10.2.1- Type de banque

.} [Trésor ••••• ) (si)@~
Cet écran permet d' efectuer le T" iJ~ '11. ::: :.mque
paramétrage des types de banque. Ce lrl011Mtions
Code:
paramétrage est effectué par l'ajout, la Lbelè:
modification, la suppression et la consultation l!,tc
des informations concernant les types de Code

1
l.bdé
ûmnerdale
banques.
.
1 [ ,o. fjocter 1 IWJ!lo<h! !xs.w--1 1- • Eemier 1
10.2.2- Banque
~ rr""'°""' ••1 {EJEl @3
--
Cet écran permet d 'efectuer le r i-'
paramétrage des banques. Ce paramétrage est ...,.......,,.

---
effectué par l'ajout, la modification, la Code

~ -- -
. - -
Ba,nq.,e:
suppression et la consultation des informations T-deb.w),c·
-- --
Pay.: - ---
concernant les banques.
U.•deot>an<,.,eo
Code U>elo
a-01 00...0
8-Q2 BTD
8-03 ECOllANK
B-04 UT8
e-œ BTCI
B-06 CX:P
8-07 BIA
1 [,o. ,-.,J [@ Modfa- j [><~] [, - F......- 1
134
Ingénieur MIAGE
Mémoire de fin de Cycle • ••••.:1 •.~•
10.2.3- Compte bancaire •:! -

[Tl5lttrie)
---- [B]Gf~
Cor-ip ~ l'::dncaîre
Cet écran permet d'efectuer le
lrlonnal!Crll
paramétrage des comptes bancaires. Ce Code:
~~ -
paramétrage est effectué par l'ajout, la 1
l.b elé:
~ --
tbn!ro ÔJ ~ e: --
modification, la suppression et la Î)l)e de~· :
--
consultation des informations concernant Banq.,e:
- - ~--
les comptes bancaires. l.itle
Code l.tJelé t,;.mhode~ e
1
BTO
1 CBD1 Fagoce 0121456789
BTO
CBD2 Notre Ctlmlll• BTO 58695214
(,o. bwer j (ail l!lodfer J [xs--J 1 1 fermer 1
10.2.3- Type de compte bancaire
Cet écran permet d'efectuer le •'i [TmorerïeJ

-·-~-- CEJ s ~
paramétrage des types de compte bancaire. Ce Type _ c .1- pte Bancaire
paramétrage est effectué par l'ajout, la lrlo,maliono
modification, la suppression et la consultation Codo:

--- -
' lJbell!:
des informations concernant les types de
ll9te
comptes. Codo Lbelé
1 CorrpeCOIJraf'II
2 Corrped~
1 ( ,O. liruter J [(il Mc,dter ) ( X 54,p;mer ) 1~ 1 fenne, 1
135
Ingénieur MIAGE
M émoire de fin de Cycle ~ .....
10.3- L'exploitation
L'exploitation du système est la partie la plus utilisée dans le système.

Elle permet d'effectuer le traitement des informations de gestion des différents
métiers de la trésorerie dont : les encaissements, les décaissements, les caisses,
les comptes bancaires, les emprunts, les liquidités. Nous présenterons un écran
pour chacun de ces différents métiers.
10.3.1- Encaissement (Gestion des Encaissements)
L'écran ci-dessous permet d'enregistrer les encaisements de la société

concernant les règlements de factures clients et les règlements de ventes de
produits ou services.
i >'d. [TttSOttri•J ----- -- . --- ~-~ - -
Cru e:r~
E, 1c •.. ,.sse.,ients
IOPtian~I ,~ ~ càJ ~ J
0 ~ ·de,_ : V<nesdeprodJIJ Mctf. - ••.... .•..• : ~
0 FCFA
Opt,on de rechefche
-~ N" de la Fa<:tue Coderu- . _ N'deT~ Olbe. -- [.JQkJ
Oelt fa<:tuelt)
- ~-- - faa,n Dale
-
Mortart
Nan
~ --- - ·---
N'T~
l'rocl.«
l'rocl.«
- - - -
~-
Manan11-àrt,,;Ja-
l&r •I
1
......_.._,
Eap,,œ
Cùd,et
Empk,,.ë
Drection Gm!rale
wchd 1
AOOKOUEl<d<ou
--- Modedeiègjon,ertEoc,eceo
. .,. _,_ -
- . -
--
0
Mananencal-6 0
o..-., FCFA--
Jx flrruer! 1v-~1 J, · feraer 1
10.3.2-Autorisation de décaissement (Gestion des Décaissements)
L'écran ci-dessous permet au directeur général de la société, au directeur

:financier et comptable puis au chef de la trésorerie, d'autoriser les demandes de
décaissements effectuées pour les règlemements concernant les factures
fournisseurs, ou toute autre facture à régler par Togo Telecom, les dépôts de
garantie, les notes de service, les ordres de mission, la paie . . . etc. Ce en vue
136
Ingénieur MIAGE
d'établir les pièces de règlement des différents bénéficiaires, dont les chèques,
les ordres de virements ou les bons de caisses.
•':! [Tl'tioiwi•I
--~~- r.;l~
l -oris- ions des décaissements
-,-1
~~
~,-
l'6œ
~
...•..•.
Fnaunf'o<m>ocu
Tw,,:
---
-
,--;i
_I Motl:
_,,,,,.,
--·----~ -
(..le»< 1
°"":
-
~ àeleœ..erl
Upcccs
f.l,CTfRSC0002
f .lCTFRSOOClll
Cheque.
Pioce O..e
12/1)1/2008
07/01/2008
- - -.,
1250000
236000
!l'mio:()
Fn,jft:
Code~:
[Ptec....-.. ,J
-----
-------
-
-----
FACTfR~ 17/01/2008 500000 Notf;
-
FACTFRSOOOO!i 0711)1/2008 750000 l'ike;
-~-
F.ICTfRS00006 07/01/2008 1 000000
N'Nœ:
-~ ---
Vweme.nt Banuirt: FCf_
A __
More.an:
F/CTfRS00001 0!/01/2008 3 500000 --
O..e- : Dolevalodoloon:
.,.., ••• • dl~
IBénéficioe Ill!
1-·-· Mortirt
fOéc----,1
Mode<lc~
°"-
Bonq..e
0~1cs<iéc·, l'lbltS
a.--•. . . __
_, --~ - -
N'du~
---~-- --·rêder
Cloleduâhµ f•
a...- FCFA
r,,,.,c1e~ local
ltx b'narl lv' Y>Mirl 1-' t--1
10.3.3- Règlement en espèce (Gestion des caisses)
Cet écran permet d'effectuer les règlements en espèces des

différents bénéficiaires internes ou externes à Togo Télécom à partir de
leur bon de caisse.
137
Ingénieur MIAGE
at
-
ni:.--lo.'11•
rties de caisses
(l)i,ponibMé de la Cl!is9oe)
'Bonde~ Mali déaùaemert Mcrn.n:
N' de la pièce:
N'Onlre Nom
Type de Pièce
N'de la Pièce
Oae:
Î)f)e de ~
N'dub~
Nom
Prénom(,)
Paielœrt
~I Came Mode
Dale
lv Vaider J
10.3.4- Saisie des opérations bancaires (Gestion des Cptes bancaires)
La saisie des opérations du relevé de compte (les mouvements bancaires)

permet de renseigner dans le système toutes les opérations effectuées par les
banques sur les comptes de Togo Telecom en vue de connaitre à tout moment la
disponibilité de chacune de ses banques et de ses comptes bancaires.
138
Ingénieur MIAGE
•'l
-
~"'""'li
(c:,ll!!J~:l-1
".ai'.".i·" des relevés de compte

Rechen:he
N' flelevë
~ - - ~ .•...•..•...
0...dc:~ :llV0&!2007 . ClaloopMtion Opbaion O..evalel.r Mortar1 Sens
~ll.istfsl
Rdevt\dc:""'1'4lle
,..,,..., OOOG4
------
--
~ CCP
Co,rçtcbo,jc..., 01030-0!>912S00187-94
-
O..c 01/ll&/2007
PéoodedJ 01/W200
~ lu 31l/C6/2C07
T<èidlbl 79!1!1973'.1' R::fA
ÎQlolaédl 59954743' fŒA
Solde - ~--425 2li5 tiï R:FA
rtOll'.IOllorw
Opk,tion
Î)'l)Cpibœ - ---
N"~
-- - --
0..e~
-~ ---.
Dac
- . ----
M<rfon
Récopl,J,d1
Opêtal,ont-
-
T<toldébl 799 !197 379 R:FA
~ J
T<taiaédl 599 547 43' R:FA
Solde 7'9 !197 379 FCl'A e.,q,e a:P ,_ d'opM,,ono effecMeo
Ea,n
-- -54706 7'9 !197 379
Débl Oü 7'9 !197 37! Soide 79!t !197379
: Annue 1 1 \/aider 1 1 fenaer 1
10.3.5- Réalisation de trésorerie (Gestion des liquidités)
Les réalisations de trésorerie permettent de consulter la Liste et la somme

totale des encaissements puis des décaissements effectués par Togo Telecom.
Ces informations peuvent être consultées pour un site ou pour une banque, sur
une période données et concernant un ou plusieurs critères donnés dont : le
motif d'encaissement, le produit, le site, le gichet, la caisse, le mode de
règlement, la banque, le compte bancaire, la devise ... etc.
139
Ingénieur MIAGE
~ ITiâÔnriel - ~ -, - - :-0,.
-. - . -.- -
.,- .•
-
·- ..•.•.. -- .... r.;i(IDQiij
-,
Réalisations de trésorerie
- -
ÎJPede-
1!, ~ 0~
°"*
~· Monoaùie 0 lüatèle
Péllode det Mcwemeru Mat-.
-
~ci, 07/11/2008
- >u 117/11/2008
- ·!; •••••••••• o~
J•v S.Silm 1 () En llanqt.e 4 • X
°'*°" de rechat:he ~de!Jl)lc,age

~J Dale 0 Modd'- O!iie Of'IM.II 0 G.ic:nd,Ca;ue
O Modd'e, nert
~
0 PrM.11 Code Mid Dole Manlll'I
(JSle
UCuclloi
ÔÛhlc
QMoœde~
oa..,,_
0 ~banc.aie
1
1
1
0 o.....e
CtiiR de n,chen:he
Ûlffll;
-
1
~ -
tblne~ : Nnn.-llûl:
:11xhwutr 1 [--v.. 1 1-lFcnncr 1
140
Ingénieur MIAGE
Conclusion
Six mois durant, nous avons travaillé lors de notre stage de fin de cycle
d'ingénieur MIAGE au sein de la SSII Kera Telecom Systems, sur la conception
et la réalisation d'un système informatisé de gestion de trésorerie, pour le
compte de Togo Telecom. En effet il était question de participer à réalisation
d'un système de gestion financière par la mise en place d'un logiciel de gestion
de trésorerie devant interagir de façon fluide, efficace et collaborative avec un
logiciel de gestion de budget et un logiciel de gestion de comptabilité. Le
logiciel de gestion de trésorerie devait prendre en compte les processus métiers
de gestion de trésorerie dont : la gestion des encaissements, la gestion des
décaissements, la gestion des caisses, la gestion des comptes bancaires, la
gestion des emprunts, la gestion des liquidités.
Ainsi "CapTréso", le système informatisé de gestion de la trésorerie de
Togo Telecom a été réalisé sous la plateforme Microsoft .Net avec le
Framework Microsoft .Net 2.0 comme technologie. Microsoft Visual Studio
.Net 2005, a servi d'environnement de développement intégré de l'application.
Microsoft SQL Server 2005 a été utilisé pour la gestion des bases de données
du système. Microsoft IlS 6.0 a permis l'hébergement des pages web et des
services web du système. Le tout fonctionnant sous Microsoft Windows 2003
Server, côté Serveur de bases de données et serveur d'application puis
Microsoft Windows XP et Vista côté postes des utilisateurs de l'application.
Le système implémenté a été éprouvé lors de son fonctionnement et est en
phase de validation. Cependant il aurait mieux fonctionné si ses communications
avec les systèmes de gestion clientèles et commerciales Gaïa, GestAb et
SysMediation étaient assurées par des services web. Car ils sont effectués via
des packages SSIS (SQL Server lntegration Service).
Nous pouvons dire au terme de notre mémoire de fin de cycle d'ingénieur

MIAGE, que ce stage nous a été bénéfique et plein d'expérience car il nous a
permis de mettre en œuvre des concepts évolués du développement
d'applications en l'occurrence la programmation base de données, la
programmation orientée objet, l'architecture n-tiers, l'architecture orienté
services (SOA), les services web (SOAP) et la gestion des processus métiers.
Il nous a également permis de nous frotter au métier d'architecture des

systèmes d'information. Métier au quel nous aspirions depuis la fin de notre
formation d'ingénieur MIAGE.
141
Ingénieur MIAGE
Lexique
- Architecture logicielle : Elle décrit de manière symbolique et

schématique les différentes composants d 'un ou de plusieurs programmes
informatiques.
- Framework : c, est un espace de travail modulaire. C, est un ensemble de
bibliothèques et/ou de classes, d'outils et de conventions permettant le
développement et le déploiement d'applications. Il fourni suffisamment de
composantes logiciels et impose suffisamment de rigueur pour la production de
façon efficace, de logiciel faciles à maintenir. Ces composantes sont organisées
pour être utilisées en interactions le unes avec les autres.
- Un processus métier: c'est un ensemble d'activités intervenant dans la
réalisation d'un métier dont l'objectif est de fournir des résultats observables et
mesurables.
- Un système d'information: un système d'information représente un
ensemble organisé d'éléments participant à la gestion, au stockage, au
traitement, au transport et à la diffusion de l'information au sein d'une
organisation.
- Un service web: c'est un programme informatique permettant la

communication et l'échange de données entre applications et systèmes
hétérogènes dans des environnements distribués. Il s'agit donc d'un ensemble de
fonctionnalités exposées sur internet ou sur un intranet, par et pour des
applications ou machines, sans intervention humaine, et en temps réel.
142
Ingénieur MIAGE
M ém oire de fin de Cycle ----
Bibliographie
Titre Auteur(s) Année
Edition
UML 2. 0 (IUT Département Informatique, Laurent

3ème Année) AUDIBERT
Merise vers OMT et UML. 3eme Edition Joseph Gabay
UML, le langage de modélisation objet unifié
Laurent Piechocki
Pro .NET 2.0 Windows Forms And Custom Matthew 2006

Controls In VB 2005 MacDonald
Sams Microsoft SQL Server 2005 Ray Rankins 2007
W ebographie
Adresse Copyright Date dernière visite
httQ://msdn.microsoft.com/fr-fr/ MSDN 30/04/2009

www.wikigedia.org wikipedia 30/04/2009
www.commentcamarche.net commentcamarche 30/04/2009

www .develogez.com 12/04/2009
www.wnl.free.com 10/04/2009
www.softeam.fr softeam 03/04/2009
www .dotnet-guru.com Dotnetguru 03/04/2009
143
Ingénieur MIAGE

Memoire 636953431836401685

Transféré par

Droits d'auteur :

Formats disponibles

Memoire 636953431836401685

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire 636953431836401685

Transféré par

Droits d'auteur :

Formats disponibles

l

MEMOIRE DE FIN DE CYCLE

Spécialité : Méthode Informatiques Appliquées à la Gestion des Entreprises

Filières professionnalisées MIAGE-GI

Conception et réalisation d'un

Soutenu publiquement le 13 Mai 2009

Président : Prof. KOUA Konin, Professeur titulaire à l'UFR-MI de l'Université

M. WAH Médard, Consultant en Systèmes d'informations

M. DIARRA Mamadou, Ingénieur Informaticien, Assistant à l'UFR-MI de l'Université

M. KOUASSI Florent, Ingénieur Informaticien, Chef de l'équipe de

Table des matières

Je rends grâce à DIEU TOUT PUISSANT pour tous ses bienfaits!

A Mon père M. GOGORI Brou Félix

A ma mère Mme GOGORI Née YEDE N'DRI Joséphine

Que DIEU les comble de grâces, de bénédictions 1 ! !

Je souhaite avant tout propos, remercier le SEIGNEUR DIEU TOUT

Mes remerciements vont à l'endroit de :

- Mon père et ma mère qui ont assuré moralement, financièrement et

La réalisation de ce travail fut parfois complexe et difficile mais très bénéfique à

C'est dans ce cadre institutionnel, qu'ont été créées en 1999, en

C'est ainsi que au terme de notre formation d'ingénieur MIAGE, au sein

Ingénieur MIAGE Ill

La DFC de Togo Telecom voudrait donc une gestion optimale de l'aspect

- que faire et comment mettre en place un tel système ?

- que permettra t-il de faire exactement?

- quelle méthodologie adopter pour la mise en place de ce système ?

- quelle architecture aura notre système ?

- quels outils de modélisation et de développement, allons nous utiliser?

- quels moyens et ressources cela devra-t-il nécessiter ?

C'est à ces préoccupations que nous tenterons d'apporter des éléments de

Chapitre 1 : Cadre de référence

Née en Décembre 1990 de la scission de l'OPTT en deux sociétés, Togo

1.2- Organisation et Fonctionnement

Avec un effectif de plusieurs centaines de personnes, Togo Telecom est

- la Direction Générale (DG) :

Sous le control du Directeur General, elle coordonne les activités de l'entreprise,

- la Direction Commerciale et Marketing (DCM) :

Elle est chargée de la prospection, l'acquisition et la gestion des clients de la

Elle s'occupe également de la proposition de création de nouveaux produits et

Elle est en contact permanent avec sa clientèle en vue de l'éclairer sur

- la Direction Financière et comptable (DFC) :

Elle s'occupe de tout l'aspect :financier et comptable de la société. Elle planifie

Elle a également en charge la gestion de la comptabilisation de toutes les entrées

- la Direction des réseaux (DRX):

C'est le cœur de la société. Elle assure la gestion et la maintenance de tous les

- la Direction des Opérateurs et des Relations Extérieurs (DOR) :

- la Direction des Ressources Humaines (DRR):

- la Direction des systèmes d'information (DSI) :

Elle assure la gestion de l'information au sein de la société. C'est-à-dire le

Togo Telecom a pour mission principale, l'équipement et l'exploitation du

- l'installation et l'exploitation du réseau public des télécommunications à

- la fourniture de l'accès à internet

- la location de matériels et d'équipements téléphoniques

- la location de bâtiments techniques.

Chapitre 2: Etude de l'existant

2.1- Description de l'existant

2.1.1- L'aspect réseaux

La topologie mise en place au sein du réseau de Togo Télécom est le "Réseau

Le câblage du réseau de l'entreprise est toute la connectique réseau mise