Rapport de PFE

Automatisation Règlement des commissions Réseau Alternatif
 Page 1
Mise en place d’une solution
Automatisation Règlement des commissions Réseau
Alternatif
Ingénierie Informatique et Réseaux
Méthodes Informatiques Appliquées à la Gestion des Entreprises
(MIAGE)
2013-2014
Mlle. Ghizlane ALOZADE
M. Khalid ECHERIF
M. Hassan NACHIFA

 Page 2
Dédicaces
À mes chers parents Ahmed et R’qia,
Autant de phrases et d’expressions aussi éloquentes soient-elles ne sauraient
exprimer ma gratitude et ma reconnaissance. Vos conseils ont toujours guidé
mes pas vers la réussite. Votre compréhension et votre encouragement sont
pour moi le soutien indispensable que vous avez toujours su m’apporter.
Je vous dois ce que je suis aujourd’hui et ce que je serai demain et je ferai
toujours de mon mieux pour rester votre fierté et ne jamais vous décevoir.
Que Dieu, le tout puissant, vous préserve, vous accorde santé,
bonheur, quiétude de l’esprit et vous protège de tout mal.
À mes adorables frères Tarik et M’hamed,
Merci d’être toujours à mes côtés, par votre présence, par votre amour dévoué
et votre tendresse, pour donner du goût et du sens à ma vie. En témoignage de
mon amour et de ma grande affection, je vous prie de trouver dans ce travail
l’expression de mon estime et mon sincère attachement.
Je prie Dieu, le tout puissant, pour qu’il vous donne bonheur et prospérité.
À tous ceux qui mes ont chers, je dédie ce travail.
Ghizlane Alozade

 Page 3
Remerciements
En préambule à ce rapport, je souhaite adresser mes remerciements les plus
sincères aux personnes qui m’ont apporté leur aide et qui ont contribué à
l’élaboration de ce rapport ainsi qu’à la réussite de ce projet de fin d’études.
A cette occasion, j’exprime ma profonde gratitude à M. Hassan NACHIFA, pour
ses conseils, son soutien et ses précieuses directives.
Mes vifs remerciements vont également à M.KHALID ECHERIF, ainsi qu’à tout
le personnel de SAHAM, pour leur sympathie, leur disponibilité et leurs
compétences qu’ils ont su me prodiguer tout au long de mon stage de fin
d’études.
Un grand merci va à tous les enseignants qui m’ont accompagné durant mon
cursus à l’EMSI. Enfin, je remercie tous ceux qui ont contribué de près ou de
loin à la réussite de ce projet.
Je termine par un remerciement spécial à mes parents pour leur soutien moral
et financier durant ces nombreuses années d’études.
Un remerciement particulier aux membres du jury pour avoir accepté de juger
ce travail et de me faire profiter de leurs remarques et conseils.
Merci à tous et à toutes.

 Page 4
Résumé
Le présent document est la synthèse de mon travail dans le cadre du projet de fin
d’études, ce projet est une réponse à des besoins de sélection et de gestion
d’information formulés par l’équipe d’animation des réseaux alternatifs, au sein de
l’Entreprise SAHAM Assurances. Cette équipe, désireuse de structurer,
d’automatiser son action, souhaite disposer d’une solution d’automatisation et d’un
accompagnement méthodologique. Après un choix opéré sur la base de scénarios, la
création d’une nouvelle base de données et la réalisation d’un logiciel pour la mise
en place d’une solution d’automatisation du règlement des commissions sont
demandées, afin d’être agrégées dans un portail de publication et de diffusion
sélective d’informations. Le projet débouche sur la mise à disposition d’un système
d’automatisation global intégrant toutes ces fonctionnalités, accessible en local,
disposant d’un module d’administration et accompagné de la documentation
associée.
Mots-clés :
Réseau Alternatif, Commission, informatique, Automatisation, Calcul, commercial,
Démarcheurs, Encaissements.
Abstract
This document is a summary of my work in the project graduation, this project is a
response to the needsof the selection and management of informationformulated
by the entertainment alternative networksteamwithinEnterprise SAHAM
Insurance. This team is willing to structure,automate its action, wantsto have an
automation solution and methodological support. After surgery on the basis of
scenarios choice,creating a new database and implementation of software for the
implementation of a solution to automate the payment of the fees are required to be
aggregated in a publishing portal and selective disclosure.The project will lead to
the provision of a comprehensive automation system integratingall of these
features, accessible locally, withan administration and accompanied by supporting
documentation module.
Keywords:
Alternative Network, Commission, computer, automation, computing, commercial,
cold callers, Receipts.

 Page 5
Liste des abréviations * selon l’ordre d’apparition
SI Système d’information
DSI Direction des systèmes d’informations
UML Unified Modeling Language
SFI Société Financière Internationale
GSK Glaxo Smith Kline
BVD Bureau De Vente
PDV Point De Vente
AV Agent Vivier
CVT Centre de Visite Technique
2TUP 2 Track Unified Process
UP Unified Process
PU Processus Unifié
MVC Modèle, Vue, Contrôleur
PAQ Plan d’Assurance Qualité
OOSE Object Oriented Software Engineering
OMT Object Modeling Technique
SSIS SQL Server Intégration Services

 Page 6
Liste des figures
Figure 1: Les différents pôles de SAHAM Group__________________________________ 15
Figure 2:Organigramme de SAHAM Assurance __________________________________ 16
Figure 3:Organigramme de la DSI _____________________________________________ 17
Figure 4:Processus de développement en Y ______________________________________ 21
Figure 5:Planning prévisionnel________________________________________________ 26
Figure 6:Planning réel_______________________________________________________ 26
Figure 7:Schéma de classement________________________________________________ 28
Figure 8:Diagramme de contexte statique _______________________________________ 32
Figure 9:Diagramme de contexte dynamique_____________________________________ 33
Figure 10 : Cas d’utilisation « Consulter le règlement des commissions »_______________ 38
Figure 11: Diagramme de séquence« Consulter le règlement des commissions » _________ 39
Figure 12:Classes participantes « Consulter le règlement des commissions » ____________ 40
Figure 13:Cas d'utilisation « Lancer une Nouvelle Extraction »_______________________ 40
Figure 14: Diagramme de séquence « Lancer une Nouvelle Extraction » _______________ 42
Figure 15:Classes participantes « Lancer une Nouvelle Extraction »___________________ 43
Figure 16:Cas d'utilisation « Contrôler les commissions calculées »___________________ 43
Figure 17:Diagramme de séquence « Contrôler les commissions calculées » ____________ 44
Figure 18:Classes participantes« Contrôler les commissions calculées » ________________ 45
Figure 19:Cas d'utilisation « Paramétrer les taux »_________________________________ 45
Figure 20:Fiche descriptive « Paramétrer les taux » ________________________________ 46
Figure 21:Diagramme de séquence« Paramétrer les taux » __________________________ 46
Figure 22:Classes participantes « Paramétrer les taux »_____________________________ 47
Figure 23:Diagramme de cas d'utilisation global __________________________________ 47
Figure 24:architecture du scénario 1 ____________________________________________ 51
Figure 25:Architecture du scénario 2 ___________________________________________ 52
Figure 26:Diagramme de déploiement __________________________________________ 53
Figure 27:Diagramme de composants___________________________________________ 54
Figure 28:Fusion des classes participantes _______________________________________ 56
Figure 29:Diagramme de Package _____________________________________________ 57
Figure 30:Diagramme de classe « Recouvrement Back Office »_______________________ 59
Figure 31:Diagramme de classe « Comptabilité Technique »_________________________ 61
Figure 32: Diagramme de classe« Administration »________________________________ 63
Figure 33:Diagramme de classe statique global ___________________________________ 64
Figure 34:Diagramme de séquence MVC2 de « Contrôler les commissions calculées»_____ 65
Figure 35:Diagramme d’états-transitions ________________________________________ 66
Figure 36:Diagramme d’activité _______________________________________________ 67
Figure 37:Diagramme de classe dynamique______________________________________ 68
Figure 38:Couplage entre les deux démarches____________________________________ 69
Figure 39:Architecture du projet_______________________________________________ 71
Figure 40: Modèle logique de données__________________________________________ 72

 Page 7
Figure 41:Page d'authentification ______________________________________________ 76
Figure 42:Menu Principal Recouvrement Back Office ______________________________ 76
Figure 43:Notifications ______________________________________________________ 77
Figure 44:lancement de l’extraction ____________________________________________ 77
Figure 45:Liste des extractions ________________________________________________ 77
Figure 46:Valider les commissions _____________________________________________ 78
Figure 47:Signaler une anomalie_______________________________________________ 78
Figure 48:Enregistrement sous Excel ___________________________________________ 78
Figure 49:Consulter le règlement des commissions ________________________________ 79
Figure 50:Contacter l'administrateur ___________________________________________ 79
Figure 51:Menu principal Comptabilité technique_________________________________ 80
Figure 52:Valider les commissions calculées _____________________________________ 80
Figure 53:Edition des chèques_________________________________________________ 81
Figure 54:Fichier .txt Edition des chèques _______________________________________ 81
Figure 55:Page d'accueil d'administration _______________________________________ 82
Figure 56:Paramétrage des taux _______________________________________________ 82
Figure 57:Mise à jour des séries de chèques ______________________________________ 83
Figure 58:Mise à jour des opérateurs ___________________________________________ 83
Figure 59:Page d'accueil d'animation des réseaux alternatifs_________________________ 84
Figure 60:Page d'accueil de bureau d'ordre ______________________________________ 84
Figure 61:Bibiographie ______________________________________________________ 86
Figure 62: La création d'une ADO NET Source pour SQL Server ________________ 88
Figure 63: Requête pour l'affichage des commissions__________________________ 89
Figure 64: Exécution de la requête __________________________________________ 89
Figure 65: Mappage entre la base SQL Server et Oracle________________________ 90
Figure 66: Les données SQL Server vers Orale________________________________ 90

 Page 8
Liste des tableaux
Tableau 1: Livrables ________________________________________________________ 23
Tableau 2: Acteurs du projet__________________________________________________ 24
Tableau 3:Analyse des écarts _________________________________________________ 27
Tableau 4:Matrice des risques_________________________________________________ 28
Tableau 5:Tableau des estimations _____________________________________________ 29
Tableau 6:Messages_________________________________________________________ 34
Tableau 7:USE Case et leur Acteurs ____________________________________________ 37
Tableau 8:Fiche Descriptive « Consulter le règlement des commissions » ______________ 39
Tableau 9: Fiche descriptive« Lancer une Nouvelle Extraction »______________________ 41
Tableau 10:Fiche descriptive « Contrôler les commissions calculées » _________________ 44
Tableau 11:structure des use case en packages____________________________________ 48
Tableau 12:Classement des Use Cases __________________________________________ 49
Tableau 13:Affiner les associations « Recouvrement Back Office » ____________________ 57
Tableau 14:Affiner les attributs« Recouvrement Back Office » _______________________ 59
Tableau 15:Affiner les associations « Comptabilité Technique » ______________________ 60
Tableau 16:Affiner les attributs « Comptabilité Technique » _________________________ 61
Tableau 17:Affiner les associations « Administration » _____________________________ 62
Tableau 18:Affiner les attributs « Administration » ________________________________ 63
Tableau 19:Structure lot _____________________________________________________ 87

 Page 9
Liste des matières
Dédicaces___________________________________________________________________________ 2
Remerciements______________________________________________________________________ 3
Résumé_____________________________________________________________________________ 4
Abstract ____________________________________________________________________________ 4
Liste des abréviations * selon l’ordre d’apparition_______________________________________ 5
Liste des figures _____________________________________________________________________ 6
Liste des tableaux ___________________________________________________________________ 8
Liste des matières ___________________________________________________________________ 9
Introduction générale _______________________________________________________________ 12
CHAPITRE I :_______________________________________________________________________ 14
Contexte général du projet __________________________________________________________ 14
I. Présentation de l’organisme d’accueil _____________________________________________ 15
1. Présentation du groupe SAHAM _______________________________________________ 15
2. Organigramme du groupe ____________________________________________________ 16
3. Présentation de la DSI de SAHAM Assurance ____________________________________ 17
II. Cadre général du projet _________________________________________________________ 18
1. Contexte du projet ___________________________________________________________ 18
2. Objectifs généraux du projet ___________________________________________________ 18
Conclusion _______________________________________________________________________ 18
CHAPITRE II : ______________________________________________________________________ 19
Gestion du projet ___________________________________________________________________ 19
I. Conduite du projet _____________________________________________________________ 20
1. Définition __________________________________________________________________ 20
2. Méthodologie _______________________________________________________________ 20
II. Plan d’assurance qualité : _______________________________________________________ 22
1. Gestion du Plan Projet ________________________________________________________ 22
2. Périmètre du projet __________________________________________________________ 22
3. Organisation du projet________________________________________________________ 23
4. Planification et suivi du projet _________________________________________________ 25
5. Planning ___________________________________________________________________ 26
6. Matrice des risques __________________________________________________________ 27
Conclusion _______________________________________________________________________ 29
CHAPITRE III : _____________________________________________________________________ 30

 Page 10
Étude Préliminaire__________________________________________________________________ 30
I. Les acteurs du système _________________________________________________________ 31
1. Définition __________________________________________________________________ 31
2. Identification des acteurs______________________________________________________ 31
3. Diagramme de contexte statique _______________________________________________ 31
II. Les messages__________________________________________________________________ 32
1. Identification des messages____________________________________________________ 32
2. Diagramme de contexte dynamique ____________________________________________ 33
Conclusion _______________________________________________________________________ 34
CHAPITRE IV : _____________________________________________________________________ 35
Capture des besoins fonctionnels ____________________________________________________ 35
I. Identification des cas d’utilisations par ses acteurs ___________________________________ 36
II. Description des différents cas d’utilisation _________________________________________ 37
1. Description des cas d’utilisation________________________________________________ 38
2. Organisation des UseCases ____________________________________________________ 47
3. Structuration des UseCases en Packages _________________________________________ 48
4. Classement des Use Cases_____________________________________________________ 49
Conclusion _______________________________________________________________________ 49
CHAPITRE V : ______________________________________________________________________ 50
Capture des besoins techniques _____________________________________________________ 50
I. Architecture Matérielle _________________________________________________________ 51
1. Description des scénarii_______________________________________________________ 51
2. Diagramme de déploiement ___________________________________________________ 53
II. Architecture logicielle __________________________________________________________ 54
Conclusion _______________________________________________________________________ 54
CHAPITRE VI : _____________________________________________________________________ 55
Analyse ____________________________________________________________________________ 55
I. Modèle statique _______________________________________________________________ 56
1. Fusion des Classes participantes________________________________________________ 56
2. Diagramme de package _______________________________________________________ 57
3. Package Recouvrement Back Office _____________________________________________ 57
4. Package Comptabilité Technique _______________________________________________ 60
5. Package Administration ______________________________________________________ 61
6. Diagramme de classe statique global ____________________________________________ 64
II. Modèle Dynamique ____________________________________________________________ 65

 Page 11
1. Diagramme de séquence MVC2 ________________________________________________ 65
2. Diagramme d’états-transitions _________________________________________________ 66
3. Diagramme d’activité ________________________________________________________ 66
4. Diagramme de classes final____________________________________________________ 68
Conclusion _______________________________________________________________________ 69
CHAPITRE VII :_____________________________________________________________________ 70
Conception_________________________________________________________________________ 70
I. Architecture du projet __________________________________________________________ 71
II. Modèle logique de données______________________________________________________ 72
Conclusion _______________________________________________________________________ 72
CHAPITRE VII :_____________________________________________________________________ 73
Réalisation_________________________________________________________________________ 73
I. Technologies et outils de développement: __________________________________________ 74
1. Plateforme : Microsoft .Net ___________________________________________________ 74
2. Environnement de développement : Visual studio _________________________________ 74
3. Système de Gestion de Base de Données (SGBD) __________________________________ 74
4. Méthode de conception : UML _________________________________________________ 75
5. Logiciel de la conception : Power Designer _______________________________________ 75
6. Logiciel de migration : SSIS____________________________________________________ 75
II. Réalisation____________________________________________________________________ 76
1. Authentification _____________________________________________________________ 76
2. Recouvrement Back Office ____________________________________________________ 76
3. Comptabilité Technique ______________________________________________________ 80
4. Administration ______________________________________________________________ 81
5. Animation des Réseaux Alternatif ______________________________________________ 84
6. Bureau d’ordre ______________________________________________________________ 84
Conclusion_________________________________________________________________________ 85
Bibliographie _______________________________________________________________________ 86
Webographie _______________________________________________________________________ 86
ANNEXE ___________________________________________________________________________ 87
1. Structure lot standard SAHAM ASSURANCE ______________________________________ 87
2. Migration SQL Server Oracle ____________________________________________________ 88

 Page 12
Introduction générale
Dans le prolongement des réalisations rendues possibles grâce à sa restructuration
et à sa dynamique commerciale, SAHAM Assurance souhaite poursuivre ses efforts
en faveur d’un alignement de ses processusSI sur les meilleurespratiques.
La nouvelles stratégie de la compagnie met le client au centre de ses préoccupations
en lui garantissant le service adéquat dans le timing voulu, et pour le faire, il est
indispensable de s’offrir des outils de gouvernance SI qui permettent aux directions
des systèmes d’information d’être en coordination avec les stratégies définies et de
se transformer de centres de coût comme c’est vue dans la plupart des sociétés en
des centres de création de la valeur qui contribue pleinement dans la création de
richesse.
Afin de pouvoir s’aligner à cette stratégie, la DSI (Direction des Systèmes
d’Information) s’est inscrit à un certain nombre de démarches :
 Elaboration budgétaire.
 Pilotage des projets.
 Amélioration des services.
 Pilotage de la DSI.
 Pilotage des coûts informatiques.
L’objectif de ce projet consiste à développer une solution informatique. Il s’agit d’un
outil de règlement automatique des commissions pour la société SAHAM
Assurance.
Cette solution doit assurer un ensemble de fonctionnalités dont :
 Extraction des encaissements mensuels chaque début de mois.
 Calcul des commissions, la récupération du fichier du calcul et le transmettre pour
la validation.
 Edition des chèques et la génération automatique des écritures comptable.
 Paramétrage : permet à l’administrateur de gérer les sauvegardes qui lui permettront
d'enregistrer la base des données et faire la mise à jour nécessaire pour le bon
fonctionnement de l’application.
D’autre part, la mise en place d’un projet d’une telle ampleur nécessite une bonne
organisation et une méthodologie. Nous avons donc décidé de suivre la méthode
2TUP.

 Page 13
Le présent rapport synthétise tout le travail effectué dans cette perspective. Il est
organisé comme suit :
Le premier chapitre intitulé « Contexte général du projet » est dédié à la
présentation de l’organisme d’accueil de SAHAM Assurance et le cadre général du
projet.
Le deuxième chapitre «Gestion du projet » son objectif est l’identification et la
planification du projet ainsi que l’organisation de la mise en œuvre et le choix
méthodologique adopté.
Le troisième chapitre « Etude préliminaire » présente les différents acteurs du
futur système représentés sous forme d’un diagramme de contexte statique et
dynamique.
Le quatrième chapitre « Capture des besoins fonctionnels », Dans ce chapitre
nous partirons à la découverte des besoins fonctionnels .Et pour ce faire nous
utiliserons la notion de UseCase.
Le cinquième chapitre « Capture des besoins techniques » décrit les besoins
techniques.
Le sixième chapitre « Analyse » permet d’illustrer les principales constructions du
diagramme de classesUML durant l’étape d’analyse.
Le septième chapitre « Conception » propose une solution technique au problème
qui a été exposé lors de l’analyse et de donner une vision générale de l’architecture
logicielle qui sera mise en place.
Le huitième chapitre « Réalisation » sera consacré à présenter les outils utilisés
pour réaliser notre application ainsi qu’un aperçu sur cette dernière.
Et enfin,
Le dernier chapitre « Conclusion » présente un bilan global de ce stage, les acquis
à travers cette expérience que les retombées sur l’organisme, je donne quelques
perspectives à mon projet.

 Page 14
CHAPITRE I :
Contexte général du projet
Ce chapitre a pour but de situer le projet dans
son environnement organisationnel et
contextuel. Il présente dans la première partie
l’organisme d’accueil, sa structure et ses
activités, tandis que dans la deuxième partie,
présente le cadre général du projet.

 Page 15
I. Présentation de l’organisme d’accueil
1. Présentation du groupe SAHAM
Le Groupe SAHAM est une holding marocaine opérant dans plusieurs secteurs
d’activité et investissant dans des structures à fort potentiel de croissance. Créé en
1995, le Groupe réalise plus de 8 milliards de Dollars de chiffre d’affaires en 2013
et emploie plus de 5 600 collaborateurs.
Le Groupe a développé des partenariats capitalistiques et commerciaux avec des
acteurs de grande renommée tels que Bertelsmann, Mondial Assistance, CEGEDIM,
Sanam Holding, Abraaj Capital, la Société Financière Internationale (SFI) qui sont
devenus associésde certaines entitésdu Groupe.
Les activités du Groupe s’articulent autour de 4 axes : Assurance, Offshoring, Santé
et Immobilier.
Figure 1: Les différents pôles de SAHAM Group
 SAHAM Finance : SAHAM finance regroupe les activités d'assurance
(SAHAM assurance), d'assistance & TPA (SAHAM assistance) et de crédit à la
consommation (Taslif).
 SAHAM Offshoring : SAHAM est l'un des pionniers du secteur de
l'Offshoring avec la création de Phone Assistance en 1999 et de BPO
Insurance en 2011. Le groupe compte 8 centres de contact et 4000
collaborateurs au Maroc.
SAHAM Group
Pôle Finance
ASSURANCE
assistance
Crédit CONSO
TPA
Pôle
OFFSHORRING
Pôle Santé Pôle Immobilier
SAHAM Fondation

 Page 16
 SAHAM Santé : SAHAM Pharma, filiale du groupe SAHAM, a acquis en
mars 2011 le site de fabrication de la société GSK Maroc, filiale du groupe
international GlaxoSmithKline. Cette acquisition a constitué une étape
décisive dans la stratégie de développement de SAHAM dans le secteur de la
santé. L'activité établissements de soins santé est en cours de développement
avec la conclusion très récente d'un partenariat avec un opérateur européen
de premier plan.
 SAHAM Immobilier : Le Groupe SAHAM a choisi de mettre sa rigueur et son
savoir-faire au service de projets immobiliers d’envergure, à travers la
création de SAHAM Immobilier, qui a initié un ensemble de projets
immobiliersau Maroc.
 SAHAM Fondation : Portée par une vision citoyenne, la Fondation SAHAM
créée en 2008 s’engage auprès de populations dans le besoin, pour accélérer
le développement des pays où le Groupe est présent en Afrique et au Moyen-
Orient.
2. Organigramme du groupe
L’organigramme de SAHAM ASSURANCE est le suivant :
Figure 2:Organigramme de SAHAM Assurance

 Page 17
3. Présentation de la DSI de SAHAMAssurance
La direction des systèmes d’information est chargée de gérer les systèmes
d’information existants et de concevoir les nouvelles infrastructures matérielle,
logicielle, télécoms, permettant d’améliorer la qualité de service et la rentabilité de
la compagnie. La mission organisation consiste à mettre en place des nouvelles
procédures visant l’amélioration de l’efficacité collective des différentes entités
composant SAHAM Assurances.
Cette direction gère les besoins de la compagnie en ce qui concerne la mise en place
et la maintenance des systèmes d’information ainsi que l’ensemble des applications
utilisées à ce niveau. Elle compte un effectif de cinquante collaborateurs qui veillent
au respect des plannings et la fiabilité des informations aux différents niveaux de
traitement.
1.4 Missions de la DSI
La fonction SI pour SAHAM Assurances a une importance vitale et critique, le rôle
SI est peut se résumer comme suit :
 Assurer la surveillance et la gestion opérationnelle de l’ensemble des ressources
informatiques, en garantissant :
 Le niveau et les engagements de service ;
 La qualité des traitements.
 Garantir l’évolution cohérente de l’ensemble du SI dans le respect :
 Des objectifs fixés en termes de délais et de coûts;
 Respect des orientations stratégiques du top management
2.4 Organigramme de la DSI
Figure 3:Organigramme de la DSI
Directeur des Systémes
d'informations
LHOUSSAIN DRISSI KAMILI
Responsable Production
Rabii TAOUSSI
Nabil REMISS
Moustapha
HRIZZAN
Samira
SATROURI
LARBI BALI
Responsable Sécurités
et intégration
Hassan lagroubi
Fatiha KHALID
Khalid
MEZBERT
Responsable de
domaine transverse
KhalidECHRIF
Naoual
ELHROUR
Driss
ELHASSANI
Recherche et
développement
Amina THAMI
Fouad CHERRAGI
Kenza
BENHADDOU

 Page 18
II. Cadre général du projet
1. Contexte du projet
La gestion du réseau alternatif SAHAM Assurance a connu plusieurs évolutions
depuis sa création qui sont liées au changement du modèle initial (modèle salariés)
au modèle de démarcheurs.
Les faits les plus marquants sont :
 Augmentation de la taille du réseau (26 BDV en 2008 à 93 en 2013) ;
 Plan stratégique 2014-2016 : ouverture de 30 PDV/an ;
 Des systèmes classiques de pointage manuel et des fichiers Excel favorisant
plusieurs risques de traitement ;
 Multitude d’intervenants, de critères et de paramètres impactant le règlement des
commissions ;
 Manque de traçabilité du règlement des commissions.
Le présent projet est destiné à la mise en place d’un outil de règlement automatique
des commissions dédié à SAHAM Assurance.
2. Objectifs généraux du projet
L’objectif du projet est de concevoir, réaliser et implémenter une solution
d’automatisation du règlement des commissions Réseau Alternatif.
Cet outil doit assurer en premier lieu un ensemble de fonctionnalitésdont :
 Extraction des encaissements : Extraire les encaissements mensuels (mois
précédent) des AV et CVT.
 Calcul des commissions : Lancer le calcul des commissions et les transmettre
pour validation.
 Contrôle des commissions calculées : Contrôler les commissions calculées et
lancer l’édition des chèques et la génération automatique des écritures
comptables.
 Parametrage : Gérer les cheques, parametrer les taux.
 Gestion des utilisateurs : gérer les opérateurs ainsi que ses profils.
Conclusion
Ce premier chapitre représente un point de départ pour l’élaboration de ce projet,
dans la mesure où il présente successivement l’organisme d’accueil, ses différentes
activités, ses produits et le département d’accueil ainsi que le cadre général du
projet.

 Page 19
CHAPITRE II :
Gestion du projet
L’objectif de ce chapitre est l’identification et la
plannification du projet ainsi que
l’organisation de la mise en œuvre et le choix
méthodologique adopté.

 Page 20
I. Conduite du projet
1. Définition
La gestion de projet ou conduite de projet est une démarche visant à structurer,
assurer et optimiser le bon déroulement d'un projet suffisamment complexe pour
devoir :
 Etre planifiée dans le temps : c'est l'objet de la planification (La planification est la
programmation d'actions et d'opérations à mener).
 Etre budgétée (étude préalable des coûts et avantages ou revenus attendus en
contrepartie, des sources de financement, étude des risques opérationnels et
financiers et des impacts divers...).
 Faire intervenir de nombreuses parties prenantes : c'est l'objet des organisations qui
identifient maîtrise d'œuvre et maîtrise d’ouvrage (voir également fonctions de
maîtrise d'ouvrage).
 Responsabiliser le chef de projet ou le directeur de projet (Le directeur de projet ou
encore coordinateur de projet est la personne responsabilisée sur l'aboutissement
d'un projet (par exemple, d'un projet d'évolution du système d'information), mettre
en place un comité de pilotage.
 Suivre des enjeux opérationnels et financiers importants.
Afin de réussir ce projet, il est nécessaire de se baser sur un cycle de
développement sur lequel s’articule l’ensemble des solutions. Pour ce faire nous
avons choisi UML comme langage de modélisation et le processus 2TUP comme
méthode de développement.
2. Méthodologie
1.2 Langage UML
UML ou Unified Modeling Language, est un langage de modélisationqui est né au
milieu des années 90·· de la fusion de trois méthodesobjets: OMT(Object Modeling
Technique),BOOCH1 et OOSE (Object Oriented Software Engineering).
L'idée de cette fusion est partie du constat qu'à l'époque il existait plusieurs
méthodesobjets liées par un consensusautour d'idéescommunes: objets, classes,
sous-systèmes etc.
C'est à partir de 1997 que l'OMG2 (Object Management Group) qui standardise les
technologies de l'objet, s'est attachée à la définition d'un langage commun unique,
utilisable par toutes les méthodesobjets dans toutes les phases du cycle de vie e t
compatible avec les techniques de réalisation du moment. D'où la naissance d'UML.
UML offre des éléments pour décrire les différents aspectsd'un système: les
diagrammes.
Les diagrammes utilisés dans l'ensemble de notre analyse sont:
 Le diagramme des cas d'utilisation
 Le diagramme de classes d'objets
 Le diagramme de package

 Page 21
 Le diagramme de séquences
 Le diagramme d'activité
2.2 Processus 2TUP
Le Two Track Unified Process (2TUP), est une variante du processus unifié (UP). Un
processus Unifié est un processus de développement logiciel construit sur UML. Il
est itératif et incrémentai, conduit par les cas d'utilisation et piloté par les risques.
La gestion d'un tel processus est organisée selon 5 phases:
 Pré étude, capture des besoins et étude
 Analyse et conception préliminaire
 Conception et tests
 Déploiement et tests
 Bilan du cycle de développement.
Le processus unifié n'est pas un processus universel mais une trame commune des
meilleures pratiques de développement. L'objectif du processus 2TUP est de
capitaliser le travail effectué sur la branche fonctionnelle d'une part et technique
d'autre part avant même de commencer la conception du système souhaité. Le
2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques
des aspects fonctionnels. Illustré par la figure ci-dessous, le processus en Y
s'articule autour de 3 phases:
Branche technique: qui a pour objectif de recenser les besoins techniques et
d'élaborer une architecture logicielle et applicative ;
Branche fonctionnelle: elle a pour but de dégager les grandes fonctionnalités et les
frontières du système;
Phase de réalisation: qui consiste en la conception et en la mise en œuvre du
système.
Figure 4:Processus de développement en Y

 Page 22
II. Plan d’assurance qualité :
Le plan projet vise à décrire les dispositions prises pour obtenir la qualité du logiciel
définie en accord avec la maîtrise d'ouvrage.
Il sert de référence pour définir :
 quels sont les objectifs du projet,
 ce que le projet doit produire,
 qui intervient dans le projet et quand,
 comment on travaille sur ce projet,
 quel est le déroulement du projet (planning, phases).
L'utilisation du PAQ doit permettre d'atteindre les objectifs suivants:
 Constituer une référence commune à tous les membres de l'équipe projet.
 Il permettra d'assurer une bonne cohérence et une homogénéité dans les méthodes de
travail.
 garantir la qualité du produit et des prestations. Cette qualité s'exprime par des critères
de qualité à respecter dans le cadre de ce projet.
 définir les procédures à suivre, les outils à utiliser, les normes à re specter, la
méthodologie de développement du produit et les contrôles prévues pour chaque activité.
1. Gestion du Plan Projet
1.1 Procédure de validation du Plan Projet
Le Plan Projet établit les règles d’organisation, de fonctionnement et de production
de livrables entre les différents acteurs du projet. Il doit donc être validé.
2.1 Procédure d’évolution du Plan Projet
La rédaction et la mise à jour de ce document sont sous la responsabilité de l’élève
ingénieure « Alozade Ghizlane», l’encadrant du projet « Mr. Hassan NACHIFA »
participe à l’élaboration du plan d’Assurance qualité et à son approbation.
La mise à jour de ce document sera effectuée en cas d’événement exceptionnel
nécessitant une remise en cause forte du planning, des charges ou du périmètre du
projet.
2. Périmètre du projet
1.2 But du projet
Ce projet de fin d’études a pour but de mettre en place un outil de règlement
automatique des commissions qui permettra au Recouvrement Back office de
calculer automatiquement les commissions des démarcheurs .La comptabilité
technique aura la possibilité d’éditer les chèques et l’insertion des écritures
comptables au sein de CODA . Un service de mailing servira à informer de l’état
d’avancement du règlement de la commission.

 Page 23
2.2 Objectifs stratégiques du projet
Parmi les objectifs fixés par la mise en place de cette plate -forme on peut citer :
 Mettre en place un outil orienté vers les démarcheurs pour développer leurs besoins
en matière de règlement de leurs commissions.
 Délivrer la bonne information, au bon temps, à la bonne personne et sous le bon
format.
 Intégrer et fusionner toutes les données relatives aux calculs des commissions
autour de notre futur système.
3.2 Mission du projet
Dans le cadre du projet, des principales missions sont à accomplir, à savoir:
 La montée en compétences
 L’étude préalable
 L’étude technique
 L’analyse
 La conception
 L’implémentation
 L’intégration et test
 Le déploiement
 La documentation du projet
4.2 Livrables
Phase Livrable Responsable Date
livraison
prévue
Date
livraison
réelle
Date
validation
prévue
Etude
Préalable
Chef de
projet
29/04/2014
18/04/2014
11/04/2014
05/05/2014
24/04/2014
17/04/2014
30/04/2014
30/04/2014
30/04/2014
Analyse Spécifications
Générales
Chef de
projet
30/05/2014 03/06/2014 02/06/2014
Conception
fonctionnelles.
Chef de
projet
06/06/2014
12/06/2014
09/06/2014
13/06/2014
13/06/2014
13/06/2014
techniques.
Réalisation Chef de
projet
22/07/2014
-
17/07/2014
-
25/07/2014
-
Tableau 1: Livrables
3. Organisation du projet
1.3 Acteurs du projet
Nom Organisme d’accueil Fonction Rôle dans le projet

 Page 24
Mr KHALID
ECHERIF
SAHAM ASSURANCE Responsable de domaine
transverse
Maitre d’ouvrage
Mr HASSAN
NACHIFA
EMSI ENCADRANT EMSI RESPONSABLE
PEDAGOGIQUE
Mlle ALOZADE
Ghizlane
SAHAM ASSURANCE STAGIAIRE Chef de projet
Tableau 2: Acteurs du projet
2.3 Rôles des acteurs du projet
Maître d’ouvrage
Il est responsable sur l’ensemble du projet, à ce titre:
 Valide les livrables du projet.
 S’assure de la cohérence entre les spécifications fonctionnelles et la solution technique
 Contrôle le respect du périmètre, du délai par un suivi périodique de l’avancement par
rapport au jalon projet.
Chef de projet
 Elabore le planning de réalisation
 Elabore le document de veille technologique
 Elabore le dossier des spécifications fonctionnelles
 Rédige les comptes rendus de réunion
 Rédige et met à jour la matrice de traçabilité
 Réalise le prototype (Analyse, Conception, Réalisation)
 Rédige les plans de test d’intégration.
3.3 Instances de suivi de projet
Une séance d’encadrement avec l’encadrent pédagogique sera organisée toutes les
semaines le Samedi à 11h30 GMT.
Cette réunion a pour objectifs :
 Le suivi détaillé de l’avancement du projet
 Le suivi des actions à mener sur le projet
 Le suivi des actions d’assurance qualité menées
 La synchronisation entre l’équipe
 Les éléments issus d’une révision périodique du projet :
 La validation de la révision des risques
 La validation des indicateurs projets

 Page 25
1.2 Outils de Gestion de projet
Gantt Project est un logiciel libre de gestion de projet écrit en Java, ce qui permet
de l'utiliser sur de nombreux OS tel que Windows, Linux, MacOS.
Gantt Project permet la planification d'un projet à travers la réalisation
d'un diagramme de Gantt. L'outil permet de créer des diagrammes de Gantt, des
diagrammes de ressources et des réseaux PERT .
Les principales fonctionnalités:
 Planification et pilotage des projets.
 Gestion des ressources.
 Gestion des couts.
 Analyse et communication des informations du projet.
4. Planification et suivi du projet
1.4 Planification
L'objectif de ce planning est de déterminer les étapes du proje t et le timing. Ce
planning joue un rôle primordial pour la réalisation et le suivi du projet, il est établi
dans le début de chaque projet afin de suivre le bon déroulement de chaque tâche.
L’élaboration du planning s’est basée sur l’hypothèse suivante :
 Respect des périodes de validation.
 Le planning peut subir des modifications suivant les impératifs du projet.
2.4 Structure de découpage du projet
 Phase d’Etude préalable : Cette phase démarre par une identification et planification
du projet, qui consiste à collecter les besoins fonctionnelles et techniques. Aussi une
identification et justification des choix techniques à adopter pour la réalisation des deux
formes de l’application. De plus qu’une étape de formation et familiarisation avec les
nouvelles technologies à utiliser. Cette phase se termine par une élaboration d’un PQP,
un dossier de l’existent et un dossier technique du projet.
 Analyse et conception: la phase d’analyse et conception va permettre de recenser les
besoins fonctionnels du point de vue de l’utilisateur. permet la conception graphique,
fonctionnelle et technique du projet
 Réalisation : La phase de réalisation va permettre une implémentation de l’application,
d’une façon modulaire, en respectant les documents réalisés dans la phase d’analyse et
de conception cette phase intègre les tests et déploiement de l’application.

 Page 26
5. Planning
1.5 Planning prévisionnel
Ce planning a été établi après la définition du besoin. Il comporte les étapes du
projet et les durées qui leur ont été allouées aussi bien que les durées des
différentes sous taches composant chaque phase. Ainsi, ce planning a servi de
tableau de bord pour le suivi de l’état d’avancement du projet.
Figure 5:Planning prévisionnel
2.5 Planning réel du projet
L’élaboration du planning s’est basée sur le respect des périodes de validation.
Le planning peut subir des modifications suivant lesimpératifs du projet.
Figure 6:Planning réel

 Page 27
La figure ci-dessus représente le planning réel du projet qui est diffèrent du
planning prévisionnel cité au début, et ces écart sont analysés dans la partie
suivante.
3.5 Analyse des écarts
L’analyse des écarts permet de faire la comparaison entre le planning réel et celui
prévisionnel.
Son objectif principal réside dans la recherche des causes des écarts et la mesure
de leurs impacts sur le projet, et surtout en tirer des conclusions pratiques pour
l’élaboration des futurs plannings.
Cause d’écart Nombre de
jours
Type d’écart
L’identification du projet a pris 9 jours au lieu de 5 vu que
les fonctionnalités du projet n’étaient pas assez claires au
début.
+4 Retard
La partie Codage nous a pris 21 jours au lieu de 27 parce
qu’il n’y avait pas assez de complications là-dessus.
-6 Avance
Tableau 3:Analyse des écarts
6. Matrice des risques
Maîtriser les risques est une préoccupation majeure en conduite de projet
informatique. Les risques sont définis comme la possibilité qu'un projet ne s'exécute
pas conformément aux prévisions de dates, de coût ou de qualité.
L’identification initiale des risques s’est effectuée en fonction des objectifs, des
exigenceset du contexte du projet.
Pour effectuer ce recensement, nous avons procédé à un brainstorming avec les
membres de l’équipe et consulter les suivis des risques effectués sur les projets
antérieurs.
Ensuite les risques sont classifiés (classification selon une typologie et estimation
de leur probabilité d’apparition) ; leurs conséquences sont évaluées (en termes
d’impacts).
Le tableau suivant illustre la matrice des risques identifiés susceptible d’affecter le
déroulement normal du projet, leurs impacts et les actions préventives à réaliser
pour limiter la probabilité de l’apparition de chaque risque.

 Page 28
Risque Impact Probabilité
Niveau
d’impact Classement Actions préventives Actions Correctives
Non
Validation
des
interfaces
Conduit à un
retard sur le délai
de mise en œuvre
des interface dû à
une mauvaise
ergonomie
2/4 3/4 * Analyse du travail
(démarche
d’ergonomie) : prise en
compte de l’utilisateur
(fonction,
comportement.)
* Maquettage et
évaluation
ergonomique
* Organiser des
réunions avec le
client afin de
déterminer et de
valider les
maquettes
Abscence de
cahier des
charges
Création d'une
ambigüité ce qui
pourra générer
un retard qui
influencera
probablement la
date de livraison
2/4 2/4 *Réorganisation du
travail en cas de conflit
* Réunions avec le
client et collecte de
leurs suggestions
* Organiser des
réunions avec le
client afin de
détailler le cahier
des charges
Changement
ou évolution
des besoins
du client
Conduit à un
retard sur le délai
2/4 3/4 *le choix d’une
approche impliquant
fortement le client le
long du projet
* Réunions avec le
client et prise en
compte des ses
nouveaux besoins
Changement
de la
technologie
Retard dans
l’avancement du
projet
4/4 3/4 *Etude préalable et
comparative des
technologies existantes
*Changer la
technologie et
augmenter la masse
horaire
*Doubler l’effort
pour couvrir le
manque
Tableau 4:Matrice des risques
Classement:
impact *
probabilité
1/16
->4/16:
Faible
4/16
->8/16:
Moyen
8/16
->12/16:
Sévère
12/16
->16/16:
Dangereux
Figure 7:Schéma de classement

 Page 29
Echelle Impact Probabilité
1/4 Risque acceptable Rare
2/4 Performance Possible
3/4 Retard de livraison Souvent
4/4 Non disponibilité d’une fonction
vitale
Très possible
Tableau 5:Tableau des estimations
Conclusion
Après avoir déterminé méthodologie du travail sur le projet, le planning, les tâches
du projet et les risques pouvant nuire à l’aboutissement d’objectifs, le chapitre
suivant concerne une étude comparative.

 Page 30
CHAPITRE III :
Étude Préliminaire
L’étude préliminaire est la toute première
étape du processus de développement. Elle
consiste à effectuer un premier repérage des
besoins fonctionnels et opérationnels, en
utilisant principalement le texte, ou des
diagrammes très simples, Elle prépare les
activités plus formelles de capture des besoins
fonctionnels et de capture des besoins
techniques .

 Page 31
I. Les acteurs du système
1. Définition
Un acteur représente l'abstraction d'un rôle joué par des entités externes
(utilisateur, dispositif matériel ou autre système) qui interagissent directement avec
le système étudié.
Un acteur peut consulter et/ou modifier directement l'état du système, en émettant
et/ou en recevant des messages éventuellement porteurs de données.
Les acteurscandidats sont systématiquement :
 les utilisateurs humains directs : identifiez tous les profils possibles, sans
oublier l'administrateur, l'opérateur de maintenance,etc. ;
 les autres systèmes connexes qui interagissent aussi directement avec le
système.
2. Identification des acteurs
Les acteursqui interagissent avec le Système sont :
 Recouvrement Back office : Le recouvreur est généralement en charge de
l’extraction des encaissements mensuels (mois précédent) des AV et CVT
,ainsi, il a pour missions principales , le lancement du calcul des
commissions;
 Comptabilité technique : le Comptable a comme rôle le contrôle des
commissions calculées ;
 Bureaud’ordre : les agentsdu bureau d’ordre confirme la réception des
chèques de règlement suite à un courrier électronique envoyé par le
système afinde les transmettre aux démarcheurs;
 Animation des réseauxAlternatif : les fonctionnalités des animateurs de
réseau Alternatifse limitent à la transmission des chèques des démarcheurs
au Bureau d’ordre ;
 Administrateur System : L'administrateur système gère les profils des
utilisateurs, il est en charge du bon fonctionnement et de la maintenance de
la plate-forme ;
 CIOL : Ce système s’occupe de l’émergement des primes encaissées et les
annotations ;
 CHECK 2003 : cette application permet l’édition automatique des chèques de
règlement;
 CODA : cet outil facilite la génération automatique des écritures comptables.
Tous les utilisateursdoivent s’authentifier avant de passer à n’importe quelle
opération dans le système .Cesdifférentsacteurssont présentés sur le diagramme
de contexte statique ci-dessous (Figure 8).
3. Diagramme de contexte statique
Le diagramme montre le nombre d'instances d'acteursreliésau système à un
moment donné.

 Page 32
Dans notre cas, nous avons :
 Un Comptable technique;
 Plusieurs animateurs réseau alternatif;
 Un agent Bureau d’ordre ;
 Un serveur Check 2003;
 Un CIOL qui fournit la base de donnéesdes commissions ;
 Un Systéme CODA;
 Un agent Recouvrement Back Office;
 un administrateur.
Figure 8:Diagramme de contexte statique
II. Les messages
1. Identification des messages
Un message représente la spécificationd'une communication unidirectionnelle
entre objets et qui transporte de l'information avec l'intention de déclencher une
activité chez le récepteur.
Un message est normalement associé à deux occurrences d'évènement :
Un évènement d'envoi et un évènement de réception.
Les messagesrépertoriés entre le système et sesacteurs sont :
Messages émis par le système
 Afficher la liste des encaissements ;
 Afficher la liste des commissions calculées ;

 Page 33
 Afficher la liste des opérateurs ;
 Afficher la liste des taux ;
 Afficher la liste des sériesdes chèques ;
 Afficher la liste des commissions calculées ;
 Renvoyer la liste des commissionsà réglées sous format .txt ;
 Insérer les écritures comptables dans les tables brouillards ;
 Afficher la liste des chèques de règlement.
Messages reçus par le système
 Lancer une nouvelle extraction ;
 Déclencher le calcul ;
 Renvoyer la liste des encaissementsmensuels ;
 Mettre à jour des opérateurs ;
 Paramétrer lestaux ;
 Gérer les sériesdes chèques ;
 Valider les commissions calculées ;
 Remonter les anomalies ;
 Accuser la réception des chèques ;
 Remettre le chèque de règlement.
Ces messagesrépertoriés peuvent être représentés sur un diagramme de contexte
dynamique.
2. Diagramme de contexte dynamique
C'est un diagramme de communication qui permet de positionner le système étudié
dans son environnement. Ce diagramme précise les échanges d'informations qui
sont réalisés entre notre système et les élémentsextérieurs au système.
Figure 9:Diagramme de contexte dynamique

 Page 34
Acteur Messages Emis Message Reçus
Recouvrement Back Office (1)Lancer une nouvelle
extraction
(2)Déclencher le calcul
(3)Afficher la liste des
encaissements
(4) Afficher la liste des
commissions calculées
CIOL (5)Renvoyer la liste des
encaissements mensuels
Administrateur (6)Mettre à jour des
opérateurs
(7)Paramétrer lestaux
(8)Gérer lessériesdes
chèques
opérateurs
taux
sériesdes chèques
Comptabilité technique (12)Valider les commissions
calculées
(13)Remonter les anomalies
commissions calculées
Check 2003 (15)Renvoyer la liste des
commissions à réglées sous
format .txt
CODA (16)Insérer les écritures
comptables dans les
tables brouillards
Animateur Réseau Alternatif (17)Accuser la réception des
chèques
chèques de règlement
Bureau d’ordre (19)Remettre le chèque de
règlement
chèques de règlement
Tableau 6:Messages
Conclusion
Nous avons présenté dans cette partie une étude détaillée du besoin en décrivant le
processus métier auquel ce projet devra répondre.

 Page 35
CHAPITRE IV :
Capture des besoins fonctionnels
Dans ce chapitre nous partirons à la
découverte des besoins fonctionnels .Et pour
ce faire nous utiliserons la notion de
UseCase. Chaque UseCase sera identifié,
décrit, et organisé, classé en fonction de son
importance dans le projet.

 Page 36
I. Identification des cas d’utilisations par ses acteurs
Considérons l’intention fonctionnelle de l’acteur par rapport au système dans le
cadre de l’émissionou de la réception de chaque message.
En regroupant les intentions fonctionnellesen unités cohérentes, on obtient les use
case recherchés.
UseCase Acteur Principal/
Acteurs Secondaires
MessagesEmis/ Reçus par
Acteurs
Consulte r le rè gle me nt
de s commi ssi ons
o Recouvrement BO
o Compta bilité
technique
o Administrateur
o Animation des
réseaux alternatifs
o Bureau d’ordre
Emi s :
Re çu :
o Affi che r la li ste de s
commi ssi ons calculé e s.
Lance r nouve lle
e xtracti on
o Recouvrement BO
o CIOL
Emi s :
o Lance r une nouve lle
e xtracti on.
o Dé cle nche r le calcul.
o Re nvoye r la li ste de s
e ncai sse me nts me nsue ls.
Re çu :
e ncai sse me nts
Contrôle r le s
commi ssi ons calculé e s
o Compta bilité
technique
Emi s :
o Vali de r le s commi ssi ons
calculé e s.
o Re monte r le s anomali e s.
Re çu :
commi ssi ons calculé e s.
Lance r l’é di ti on de s
chè que s
o Compta bilité
technique
o Check 2003
Emi s :
Re çu :
commi ssi ons à ré glé e s
sous format .txt .
Paramé tre r le s taux de s
commi ssi ons
o Administrateur Emi s :
o Paramé tre r le s taux.
Re çu :
o Affi che r la li ste de s taux.
Gé re r le s chè que s o Administrateur Emi s :
o Gé re r le s sé ri e s de s
chè que s
Re çu :

 Page 37
chè que s
Me ttre à jour le s profi ls o Administrateur Emi s :
o Me ttre à jour le s
opé rate urs
Re çu :
opé rate urs
Re ce voi r le s chè que s o Animation des
Emi s :
o Accuse r la ré ce pti on de s
chè que s
Re çu :
chè que s de rè gle me nt
Re me ttre le chè que de
rè gle me nt
o Bureau d’ordre Emi s :
o Re me ttre le chè que de
rè gle me nt
Re çu :
chè que s de rè gle me nt
Edi te r le s chè que s o CHECK 2003 Emi s :
o
Re çu :
commi ssi ons à ré glé e s
sous format .te xt
Gé né re r le s é cri ture s
comptable s
o CODA Emi s :
Re çu :
o Insé re r le s é cri ture s
comptable s dans le s table s
broui llards
Tableau 7:USE Case et leur Acteurs
II. Description des différents cas d’utilisation
Chaque UseCase est décrit dans sa fiche descriptive.
Comment lire la fiche descriptive d’un UseCase :
Afin de mieux comprendre un fonctionnement d’un UseCase, il faut procéder de la
manière suivante pour chacun des UseCase :
 Tout d’abord il faut savoir que pour chaque UseCase nous avons une fiche
descriptive suivie d’une table de définition, voire même un schéma descriptif.
 lire la fiche descriptive. Si un mot est ambigu alors il faut jeter un coup d’œil sur la
table de définition de cet UseCase.
 Revenir en arrière sur la fiche descriptive afin de poursuivre la lecture.

 Page 38
1. Description des cas d’utilisation
Cas d’utilisation « Consulter le règlement des commissions »
Figure 10 : Cas d’utilisation « Consulter le règlement des commissions »
a. Description textuelle
Fiche Descriptive de l’UseCase :
Consulter le règlement des commissions
Sommaire d’Identification
Titre : Consulter le règlement des commissions.
But : Visualiser la liste des commissions calculées par mois ou
intermédiaire.
Résumé : Filtrer la liste par intermédiaire ou date.
Date de Création: 20 /05/2014 Date de Mise à Jour:23/05/2014
Pré condition
L’utilisateur doit être authentifié
Scénario Nominal
1. L’utilisateur accède au menu principal ;
2. L’utilisateur demande la consultation du règlement des
commissions ;
3. Le système affiche la liste des commissions calculées du
dernier mois réglé ;
4. L’utilisateur filtre la liste selon son intérêt ;
5. L’utilisateur quitte le menu.
Scénario Alternatif

 Page 39
Il débute à l'étape 4 du scénario principal:
1. Lorsque l’utilisateur choisi un mois non réglé, le système
affiche un message d’alerte ;
2. Le chef commercial choisie un autre critère de recherche;
3. Le chef commercial quitte le système.
Post Conditions
Tableau 8:Fiche Descriptive « Consulter le règlement des commissions »
b. Diagramme de Séquence
Figure 11: Diagramme de séquence« Consulter le règlement des commissions »

 Page 40
c. Classes Participantes
Figure 12:Classes participantes « Consulter le règlement des commissions »
Cas d’utilisation « Lancer une Nouvelle Extraction »
Figure 13:Cas d'utilisation « Lancer une Nouvelle Extraction »
Fiche Descriptive de l’UseCase :
Lancer une Nouvelle Extraction
Titre : Lancer une Nouvelle Extraction
But : calculer les commissions.

 Page 41
Résumé : Extraire les encaissements mensuels (mois précédent) des
AV et CVT.
Date de Création: 20 /05/2014Date de Mise à Jour:22/05/2014
Pré condition
Scénario Nominal
1. Le Recouvreur accède au menu principal ;
2. Le Recouvreur demande une nouvelle extraction ;
3. Le système affiche la liste des mois et les années ;
4. Le Recouvreur choisi le mois souhaité avant de lancer
l’extraction ;
5. Le système affiche la liste des encaissements mensuels
du mois choisi ;
6. Le Recouvreur lance le calcul ;
7. Le système affiche la liste des commissions calculées;
8. Le Recouvreur valide l’extraction ;
9. Le Recouvreur quitte le Menu
1. Lorsque le recouvreur signal une anomalie e n cas d’une
extraction non valide ;
2. un mail est envoyé automatiquement au help desk en copie
avec l’administrateur;
3. Le Recouvreur quitte le Menu ;
Post Conditions
L’administrateur relance l’extraction des encaissements.
Le help desk ajoute cette déclaration à CA.
Tableau 9: Fiche descriptive« Lancer une Nouvelle Extraction »
Note :
La CA est solution dédiée au service HelpDesk permet la gestion des réclamations.

 Page 42
Figure 14: Diagramme de séquence « Lancer une Nouvelle Extraction »

 Page 43
Figure 15:Classes participantes « Lancer une Nouvelle Extraction »
Cas d’utilisation « Contrôler les commissions calculées »
Figure 16:Cas d'utilisation « Contrôler les commissions calculées »
Fiche Descriptive de l’Use Case :
Contrôler les commissions calculées
Titre : Contrôler les commissions calculées
But : Vérifier les commissions calculées par le recouvrement Back
office avant de lancer l’édition des chèques.
Résumé :
Date de Création: 20 /05/2014Date de Mise à Jour:24/07/2014
Pré condition
Scénario Nominal

 Page 44
1. Le comptable accède au menu principal ;
2. Le système affiche le menu principal ;
3. Le comptable demande le contrôle des commissions calculées ;
4. Le système affiche la liste des commissions calculées ;
5. Le comptable valide les commissions ;
6. Le comptable quitte le menu ;
1. Lorsque les commissions affichées sont invalides ;
2. L’agent comptable signale une anomalie en envoyant un
mail au service help desk;
3. Le comptable quitte le menu
Post Conditions
Le service help desk transfère le signal d’anomalie à l’administrateur.
Tableau 10:Fiche descriptive « Contrôler les commissions calculées »
Figure 17:Diagramme de séquence « Contrôler les commissions calculées »

 Page 45
Figure 18:Classes participantes« Contrôler les commissions calculées »
Cas d’utilisation « Paramétrer les taux »
Figure 19:Cas d'utilisation « Paramétrer les taux »
Fiche Descriptive de l’Use Case :
Paramétrer les taux
Titre : Paramétrer les taux
But : Faire une mise à jour des taux, branches, et des groupes
Résumé :
Date de Création: 20 /05/2014 Date de Mise à Jour:24/07/2014
Pré condition
Scénario Nominal

 Page 46
1. L’administrateur accède au menu principal ;
2. Le système affiche la fenêtre des taux ;
3. L’administrateur choisi un onglet
(taux/branches/groupes) selon son besoin ;
4. Le système affiche la liste des informations ;
5. L’administrateur mettre à jour les informations souhaitées;
6. L’administrateur quitte la fenêtre.
1. Lorsque l’administrateur veut mettre à jour ou
rechercher une information invalide ;
2. Le système affiche un message d’erreur;
3. L’administrateur ressaisi ses informations ;
4. L’administrateur quitte la fenêtre;
Post Conditions
Figure 20:Fiche descriptive « Paramétrer les taux »
Figure 21:Diagramme de séquence« Paramétrer les taux »

 Page 47
Figure 22:Classes participantes « Paramétrer les taux »
2. Organisation des UseCases
Figure 23:Diagramme de cas d'utilisation global

 Page 48
3. Structuration des UseCases en Packages
UseCases Acteur Principal,
Acteurs Secondaires
PACKAGES
Consulte r le rè gle me nt
de s commi ssi ons
o Recouvre ur BO
o Agent Comptable
o Administrateur
o Animateur des
o Agent Bureau
d’ordre
Administration
Lance r nouve lle
e xtracti on
o Recouvre ur BO Recouvrement BO
Contrôle r le s
commi ssi ons calculé e s
o Agent Compta bilité
technique
Comptabilité technique
Lance r l’é di ti on de s
chè que s
technique
Comptabilité technique
Me ttre à jour le s profi ls o Administrateur Administration
Paramé tre r le s taux o Administrateur Administration
Gé re r le s chè que s o Administrateur Administration
Re ce voi r le s chè que s o Animateur des
Animation des réseaux
alternatifs
Re me ttre le chè que de
rè gle me nt
o Agent Bureau
d’ordre
Bureau d’ordre
Edi te r le s chè que s o CHECK 2003 Comptabilité technique
Gé né re r le s é cri ture s
comptable s
o CODA Comptabilité technique
S’authe nti fi e r o Recouvreur BO
technique
o Administrateur
o Animateur des
o Agent Bureau
d’ordre
Administration
Tableau 11:structure des use case en packages
A ce niveau nous avons déjà un premier découpage de notre solution en packages.
Ensuite nous avons réalisé des diagrammes de UseCases de chacun des Packages
.Et ceci a été détaillé dans le document annexe Capture des BesoinsFonctionnels.

 Page 49
4. Classement des Use Cases
Dans cette partie, nous allons procéder à une organisation des UseCases afin
d’identifier au Plutôt les UseCases les plus importants et procéder par la même
occasion à une identification Desrisques.
Et Par la suite nous allons identifier et dresser un tableau récapitulatif des
différents UseCases avec cette fois ci les différentes spécifications afin d’être sûr que
nos différents diagrammes de cas d’utilisation répondent effectivement aux besoins
du client.
Liste des UseCases Niveau de Risque Type de Priorité Classement
Consulte r le
rè gle me nt de s
commi ssi ons
Bas Moyenne 6
Lance r nouve lle
e xtracti on
Haut Haute 1
Contrôle r le s
commi ssi ons
calculé e s
Haut Haute 2
Lance r l’é di ti on
de s chè que s
Haut Haute 3
Paramé tre r le s
taux de s
commi ssi ons
Bas Basse 9
Gé re r le s chè que s Bas Basse 10
Me ttre à jour le s
profi ls
Bas Basse 11
Re ce voi r le s
chè que s
Bas Moyenne 7
Re me ttre le
chè que de
rè gle me nt
Bas Moyenne 8
Edi te r le s
chè que s
Haut Haute 4
Gé né re r le s
é cri ture s
comptable s
Haut Haute 5
S’authe nti fi e r Bas Basse 12
Tableau 12:Classement des Use Cases
Conclusion
Le but de ce chapitre consiste à identifier en première partie les différents acteurs
du système tout en précisant le diagramme de contexte statique et en deuxième
partie les différentsmessagesen réalisant le diagramme de contexte dynamique.

 Page 50
CHAPITRE V :
Capture des besoins techniques
Les besoins techniques seront exprimés
dans les lignes qui suivront. Les différentes
Architectures techniques (matérielle,
logicielle) seront évoquées.

 Page 51
I. Architecture Matérielle
1. Description des scénarii
1.1 Description du Scénario 1
Le premier scénario que nous proposons est assez simple dans son architecture
réseau et dans sa mise en œuvre. Ce scénario consistera à mettre en place une
application fonctionnant selon une architecture 2-tiers encore appelée architecture
client lourd/serveur. Ce style d'architecture met en œuvre deux niveaux
environnementaux et organisationnels. En effet, on distingue d'une part le «client
lourd» demandeur de service et d'autre part le «serveur de données» qui fournit le
service. Du point de vue logique, nous avons choisi d'associer l'architecture
logicielle en cinq (O5) couches à cette architecture physique. De ce fait, les couches
présentation, application et métier seront développées du côté « client» et les
couches accèsaux données et physique du côté « serveur ».
Nous aurons donc la base de données qui sera délocalisée sur un serveur dédié, le
serveur de données qui fournira les données à exploiter. Les utilisateurs pourront
avoir accès à ces données à travers le code applicatif qui sera installé sur leurs
postes de travail respectifset ce, via le réseaulocal d'entreprise.
Figure 24:architecture du scénario 1
 Matériels et logiciels requis:
Le service informatique dispose déjà d'un réseau local avec des serveurs de grande
capacité. Il dispose également des matériels nécessaires (switchs, postes de travail,
routeurs ...) pour la mise en œuvre de l'application. La mise en œuvre de notre
système ne va donc pas entraîner un coût matériel.

 Page 52
2.1 Description du Scénario 2
Ce scénario est assez semblable au premier, mais en plus des « clients» et du
serveur de données évoqués plus haut, il fait intervenir un troisième tiers: un
serveur d'application.
Ce type d'architecture physique est appelé architecture 3-tiers. A la différence du
scénario précédent, les machines clientes, appelées aussi «clients légers» ne
contiennent que l'interface de l'application afin d'assurer les interactions avec le
système. Elles sont ainsi déchargées de tout traitement comme c'était le cas au
niveau du premier scénario. La logique applicative est maintenant dédiée au second
tiers, le serveur d'application, qui sert de liaison entre l'interface applicative et les
données toujours localisées au niveau du serveur de données. Cette architecture
sur le plan logique, sera mise en œuvre suivant le modèle Mvc (Modèle Vue
Contrôleur). Le modèle c'est-à-dire la base de données sera déployée au niveau du
serveur de données, la Vue (interface) au niveau client et le contrôleur (code
applicatif) au niveau du serveur d'application.
Les utilisateurs, à partir de n'importe quel poste de travail relié au serveur
d'application pourront accéder à l'application.
Figure 25:Architecture du scénario 2
 Matériels et logiciels requis
Ce scénario n'entraînera pas aussi de coût matériel. En effet, les équipements
matériels nécessairesexistent déjà.
3.1 Etude comparative des différents scénarii
Il s'agit pour nous dans ce paragraphe, de faire un choix entre les différentes
solutions présentées, en se basant sur les points forts et les points faibles de
chacune d'elles. L'étude comparative des scénarii proposées qui suivra, nous aidera
à opérer le choix le plus judicieux.
 Avantages et Inconvénients du Premier scénario
Avantage:
 Facile à réaliser;
 Sécurité renforcée à cause de la réduction de points d'entrée;

 Page 53
 Permet un dialogue direct entre le client et le serveur;
Inconvénient:
 Performance réduit;
 Nécessité d'installer les pilotes applicatifs et les pilotes de données sur
chaque poste;
 Avantages et Inconvénients du Deuxième scénario
Avantage:
 Possibilité de modifier une couche sans répercussion sur les autres;
 Déploiement et maintenance peu coûteux;
Inconvénients:
 Complexité de la mise en œuvre ;
 Nombre de points d'entrées élevés;
4.1 Choix du scénario
Le premier scénario, à la différence du deuxième, propose une architecture
physique et logicielle assez simple à mettre en place. En effet, il fait l'économie de
l'usage d'un second serveur (serveur d'application) et se trouve moins coûteux. De
plus en termes de sécurité, il s'avère plus avantageux car avec l'architecture 2-tiers,
les points d'accès au système sont considérablement réduits. De ce fait, il n'exige
pas une politique de sécurité complexe.
Le second scénario quant à lui, est moins coûteux en termes de déploiement et de
maintenance.
Au sortir de cette étude comparative, notre choix en conformité avec le groupe de
pilotage s'est porté sur la combinaison des deux scénarii pour la mise en œuvre de
notre système.
2. Diagramme de déploiement
Dans cette partie nous nous contenteronsde proposer une architecture technique
selon le diagramme de déploiement UML.
Figure 26:Diagramme de déploiement
TCP/IP TCP/IP
Client
lourd
Serveur de données
SQL Server
Oracle
Serveur d'
application

 Page 54
II. Architecture logicielle
Sur le plan logique ; notre architecture 3 tiers est mise en œuvre suivant le modèle
MVC (Modèle Vue Contrôleur) qui s'applique donc au niveau du client.
En effet, la spécification d’une architecture à composants métier 3-tiers implique la
répartition des composants d’exploitation suivant lesresponsabilités.
Le diagramme de composants ci-dessous, montre les différents types de
composants d’exploitation du système.
Figure 27:Diagramme de composants
Conclusion
Le but de ce chapitre consiste à identifier en première partie l’architecture
matérielle en précisant le diagramme de déploiement et en deuxième partie
l’architecture logicielle.
Serveur d'application
Couche Métier
Couche accés aux données
Entity Framework
Serveur de base de données
SQL SERVER
ORACLE
Client lourd
Couche Présentation
WinForm

 Page 55
CHAPITRE VI :
Analyse
Ce chapitre va nous permettre d’illustrer les principales
constructions du diagramme de classes UML durant
l’étape d’analyse. Le diagramme de classes a toujours
été le diagramme le plus important dans toutes les
méthodes orientées objet. C’est également celui qui
contient la plus grande gamme de notations et de
variantes.

 Page 56
I. Modèle statique
1. Fusion des Classes participantes
Figure 28:Fusion des classes participantes

 Page 57
2. Diagramme de package
A partir de Diagrammes de classes candidates précédent nous allons le découper en
diagramme de package suivant :
Figure 29:Diagramme de Package
Nous allons choisir les packages suivant pour les traiter
 Recouvrement Back Office
 Comptabilité technique
 Administration
3. Package Recouvrement Back Office
1.1 Affiner les Classes
Nous avons les classessuivant :
Organisme,Intermédiaire, Client, Quittance, Police.
2.1 Affiner les associations
Association Classes Cardinalités
Police Client Intermédiaire 1..* 1..*
contenir Quittance Police 1..1 0..*
Tableau 13:Affiner les associations « Recouvrement Back Office »
3.1 Affiner les attributs
Classe Attribut Description
Client idClient Code du client
Recouvrement Back Office Comptabilité Technique
Bureau d'ordreAnimation des Réseaux
Alternatif
Administration

 Page 58
Organisme adresse1 La première adresse de
l’organisme
adresse2 La deuxième adresse de
l’organisme
adresse3 La troisième adresse de
l’organisme
tel1 Le premier numéro téléphone de
l’organisme
tel2 Le deuxième numéro téléphone
de l’organisme
fax Le numéro de fax de l’organisme
adresseMail L’adresse mail de l’organisme
raisonSociale La raison sociale de l’organisme
tel3 Le troisième numéro téléphone
de l’organisme
idOrganisme L’identifiant de l’organisme
Police idPolice L’identifiant de la police
dateDebut La date début de la police
dateFin La date fin de la police
nature La nature de la police
codeAssurance Le code d’assurancede la police
dateMotivation La date de motivation de la
police
debutGarantie La date début de garantie de la
police
finGarantie La date fin de garantie de la
police
Quittance idQuittance L’identifiant de la quittance
credit Le crédit de la quittance
dateEmission La date d’émission de la
quittance
primeNet La prime nette de la quittance
montantTaxe Le montant taxé de la quittance

 Page 59
montantAccessoire Le montant des accessoires de la
quittance
total Le montant total de la quittance
netAPayer Le net à payer de la quittance
dateReglement La date de règlement de la
quittance
Intermédiaire idIntermediare L’identifiant de l’intermédiaire
matricule La matricule de l’intermédiaire
formeJuridique La forme juridique de
l’intermédiaire
titulaire Le nom complet de l’agent
codeConvention Le code convention de
l’intermédiaire
codeCompable Le code comptable de
l’intermédiaire
Tableau 14:Affiner les attributs« Recouvrement Back Office »
4.1 Diagramme de classe
Figure 30:Diagramme de classe « Recouvrement Back Office »

 Page 60
4. Package Comptabilité Technique
Commission, chèque, Règlement, statut.
Suivre Chèque Règlement 1..1 0..1
Police Client Intermédiaire 1..* 1..*
Dépendre Commission Règlement 0..1 1..*
Avoir Commission Statut 1..1 0..1
Tableau 15:Affiner les associations « Comptabilité Technique »
Commission idCommission L’identifiant de la commission
dateCommission La date de traitement de la
commission
total Le total de la commission
plafond Le plat fond de la commission
accessoire Les accessoires de la commission
timbre Le timbre de la commission
taux Le taux de la commission
mois Le mois de la commission
annee L’année de la commission
Chèque idCheque L’identifiant de chèque
numeroCompte Le numéro du compte de chèque
rib Le RIB de chèque
case1 La première case à remplir de
chèque
case2 La deuxième case à remplir de
chèque

 Page 61
montant Le montant de chèque
dateTraitement La date de traitement de chèque
par la comptabilité
dateRa La date de traitement de chèque
par RA
dateBo La date de traitement de chèque
par BO
Règlement idReglement L’identifiant de règlement
total Le total de règlement
dateReglement La date de règlement
Statut idStatut L’identifiant de statut
libelle Libellé de statut
dateMaj La date de mise à jour de statut
dateCreation La date de création de statut
actif True si le statut est actif et false
s’il est désactivé
Tableau 16:Affiner les attributs « Comptabilité Technique »
Figure 31:Diagramme de classe « Comptabilité Technique »
5. Package Administration
Banque, Société, Série_Chèque, Profil, Opérateur, Type, Groupe, Branche,Service,
Département, Région, Ville.
1..10..1 0..1 1..*
1..1
0..1
Commission
-
-
-
-
-
-
-
-
-
id_commission
date_commission
total
plafond
accessoire
timbre
taux
mois
annee
: Integer
: Date
: Double
: Double
: Double
: Double
: Double
: String
: String
Réglement
-
-
-
id_reglement
total
date_reglement
: Integer
: Double
: Date
Chéque
-
-
-
-
-
-
-
-
-
id_cheque
numero_compte
rib
case1
case2
montant
date_traitement
date_ra
date_bo
: Integer
: String
: String
: String
: String
: Double
: Date
: Date
: Date
Statut
-
-
-
-
-
id_statut
libelle
date_maj
date_creation
actif
: Integer
: String
: Date
: Date
: Boolean

 Page 62
Taux Branche Type 1..* 1..*
Dépendre Banque Série_Chèque 0..* 1..1
Appartenir Société Banque 0..* 1..1
Se composer Service Département 1..1 1..*
Avoir Groupe Branche 1..* 1..1
Groupe Groupe 1..1 0..1
Lier Operateur Service 1..1 0..*
Posséder Profil Operateur 0..* 0..1
Attacher Profil Région 0..1 0..*
Se situer Ville Région 1..1 1..*
Tableau 17:Affiner les associations « Administration »
Banque idBanque Identifiant de la banque
libelle Libellé de la banque
Branche idBranche Identifiant de la branche
libelle Libellé de la branche
Département idDept Identifiant du département
Groupe idGroupe Identifiant du Groupe
libelle Libellé du Groupe
Operateur login Le nom d’utilisateur
motPasse Le mot de passe

 Page 63
actif Le statut de l’opérateur
Profil idProfil Identifiant du profil
Région idRegion Identifiant de la région
Service idService Identifiant du service
Société idSociete Identifiant de la société
Série_Chèque debut Le début de série XXXX
fin La fin de la série YYYY
Taux taux Le taux de la commission
Type idType Identifiant du type
Ville idVille Identifiant de la ville
Tableau 18:Affiner les attributs « Administration »
Figure 32: Diagramme de classe« Administration »

 Page 64
6. Diagramme de classe statique global
Figure 33:Diagramme de classe statique global

 Page 65
II. Modèle Dynamique
Le développement du modèle dynamique constitue une activité primordiale de
l’étape d’analyse. Elle se situe sur la branche gauche du cycle en Y. Il s’agit d’une
activité itérative, fortement couplée avec l’activité de modélisation statique, décrite
au chapitre précédent.
1. Diagramme de séquence MVC2
Nous savons qu’un cas d’utilisation décrit un ensemble de scénarios. Lors de l’étape
de détermination des besoins fonctionnels, un scénario représente une séquence
d’interactions entre le système et ses acteurs. Le système est alors considéré comme
une boîte noire. Maintenant que nous avons développé le modèle statique d’analyse,
nous allons remplacer le système par une collaboration d’objets dans chaque
scénario il s’agit de diagramme de séquence MVC 2.
Nous avons opté de décrire les diagrammes de use case traités précédemment pour
respecter la méthode 2TUP Diagramme de séquence MVC2.
1.1 Diagramme de séquence MVC2 de « Contrôler les commissions calculées»
Figure 34:Diagramme de séquence MVC2 de « Contrôler les commissions calculées»

 Page 66
2. Diagramme d’états-transitions
Un diagramme états-transitions affiche les états possibles de l'objet et les
transitions qui provoquent un changement d'état.
Figure 35:Diagramme d’états-transitions
3. Diagramme d’activité
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 de flots de données. Ils permettent ainsi de représenter graphiquement
le comportement d’une méthode ou le déroulement d’un cas d’utilisation.
Le diagramme d’activité correspondant au règlement des commissions est le
suivant :
Signaler Anomalie
Extraire Encaissement
Lancer Calcul
Contrôler Calcul Editer Chèques
Fin Réglement
En attente
Calculée
Validée
Réglée

 Page 67
Figure 36:Diagramme d’activité

 Page 68
4. Diagramme final de classes
Figure 37:Diagramme de classe dynamique
0..1
0..*1..1
1..*
0..*
0..1
1..1
0..*
1..10..*
0..*
1..1
0..*
1..1
1..1
0..10..1
1..*
0..*
1..1
1..*
1..10..*
0..1
1..*
1..*
0..*
0..1
1..1
0..*
1..1
0..*
1..10..1
1..1
1..*
0..*
1..1
1..*
1..*
0..*
1..1
1..1
0..1
Intermédiaire
-
-
-
-
-
-
id_intermediare
matricule
forme_juridique
Titulaire
code_convention
code_compable
:Integer
:String
:String
:String
:String
:String
+
+
+
+
+
ajouter()
modifier()
supprimer()
getAllIntermediaire()
Affecter()
:Boolean
:Boolean
:Boolean
:List
:void
Client
-Id_Client:Integer
+
+
+
+
ajouter()
modifier()
supprimer()
getAllClient()
:Boolean
:Boolean
:Boolean
:List
Police
-
-
-
-
-
-
-
-
Id_police
Date_debut
Date_fin
nature
code_assurance
date_motivation
debut_garantie
fin_garantie
:Integer
:Date
:Date
:String
:String
:Date
:Date
:Date
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllPolice()
:Boolean
:Boolean
:Boolean
:Police
:List
Type
-
-
id_type
libelle
:Integer
:String
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllType()
:Boolean
:Boolean
:Boolean
:Type
:List
Quittance
-
-
-
-
-
-
-
-
-
id_quittance
credit
date_emission
prime_net
montant_taxe
montant_accessoire
total
net_a_payer
date_Reglement
:Integer
:Double
:Date
:Double
:Double
:Double
:Double
:Double
:int
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllQuittance()
:Boolean
:Boolean
:Boolean
:Quittance
:List
Branche
-
-
Id_branche
libelle
:Integer
:String
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllBranche()
:Boolean
:Boolean
:Boolean
:Branche
:List
Groupe
-
-
id_groupe
libelle
:Integer
:String
+
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllGroupe()
Affecter()
:Boolean
:Boolean
:Boolean
:Groupe
:List
:void
Commission
-
-
-
-
-
-
-
-
-
id_commission
date_commission
total
plafond
accessoire
timbre
taux
mois
annee
:Integer
:Date
:Double
:Double
:Double
:Double
:Double
:String
:String
+
+
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllCommission()
valider()
clôturer()
:Boolean
:Boolean
:Boolean
:Commission
:List
:void
:int
Réglement
-
-
-
id_reglement
total
date_reglement
:Integer
:Double
:Date
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllRéglement()
:Boolean
:Boolean
:Boolean
:Intermediaire
:List
Chéque
-
-
-
-
-
-
-
-
-
id_cheque
numero_compte
rib
case1
case2
montant
date_traitement
date_ra
date_bo
:Integer
:String
:String
:String
:String
:Double
:Date
:Date
:Date
+
+
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllCheque()
recevoir()
remettre()
:Boolean
:Boolean
:Boolean
:Cheque
:List
:void
:void
Série_Chèque
-
-
-
-
id_serie_cheque
rip
debut
fin
:Integer
:String
:String
:String
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllSerieCheque()
:Boolean
:Boolean
:Boolean
:SerieCheque
:List
Banque
-
-
Id_banque
libelle
:Integer
:String
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllBanque()
:Boolean
:Boolean
:Boolean
:BBanque
:List
Statut
-
-
-
-
-
id_statut
libelle
date_maj
date_creation
actif
:Integer
:String
:Date
:Date
:Boolean
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllStatut()
:Boolean
:Boolean
:Boolean
:Statut
:List
Société
-
-
id_societe
libelle
:Integer
:String
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllSociete()
:Boolean
:Boolean
:Boolean
:Societe
:List
Ville
-
-
id_ville
libelle
:Integer
:String
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllVille()
:Boolean
:Boolean
:Boolean
:Ville
:List
Région
-
-
id_region
libelle
:Integer
:String
+
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllRegion()
AffecterVille()
:Boolean
:Boolean
:Boolean
:Region
:List
:int
Taux
-taux:Double
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllTaux()
:Boolean
:Boolean
:Boolean
:Taux
:List
Operateur
-
-
-
-
id_operateur
login
mot_passe
actif
:Integer
:String
:String
:Boolean
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllOperateur()
:Boolean
:Boolean
:Boolean
:Operateur
:List
Profil
-
-
id_profil
libelle
:Integer
:String
+
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllProfil()
Affecter()
:Boolean
:Boolean
:Boolean
:Profil
:List
:void
Departement
-
-
id_dept
libelle
:Integer
:String
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllDepartement()
:Boolean
:Boolean
:Boolean
:Departement
:List
Service
-
-
id_service
libelle
:Integer
:String
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllService()
:Boolean
:Boolean
:Boolean
:Service
:List
Organisme
-
-
-
-
-
-
-
adresse1
tel1
fax
adresse_mail
raison_sociale
tel3
id_organisme
:String
:String
:String
:String
:String
:String
:Integer
+
+
+
+
+
ajouter()
modifier()
supprimer()
getById()
getAllOrganisme()
:Boolean
:Boolean
:Boolean
:Organisme
:List

 Page 69
Conclusion
Le Couplage entre les démarches des modèles statique et dynamique :
Figure 38:Couplage entre les deux démarches

 Page 70
CHAPITRE VII :
Conception
Dans cette partie nous allons proposer une
solution technique au problème qui a été exposé
lors de l’analyse et de donner une vision générale
de l’architecture logicielle qui sera mise en place.

 Page 71
I. Architecture du projet
ARCHITECTURE DU PROJET SOUS VISUAL STUDIO
Figure 39:Architecture du projet

 Page 72
II. Modèle logique de données
Figure 40: Modèle logique de données
Conclusion
Le but de ce chapitre consiste à identifier en première partie l’architecture du projet
et en deuxième partie le modèle logique de données.
Intermédiaire
id_organisme
id_type
id_intermediare
matricule
forme_juridique
Titulaire
code_convention
code_compable
INTEGER
INTEGER
INTEGER
VARCHAR2(254)
VARCHAR2(254)
VARCHAR2(254)
VARCHAR2(254)
VARCHAR2(254)
<pk,fk2>
<fk1>
Client
id_organisme
Id_Client
INTEGER
INTEGER
<pk,fk>
Police
id_organisme
Cli_id_organisme
Id_police
Date_debut
Date_fin
nature
code_assurance
date_motivation
debut_garantie
fin_garantie
INTEGER
INTEGER
INTEGER
DATE
DATE
VARCHAR2(254)
VARCHAR2(254)
DATE
DATE
DATE
<pk,fk1>
<pk,fk2>
<pk>
Type
id_type
libelle
INTEGER
VARCHAR2(254)
<pk>
Quittance
id_quittance
id_organisme
Cli_id_organisme
Id_police
id_groupe
Id_branche
credit
date_emission
prime_net
montant_taxe
montant_accessoire
total
net_a_payer
date_Reglement
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
INTEGER
NUMBER
DATE
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
INTEGER
<pk>
<fk2>
<fk2>
<fk2>
<fk1>
<fk1>
Branche
id_groupe
Id_branche
libelle
INTEGER
INTEGER
VARCHAR2(254)
<pk,fk>
<pk>
Groupe
id_groupe
Gro_id_groupe
libelle
INTEGER
INTEGER
VARCHAR2(254)
<pk>
<fk>
Commission
id_commission
id_reglement
id_quittance
id_statut
date_commission
total
plafond
accessoire
timbre
taux
mois
annee
INTEGER
INTEGER
INTEGER
INTEGER
DATE
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
VARCHAR2(254)
VARCHAR2(254)
<pk>
<fk1>
<fk3>
<fk2>
Réglement
id_reglement
id_cheque
total
date_reglement
INTEGER
INTEGER
NUMBER
DATE
<pk>
<fk>
Chéque
id_cheque
id_serie_cheque
id_reglement
numero_compte
rib
case1
case2
montant
date_traitement
date_ra
date_bo
INTEGER
INTEGER
INTEGER
VARCHAR2(254)
VARCHAR2(254)
VARCHAR2(254)
VARCHAR2(254)
NUMBER
DATE
DATE
DATE
<pk>
<fk1>
<fk2>
Série_Chèque
id_serie_cheque
id_statut
Id_banque
rip
debut
fin
INTEGER
INTEGER
INTEGER
VARCHAR2(254)
VARCHAR2(254)
VARCHAR2(254)
<pk>
<fk2>
<fk1>
Banque
Id_banque
id_societe
libelle
INTEGER
INTEGER
VARCHAR2(254)
<pk>
<fk>
Statut
id_statut
id_serie_cheque
id_commission
id_operateur
libelle
date_maj
date_creation
actif
INTEGER
INTEGER
INTEGER
INTEGER
VARCHAR2(254)
DATE
DATE
SMALLINT
<pk>
<fk3>
<fk2>
<fk1>
Société
id_societe
libelle
INTEGER
VARCHAR2(254)
<pk>
Ville
id_region
id_ville
libelle
INTEGER
INTEGER
VARCHAR2(254)
<pk,fk>
<pk>
Région
id_region
libelle
INTEGER
VARCHAR2(254)
<pk>
Taux
id_type
id_groupe
Id_branche
taux
INTEGER
INTEGER
INTEGER
NUMBER
<pk,fk1>
<pk,fk2>
<pk,fk2>
Operateur
id_operateur
id_dept
id_service
id_profil
login
mot_passe
actif
INTEGER
INTEGER
INTEGER
INTEGER
VARCHAR2(254)
VARCHAR2(254)
SMALLINT
<pk>
<fk2>
<fk2>
<fk1>
Profil
id_profil
id_region
libelle
INTEGER
INTEGER
VARCHAR2(254)
<pk>
<fk>Departement
id_dept
libelle
INTEGER
VARCHAR2(254)
<pk>
Service
id_dept
id_service
libelle
INTEGER
INTEGER
VARCHAR2(254)
<pk,fk>
<pk>
Organisme
adresse1
tel1
fax
adresse_mail
raison_sociale
tel3
id_organisme
id_region
id_ville
VARCHAR2(254)
VARCHAR2(254)
VARCHAR2(254)
VARCHAR2(254)
VARCHAR2(254)
VARCHAR2(254)
INTEGER
INTEGER
INTEGER
<pk>
<fk>
<fk>

 Page 73
CHAPITRE VII :
Réalisation
Ce chapitre sera consacré à présenter les
outils utilisés pour réaliser notre
application ainsi qu’un aperçu sur cette
dernière.

 Page 74
I. Technologies et outils de développement:
1. Plateforme : Microsoft .Net
Le C♯ est un langage de programmation orienté objet à
typage fort, créé par la société Microsoft, et notamment un de ses employés, ‘Anders
Hejlsberg’, le créateur du langage Delphi.
Il a été créé afin que la plate-forme Microsoft .NET soit dotée d'un langage
permettant d'utiliser toutes ses capacités. Il est très proche du Java dont il reprend
la syntaxe générale ainsi que les concepts (la syntaxe reste cependant relativement
semblable à celle de langages tels que le C++ et le C). Un ajout notable au C♯ est la
possibilité de surcharge des opérateurs, inspirée du C++. Toutefois,
l'implémentation de la redéfinition est plus proche de celle du Pascal Objet.
2. Environnement de développement : Visual studio
Microsoft Visual Studio est une suite de logiciels de
développement pour Windows conçue par Microsoft.
La dernière version s'appelle Visual Studio 2013.
Visual Studio est un ensemble complet d'outils de développement permettant de
générer des applications Web ASP.NET, des Services Web XML, des applications
bureautiques et des applications mobiles. Visual Basic, Visual C++, Visual C# et
Visual J# utilisent tous le même environnement de développement intégré (IDE,
Integrated Development Environment), qui leur permet de partager des outils et
facilite la création de solutionsfaisant appel à plusieurs langages.
3. Système de Gestion de Base de Données (SGBD)
SQL Server 2012
Microsoft SQL Server est un système de gestion de base
de données (abrégé en SGBD ou SGBDR pour « Système
de gestion de base de données relationnelles ») développé
et commercialisé par la société Microsoft.
Bien qu'il ait été initialement codéveloppé par Sybase et Microsoft, Ashton-Tate a
également été associé à sa première version, sortie en 1989. Cette version est sortie
sur les plates-formes Unix et OS/2. Depuis, Microsoft a porté ce système de base de
données sous Windows et il est désormais uniquement pris en charge par ce
système.

 Page 75
Oracle 11g
Oracle Data base est un système de gestion de
base de données relationnel (SGBDR) qui
depuis l'introduction du support du modèle
objet dans sa version 8 peut être aussi qualifié
de système de gestion de base de données relationnel-objet (SGBDRO). Fourni
par Oracle Corporation, il a été développé par Larry Ellison, accompagné d'autres
personnes telles que Bob Miner et Ed Oates.
4. Méthode de conception : UML
« Unified Modeling Language » : UML se définit comme un
langage de modélisation graphique et textuel destiné à
comprendre et décrire des besoins, spécifier, concevoir des
solutions et communiquer des points de vue. (Pitman, 2006)
UML unifie à la fois les notations et les concepts orientés
objet.il ne s’agit pas d’une simple notation, mais les concepts transmis par un
diagramme ont une sémantique précise et sont porteurs de sens au même titre que
les mots d’un langage, c’est pour ça qu’UML est présenté parfois comme une
méthode alors qu’il ne l’est absolument pas.
5. Logiciel de la conception : Power Designer
Power Designer est une puissante solution de Modélisation des
Systèmes d'Informations. Cet ensemble d'outils supporte plusieurs
techniques de modélisation standard : modélisation Merise
(Données et Traitements), Modélisation UML particulièrement adaptée à la logique
des applications et Modélisation des Processus Métiers.
6. Logiciel de migration : SSIS
SSIS est un outil d'extraction, de transformation
et de chargement de données,en bref ce que l'on appelle un ETL. On extrait d'une
source de données, puis suit la transformation si besoin, pour ensuite injecter ces
données vers MS SQL Server ou encore d'autresdestinations.
SSIS est l'amélioration de la version 2005 d'un outil souvent plus connu, dans les
versions antérieures à 2005, sous le nom de Data Transformation Services, soit
DTS.

 Page 76
II. Réalisation
Cette partie présente quelques interfaces correspondant à la solution.
1. Authentification
Figure 41:Page d'authentification
Selon le compte connecté, l’utilisateur sera redirigé vers l’un des cinq profils de la solution.
2. Recouvrement Back Office
1.2 Page d’accueil
Figure 42:Menu Principal Recouvrement Back Office

Rapport de PFE

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Rapport de PFE

Similaire à Rapport de PFE (20)

Rapport de PFE