Rapportfinalv1 160413132045

Automatisation Règlement des commissions Réseau Alternatif
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)
M. Hassan NACHIFA
Mlle. Ghizlane ALOZADE
M. Khalid ECHERIF
2013-2014
 Page 1
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 2
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 3
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 needs of the selection and management of information formulated
by the entertainment alternative networks team within Enterprise SAHAM
Insurance. This team is willing to structure, automate its action, wants to 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 integrating all of these
features, accessible locally, with an administration and accompanied by supporting
documentation module.
Keywords:
Alternative Network, Commission, computer, automation, computing, commercial,

cold callers, Receipts.
 Page 4
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 5
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 6
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 7
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 8
Liste des matières

Dédicaces ___________________________________________________________________________ 2
Remerciements ______________________________________________________________________ 3
Résumé _____________________________________________________________________________ 4
Abstract ____________________________________________________________________________ 4
Liste des abréviations * selon l’ordre d’a pparition _______________________________________ 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. Organigra mme 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éthodologi e _______________________________________________________________ 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 9
É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 packa ge _______________________________________________________ 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 10
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
Bibliogra phie _______________________________________________________________________ 86
Webogra phie _______________________________________________________________________ 86

ANNEXE ___________________________________________________________________________ 87
1. Structure lot standard SAHAM ASSUR ANCE ______________________________________ 87
2. Migration SQL Server Oracle ____________________________________________________ 88
 Page 11
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 processus SI sur les meilleures pratiques.
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 12
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 classes UML 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 13
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 14
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és de certaines entités du Groupe.
Les activités du Groupe s’articulent autour de 4 axes : Assurance, Offshoring, Santé

et Immobilier.
SAHAM Group
SAHAM Fondation
Pôle Pôle Immobilier

Pôle Finance Pôle Santé
OFFSHORRING
ASSURANCE
assistance
Crédit CONSO
TPA
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.
 Page 15
 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
immobiliers au 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 16
3. Présentation de la DSI de SAHAM Assurance
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

Directeur des Systémes
d'informations
LHOUSSAIN DRISSI KAMILI
Responsable Sécurités Responsable de Recherche et

Responsable Production et intégration domaine transverse développement
Rabii TAOUSSI Hassan lagroubi Khalid ECHRIF Amina THAMI
Naoual
Nabil REMISS Fatiha KHALID Fouad CHERRAGI
ELHROUR
Moustapha Khalid Driss Kenza

HRIZZAN MEZBERT ELHASSANI BENHADDOU
Samira
SATROURI
LARBI BALI
Figure 3:Organigramme de la DSI
 Page 17
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 assure r en premier lieu un ensemble de fonctionnalités dont :
 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 : C ontrô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 18
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 19
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).
 Responsa biliser le chef de projet ou le directeur de projet (Le directeur de projet ou
encore coordinateur de projet est la personne responsa bilisé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élisation qui est né au

milieu des années 90·· de la fusion de trois méthodes objets: 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éthodes objets liées par un consensus autour d'idées communes: objets, classes,
sous-systèmes etc.
C'est à partir de 1997 que l'OMG2 (Object Manage ment 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éthodes objets 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 aspects d'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 20
 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 21
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 22
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 Date Date
livraison livraison validation
prévue réelle prévue
Etude Chef de 29/04/2014 05/05/2014 30/04/2014
Préalable projet 18/04/2014 24/04/2014 30/04/2014

11/04/2014 17/04/2014 30/04/2014
Analyse Spécifications Chef de 30/05/2014 03/06/2014 02/06/2014
Générales projet
Conception Chef de 06/06/2014 09/06/2014 13/06/2014
fonctionnelles. projet
12/06/2014 13/06/2014 13/06/2014
techniques.
Réalisation Chef de 22/07/2014 17/07/2014 25/07/2014
projet - - -
Tableau 1: Livrables
3. Organisation du projet
1.3 Acteurs du projet
Nom Organisme d’accueil Fonction Rôle dans le projet
 Page 23
M r KHALID SAHAM ASSURANCE Responsable de domaine Maitre d’ouvrage

ECHERIF transverse
M r HASSAN EMSI ENCADRANT EMSI RESPONSABLE

NACHIFA PEDAGOGI QUE
M lle ALOZADE SAHAM ASSURANCE STAGIAIRE Chef de projet

Ghizlane
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 risque s
 La validation des indicateurs projets
 Page 24
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 conce ption: 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’an alyse et
de conception cette phase intègre les tests et déploiement de l’application.
 Page 25
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 les impératifs du projet.
Figure 6:Planning réel
 Page 26
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 Type d’écart

jours
L’identification du projet a pris 9 jours au lieu de 5 vu que +4 Retard
les fonctionnalités du projet n’étaient pas assez claires au
début.
La partie Codage nous a pris 21 jours au lieu de 27 parce -6 Avance

qu’il n’y avait pas assez de complications là-dessus.
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
exigences et 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 27
Niveau
Risque Impact Probabilité d’impact Classement Actions préventives Actions Correctives
Non Conduit à un 2/4 3/4 * Analyse du travail * Organiser des

Validation retard sur le délai (démarche réunions avec le
des de mise en œuvre d’ergonomie) : prise en client afin de
interfaces des interface dû à compte de l’utilisateur déterminer et de
une mauvaise (fonction, valider les
ergonomie comportement.) maquettes
* Maquettage et
évaluation
ergonomique
Abscence de Création d'une 2/4 2/4 *Réorganisation du * Organiser des

cahier des ambigüité ce qui travail en cas de conflit réunions avec le
charges pourra générer * Réunions avec le client afin de
un retard qui client et collecte de détailler le cahier
influencera leurs suggestions des charges
probablement la
date de livraison
Changement Conduit à un 2/4 3/4 *le choix d’une * Réunions avec le

ou évolution retard sur le délai approche impliquant client et prise en
des besoins fortement le client le compte des ses
du client long du projet nouveaux besoins
Changement Retard dans 4/4 3/4 *Etude préalable et *Changer la

de la l’avancement du comparative des technologie et
technologie projet technologies existantes augmenter la masse
horaire
*Doubler l’effort
pour couvrir le
manque
Tableau 4:Matrice des risques
1/16
->4/16:
Faible
12/16
Classement: 4/16
->16/16: impact * ->8/16:
Dangereux Moyen
probabilité
8/16
->12/16:
Sévère
Figure 7:Schéma de classement
 Page 28
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 Très possible

vitale
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 29
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 30
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 acteurs candidats 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 acteurs qui 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 ;
 Bureau d’ordre : les agents du bureau d’ordre confirme la réception des
chèques de règlement suite à un courrier électronique envoyé par le
système afin de les transmettre aux démarcheurs;
 Animation des réseaux Alternatif : les fonctionnalités des animateurs de
réseau Alternatif se 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 utilisateurs doivent s’authentifier avant de passer à n’importe quelle

opération dans le système .Ces différents acteurs sont 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'acteurs reliés au système à un
moment donné.
 Page 31
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ées des 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écification d'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 messages répertoriés entre le système et ses acteurs sont :
Messages émis par le système
 Afficher la liste des encaissements ;

 Afficher la liste des commissions calculées ;
 Page 32
 Afficher la liste des opérateurs ;

 Afficher la liste des taux ;
 Afficher la liste des séries des 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 encaissements mensuels ;
 Mettre à jour des opérateurs ;
 Paramétrer les taux ;
 Gérer les séries des 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 messages ré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éments extérieurs au système.
Figure 9:Diagramme de contexte dynamique
 Page 33
Acteur Messages Emis Message Reçus
Recouvrement Back Office (1)Lancer une nouvelle (3)Afficher la liste des

extraction encaissements
(2)Déclencher le calcul (4) Afficher la liste des
commissions calculées
CIOL (5)Renvoyer la liste des

encaissements mensuels
Administrateur (6)Mettre à jour des (9)Afficher la liste des

opérateurs opérateurs
(7)Paramétrer les taux (10)Afficher la liste des
(8)Gérer les séries des taux
chèques (11)Afficher la liste des
séries des chèques
Comptabilité technique (12)Valider les commissions (14)Afficher la liste des
calculées commissions calculées
(13)Remonter les anomalies
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 (18)Afficher la liste des

chèques chèques de règlement
Bureau d’ordre (19)Remettre le chèque de (20)Afficher la liste des
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 34
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 35
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’émission ou de la réception de chaque message.
En regroupant les intentions fonctionnelles en unités cohérentes, on obtient les use
case recherchés.
UseCase Acteur Principal/ Messages Emis/ Reçus par

Acteurs Secondaires Acteurs
C on sulte r le rè gle m e n t o Re couvre me nt BO Em i s :
de s com m i ssi on s o Com pta bilité Re çu :
te chnique o Affi ch e r la li ste de s
o Administrate ur com m i ssi on s ca lculé e s .
o Animation de s
ré se aux alte rnatifs
o Bure au d’ordre
La n ce r n ouve lle o Re couvre me nt BO Em i s :
e xtra cti on o CIOL o La n ce r un e n ouve lle
e xtra cti on .
o Dé cle n ch e r le ca lcul .
o Re n voye r la li ste de s
e n ca i sse m e n ts m e n sue ls .
Re çu :
o Affi ch e r la li ste de s
e n ca i sse m e n ts
C on trôle r le s o Com pta bilité Em i s :
com m i ssi on s ca lculé e s te chnique o Va li de r le s com m i ssi on s
ca lculé e s.
o Re m on te r le s a n om a li e s.
Re çu :
com m i ssi on s ca lculé e s.
La n ce r l’é di ti on de s o Com pta bilité Em i s :

ch è que s te chnique Re çu :
o Che ck 2003 o Re n voye r la li ste de s
com m i ssi on s à ré glé e s
sous form a t .txt .
Pa ra m é tre r le s ta ux de s o Administrate ur Em i s :
com m i ssi on s o Pa ra m é tre r le s ta ux.
Re çu :
o Affi ch e r la li ste de s ta ux.
Gé re r le s ch è que s o Administrate ur Em i s :
o Gé re r le s sé ri e s de s
ch è que s
Re çu :
 Page 36
ch è que s
Me ttre à jour le s profi ls o Administrate ur Em i s :
o Me ttre à jour le s
opé ra te urs
Re çu :
opé ra te urs
Re ce voi r le s ch è que s o Animation de s Em i s :
ré se aux alte rnatifs o Accuse r la ré ce pti on de s
ch è que s
Re çu :
ch è que s de rè gle m e n t
Re m e ttre le ch è que de o Bure au d’ordre Em i s :
rè gle m e n t o Re m e ttre le ch è que de
rè gle m e n t
Re çu :
ch è que s de rè gle m e n t
Edi te r le s ch è que s o CHECK 2003 Em i s :
o
Re çu :
o Re n voye r la li ste de s
com m i ssi on s à ré glé e s
sous form a t .te xt
Gé n é re r le s é cri ture s o CODA Em i s :
com pta ble s
Re çu :
o I n sé re r le s é cri ture s
com pta ble s da n s le s ta ble s
broui lla rds
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 37
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. D escription textuelle
Fiche Descriptive de l’UseCase :

Consulte r le rè gle me nt de s commissions
Sommaire d’Identification
Titre : Consulte r le rè gle me nt de s 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’utilisate ur accè de au me nu principal ;
2. L’utilisate ur de mande la consultation du rè gle me nt de s
commissions ;
3. Le systè me affiche la liste de s commissions calculé e s du
de rnie r mois ré glé ;
4. L’utilisate ur filtre la liste se lon son inté rê t ;
5. L’utilisate ur quitte le me nu.
Scénario Alternatif
 Page 38
Il dé bute à l'é tape 4 du scé nario principal:

1. Lorsque l’utilisate ur choisi un mois non ré glé , le systè me
affiche un me ssage d’ale rte ;
2. Le che f comme rcial choisie un autre critè re de re che rche ;
3. Le che f comme rcial quitte le systè me .
Post Conditions
Tableau 8:Fiche Descriptive « Consulter le règlement des commissions »
b. D iagramme de Séquence
Figure 11: Diagramme de séquence« Consulter le règlement des commissions »
 Page 39
c. Classes Participantes
Figure 12:Classes participantes « Consulter le règlement des commissions »
Cas d’utilisation « Lancer une N ouvelle Extraction »
Figure 13:Cas d'utilisation « Lancer une Nouvelle Extraction »
Fiche Descriptive de l’UseCase :

Lance r une Nouve lle Extraction
Titre : Lance r une Nouve lle Extraction
But : calculer les commissions.
 Page 40
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 Re couvre ur accè de au me nu principal ;
2. Le Re couvre ur de mande une nouve lle e xtraction ;
3. Le systè me affiche la liste de s mois e t le s anné e s ;
4. Le Re couvre ur choisi le mois souhaité avant de lance r
l’e xtraction ;
5. Le systè me affiche la liste de s e ncaisse me nts me nsue ls
du mois choisi ;
6. Le Re couvre ur lance le calcul ;
7. Le systè me affiche la liste de s commissions calculé e s;
8. Le Re couvre ur valide l’e xtraction ;
9. Le Re couvre ur quitte le Me nu
1. Lorsque le re couvre ur signal une anomalie e n cas d’une
e xtraction non valide ;
2. un mail e st e nvoyé automatique me nt au he lp de sk e n copie
ave c l’administrate ur;
3. Le Re couvre ur quitte le Me nu ;
Post Conditions
L’administrate ur re lance l’e xtraction de s e ncaisse me nts.
Le he lp de sk ajoute ce tte dé claration à CA .
Tableau 9: Fiche descriptive« Lancer une Nouvelle Extraction »
N ote :
La CA est solution dédiée au service Help Desk permet la gestion des réclamations.
 Page 41
Figure 14: Diagramme de séquence « Lancer une Nouvelle Extraction »
 Page 42
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ôle r le s commissions calculé e s
Titre : Contrôle r le s commissions calculé e s
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 43
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 44
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é tre r le s taux
Titre : Paramé tre r le s 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 45
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’administrate ur ve ut me ttre à jour ou
re che rche r une information invalide ;
2. Le systè me affiche un me ssage d’e rre ur ;
3. L’administrate ur re ssaisi se s 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 46
Figure 22:Classes participantes « Paramétrer les taux »
2. Organisation des UseCases
Figure 23:Diagramme de cas d'utilisation global
 Page 47
3. Structuration des UseCases en Packages

UseCases Acteur Principal, PACKAGES
Acteurs Secondaires
C on sulte r le rè gle m e n t o Re couvre ur BO Administration

de s com m i ssi on s o Age nt Comptable
o Administrate ur
o Animate ur de s
o Age nt Bure au
d’ordre
La n ce r n ouve lle o Re couvre ur BO Recouvrement BO
e xtra cti on
C on trôle r le s o Age nt Com pta bilité Comptabilité technique
com m i ssi on s ca lculé e s te chnique
La n ce r l’é di ti on de s o Age nt Com pta bilité Comptabilité technique

ch è que s te chnique
Me ttre à jour le s profi ls o Administrate ur Administration

Pa ra m é tre r le s ta ux o Administrate ur Administration
Gé re r le s ch è que s o Administrate ur Administration
Re ce voi r le s ch è que s o Animate ur de s Animation des réseaux
ré se aux alte rnatifs alternatifs
Re m e ttre le ch è que de o Age nt Bure au Bureau d’ordre

rè gle m e n t d’ordre
Edi te r le s ch è que s o CHECK 2003 Comptabilité technique
Gé n é re r le s é cri ture s o CODA Comptabilité technique
com pta ble s
S ’a uth e n ti fi e r o Re couvre ur BO Administration
o Age nt Com pta bilité
te chnique
o Administrate ur
o Animate ur de s
o Age nt Bure au
d’ordre
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 Besoins Fonctionnels.
 Page 48
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 Des risques.
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éponde nt effectivement aux besoins
du client.
Liste des UseCases Niveau de Risque Type de Priorité Classement

C on sulte r le Bas Moyenne 6
rè gle m e n t de s
com m i ssi on s
La n ce r n ouve lle Haut Haute 1
e xtra cti on
C on trôle r le s Haut Haute 2
com m i ssi on s
ca lculé e s
La n ce r l’é di ti on Haut Haute 3
de s ch è que s
Pa ra m é tre r le s Bas Basse 9
ta ux de s
com m i ssi on s
Gé re r le s ch è que s Bas Basse 10
Me ttre à jour le s Bas Basse 11
profi ls
Re ce voi r le s Bas Moyenne 7
ch è que s
Re m e ttre le Bas Moyenne 8
ch è que de
rè gle m e n t
Edi te r le s Haut Haute 4
ch è que s
Gé n é re r le s Haut Haute 5
é cri ture s
com pta ble s
S ’a uth e n ti 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érents messages en réalisant le diagramme de contexte dynamique.
 Page 49
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 50
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ès aux 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 respectifs et ce, via le réseau local 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 51
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écessaires existent 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 52
 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 contenterons de proposer une architecture technique
selon le diagramme de déploiement UML.
Serveur de données
SQL Server
TCP/IP TCP/IP
Serveur d'
Client application
lourd
Oracle
Figure 26:Diagramme de déploiement
 Page 53
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 les responsabilités.
Le diagramme de composants ci-dessous, montre les différents types de
composants d’exploitation du système.
Client lourd
Couche Présentation
WinForm
Serveur d'application
Serveur de base de données
Couche Métier
SQL SERVER
ORACLE
Couche accés aux données
Entity Framework
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.
 Page 54
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 55
I. Modèle statique
1. Fusion des Classes participantes
Figure 28:Fusion des classes participantes
 Page 56
2. Diagramme de package
A partir de Diagrammes de classes candidates précédent nous allons le découper en
diagramme de package suivant :
Recouvrement Back Office Comptabilité T echnique
Administration
Animation des Réseaux Bureau d'ordre

Alternatif
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 classes suivant :
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
 Page 57
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’assurance de 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 58
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 59
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 60
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 »

Commission
Chéque Réglement
- id_commission : Integer
- id_cheque : Integer - id_reglement : Integer - date_commission : Date
- numero_compte : String - total : Double - total : Double
- rib : String 0..1 1..1 - date_reglement : Date 0..1 1..* - plafond : Double
- case1 : String - accessoire : Double
- case2 : String - timbre : Double
- montant : Double 0..1 - taux : Double
- date_traitement : Date - mois : String
- date_ra : Date Statut - annee : String
- date_bo : Date
- id_statut : Integer
- libelle : String
- date_maj : Date
- date_creation : Date
- actif : Boolean 1..1
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.
 Page 61

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 62
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 63
6. Diagramme de classe statique global
Figure 33:Diagramme de classe statique global
 Page 64
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 65
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.
Extraire Encaissement
Signaler Anomalie
En attente
Lancer Calcul
Réglée
Calculée Contrôler Calcul Editer Chèques
Validée
Fin Réglement
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 :
 Page 66
Figure 36:Diagramme d’activité
 Page 67
Organisme Intermédiaire
Type
0..* - adresse1 : String - id_intermediare : Integer
- tel1 : String - matricule : String - id_type : Integer
- fax : String 0..* - libelle : String
- forme_juridique : String
- adresse_mail : String Client - Titulaire : String 0..1 + ajouter () : Boolean
 Page 68
- raison_sociale : String - code_convention : String + modifier () : Boolean
- tel3 : String - Id_Client : Integer 1..* - code_compable : String + supprimer () : Boolean
- id_organisme : Integer + ajouter () : Boolean 1..* + getById () : Type
+ ajouter () : Boolean
+ ajouter () : Boolean + modifier () : Boolean + modifier () : Boolean + getAllType () : List
+ modifier () : Boolean + supprimer () : Boolean + supprimer () : Boolean
+ supprimer () : Boolean + getAllClient () : List + getAllIntermediaire () : List 1..*
+ getById () : Organisme + Affecter () : void
+ getAllOrganisme () : List
Taux
Commission
Police - taux : Double
Réglement - id_commission : Integer
Chéque - date_commission : Date - Id_police : Integer + ajouter () : Boolean
- id_reglement : Integer + modifier () : Boolean
- total : Double - Date_debut : Date
- id_cheque : Integer - total : Double + supprimer () : Boolean
- plafond : Double - Date_fin : Date
- numero_compte : String - date_reglement : Date + getById () : Taux
- accessoire : Double - nature : String
- rib : String + ajouter () : Boolean + getAllTaux () : List
1..* - timbre : Double - code_assurance : String
- case1 : String 1..1 + modifier () : Boolean - taux : Double - date_motivation : Date
- case2 : String + supprimer () : Boolean 0..1
0..1 - mois : String - debut_garantie : Date
- montant : Double + getById () : Intermediaire 1..*
- annee : String - fin_garantie : Date
- date_traitement : Date 0..* + getAllRéglement () : List
- date_ra : Date + ajouter () : Boolean + ajouter () : Boolean
+ modifier () : Boolean Branche
- date_bo : Date + modifier () : Boolean
+ supprimer () : Boolean + supprimer () : Boolean - Id_branche : Integer
+ getById () : Commission + getById () : Police 1..1 - libelle : String
+ modifier () : Boolean
+ getAllCommission () : List + getAllPolice () : List 0..*
+ supprimer () : Boolean + ajouter () : Boolean
4. Diagramme final de classes
+ valider () : void
+ getById () : Cheque + modifier () : Boolean
+ clôturer () : int Quittance
+ getAllCheque () : List + supprimer () : Boolean
+ recevoir () : void - id_quittance : Integer + getById () : Branche
+ remettre () : void 1..1 0..* - credit : Double + getAllBranche () : List
1..1 Série_Chèque
1..1 - date_emission : Date
- id_serie_cheque : Integer - prime_net : Double 1..*
0..1
- rip : String - montant_taxe : Double
Ville - debut : String - montant_accessoire : Double
- id_ville : Integer Banque - fin : String 1..1 - total : Double
- libelle : String + ajouter () : Boolean - net_a_payer : Double
- Id_banque : Integer Statut
+ ajouter () : Boolean + modifier () : Boolean - date_Reglement : int 0..* 1..1
- libelle : String
+ modifier () : Boolean + supprimer () : Boolean - id_statut : Integer + ajouter () : Boolean
+ ajouter () : Boolean 1..1 - libelle : String
+ supprimer () : Boolean + getById () : SerieCheque + modifier () : Boolean
+ modifier () : Boolean - date_maj : Date Groupe
+ getById () : Ville 0..* + getAllSerieCheque () : List + supprimer () : Boolean
+ supprimer () : Boolean - date_creation : Date - id_groupe : Integer
+ getAllVille () : List + getById () : Quittance
+ getById () : BBanque - actif : Boolean - libelle : String
+ getAllQuittance () : List
+ getAllBanque () : List 1..1 + ajouter () : Boolean + ajouter () : Boolean
1..* + modifier () : Boolean + modifier () : Boolean
Figure 37:Diagramme de classe dynamique

0..* 0..* + supprimer () : Boolean + supprimer () : Boolean
+ getById () : Statut + getById () : Groupe
Service
1..1 + getAllStatut () : List + getAllGroupe () : List
0..1 - id_service : Integer + Affecter () : void
1..1 - libelle : String
Région Profil 1..1 0..*
- id_region : Integer 0..1 1..1
Société - id_profil : Integer + modifier () : Boolean
- libelle : String Operateur
- libelle : String + supprimer () : Boolean

+ ajouter () : Boolean - id_societe : Integer + getById () : Service Departement
+ ajouter () : Boolean - id_operateur : Integer 1..1
+ modifier () : Boolean - libelle : String + getAllService () : List
+ modifier () : Boolean - login : String - id_dept : Integer
+ supprimer () : Boolean + ajouter () : Boolean + supprimer () : Boolean - mot_passe : String - libelle : String
+ getById () : Region + modifier () : Boolean + getById () : Profil 0..1 - actif : Boolean
+ getAllRegion () : List 1..* + ajouter () : Boolean
+ supprimer () : Boolean + getAllProfil () : List 0..*
+ AffecterVille () : int 0..1 + ajouter () : Boolean + modifier () : Boolean
+ getById () : Societe + Affecter () : void + modifier () : Boolean + supprimer () : Boolean
+ getAllSociete () : List 0..* 1..1
+ supprimer () : Boolean + getById () : Departement
+ getById () : Operateur + getAllDepartement () : List
+ getAllOperateur () : List
0..*
Conclusion
Le Couplage entre les démarches des modèles statique et dynamique :
Figure 38:Couplage entre les deux démarches
 Page 69
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 70
I. Architecture du projet
ARCHITECTURE DU PROJET SOUS VISUAL STUDIO
Figure 39:Architecture du projet
 Page 71
Organisme
Intermédiaire
adresse1 VARCHAR2(254) Type
id_organisme INTEGER <pk,fk2>
tel1 VARCHAR2(254)
fax VARCHAR2(254) id_type INTEGER <fk1> id_type INTEGER <pk>
id_intermediare INTEGER libelle VARCHAR2(254)
II.
adresse_mail VARCHAR2(254)
 Page 72
Client matricule VARCHAR2(254)
raison_sociale VARCHAR2(254)
id_organisme INTEGER <pk,fk> forme_juridique VARCHAR2(254)
tel3 VARCHAR2(254)
id_organisme INTEGER <pk> Id_Client INTEGER Titulaire VARCHAR2(254)
code_convention VARCHAR2(254)
id_region INTEGER <fk>
Conclusion
id_ville INTEGER <fk> code_compable VARCHAR2(254)
Réglement
id_reglement INTEGER <pk> Taux
id_cheque INTEGER <fk> Police
Commission id_type INTEGER <pk,fk1>
total NUMBER
id_organisme INTEGER <pk,fk1> id_groupe INTEGER <pk,fk2>
date_reglement DATE id_commission INTEGER <pk>
Cli_id_organisme INTEGER <pk,fk2> Id_branche INTEGER <pk,fk2>
id_reglement INTEGER <fk1>
Id_police INTEGER <pk> taux NUMBER
id_quittance INTEGER <fk3>
Chéque Date_debut DATE
id_statut INTEGER <fk2>
id_cheque INTEGER <pk> date_commission DATE Date_fin DATE
id_serie_cheque INTEGER <fk1> total NUMBER nature VARCHAR2(254)
id_reglement INTEGER <fk2> plafond NUMBER code_assurance VARCHAR2(254)
numero_compte VARCHAR2(254) accessoire NUMBER date_motivation DATE
rib VARCHAR2(254) timbre NUMBER debut_garantie DATE
case1 VARCHAR2(254) taux NUMBER fin_garantie DATE
case2 VARCHAR2(254) mois VARCHAR2(254) Branche
montant NUMBER annee VARCHAR2(254)
id_groupe INTEGER <pk,fk>
date_traitement DATE
Id_branche INTEGER <pk>
date_ra DATE
Quittance libelle VARCHAR2(254)
date_bo DATE
id_quittance INTEGER <pk>
id_organisme INTEGER <fk2>
Cli_id_organisme INTEGER <fk2>
Série_Chèque Id_police INTEGER <fk2>
id_groupe INTEGER <fk1>
id_serie_cheque INTEGER <pk>
Modèle logique de données
Id_branche INTEGER <fk1>

id_statut INTEGER <fk2>
credit NUMBER
Ville Id_banque INTEGER <fk1>
date_emission DATE
rip VARCHAR2(254)
id_region INTEGER <pk,fk> Banque prime_net NUMBER
debut VARCHAR2(254) Statut
id_ville INTEGER <pk> montant_taxe NUMBER
Id_banque INTEGER <pk> fin VARCHAR2(254)
libelle VARCHAR2(254) id_statut INTEGER <pk> montant_accessoire NUMBER
id_societe INTEGER <fk>
id_serie_cheque INTEGER <fk3> total NUMBER
libelle VARCHAR2(254) net_a_payer NUMBER
id_commission INTEGER <fk2>
id_operateur INTEGER <fk1> date_Reglement INTEGER
libelle VARCHAR2(254) Groupe
date_maj DATE id_groupe INTEGER <pk>
et en deuxième partie le modèle logique de données.

date_creation DATE Gro_id_groupe INTEGER <fk>
actif SMALLINT libelle VARCHAR2(254)
Figure 40: Modèle logique de données

Service
id_dept INTEGER <pk,fk>
id_service INTEGER <pk>
libelle VARCHAR2(254)
Région Profil
Operateur
id_region INTEGER <pk> Société id_profil INTEGER <pk>
id_region INTEGER <fk> id_operateur INTEGER <pk> Departement
libelle VARCHAR2(254)
id_societe INTEGER <pk> libelle VARCHAR2(254) id_dept INTEGER <fk2> id_dept INTEGER <pk>
libelle VARCHAR2(254) id_service INTEGER <fk2> libelle VARCHAR2(254)
id_profil INTEGER <fk1>
login VARCHAR2(254)
mot_passe VARCHAR2(254)
actif SMALLINT
Le but de ce chapitre consiste à identifier en première partie l’architecture du projet

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 73
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 solutions faisant 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 74
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'autres destinations.
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 75
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
 Page 76
2.2 Notifications
Le système envoie un mail et affiche une notification chaque début du mois pour ra ppeler le
Recouvreur du lancement des extractions .Si le Recouvreur dépasse le délai (10 du mois
M+1) un message d’erreur sera affiché.
Figure 43:Notifications
3.2 Nouvelle Extraction

a. Etape 1
Figure 44:lancement de l’extraction
Cette interface présente le lancement d’extraction des encaissements mensuels [mois

précédent] des AV et CVT.
b. Etape 2
Figure 45:Liste des extractions
Cette interface présente la liste des encaissements mensuels ainsi le lancement du calcul
des commissions.
 Page 77
c. Etape3
Après le calcul des commissions l’ensemble des informations s’affiche dans une nouvelle
liste.
Le Recouvreur valide le calcul des commissions.
Figure 46:Valider les commissions
Sinon le recouvreur signale une anomalie, un mail de réclamation sera envoyé au service
Help Desk.
Figure 47:Signaler une anomalie
d. Etape 4
Après la validation des commissions le recouvreur aura la possibilité d’enregistrer la liste
des commissions calculées sous format Excel ou pdf ou l’imprimer.
Figure 48:Enregistrement sous Excel
 Page 78
4.2 Consulter le règlement des commissions

Le recouvreur aura la possibilité de consulter la liste des commissions calculées par
intérmédiaire ou par mois en choisissant le menu « consulter le reglement des
commissions ».
Figure 49:Consulter le règlement des commissions
5.2 Envoyer un mail à l’administrateur

Le recouvreur peut également contacter l’administrateur en lui envoyant un mail à partir de
la page suivante.
Figure 50:Contacter l'administrateur
 Page 79
3. Comptabilité Technique
1.3 Accueil
Figure 51:Menu principal Comptabilité technique
2.3 Contrôler les commissions calculées

Après le control des commissions calculée par le recouvrement back office, le comptable
aura la possibilité de valider ses commissions.
Figure 52:Valider les commissions calculées
En cas d’une erreur, le comptable signale une anomalie.
 Page 80
3.3 Editer les chèques

Après la validation des commissions calculées, le comptable lance l’Edition des chèques.
Figure 53:Edition des chèques
Un fichier text sera créé sous un format précis afin de les imprimer par l’outil Check 2003.
Figure 54:Fichier .txt Edition des chèques
4. Administration
La troisième partie concerne l’administrateur pour tous ce qui est paramétrage des taux, la
gestion des chèques, et la mise à jour des opérateurs.
 Page 81
1.4 Accueil
Figure 55:Page d'accueil d'administration
2.4 Paramétrer les taux

Le paramétrage des taux regroupe la mise à jour des branches, des groupes et les taux,
l’administrateur peut à tout moment ajouter une branche par exemple :
a. Taux
Affecter à chaque branche et type un taux de commission.
Figure 56:Paramétrage des taux
 Page 82
3.4 Gérer les chèques

La partie « Gérer les chèques » regroupe la mise à jour des banques et des séries de chèques .
a. Série Chèque
Figure 57:Mise à jour des séries de chèques
4.4 Mettre à jour les opérateurs

Et la partie de la mise à jour des opérateurs permet à l’administrateur de paramétrer les
profils et les opérateurs.
a. Opérateur
Figure 58:Mise à jour des opérateurs
 Page 83
5. Animation des Réseaux Alternatif
Figure 59:Page d'accueil d'animation des réseaux alternatifs
Cette interface présente le quatrième profil qui concerne l’animation des réseaux alternatifs,
cette partie permet la remise des chèques de règlement, la consultation du règleme nt des
commissions, l’affichage des notifications, les visualisations du journal.
6. Bureau d’ordre
Figure 60:Page d'accueil de bureau d'ordre
Cette interface présente le cinquième profil qui concerne le bureau d’ordre , la mission
principale de ce profil et la remise des chèques de règlement.
 Page 84
Conclusion
En guise de conclusion, mon expérience chez SAHAM Assurance a été très
enrichissante tant sur le plan humain que technique. Il est donc difficile pour moi
de résumer tous les apports que ce stage m’a offert, tellement il fut riche et
formateur.
Dans un premier temps, ce stage opérationnel au sein du département des

systèmes d’informations m’a permis de mettre en pratique toutes les connaissances
acquises durant ma formation à l’EMSI, et plus particulièrement de découvrir le
métier des assurances avec toutes ses caractéristiques et ses contraintes. De plus,
j’ai eu l’occasion de me familiariser avec ce domaine et surtout d’apprendre
énormément tous les jours en peu plus. En effet, chaque jour de mon stage était
formateur, car j’apprenais tous les jours à connaitre un peu plus dans le monde des
assurances à travers les différents pôles de l’entreprise, un monde très dynamique
et vivant. Un domaine d’autant plus intéressant chez le groupe SAHAM au vu de sa
dimension internationale, qui m’a permis de me confronter et de prendre part à
différents problématiques quotidiennes
En outre, j’ai pu réaliser un outil orienté vers les démarcheurs pour développer
leurs besoins en matière de règlement de leurs commissions, qui permet d’intégrer
et de fusionner toutes les données relatives aux calculs de ces commissions faite
par le Recouvrement back office autour du futur système, cet outil donne aussi la
possibilité à la comptabilité technique d’éditer les chèques à l’aide du système
check 2003 et l’insertion des écritures comptables au sein de CODA avec Un service
de mailing servira à informer de l’état d’avancement du règlement de la commission
afin de Délivrer la bonne information, au bon temps, à la bonne personne et sous le
bon format. J’ai également pris conscience de l’importance de la mise en place
d’outil d’automatisation de règlement des commissions des réseaux alternatifs.
D’autre part, j’ai également découvert un autre univers de travail différent de ce que
j’avais pu voir avant, une ambiance positive avec une équipe soudée et des relations
professionnelles très chaleureuses.
Ces quatre mois représentent pour moi une aventure unique pendant laquelle j’ai
accumulé de nombreuses connaissances. En effet, je suis largement satisfaite de la
mission qui m’a été confiée d’une part. D’autre part, j’ai eu la chance d’avoir été
bien encadrée et soutenue tout au long de mon stage.
Je termine ces quatre mois de stage grandit par cette expérience.
 Page 85
Bibliographie
LIVRE DESCRIPTION
SQL Server 2012

Integration Services (SSIS)
C# et .NET Version2
Par Gerard LABLANZ
Figure 61:Bibiographie
Webographie
http://en.wikipedia.org/wiki/SQL_Server_Integration_Services
http://csharp.net-informations.com/xml/xml-to-database.htm
http://www.mssqltips.com/sqlservertip/2011/export-sql-server-data-to-oracle-
using-ssis/
http://stackoverflow.com/questions/571051/moving-data-from-sql-server-to-
oracle-repeatedly
http://csharp.net-informations.com/file/create-pdf.htm
http://www.codeproject.com/Tips/658959/Execute-SSIS-Packge-by-using-
Csharp-and-SQL-Server
 Page 86
ANNEXE
1. Structure lot standard SAHAM ASSURANCE
S2I Technologies
Systèmes Ingénierie DESCRIPTION DE FICHIER
Informatique FORMAT FICHIER LOT STANDARD MISE A JOUR
Technologies ymmddAxx.TXT NUMERO : 1
DATE : 20/12/2012.
FORMAT : FIXE LONGUEUR : 992
Libellé Zone Chèque Lettre

de POS LONG TYPE OBSERVATION
Vire
Change
ment
Code Agence CNIA * * * 1 3 A
Code Agence BANK * * * 4 6 A Exp 007011 Code BQ ATTW &
Code AGCE
Code Nature * * * 10 1 A Par exemple A,B.. Chèques. V :
Virement E : Effet
Numéro de Lot * * * 11 22 A Format AMMJJAxx Exemple :
50523A01
Numéro de série * * * 33 3 A En cas du chèque
Numéro de chèque * * * 36 7 N 7 chiffres (compléter par des 0 )
Nom bénéficiaire * * * 43 70 A
Complément bénéficiaire * * * 113 40 A
1 ère Adresse bénéficiaire * * * 183 50 A
2 ème Adresse bénéficiaire * * * 233 50 A
Code Fournisseur * * * 383 10 A
1 ère Zone Libre * * * 393 150 A Zone libre s’il y a d’autre
informations non prévues
2 ème Zone Libre * * * 543 136 A Zone libre s’il y a d’autre
informations non prévues
Objet règlement * * * 679 80 A C’est la ligne facture
Montant Facture * * * 759 14 N
Devise - - * 773 5 A En cas de devise étranger
Date Echéance - * - 778 10 D Pour les Effets
La cause - * - 788 10 A
RIB bénéficiaire * * * 798 30 A
Mode Règlement (‘CHQ’,’LCH’,’VIR’) - - * 828 3 A En cas du virement
1 ère Adresse Bancaire - - * 831 40 A Domiciliation bancaire
2 ème Adresse Bancaire - - * 871 40 A Suite Domiciliation bancaire
Tableau 19:Structure lot
Nombre de zones : 26
Taille ligne : 992 (991 + 1 caractère de fin de ligne)
Détail Zone libre 1

Nom Zone Position Longueur Type Position fichier
Code service 1 3 A 393
Nom utilisateur 4 20 A 396
 Page 87
N° police 24 16 A 416
Nom Souscripteur 40 40 A 432
Impayé 80 1 A 472
Nom victime 81 40 A 473
Date Survenance 121 10 A 513
Code Auxiliaire 131 12 A 523
Détail Zone libre 2

Nom Zone Position Longueur Type Position fichier
Nature Règlement 1 50 A 543
Nom assure 51 40 A 593
Référence 91 20 A 633
2. Migration SQL Server Oracle

Pour le moment je travaille avec une base de données SQL server 2012 que j’ai créé moi -
même à partir des fichiers Excel donné par l’entreprise mais Après chaque Extraction le
Recouvreur souhaite garder une copie dans une autre base de données oracle pour éviter
tous les problèmes cas de réclamation d’un démarcheur pour cela j’ai choisi d’utiliser l’outil
SSIS pour faire la migration de la base SQL server 2012 à la base oracle.
Alors comme première étape j’ai créé une ADO source (S QL server 2012) qui contient tous
les paramètres de connexion du serveur de SAHAM Assurance (contentserver).
Figure 62: La création d'une ADO NET Source pour SQL Server
Qui contient ma requête pour l’extraction des encaissements
 Page 88
Figure 63: Requête pour l'affichage des commissions
Figure 64: Exécution de la requête
Voilà le résultat de la requête que je souhaite stocké dans ma nouvelle base oracle.
Il me reste que crée une ODBC Destination et faire le mappage entre les deux bases .
 Page 89
Figure 65: Mappage entre la base SQL Server et Oracle
Et voilà le résultat final j’ai pu copier mes données en toute sécurité dans ma base oracle
Figure 66: Les données SQL Server vers Orale
Il suffit juste de faire une procédure stocké pour l’appel du package que je viens de faire
dans le code c# pour l’extraction mensuel.
 Page 90

Rapportfinalv1 160413132045

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

Rapportfinalv1 160413132045

Transféré par

Droits d'auteur :

Formats disponibles

Automatisation Règlement des commissions Réseau Alternatif

Mise en place d’une solution

Automatisation Règlement des commissions Réseau

Ingénierie Informatique et Réseaux

Méthodes Informatiques Appliquées à la Gestion des Entreprises

Mlle. Ghizlane ALOZADE

À mes chers parents Ahmed et R’qia,

À mes adorables frères Tarik et M’hamed,

À tous ceux qui mes ont chers, je dédie ce travail.

En préambule à ce rapport, je souhaite adresser mes remerciements les plus

A cette occasion, j’exprime ma profonde gratitude à M. Hassan NACHIFA, pour

Un remerciement particulier aux membres du jury pour avoir accepté de juger

Merci à tous et à toutes.

Réseau Alternatif, Commission, informatique, Automatisation, Calcul, commercial,

Alternative Network, Commission, computer, automation, computing, commercial,

Liste des abréviations * selon l’ordre d’apparition

Liste des figures

Figure 41:Page d'authentification ______________________________________________ 76

Liste des tableaux

Liste des matières

Liste des abréviations * selon l’ordre d’a pparition _______________________________________ 5

Liste des figures _____________________________________________________________________ 6

Liste des matières ___________________________________________________________________ 9

Introduction générale _______________________________________________________________ 12

I. Présentation de l’organisme d’accueil _____________________________________________ 15

1. Présentation du groupe SAHAM _______________________________________________ 15

2. Organigra mme du groupe ____________________________________________________ 16

II. Cadre général du projet _________________________________________________________ 18

1. Contexte du projet ___________________________________________________________ 18

Gestion du projet ___________________________________________________________________ 19

1. Gestion du Plan Projet ________________________________________________________ 22

2. Périmètre du projet __________________________________________________________ 22

6. Matrice des risques __________________________________________________________ 27

CHAPITRE III : _____________________________________________________________________ 30

Étude Préliminaire __________________________________________________________________ 30

I. Les acteurs du système _________________________________________________________ 31

2. Identification des acteurs______________________________________________________ 31

II. Les messages__________________________________________________________________ 32

1. Identification des messages ____________________________________________________ 32

2. Diagramme de contexte dynamique ____________________________________________ 33

Capture des besoins fonctionnels ____________________________________________________ 35

II. Description des différents cas d’utilisation _________________________________________ 37

1. Description des cas d’utilisation ________________________________________________ 38

2. Organisation des UseCases ____________________________________________________ 47

4. Classement des Use Cases _____________________________________________________ 49

Capture des besoins techniques _____________________________________________________ 50

I. Architecture Matérielle _________________________________________________________ 51

1. Description des scénarii_______________________________________________________ 51

II. Architecture logicielle __________________________________________________________ 54

I. Modèle statique _______________________________________________________________ 56

1. Fusion des Classes participantes________________________________________________ 56

3. Package Recouvrement Back Office _____________________________________________ 57

4. Package Comptabilité Technique _______________________________________________ 60

5. Package Administration ______________________________________________________ 61

II. Modèle Dynamique ____________________________________________________________ 65

1. Diagramme de séquence MVC2 ________________________________________________ 65

2. Diagramme d’états-transitions _________________________________________________ 66

3. Diagramme d’activité ________________________________________________________ 66

4. Diagramme de classes final ____________________________________________________ 68

CHAPITRE VII : _____________________________________________________________________ 70

I. Architecture du projet __________________________________________________________ 71

CHAPITRE VII : _____________________________________________________________________ 73

I. Technologies et outils de développement: __________________________________________ 74