1. MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA
RECHERCHE SCIENTIFIQUE
UNIVERSITE TUNIS EL MANAR
INSTITUT SUPERIEUR D’INFORMATIQUE
RAPPORT DE STAGE DE FIN D’ETUDES
Présenté en vue de l’obtention du
Diplôme National de Licence Appliquée en Sciences et Technologies
Mention : Informatique
Spécialité : Systèmes Informatiques et Logiciels
Par
Anouar KACEM
Alaa Eddine ZAMMEL
Encadrant professionnel Monsieur Riadh LAKDHAR
Encadrant académique Madame Fatma Hermes
Réalisé au sein de Poulina Group Holding
Année Universitaire 2014/2015
Conception et développement d’une application de
gestion de pièces bancaires électroniques

2. Dédicace
Je dédie ce modeste travail
A mes parents, mes estimes pour eux sont immenses, je vous remercie
Pour tout ce que vous avez fait pour moi.
Que dieu vous préserve une longue vie heureuse.
A ma très chère sœur Najla, et très chère frère Achref
A qui je souhaite une vie pleine de bonheur, de prospérité et de réussite.
A mon binôme Ala.
A tous mes amis : Firas, Ghassen, Belhassen, Mahmoud, Amine, Foued,
Hazem, Zouhaier.
.
Je vous dédie ce travail et vous souhaite un avenir à la hauteur de vos
Ambitions. Que notre amitié dure
A Toute ma famille, Tous ceux que j’aime, qui m’aiment et me comblez
De conseils
A tous ceux qui, un jour, ont pensé à moi, les plus beaux mots ne
Sauraient exprimer ma redevance.
Anouar

3. Dédicace
A mes très chers parents Mouhamed et Mariem,
Nul mot ne pourra exprimer mes sentiments et ma gratitude envers vous,
A ma soeur Mouna et à mon frère Brahim,
Je vous souhaite beaucoup de bonheur et de réussite.
A toute ma grande famille.
A mes chers amis, Belhassen, Ahmed, Hazem, Foued, et mon binôme
Anouar,
A tous ceux qui m’aiment,
A tous ceux que j’aime, Je dédie le fruit de mon projet de fin d’études.
Alaa

4. Remerciements
Nous tenons tout d’abord à remercier le groupe PGH (Poulina Group
Holding) de nous avoir accueilli et donné l’opportunité d’évoluer au sein
leur société.
Notre profonde gratitude et nos sincères remerciements vont à :
Mr. Riadh LAKHDAR, responsable informatique, notre encadrant au sein de
PGH, pour son encadrement, ses conseils, sa présence et son soutien,
Mme. Fatma HERMES, notre encadrant à l’ISI, pour son implication et son
précieux encadrement.
Med Ali BEN HMIDA, notre collègue et futur ingénieur au sein de PGH, pour
ses conseils efficace et son soutien,
Nous adressons également nos sincères remerciements au corps
professoral et administratif de l’ISI pour tous leurs efforts et leur
engagement durant toute notre période d’étude.

5. Table des matières
Remerciements....................................................................................................................................... 5
Table des figures.................................................................................................................................... 9
Liste des tableaux ................................................................................................................................ 10
Introduction Générale......................................................................................................................... 11
CHAPITRE 1 : CADRE GÉNÉRALE DU PROJET ...................................................................... 12
Introduction........................................................................................................................................... 13
1. Présentation du cadre du projet ....................................................................................................... 13
1.1. Présentation générale de l'entreprise d'accueil......................................................................... 13
1.2. Historique................................................................................................................................... 13
1.3. Secteurs d’activité PGH .............................................................................................................. 14
1.3.1. Secteur avicole ........................................................................................................................ 14
1.3.2. Secteur agro-alimentaire et services....................................................................................... 14
1.3.3. Secteur de la céramique.......................................................................................................... 15
1.3.4. Secteur industriel .................................................................................................................... 15
1.3.5. Secteur de l’emballage............................................................................................................ 15
1.3.6. Secteur immobilière ................................................................................................................ 15
2. Travail demandé................................................................................................................................ 16
2.1. Introduction................................................................................................................................ 16
2.2. Pièces bancaire........................................................................................................................... 17
3. Analyse et critique de l’existant ........................................................................................................ 18
3.1. Analyse de l’existant................................................................................................................... 18
3.2. Critique de l’Existant .................................................................................................................. 20
4. Méthodologie de travail.................................................................................................................... 20
Conclusion ............................................................................................................................................. 21
CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS .............................................. 22
Introduction........................................................................................................................................... 23
1. Spécification des besoins .................................................................................................................. 23
1.1. Besoins Fonctionnels.................................................................................................................. 23
1.2. Besoins non Fonctionnels........................................................................................................... 24
1.3. Identification des Acteurs et leurs rôles..................................................................................... 25
2. Diagramme des cas d'utilisations...................................................................................................... 25
2.1. Diagramme de Cas d'utilisation Global ...................................................................................... 26
2.2. Raffinement des cas d'utilisations.............................................................................................. 26

6. 2.2.1. Raffinement de cas d'utilisation : <<Authentification>>......................................................... 26
2.2.2. Raffinement de cas d'utilisation : <<Gestion des utilisateurs et droits d’accès>>.................. 28
2.2.3. Raffinement de cas d'utilisation : <<Gestion de banque>> .................................................... 29
2.2.4. Raffinement de cas d'utilisation : <<Gestion des comptes bancaires>>................................. 30
2.2.5. Raffinement de cas d'utilisation : <<Gestion des sociétés>>.................................................. 31
2.2.6. Raffinement de cas d'utilisation : <<Réception>>................................................................... 32
2.2.7. Raffinement de cas d’utilisation : <<Approbation>> .............................................................. 34
2.2.8. Raffinement de cas d'utilisation : <<Identification>> ............................................................. 35
2.2.9. Raffinement de cas d'utilisation : <<Comptabilisation>> ....................................................... 36
Conclusion ............................................................................................................................................. 37
CHAPITRE 3 : CONCEPTION ........................................................................................................ 38
Introduction........................................................................................................................................... 39
1. Outil de conception : Enterprise Architect........................................................................................ 39
2. Le Diagramme de Classes.................................................................................................................. 39
3. Description des données de diagramme de classes.......................................................................... 41
4. Diagramme de séquence................................................................................................................... 43
4.1. Diagramme de séquence du processus authentification........................................................... 43
4.2. Diagramme de séquence du processus Réception .................................................................... 44
4.3. Diagramme de séquence du processus Approbation ................................................................ 45
4.4. Diagramme de séquence du processus Identification ............................................................... 46
4.5. Diagramme de séquence du processus Comptabilisation ......................................................... 47
5. Modèle Conceptuel Edmx ............................................................................................................. 48
Conclusion ............................................................................................................................................. 50
CHAPITRE 4 : RÉALISATION........................................................................................................ 51
Introduction........................................................................................................................................... 52
1. Choix Technique ................................................................................................................................ 52
1.1. Le Framework .NET..................................................................................................................... 52
1.2. Les composants du .NET............................................................................................................. 53
1.2.1. Le langage C#........................................................................................................................... 53
1.2.2. Asp.Net.................................................................................................................................... 53
1.2.3. ADO.Net................................................................................................................................... 53
1.3. Framework Asp.Net MVC........................................................................................................... 53
1.3.1. Présentation du Framework Asp.Net MVC ............................................................................. 54
1.3.2. Modèle MVC............................................................................................................................ 54
1.4. JQWidgets................................................................................................................................... 55
1.5. Ajax............................................................................................................................................. 55

7. 2. Outils de travail ................................................................................................................................. 56
2.1. Visual Studio 2013...................................................................................................................... 56
2.2. SQL Server 2012 ......................................................................................................................... 56
2.3. IIS 8.0 Express............................................................................................................................. 56
2.4. SQL Server Integration Services : SSIS ....................................................................................... 56
2.4.1. Avantages de SSIS.................................................................................................................... 57
2.4.2. Package BIAT: Téléchargement et rattachement automatique des pièces bancaires avec les
mouvements bancaires. .................................................................................................................... 58
3. Illustration de l’utilisation de l’application........................................................................................ 60
3.1. Interface d’authentification........................................................................................................ 60
3.2. Interface d’administration.......................................................................................................... 61
3.3. Interface de la réception et rattachement de pièce bancaire ................................................... 67
3.4. Interface de l’approbation.......................................................................................................... 68
3.5. Interface de l’identification........................................................................................................ 69
Conclusion ........................................................................................................................................... 711
Conclusion Générale ........................................................................................................................... 722
Webographie...................................................................................................................................... 733

8. Table des figures
Figure 1 – La structure principale du groupe PGH ............................................................................... 14
Figure 2 – L’organigramme du service informatique du groupe PGH................................................... 16
Figure 3 - Les étapes de la comptabilisation d’une pièce bancaire....................................................... 18
Figure 4 - Système générale adopté par l'entreprise............................................................................ 19
Figure 5 - Phases de la méthode XP ...................................................................................................... 21
Figure 6 - Diagramme de cas d'utilisation Global.................................................................................. 26
Figure 7 - Diagramme de cas d'utilisation authentification .................................................................. 27
Figure 8 - Diagramme de cas d'utilisation des utilisateurs et droits d’accès ........................................ 28
Figure 9 - Diagramme de cas d’utilisation des banques........................................................................ 29
Figure 10 - Diagramme de cas d'utilisation gestion des comptes bancaires ........................................ 30
Figure 11 - Diagramme de cas d'utilisation Gestion des sociétés ......................................................... 31
Figure 12 - Diagramme de cas d'utilisation réception........................................................................... 32
Figure 13 - Diagramme de cas d'utilisation approbation ...................................................................... 34
Figure 14 - Diagramme de cas d'utilisation Identification..................................................................... 35
Figure 16 - Logo de l’outil UML ............................................................................................................. 39
Figure 17 - Diagramme de classes ……………….………………………………………………………………………………….40
Figure 18 - Diagramme de séquence du processus s’authentifier........................................................ 44
Figure 19 - Diagramme de séquence du processus recevoir d’une pièce............................................. 45
Figure 20 - Diagramme de séquence du processus approbation.......................................................... 46
Figure 21 - Diagramme de séquence du processus identification ........................................................ 47
Figure 22 - Diagramme de séquence du processus comptabilisation................................................... 48
Figure 24 - Architecture du Framework .NET........................................................................................ 52
Figure 25 - Structure de l’application PBE............................................................................................. 54
Figure 26 - Modèle MVC........................................................................................................................ 55
Figure 27 - Logo de jQWidgets .............................................................................................................. 55
Figure 27 - Modèle ETL (SSIS)................................................................................................................ 57
Figure 29 - Exemple d’une tâche SSIS ................................................................................................... 58
Figure 30 - Architecture des dossiers de réception des pièces bancaires ............................................ 59
Figure 31 - Interface d’authentification ................................................................................................ 60
Figure 32 – Interface administrateur (Tableau de bord)....................................................................... 61
Figure 33 – Interface administrateur (ajouter un utilisateur)............................................................... 62
Figure 34 – Interface administrateur (Groupe utilisateur).................................................................... 63
Figure 35 – Interface administrateur (Utilisateur compte)................................................................... 64
Figure 36 – Interface administrateur (Flux)........................................................................................... 65
Figure 37 – Interface administrateur (Banque)..................................................................................... 66
Figure 38 – Interface de réception et rattachement de pièce bancaire ............................................... 67
Figure 39 – Interface d’approbation ..................................................................................................... 68
Figure 40 – Interface d’identification.................................................................................................... 70
Figure 41 – Interface d’identification (2)…………………………………………………………………………………………..70

9. Liste des tableaux
Tableau 1 : Répartition des comptes bancaires PGH para devise......................................................... 14
Tableau 2 : Description des besoins fonctionnels................................................................................. 24
Tableau 3 : Description des besoins non fonctionnels.......................................................................... 25
Tableau 4 : Description des acteurs ...................................................................................................... 25
Tableau 5 : Description textuelle de cs « s’authentifier »..................................................................... 26
Tableau 6 : Description textuelle de cas « Consulter un utilisateur »................................................... 28
Tableau 7 : Description textuelle de cas « Ajouter un utilisateur » ...................................................... 28
Tableau 8 : Description de cas « Attribuer des droits d’accès » ........................................................... 29
Tableau 9 : Description de cas « Modifier un utilisateur » ................................................................... 29
Tableau 10 : Description textuelle de cas « Consulter les banques »................................................... 30
Tableau 11 : Description textuelle de cas « Ajouter une banque » ...................................................... 30
Tableau 12 : Description textuelle de cas « Modifier ou supprimer une banque ».............................. 30
Tableau 13 : Description de cas « Consulter les comptes bancaires »................................................. 31
Tableau 14 : Description textuelle de cas « Ajouter un compte bancaire » ......................................... 31
Tableau 15 : Description textuelle de cas « Modifier ou supprimer un compte bancaire »................. 31
Tableau 16 : Description textuelle de cas « Consulter les sociétés ».................................................... 32
Tableau 17 : Description textuelle de cas « Ajouter une société »....................................................... 32
Tableau 18 : Description textuelle de cas « Modifier ou supprimer un compte bancaire »................. 32
Tableau 19 : Description textuelle de cas « Réception des pièces bancaires » .................................... 33
Tableau 20 : Description textuelle de cas « Vérification des pièces bancaires ».................................. 33
Tableau 21 : Description textuelle de cas « Envoyer les pièces rattachées pour l’approbation »........ 33
Tableau 22 : Description textuelle de cas « Rattachement automatique des pièces bancaires avec les
mouvements bancaires » ...................................................................................................................... 33
Tableau 23 : Description textuelle de cas « Approuver les mouvements bancaires réceptionnés » .. 34
Tableau 24 : Description textuelle de cas « Retourner les mouvements erronés pour révision »....... 34
Tableau 25 : Description textuelle de cas « Envoyer les mouvements approuvés pour l’identification »
............................................................................................................................................................... 35
Tableau 26 : Description textuelle de cas « Identifier les mouvements bancaires approuvés ».......... 35
Tableau 27 : Description textuelle de cas d’utilisation « Ajouter une ligne »....................................... 35
Tableau 29 : Description textuelle de cas « Retourner les mouvements pour révision » .................... 36
Tableau 30 : Description textuelle de cas « Envoyer les mouvements pour la comptabilisation »...... 36
Tableau 31 : Description textuelle de cas « Comptabiliser les mouvements identifiés »..................... 36
Tableau 32 : Description textuelle de cas d’utilisation « Retourner les mouvements pour révision » 37
Tableau 33 : Description textuelle de cas « Modifier les mouvements si nécessaires » ...................... 37
Tableau 34 : Description textuelle de cas « Envoyer les mouvements comptabilisés à MFG » ........... 37
Tableau 35 : Description des données de diagramme de classes......................................................... 43

10. 11
Introduction Générale
La trésorerie d'une entreprise peut être analysée comme l'ensemble des sommes
d'argent disponibles en caisse ou placées sur des comptes bancaires.
La bonne gestion de trésorerie permet de :
 Contrôler les entrées et sorties de fonds.
 Optimiser la gestion de trésorerie, dans un sens de sécurité et de rentabilité.
 S'assurer de la bonne application des conditions bancaires : jours de valeur, frais
appliqués sur flux de trésorerie.
Le trésorier doit gérer les flux financiers de l’entreprise grâce à l’utilisation de
certains tableaux et au respect de certains principes. Les fiches papiers, la gomme et le
crayon ont leurs limites et il est normal que l’on songe au traitement informatisé de la
trésorerie.
Ainsi, Compte tenu des importantes contraintes informationnelles (collectes, prévisions,
rapprochements...) qu'impose la gestion de trésorerie, il est devenu quasiment
incontournable de recourir à l'informatique pour gérer la trésorerie d'une entreprise.
En effet, l’informatisation de la gestion de trésorerie permet de vérifier le célèbre adage «
le temps, c’est de l’argent ».
Le personnel administratif et financier est souvent stupéfait de la rapidité et de la
simplicité avec laquelle sont effectuées certaines procédures auparavant si laborieuses.
C’est pourquoi il convient de parler d’un véritable saut technologique.
Dans ce contexte se situe ce projet de fin d’études réalisé au sein de la société Poulina
Group Holding qui m’a accordé la tâche de conception et d’implémentation d’une solution
qui a pour objectif la mise en place d’une application web de gestion électronique des
pièces bancaires.
Cette dernière sera présentée dans le présent rapport structuré comme suit :
Le premier chapitre décrit le contexte métier, la présentation générale du sujet ainsi que
la description de l’organisme d’accueil. Le deuxième chapitre vise à présenter les besoins
fonctionnels et non fonctionnels ainsi que les diagrammes des cas d’utilisation. Le
troisième sera dédié à la conception de notre système. Enfin, le dernier chapitre sera
consacré à la présentation de la solution implémentée ainsi qu’à la description de
l’environnement logiciel utilisé.

11. CHAPITRE 1 : CADRE GÉNÉRALE DU
PROJET

12. 13
Introduction
Nous présentons dans ce chapitre l'organisme d'accueil, ainsi que le travail
demandé pour le développement de l’application.
Une étude de l’existant est ensuite réalisée, pour présenter certaines des solutions qui
existent sur le serveur du groupe PGH, et montrer leurs relations avec l’application
demandée ainsi que leurs lacunes. Nous terminons enfin par une présentation de la
méthodologie de travail adoptée.
1. Présentation du cadre du projet
1.1. Présentation générale de l'entreprise d'accueil
Poulina Group Holding (PGH) est un groupement d'hommes et de femmes qui se sont
associés pour réaliser ensemble une ambition commune: celle de construire une
entreprise moderne, qui soit une fierté pour la Tunisie, qui rivalise en qualité de
management et en efficacité avec les entreprises des pays les plus développés.
Une structure capable de mobiliser des milliers d'hommes et de femmes qui développent
des valeurs communes, qui créent de la richesse et qui mettent en place une culture
saine au sein de leur entreprise.
1.2. Historique
Poulina Group Holding a été créé en 1967, l’année où tout a commencé avec l’aviculture.
Durant la première décennie d’exploitation, la société a fortement diversifié ses produits
pour se repositionner non plus comme une entité de production avicole mais comme une
entreprise offrant aux éleveurs tous les services et fournitures d’élevage nécessaires
(matériel avicole, poussins d’un jour, aliments etc…).
Dans la même logique de diversification, et afin de palier à l’étroitesse du marché local,
la société s’est développée dans des secteurs plus industrialisés (ouverture de points de
ventes de proximité spécialisés dans les produits avicoles, développement d’une chaîne
de rôtisserie). Vers la fin des années 1980, une nouvelle phase de diversification a été
entamée, développant plusieurs nouveaux produits : surgelés, pots d’échappement,
réfrigérateurs, chaînes de restauration rapide, produits en plastique, bois, céramique...
Après plus de 40 ans de croissance, le groupe est devenu un conglomérat de sociétés, ce
qui l’a amené à engager dès 2005 une réorganisation en 5 pôles d’activité pour lesquels
un travail de consolidation des comptes a été entamé.
En 2008, le groupe a décidé de s’introduire en Bourse. Cette décision s’est accompagnée
par un grand chantier de restructuration ayant pour but de réorganiser le groupe en
Holding de tête tout en regroupant les filiales en pôles d’activités homogènes.
En 2010, PGH a lancé une action de restructuration qui a donné naissance à la
recentralisation de son groupe autour de 9 métiers pour en faciliter la gestion et le suivi
des performances.

13. CHAPITRE 1: CADRE GÉNÉRALE DU PROJET
14
Les 9 métiers sont l’intégration avicole, les produits de grande consommation, la
transformation de l’acier, l’emballage, l’immobilier, les travaux publics, le bois et les
biens d’équipement, les matériaux de construction et le commerce et les services.
D’une dimension internationale, le Groupe possède 24 filiales à l'étranger, principalement
au Maroc (4), en Algérie (4), en Libye (10), en France (2), au Sénégal (1) et en Chine
(3). Créé il y a 48 ans, le Groupe comptait au 31/12/2012, 105 entreprises.
1.3. Secteurs d’activité PGH
Figure 1 – La structure principale du groupe PGH
1.3.1. Secteur avicole
Le secteur avicole assure l’approvisionnement du pays en viandes à hauteur de 50% du
total des viandes (contre 36% en1994) ainsi que la totalité des besoins en œufs de
consommation. Par ailleurs, et bien que les prix des produits avicoles soient très bon
marché, ce secteur représente environ 25 % de la valeur de l’élevage et 8 % des
productions agricoles en2006.
1.3.2. Secteur agro-alimentaire et services
La Tunisie, qui compte 12 centrales laitières, est autosuffisante en lait frais depuis la fin
des années 90 (production de 970millions de litres en 2006) mais, importe toujours du
lait en poudre.
La production de yaourts est assurée par 9 entreprises à partir de lait frais, et a
fortement augmenté dans les années 90. Cette activité tend à se diversifier avec le
développement des desserts lactés (yaourt aux fruits, yaourt à boire, crème dessert).
DELICE DANONE du groupe français DANONE, est le leader sur le marché des yaourts et
desserts lactés en Tunisie.

14. CHAPITRE 1: CADRE GÉNÉRALE DU PROJET
15
1.3.3. Secteur de la céramique
Le secteur de la céramique connaît depuis le début des années 2000, une véritable
mutation grâce à l’introduction d’un nouveau produit : « le grès ». Ce produit connaît un
franc succès dans le pays et permet de faire gagner des parts de marché aux
revêtements de sols en céramique aux dépends des revêtements concurrents (carreaux
de ciment blanc/mosaïque ; le marbre). Grâce au succès de ses produits, la société
exporte plus de 20% de sa production vers une trentaine de pays, notamment la France,
les pays d’Afrique de l’Ouest, le Maghreb et les pays du Golfe.
1.3.4. Secteur industriel
En Tunisie, le secteur du bois et de l’ameublement compte environ 400 entreprises mais
reste majoritairement dominé par les petites et micro entreprises indépendantes dont le
nombre représente 80% du marché. Sur les 400 sociétés «structurées», seules une
dizaine d’entreprises sont de grandes tailles, relativement spécialisées, emploient plus de
100 personne et écoulent leurs produits via des revendeurs franchisés.
Les débouchés du bois sont principalement l’ameublement (meubles d’intérieur, salons,
meubles de cuisine, meubles de bureaux et meubles pour collectivités) et le bâtiment.
La branche ameublement représente environ 60% de l’industrie et est majoritairement
alimentée par la demande des ménages. La filière connaît la montée en puissance du
MDF ‘Medium Density Fiberboard’ (panneau dérivé du bois), matériau qui investit de
façon exponentielle l’habitat moderne.
Quant à la branche bâtiment, elle a pour principaux débouchés les secteurs de la
construction (BTP) et l’industrie et fait face à une concurrence de plus en plus importante
des produits de substitution – PVC et aluminium.
1.3.5. Secteur de l’emballage
Depuis une dizaine d’années, le secteur de l’emballage connaît une croissance
remarquable favorisée par le développement du secteur industriel qui génère des besoins
croissants en matière d’emballage.
Il existe cinq matériaux de base pour la fabrication des emballages : le papier, le
plastique, le verre, le métal et le bois (palettes).
La société UNIPACK est leader avec 30% de part de marché dans les segments carton
ondulé et carton compact.
1.3.6. Secteur immobilière
Poulina Group Holding s’est lancé dans le métier de l’immobilier à travers sa filiale
ETTAAMIR, créée en 1997.
Ainsi, plusieurs projets de haut standing ont été réalisés dans les quartiers les plus
huppés de la Tunisie, d'autres projets sont en cours de construction et d’autres projets
en cours d'études.
À travers sa filiale ETTAAMIR, le groupe PGH est devenu un acteur incontournable du
secteur immobilier en Tunisie.

15. CHAPITRE 1: CADRE GÉNÉRALE DU PROJET
16
1.4. Présentation du service d'accueil
Le service informatique nous a accueillis durant ce stage, le département développement
informatique dont nous y effectuons notre stage de fin d’étude est conçu pour la gestion
des systèmes d’information du groupe PGH, en fait notre tâche est de réaliser une
application de gestion des pièces bancaires électroniques sur le serveur PGH encadré par
M. Riadh Lakhdar.
Figure 2 – L’organigramme du service informatique du groupe PGH
2. Travail demandé
2.1. Introduction
De nos jours le monde des entreprises est bien plus concurrentiel qu'autrefois, et seules
survivent celles qui sont plus astucieuses et performantes. Et le fonctionnement d'une
entreprise dépend inévitablement des opérations réalisées avec son environnement, se
traduisant immédiatement ou à terme, par des flux de trésorerie.
La gestion de la trésorerie doit donc d'être beaucoup plus fine. La profession a donc
évolué en technicité avec l'aide d'outils de gestion. Le Trésorier s'occupe ainsi de la
gestion des risques à travers le contrôle des règlements effectués et les créances
accordées grâce au suivi de leur compte individuel.
L'importance d'une gestion quotidienne de la trésorerie se situe dans le fait qu'elle
permet d'avoir chaque jour une idée des soldes de la trésorerie afin d'opérer des
décisions adéquates pour les transactions. L'absence de gestion efficiente pourrait
entraîner un ralentissement des activités de l'entreprise et inévitablement agira sur le
résultat comptable de l'entreprise.
Le trésorier occupe donc un poste stratégique et inévitable dans l'entreprise.

16. CHAPITRE 1: CADRE GÉNÉRALE DU PROJET
17
Tableau 1: Répartition des comptes bancaire PGH par devise
2.2. Pièces bancaire
Nous allons effectuer durant ce stage une application pour gérer les pièces bancaires
électroniques, c’est la gestion de l’ensemble des avis bancaires récupérés via serveur FTP
afin de les rattacher avec les mouvements bancaires qui nécessite une pièce et de les
contrôler en passant par plusieurs étapes pour les retourner aux filiales.
Les processus de la gestion des pièces bancaires électroniques :
 Réception des pièces bancaires via internet ou les scannées si la banque envoi des
pièces physiques.
 Rattachement Automatique des pièces bancaires avec les mouvements bancaires.
 Approbation de la pièce rattachée.
 Identification de la pièce approuvée.
 Comptabilisation de la pièce identifiée : cette étape est modélisée dans la figure 3
ci-dessous.
On nous a demandé à développer une application contenant ces différentes parties :
 Authentification
 Gestion des utilisateurs
 Gestion des types d’accès
 Réception de pièces bancaires
 Approbation des pièces bancaires réceptionnées
 Identifications des pièces bancaires approuvées
 Comptabilisation des pièces bancaires identifiées
 Reporting : des rapports générés pour chaque échec.

17. CHAPITRE 1: CADRE GÉNÉRALE DU PROJET
18
Figure 3 - Les étapes de la comptabilisation d’une pièce bancaire
Environnement de développement de l'entreprise
Pour le développement, on nous a recommandé d’utiliser :
 L’architecture MVC (Model, View, Controller) puisque nous sommes en recherche
de faire un travail bien organisé cette architecture est la meilleure solution.
 ASP.NET C# pour le développement de l’application.
 JQWIDGET pour la création des GridView et la communication entre
client/serveur, cet outil est payant si seulement si l’application sera pour un but
commerciale, en utilisant une bibliothèque JavaScript JQuery.
 SQL Server 2012 pour la gestion de base de données.
 Une Template pour le graphique de l’application qu’on doit intégrer en MVC.
3. Analyse et critique de l’existant
Notre domaine d’étude est la gestion des pièces bancaires électroniques, l’application
existante PB.NET et son fonctionnement sur le serveur du groupe PGH.
3.1. Analyse de l’existant
L’étude de l’existant constitue le cœur de la phase d’analyse d’un projet. Cette étape est
primordiale pour la mise en route de tout projet informatique ou autre, et qui permet de
définir le contexte de fonctionnement, ou bien le processus métier, et de dégager les
différentes imperfections dans le système actuel afin de les corriger.
Le fonctionnement du système existant :
La figure ci-dessous représente le fonctionnement du système de trésorerie du groupe
PGH:

18. CHAPITRE 1: CADRE GÉNÉRALE DU PROJET
19
Figure 4 - Système générale adopté par l'entreprise
 PB.NET : (Pièce Bancaire développer avec .NET) représente l’application existante
et que nous devons la développer à nouveau. Cette application doit être
redéveloppée pour organisation, maintenance et ajout de fonctionnalité.
 FRP-Rapprochement : Le module Communication de Sage FRP Treasury -
Universe Edition, représente pour l’entreprise la solution cliente universelle et
simple pour échanger ses flux avec ses partenaires financiers nationaux ou
internationaux.
Cette solution permet de générer des gains de productivité dans la chaîne de
règlements fournisseurs, assure la sécurité de bout en bout pour la chaîne des
paiements, facilite l’automatisation des tâches et améliore le processus de
décision grâce à des échanges en temps réel (génération, notification, intégration
d’informations financières).
 MFG-Filiale : ERP (Entreprise Resource Planning) MFG PRO, est la plateforme
d’interconnexion et l’ensemble des fonctions du groupe PGH dans un système
informatique centralisé qui est configuré selon le mode client-serveur.
 FileNet Content Manager pour la gestion des données. Les données élevées
exigent de faire appel sur le long terme à une solution de stockage de qualité.
Les solutions pour FileNet optimisent les performances et la disponibilité de vos
données tout en les protégeant et en assurant leur conformité.
 Base de données : on nous a fourni un échantillon de la base pour gérer les
tests de l’application.

19. CHAPITRE 1: CADRE GÉNÉRALE DU PROJET
20
3.2. Critique de l’Existant
Quelle que soit la technologie utilisée, il y aura toujours de nouveau à apporter pour
n’importe quelle solution vu que la progression de la technologie est sans frontière.
Lors de l’étude que nous avons faite dans la section précédente, nous avons relevé
plusieurs insuffisantes à savoir :
 Insuffisances fonctionnels :
 Actuellement les avis bancaires sont de pièces physiques
 identification des pièces sur papier
 La comptabilisation des pièces bancaires se fait manuellement dans l’ERP MFG
PRO
 Insuffisances techniques :
 L’application est mal structurée et elle nécessite une organisation.
 Redondance d'enregistrements.
 Des erreurs fréquentes lors de la tenue des différents documents et lors de
l'enregistrement des opérations.
 Les technologies utilisées :
- Serveur SQL 2008.
- ASPX VB.NET version antérieur.
Alors nous cherchons à développer une solution qui sera bien organisée et fonctionnelle
en utilisant des technologies récentes.
4. Méthodologie de travail
Pour assurer un bon rendement de développement en termes de qualité et de
productivité le choix de la méthodologie en informatique est primordial. Vue la
complexité des systèmes de nos jours, le génie logiciel doit tenter de remédier à cette
complexité en offrant une démarche à suivre avec des étapes bien précises .C’est le
principe des méthodologies de travail.
Nous avons choisi la méthode agile eXtremeProgramming (XP) car nous estimons qu'elle
est adaptable pour notre projet. Les principes de cette méthode ne sont pas nouveau ils
existent dans l’industrie de logiciel depuis longtemps et utilisés dans des autres
méthodes de travail.
Les besoins de l’application peuvent changer au cours du temps, des modifications, des
contraintes ou nouvelles fonctionnalités peuvent être appliquées. Généralement les
besoins sont définis au départ du projet ce qui accroît les coûts ultérieurs de
modifications alors que XP son but principale est de réduire les coûts du changement.
XP s'attache à rendre le projet plus flexible et ouvert au changement en introduisant des
valeurs de base, des principes et des pratiques.
 L'eXtremeProgramming repose sur des cycles rapides de développement (des
itérations de quelques semaines) dont les étapes sont les suivantes :
 Une phase d'exploration détermine les scénarios client qui seront fournis pendant
cette itération.
 L’équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels.
Chaque développeur s'attribue des tâches et les réalise avec un binôme.
 Lorsque tous les tests fonctionnels passent, le produit est livré.

20. CHAPITRE 1: CADRE GÉNÉRALE DU PROJET
21
Le cycle se répète tant que le client peut fournir des scénarios à livrer. Généralement le
cycle de la première livraison se caractérise par sa durée et le volume important de
fonctionnalités embarquées. Après la première mise en production, les itérations peuvent
devenir plus courtes (une semaine par exemple).
Figure 5 - Phases de la méthode XP
Conclusion
Nous avons dans ce chapitre mis notre travail dans son contexte, pour pouvoir
déterminer les étapes nécessaires à la conception et à la réalisation. Le chapitre suivant
présente l'analyse et la spécification des besoins fonctionnels et non fonctionnels ainsi
que les diagrammes des cas d’utilisations.
Tâches et
tests
fonctionnels
Implémentation
des taches
Itération
suivante
Exploration
des besoins

21. CHAPITRE 2 : ANALYSE ET
SPÉCIFICATION DES BESOINS

22. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
23
Introduction
Dans ce chapitre nous allons identifier toutes les fonctionnalités de notre application
pour chaque type d’utilisateur, en indiquant les besoins fonctionnels et d’appréhender la
liste des exigences traduites par les besoins non fonctionnels.
Par suite on va identifier les acteurs et définir tous les besoins qui seront modélisés par le
diagramme de cas d’utilisation général et les diagrammes de cas d’utilisation détaillés.
1. Spécification des besoins
Vu la difficulté de gestion des mouvements bancaires et des pièces bancaires dans une
grande entreprise comme Poulina Group Holding les trésoriers ont besoin d’un moyen
pour faciliter la gestion des pièces bancaires et éviter les erreurs humains.
1.1. Besoins Fonctionnels
L’utilisateur bénéficiera des fonctionnalités suivantes :
Administrateur
S’authentifier L'administrateur accède à l’application avec un
login et un mot de passe.
Gérer les comptes des
Utilisateurs
L'administrateur est la seule personne qui a le
droit de gérer les comptes des utilisateurs
(Ajout/Modification/Suppression/Consultation)
Gérer les droits d'accès
aux utilisateurs
L'administrateur est la seule personne qui a le
droit de gérer les droits d'accès des utilisateurs
sur le SGBD.
Consulter la structure de
la société
L'administrateur accède à l’application avec un
login et un mot de
passe et consulte la structure de la société.
Agent Siège
S’authentifier Chaque Agent siège accède à l’application avec
un login et un mot de passe.
Réceptionner les pièces
Bancaires
L'agent siège est la personne qui a le droit de
réceptionner les pièces bancaires.
Vérifier les pièces
Bancaires
Chaque agent siège peut vérifier les pièces
bancaires
Rattacher manuellement
les pièces bancaires
électroniques.
Chaque Agent siège peut rattacher
manuellement les pièces bancaires
électroniques.
Envoyer les pièces
bancaires
Chaque Agent siège peut envoyer les pièces
bancaires aux autres filiales.
Agent filiale (Approbateur)
S’authentifier Chaque Agent filiale accède à l’application avec
un login et un mot de passe.
Réceptionner les pièces
Bancaires
L'agent Filiale est la personne qui a le droit de
réceptionner les pièces bancaires de la part de
l’agent siège.
Vérifier les pièces
Bancaires
Chaque agent filial peut vérifier les pièces
bancaires
Approuver les pièces
bancaires électroniques
L’Agent Filiale est la personne qui a le droit
d'approuver les pièces bancaires électroniques.
Envoyer les pièces à l’identification L'Agent Filiale est la seule personne qui a le
droit d'envoyer les pièces bancaires pour

23. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
24
l’identification.
Agent trésorerie (Identificateur)
S’authentifier Chaque Agent trésorerie accède à l’application
avec un login et un mot de passe.
Réceptionner les pièces
Bancaires
L'agent trésorerie est la personne qui a le droit
de réceptionner les pièces bancaires de la part
de l’agent filiale.
Vérifier les pièces
Bancaires
Chaque agent filial peut vérifier les pièces
bancaires
Identifier les pièces
bancaires électroniques
L’Agent trésorerie est la personne qui a le droit
d'identifier les pièces bancaires en ajoutant
quelques informations utiles pour le comptable.
Agent comptable (peut être un identificateur)
S’authentifier Chaque Agent comptable accède à l’application
avec un login et un mot de passe.
Comptabiliser les pièces
bancaires électroniques
L’agent comptable consulte les pièces bancaires
identifiées pour la comptabilisation, une fois les
pièces sont comptabilisées une référence
comptable doit être gérée dans l’ERP MFG PRO.
Tableau 2 : Description des besoins fonctionnels
1.2. Besoins non Fonctionnels
Notre système doit respecter un ensemble de contraintes et d’exigences non
fonctionnelles :
Les besoins non fonctionnels
Sécurité L’application doit respecter la
confidentialité des données.
Ainsi le contrôle du mot de passe et la
contrôle traçabilité.
Interface utilisateur  L’application devra être cohérente
de point de vue ergonomie dont la
qualité est un facteur essentiel,
puisque l’application est conçue
pour une utilisation intensive.
 L’utilisation de l’application et
l’accès aux informations doivent
être facile pour l’utilisateur grâce à
une interface graphique claire et
conviviale.
 Une gestion des erreurs est requise
dans l’application
Contrainte temporelle Le projet doit être réalisé pendant une
durée qui ne dépasse pas quatre mois.
Exigences techniques  Environnement de développement :
ASP.NET.
 Base de données : SQL SERVER
2012.
Tableau 3 : Description des besoins non fonctionnels

24. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
25
1.3. Identification des Acteurs et leurs rôles
Nous présentons ici les agents qui auront accès à l’application :
Acteurs Description
Administrateur C’est le gérant de l’application, il a une visibilité totale sur les
bases de données. Il a pour tâches de gérer tout le système. Il
spécifie les utilisateurs et les droits de chacun.
Agent siège L'agent siège est l'acteur qui a les droits de réceptionner,
rattacher, vérifier et envoyer les pièces bancaires électroniques
aux autres filiales.
Agent filiale L'agent filial est l'acteur qui a les droits de réceptionner,
approuver, rattacher, vérifier et envoyer les pièces bancaires à
l'agent trésorerie.
Agent trésorerie Identification des pièces approuvées en ajoutant des
informations nécessaires pour la comptabilisation.
Agent comptable L'agent comptable est l'acteur qui a le droit de comptabiliser les
pièces bancaires.
Tableau 4 : Description des acteurs
2. Diagramme des cas d'utilisations
Les diagrammes de cas d'utilisation sont utilisés pour la représentation et la structuration
au niveau conceptuel, des besoins des utilisateurs et des objectifs correspondants du
système. Le but est d'identifiée les acteurs du domaine et leurs interactions avec
l'interface.
Ce diagramme permet d’identifier le comportement et les fonctionnalités que pourra
effectuer un utilisateur avec le système. D’autre part, cela permet de voir comment le
système gère ces fonctionnalités et notamment les communications entre les sous-
systèmes.
Acteur : représente un rôle joué par une entité externe (utilisateur humain, dispositif
matériel ou autre système) qui interagit directement avec le système étudié.
Cas d’utilisation (use case) : représente un ensemble de séquences d’actions qui sont
réalisées par le système et qui produisent un résultat observable intéressant pour un
acteur particulier. Un cas d’utilisation sert à exprimer le comportement du système en
termes d’actions et de réactions.
Système : représente le domaine étudié. Il permet de déterminer les limites au-delà
desquelles les fonctionnalités seront exclues.
Association : C’est une association entre acteurs, entre cas d’utilisation ou entre acteur et
cas d’utilisation. Le système assure pour les utilisateurs diverses fonctions mises en
valeur à travers le diagramme de cas d'utilisation globale illustré par la figure ci-dessous:

25. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
26
2.1. Diagramme de Cas d'utilisation Global
Figure 6 - Diagramme de cas d'utilisation Global
2.2. Raffinement des cas d'utilisations
2.2.1. Raffinement de cas d'utilisation : <<Authentification>>
Une réalisation de ce cas d’utilisation « S’authentifier » se fait comme suit :
L’utilisateur demande d’accéder à l’application et le système récupère sa session
Windows : Authentification Windows sinon l’utilisateur saisie son login et mot de passe

26. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
27
sur la page : Authentification, après vérification des données, le système sélectionne
l’utilisateur en cours.
Une requête de recherche portant le nom de l’utilisateur se déclenche dans la base de
données afin d’afficher le menu général. En cas d’existence de l’utilisateur, le système
charge les privilèges attribué précédemment à l’utilisateur.
Figure 7 - Diagramme de cas d'utilisation authentification
Nom du cas S’authentifier
Acteurs Administrateur
Utilisateur
Pré-condition Authentification Windows ou Introduire login et mot de passe.
Scénario
nominal
Ce cas d’utilisation commence lorsque l’utilisateur demande l’accès à
l’application avec une authentification Windows ou saisi son login et
son mot de passe.
Enchaînement (a) : Le système récupère la session Windows de
l’utilisateur ou ce dernier valide les données saisies.
Scénario
alternatif
Enchaînement (b) : Vérifications de l’existence de la session Windows
de l’utilisateur par le système.
Enchaînement (c) : Message de confirmation d’entrer à la session ou
échec d’entrer.
Post-condition Ouverture de l’espace personnel.
Tableau 5 : Description textuelle de cas « s’authentifier »

27. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
28
2.2.2. Raffinement de cas d'utilisation : <<Gestion des utilisateurs et droits
d’accès>>
Figure 8 - Diagramme de cas d'utilisation des utilisateurs et droits d’accès
Tableau 6 : Description textuelle de cas « Consulter un utilisateur »
Nom du cas Ajouter un utilisateur
Acteurs Administrateur
Pré-condition Créer un utilisateur
Scénario
nominal
L’administrateur doit saisir les informations nécessaires selon le type
d’utilisateur à ajouter.
Scénario
alternatif
Si la saisie est invalide le système signale l’erreur et rejette la
saisie.
Post-condition L’utilisateur est enregistré.
Tableau 7 : Description textuelle de cas « Ajouter un utilisateur »
Nom du cas Consulter un utilisateur
Acteurs Administrateur
Pré-condition Afficher les informations de l’utilisateur.
Scénario
nominal
L’administrateur choisit un utilisateur.
Le système affiche les informations de l’utilisateur choisi.

28. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
29
Nom du cas Attribuer des droits d’accès
Acteurs Administrateur
Pré-condition Créer un utilisateur
Scénario
nominal
L’administrateur doit attribuer les privilèges suivants selon le rôle
d’utilisateur :
 Droits d’accès aux comptes bancaires : consultation,
réception, approbation, identification et comptabilisation des
pièces bancaires liées à ces comptes bancaires.
Post-condition Les droits sont enregistrés.
Tableau 8 : Description de cas « Attribuer des droits d’accès »
Tableau 9 : Description de cas « Modifier un utilisateur »
2.2.3. Raffinement de cas d'utilisation : <<Gestion de banque>>
Figure 9 - Diagramme de cas d’utilisation des banques
Nom du cas Modifier un utilisateur
Acteurs Administrateur
Pré-condition L’utilisateur à modifier est existant.
Scénario
nominal
L’administrateur accède au profil de l’utilisateur.
Le système affiche les informations de l’utilisateur choisi.
Le système enregistre les modifications et affiche un message de
mise à jour avec succès.
Scénario
alternatif
Si la saisie est invalide le système signale l’erreur rejette la
modification.
Post-condition La modification est enregistrée.

29. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
30
Nom du cas Consulter une banque
Acteurs Administrateur
Pré-condition Afficher les informations d’une banque.
Scénario
nominal
L’administrateur doit choisir une banque.
Le système affiche les informations de la banque choisi.
Tableau 10 : Description textuelle de cas « Consulter les banques »
Nom du cas Ajouter une banque
Acteurs Administrateur
Pré-condition Ouvrir l’interface administrateur.
Scénario
nominal
L’administrateur doit créer une ligne contenant le nom de la banque,
code de la banque et quelques informations nécessaire pour l’ajout.
Post-condition Le système affiche « La banque est ajoutée ».
Tableau 11 : Description textuelle de cas « Ajouter une banque »
Tableau 12 : Description textuelle de cas « Modifier ou supprimer une banque »
2.2.4. Raffinement de cas d'utilisation : <<Gestion des comptes bancaires>>
Figure 10 - Diagramme de cas d'utilisation gestion des comptes bancaires
Nom du cas Modifier ou supprimer une banque
Acteurs Administrateur
Pré-condition Consulter les banques.
Scénario
nominal
L’administrateur accède à liste des banques.
Le système enregistre les modifications ou valide la suppression de
la banque.
Scénario
alternatif
Si la saisie est invalide le système signale l’erreur et rejette la
modification.
Post-condition Le système affiche « modification enregistrée » ou « suppression
validée ».

30. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
31
Nom du cas Consulter les comptes bancaires
Acteurs Administrateur
Pré-condition Afficher les informations d’un compte bancaire
Scénario
nominal
L’administrateur doit choisir un compte bancaire.
Le système affiche les informations du compte bancaire choisi.
Tableau 13 : Description de cas « Consulter les comptes bancaires »
Nom du cas Ajouter un compte banque
Acteurs Administrateur
Pré-condition Ouvrir l’interface administrateur.
Scénario
nominal
L’administrateur doit ajouter les informations nécessaires (Nom de
la banque, code de la banque, numéro de compte …)
Post-condition Le système affiche « Compte bancaire est ajouté ».
Tableau 14 : Description textuelle de cas « Ajouter un compte bancaire »
Tableau 15 : Description textuelle de cas « Modifier ou supprimer un compte bancaire »
2.2.5. Raffinement de cas d'utilisation : <<Gestion des sociétés>>
Figure 11 - Diagramme de cas d'utilisation Gestion des sociétés
Nom du cas Modifier ou supprimer un compte bancaire
Acteurs Administrateur
Pré-condition Consulter les comptes bancaires.
Scénario
nominal
L’administrateur accède à liste des comptes. Le système enregistre
les modifications ou valide la suppression du compte.
Scénario
alternatif
Si la saisie est invalide le système signale l’erreur et rejette la
modification.
Post-condition Le système affiche « modification enregistrée » ou « suppression
validée ».

31. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
32
Nom du cas Consulter les sociétés
Acteurs Administrateur
Pré-condition Afficher les informations d’une société.
Scénario
nominal
L’administrateur doit choisir une société.
Le système affiche les informations de la société choisi.
Tableau 16 : Description textuelle de cas « Consulter les sociétés »
Nom du cas Ajouter un compte banque
Acteurs Administrateur
Pré-condition Ouvrir l’interface administrateur.
Scénario
nominal
L’administrateur doit ajouter les informations nécessaires (Nom de
la société, code de la société, adresse …)
Post-condition Le système affiche « Société est ajoutée ».
Tableau 17 : Description textuelle de cas « Ajouter une société »
Tableau 18 : Description textuelle de cas « Modifier ou supprimer un compte bancaire »
2.2.6. Raffinement de cas d'utilisation : <<Réception>>
Figure 12 - Diagramme de cas d'utilisation réception
Nom du cas Modifier ou supprimer un compte bancaire
Acteurs Administrateur
Pré-condition Consulter les sociétés.
Scénario
nominal
L’administrateur accède à liste des sociétés. Le système enregistre
les modifications ou valide la suppression du compte.
Scénario
alternatif
Si la saisie est invalide le système signale l’erreur et rejette la
modification.
Post-condition Le système affiche « modification enregistrée » ou « suppression
validée ».

32. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
33
Nom du cas Réception des pièces bancaires
Acteurs Agent siège
Pré-condition Parcourir les pièces bancaires.
Scénario
nominal
L’agent sélectionne les pièces nécessaires pour le rattachement à
partir d’un serveur FTP.
L’agent réceptionne les pièces sélectionnées.
Tableau 19 : Description textuelle de cas « Réception des pièces bancaires »
Nom du cas Vérification des pièces bancaires
Acteurs Agent siège
Pré-condition Parcourir les mouvements bancaires et les pièces bancaires.
Scénario
nominal
L’agent vérifie les pièces réceptionnées et rattachées avec les
mouvements.
Scénario
alternatif
L’agent ne trouve pas une pièce pour un mouvement ou la pièce
n’est pas correcte il doit contacter le banque concerné.
Tableau 20 : Description textuelle de cas « Vérification des pièces bancaires »
Nom du cas Envoyer les mouvements avec les pièces rattachées pour
l’approbation
Acteurs Agent siège
Pré-condition Parcourir les pièces bancaires rattachées avec les mouvements.
Scénario
nominal
L’agent sélectionne les mouvements rattachés avec les pièces.
L’agent envoi les mouvements sélectionnés pour l’approbation.
Tableau 21 : Description textuelle de cas « Envoyer les pièces rattachées pour l’approbation »
Nom du cas Rattachement automatique des pièces bancaires avec les
mouvements bancaires
Acteurs Agent siège
Pré-condition Parcourir les mouvements bancaires.
Scénario
nominal
L’agent sélectionne les mouvements à rattacher avec les pièces
bancaires.
L’agent active le module de rattachement.
Post-condition Les pièces bancaires sont rattachées avec les mouvements.
Tableau 22 : Description textuelle de cas « Rattachement automatique des pièces bancaires
avec les mouvements bancaires »

33. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
34
2.2.7. Raffinement de cas d’utilisation : <<Approbation>>
Figure 13 - Diagramme de cas d'utilisation approbation
Nom du cas Approuver les mouvements bancaires réceptionnés
Acteurs Approbateur (Agent filiale)
Pré-condition Parcourir les mouvements à approuver.
Scénario
nominal
L’approbateur consulte les informations des mouvements
réceptionnés et les compare avec les pièces bancaires.
L’approbateur approuve les mouvements si les données sont
conformes.
Scénario
alternatif
L’approbateur rejette les pièces non conformes avec les
mouvements.
Post-condition Le système affiche « Mouvement est approuvé».
Tableau 23 : Description textuelle de cas « Approuver les mouvements bancaires
réceptionnés »
Nom du cas Retourner les mouvements erronés pour révision
Acteurs Approbateur (Agent filiale)
Pré-condition Parcourir les mouvements rejetés.
Scénario
nominal
L’approbateur consulte les mouvements rejetés pour vérification.
L’approbateur renvoie les mouvements vers l’agent siège.
Post-condition Mouvement est renvoyé vers le service précédant.
Tableau 24 : Description textuelle de cas « Retourner les mouvements erronés pour révision »
Nom du cas Envoyer les mouvements approuvés pour l’identification
Acteurs Approbateur (Agent filiale)
Pré-condition Parcourir les mouvements approuvés.
Scénario
nominal
L’approbateur consulte les mouvements approuvés.
L’approbateur envoie les mouvements vers l’agent trésorerie.
Post-condition Mouvement est envoyé vers le service suivant.
Tableau 25 : Description textuelle de cas « Envoyer les mouvements approuvés pour
l’identification »

34. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
35
2.2.8. Raffinement de cas d'utilisation : <<Identification>>
Figure 14 - Diagramme de cas d'utilisation Identification
Nom du cas Identifier les mouvements bancaires approuvés.
Acteurs Agent trésorerie
Pré-condition Parcourir les mouvements à identifier.
Scénario
nominal
L’agent trésorerie doit consulter les mouvements réceptionnés et
doit définir la nature du mouvement bancaire en ajoutant des
informations nécessaires ou saisir la description de la pièce dans le
champ concerné.
Scénario
alternatif
L’agent rencontre des informations fausses ou non conformes entre
la pièce et le mouvement, il doit le rejeter.
Post-condition Mouvement est identifié.
Tableau 26 : Description textuelle de cas « Identifier les mouvements bancaires approuvés »
Nom du cas Ajouter une ligne
Acteurs Agent trésorerie
Pré-condition Consulter les mouvements à identifier.
Scénario
nominal
L’agent trésorerie doit ajouter des informations supplémentaires.
Les informations qui concernent le document (une ligne d’entête) :
Domaine, Dossier, Entité, Banque, Montant, Date etc…
Post-condition Ligne est ajoutée.
Tableau 27 : Description textuelle de cas d’utilisation « Ajouter une ligne »
Nom du cas Saisir les informations nécessaires.
Acteurs Agent trésorerie
Pré-condition Consulter les mouvements à identifier.
Scénario
nominal
L’agent trésorerie doit définir ou saisir les informations utilisées
(suivant le type de document) dans les champs concernés.
Post-condition Des informations sont ajoutées.
Tableau 28 : Description textuelle de cas « Saisir les informations nécessaires »

35. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
36
Nom du cas Retourner les mouvements pour révision
Acteurs Agent trésorerie
Pré-condition Parcourir les mouvements rejetés.
Scénario
nominal
L’agent trésorerie consulte les mouvements rejetés pour vérification.
L’agent trésorerie renvoie les mouvements vers l’agent filial.
Post-condition Le mouvement est renvoyé vers le service précédant.
Tableau 29 : Description textuelle de cas « Retourner les mouvements pour révision »
Nom du cas Envoyer les mouvements pour la comptabilisation
Acteurs Agent trésorerie
Pré-condition Parcourir les mouvements identifiés.
Scénario
nominal
L’agent sélectionne les mouvements identifiés.
L’agent envoi les pièces sélectionnées pour la comptabilisation.
Post-condition Le mouvement est envoyé vers le service suivant.
Tableau 30 : Description textuelle de cas « Envoyer les mouvements pour la comptabilisation »
2.2.9. Raffinement de cas d'utilisation : <<Comptabilisation>>
Figure 15 - Diagramme de cas d'utilisation Comptabilisation
Nom du cas Comptabiliser
Acteurs Comptable
Pré-condition Parcourir les mouvements identifiés.
Scénario
nominal
Le comptable doit consulter les mouvements bancaires et vérifier les
informations déjà affichées.
Le comptable peut modifier les mouvements si c’est nécessaire.
Scénario
alternatif
L’agent comptable peut rejeter complètement un mouvement en cas
de non nécessité de sa comptabilisation (cas de blocage, déblocage
de fonds) ou un mouvement avec des informations erronés.
Post-condition Mouvement est comptabilisé.
Tableau 31 : Description textuelle de cas « Comptabiliser les mouvements identifiés »

36. CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS
37
Nom du cas Retourner les mouvements pour révision
Acteurs Comptable
Pré-condition Parcourir les mouvements rejetés.
Scénario
nominal
Le comptable consulte les mouvements rejetés pour vérification.
Le comptable renvoie les mouvements vers l’agent trésorerie.
Post-condition Mouvement est renvoyé vers le service précédant.
Tableau 32 : Description textuelle de cas d’utilisation « Retourner les mouvements pour
révision »
Nom du cas Modifier les mouvements si nécessaires
Acteurs Comptable
Pré-condition Parcourir les mouvements identifiés.
Scénario
nominal
Le comptable consulte les mouvements qui nécessitent une
modification, il peut modifier ou ajouter des informations.
Post-condition Le système affiche « Mouvement est modifié ».
Tableau 33 : Description textuelle de cas « Modifier les mouvements si nécessaires »
Nom du cas Retourner les mouvements pour révision
Acteurs Comptable
Pré-condition Parcourir les mouvements comptabilisés.
Scénario
nominal
L’agent trésorerie consulte les mouvements comptabilisés.
L’agent trésorerie envoie les mouvements vers MFG (ERP).
Post-condition Une référence comptable doit être retournée pour chaque
comptabilisation.
Tableau 34 : Description textuelle de cas « Envoyer les mouvements comptabilisés à MFG »
Conclusion
Dans ce chapitre, nous avons présenté une analyse des besoins de notre
application. Nous avons commencé par l’étude des besoins puis par leur analyse. Dans le
chapitre suivant nous allons faire la conception de notre application.

37. CHAPITRE 3 : CONCEPTION

38. 39
Introduction
Dans ce chapitre nous présenterons la conception du projet, une description logique
de la façon dont le système va fonctionner.
Nous allons présenter le diagramme de classe qui permet une modélisation et qui montre
la structure du modèle de notre application.
Ensuite nous allons mettre en relief la partie dynamique de l’application à travers les
diagrammes de séquences.
Cette application suivra le patron de conception MVC.
1. Outil de conception : Enterprise Architect
Enterprise Architect est un logiciel de modélisation et de conception UML, édité par la
société australienne Sparx Systems. Couvrant, par ses fonctionnalités, l'ensemble des
étapes du cycle de conception d'application, il est l'un des logiciels de conception et de
modélisation les plus reconnus.
Enterprise Architect couvre tous les aspects du cycle de développement d'applications
depuis la gestion des exigences, en passant par les phases de conception, la
construction, tests et maintenance. Ces aspects sont appuyés par des fonctions de
support tels que la traçabilité, la gestion de projet, ou encore le contrôle de version.
Le produit est destiné aux analystes et développeurs de toutes structures : de petites
entreprises aux multinationales, ainsi que les organisations gouvernementales.
Figure 16 - Logo de l’outil UML
2. Le Diagramme de Classes
Le diagramme de classes représente la structure interne du logiciel. On l'utilise surtout
en conception. Une classe regroupe des objets de même nature. Ses objets sont des
entités concrète ou abstraite du domaine d'application. Les objets sont appelé instance
d'une classe. La navigation parmi les classes est rendue possible par l'existence des
associations qui les unissent.
Dans la figure ci-dessous nous avons présenté le diagramme de classe représentant
notre modèle.

39. CHAPITRE 3 : CONCEPTION
40
Figure 17 – Diagramme de classes

40. CHAPITRE 3 : CONCEPTION
41
3. Description des données de diagramme de classes
Classe Attribut Description
Banque Code_Banque : string Chaque banque est
représentée par un code qui
l’identifie.
Description_Banque : string La description contient le
nom de la banque et son
adresse.
Electronique : boolean Si la banque envoie ses
pièces électroniquement
alors l’attribut
« Electronique » est vrai.
Flux : mouvement
entrée/sortie de
liquidités.
Code_FLUX : int Chaque est identifié par un
code.
Delais : string Délais de validation des
Flux.
Description : string La description contient le
nom, type, la date etc...
Electronique : boolean 0 : si la pièce n’est pas
électronique 1 : si la pièce
est électronique
FraisSibtel : boolean Un mouvement qui ne
nécessite pas une pièce (0
ou 1) mais doit être
comptabilisé.
Integrable : boolean Un mouvement qui
nécessite une pièce
Note : string Information supplémentaire
Type_document Code_type_document :
string
Chaque document a un code
d’identification chèque
devise, montant …
Id_type_document Chaque document a un
identifiant unique.
Type_transaction Code_type_transation :
string
Chaque transaction a un
code d’identification.
Id_type_transaction : int Chaque transaction a un
identifiant unique.
Libelle_type_transaction :
string
Description des codes
transactions (R : recette
client, P : paiement
fournisseur …)
Mouvement_Bancaire Code_Mvt : string Chaque mouvement a un
code d’identification.
Date_Operation : date Date du mouvement
effectué.
Description : string Description du mouvement.
Id_Mvt : int Chaque mouvement a un
identifiant unique.
Montant : double Chaque mouvement a un
montant.
Piece_Jointe : string Chaque mouvement doit
avoir une pièce jointe (avis
bancaire).
Reference : string Chaque mouvement a une

41. CHAPITRE 3 : CONCEPTION
42
référence de l’avis bancaire.
Signe : char (+ ou -) signe du montant
FRP-Rapprochement :
solution pour recevoir les
flux.
Code_Banque : string Identificateur de la banque
Id_Mvt : int Identifiant unique du
mouvement
FraisSibtel : boolean Mouvement qui ne nécessite
pas une pièce.
idPB : int Identifiant de la pièce reliée
au mouvement.
Montant : double Montant du mouvement
Reference : int Référence de la pièce
bancaire reliée au
mouvement
CMP_Code : string Code de la société concerné
par le mouvement.
Societe CMP_Code : string Identifiant unique de la
société.
Code_monnaie : string La monnaie utilisée par la
société (TND, EUR, DA...)
Code_pays : string Pays ou existe la société.
Description : string Description de la société
(Nom ...).
Adresse : string Adresse de la société.
Compte_bancaire Code_compte : string Chaque compte bancaire a
un code.
Code_monnaie : string Chaque compte bancaire a
sa propre monnaie utilisée0
Code_pays : string Code du pays ou existe le
compte bancaire.
Groupe_utilisateur Description_role : string Description du rôle groupe
(trésorerie, comptabilité...)
Id_groupe_utilisateur : int Chaque groupe a un
identifiant unique.
Libelle : string Désignation du groupe.
Utilisateur_groupe Id_utilisateur_groupe : int Chaque utilisateur a un
groupe qui a un identifiant
unique.
utilisateur CIN : string Numéro de la carte
d’identité.
Code_filiale : string Code du filiale ou appartient
l’utilisateur.
Compte_lotus : string Adresse du compte
d’utilisateur sur le serveur
srvpgh.
Date_modification :date Date de la dernière
modification du compte.
EstAdmin : boolean (0 ou 1) 1 si c’est
administrateur.
EstCentraliseur : boolean (0 ou 1) 1 si c’est
centralisateur.
EstDirecteur : boolean (0 ou 1) 1 si c’est directeur.
EstResponsable : boolean (0 ou 1) si c’est
responsable.
Identite : string Nom et prénom
d’utilisateur.
Matricule : string Matricule de l’utilisateur

42. CHAPITRE 3 : CONCEPTION
43
chez la société.
Type_acces Id_type_acces : int Chaque type d’accès a un
identifiant unique. Le type
d’accès diffère
d’Administrateur, du
comptable, de l’agent siège
etc…).
Libelle : string Description de l’accès.
Tableau 35 : Description des données de diagramme de classes
4. Diagramme de séquence
Le diagramme de séquence représente les interactions entre les objets, une chronologie
des messages échangé entre les objets et les acteurs. Nous utiliserons les diagrammes
de séquence décrivant les processus.
4.1. Diagramme de séquence du processus authentification
L'authentification est indispensable pour gérer l’accès des utilisateurs et la sécurité de la
plateforme. Dans la figure ci-dessous nous avons présenté toutes les différentes étapes
de l’authentification.
Chaque utilisateur se connecte à partir de son propre poste sur le serveur du groupe
PGH, lors du lancement de l’application une vérification de l’existence de l’utilisateur dans
la base des sessions enregistrées (Matricule du poste) sera exécutée : s’il existe, il est
redirigé vers le tableau de bord sinon il doit s’identifier en passant par les autres étapes
de vérification nécessaire.

43. CHAPITRE 3 : CONCEPTION
44
Figure 18 - Diagramme de séquence du processus s’authentifier
4.2. Diagramme de séquence du processus Réception
La réception des pièces bancaires nécessite l’accès d’un agent siège pour les récupérer à
partir d’un serveur ftp, sélectionner les pièces qui sont nécessaire et les rattacher avec
les mouvements concernés. Enfin l’agent doit les envoyer vers l’approbation.

44. CHAPITRE 3 : CONCEPTION
45
La connexion via le serveur ftp se fait automatiquement et la récupération se fait par un
bouton parcourir après la sélection l’agent doit cliquer sur le bouton rattacher en
sélectionnant le mouvement concerné. Une fois les pièces nécessaires sont rattachées
l’agent clique sur le bouton envoyer.
Figure 19 - Diagramme de séquence du processus recevoir d’une pièce
4.3. Diagramme de séquence du processus Approbation
L’approbation des pièces bancaires nécessite l’accès d’un agent filiale (approbateur) pour
les récupérer à partir de la base de données, vérifier les pièces qui sont rattachées avec
les mouvements : s’il y a une faute technique la pièce est renvoyée vers le service
précédant sinon elle est approuvée.
La vérification de l’approbateur consiste à comparer les informations existantes sur la
pièce bancaire et celle du mouvement (la base de données) s’elles sont identiques, la
pièce est approuvée sinon renvoyée.

45. CHAPITRE 3 : CONCEPTION
46
Figure 20 - Diagramme de séquence du processus approbation
4.4. Diagramme de séquence du processus Identification
L’identification des pièces bancaires nécessite l’accès d’un agent trésorerie pour les
récupérer à partir de la base de données, vérifier les pièces qui sont approuvées puis
saisir les informations utilisées (suivant le type de document), après il peut envoyer les
pièces pour comptabilisation avec un bouton envoyer, si elles ne sont pas conformes il
peut les renvoyer pour approbation.
Les informations qui concerne le document (une ligne d’entête) : Domaine, Dossier,
Entité, Banque, Montant, Date effet sont récupérés automatiquement de l’extrait, ces
informations seront nécessaire pour la comptabilisation.

46. CHAPITRE 3 : CONCEPTION
47
Figure 21 - Diagramme de séquence du processus identification
4.5. Diagramme de séquence du processus Comptabilisation
La comptabilisation de la pièce déjà identifiée par le service concerné consiste à vérifier
les informations déjà affichées, de modifier si c’est nécessaire ou de rejeter
complètement la pièce, en cas de non nécessité de sa comptabilisation (cas de blocage,
déblocage de fonds) en cliquant sur le bouton comptabiliser, une référence de
comptabilisation est renvoyée depuis MFG.

47. CHAPITRE 3 : CONCEPTION
48
Figure 22 - Diagramme de séquence du processus comptabilisation
5. Modèle Conceptuel Edmx
Un fichier edmx est un fichier XML qui définit un modèle conceptuel, un modèle de
stockage et le mappage entre ces modèles. Un fichier .edmx contient également des

48. CHAPITRE 3 : CONCEPTION
49
informations utilisées par ADO.NET Entity Data Model Designer (Entity Designer) pour
restituer graphiquement un modèle.
Figure 23 - Modèle EDMX

49. CHAPITRE 3 : CONCEPTION
50
Conclusion
Dans ce chapitre, nous avons présenté une étude conceptuelle de notre
application. Dans le prochain chapitre nous détaillons la démarche que nous avons suivi
pour implémenter notre travail.

50. CHAPITRE 4 : RÉALISATION

51. 52
Introduction
Dans ce chapitre rentrons dans les détails techniques de l’application. Nous
présentons d'abord l’architecture de l’application, nous définissons ensuite tous les outils
et environnements utilisés tout au long de notre projet, et décrivons enfin les scénarios
d'utilisation de notre application, étayés par quelques interfaces.
1. Choix Technique
Pour développer notre application, nous avons utilisé la technologie .Net de Microsoft,
version 4.5.
Vu que ce choix est imposé par l’entreprise qui a déjà mis en place des applications en
utilisant la technologie Microsoft.
1.1. Le Framework .NET
Le Framework .NET est un standard proposé par la société Microsoft, pour le
développement d'applications d'entreprises multi-niveaux, basées sur des composants.
Microsoft .NET constitue ainsi la réponse de Microsoft à la plate-forme J2EE de Sun.
.NET permet de construire, de déployer et d’exécuter des applications Web, des services
Web, aussi des applications classiques s’exécutant sur Windows. Le .NET Framework est
un environnement qui est disponible gratuitement sur toutes les versions de Windows
depuis 95. Les .NET Servers sont la nouvelle génération des serveurs Microsoft qui vont
donc succéder aux Windows 2003 Servers.
Figure 24 - Architecture du Framework .NET

52. CHAPITRE 4 : RÉALISATION
53
Nouveautés du .NET Framework 4.5
.NET Framework 4.5 apporte bien sûr un total support pour la création d'applications de
style Metro pour Windows en utilisant C# ou Visual Basic. Une sécurité accrue
accompagnée d'une meilleure fiabilité et de performances décuplées dues à une
meilleure prise en charge des processeurs multi-cœurs font leur apparition. Des
améliorations significatives viennent parfaire l'ensemble dans les domaines fonctionnels
tels qu'ASP.NET, Windows Communication Foundation, Windows Identity Foundation ou
encore Windows Workflow Foundation.
1.2. Les composants du .NET
1.2.1. Le langage C#
C’est le langage de la nouvelle version de Visual Studio .NET le plus utilisé, un langage
dérivé du C++, qui reprend des caractéristiques du langage Java. C# peut être utilisé
pour créer des applications Windows et Web. Le langage C# ajoute au C++ les
techniques de construction de programmes sur base de composants prêts à l’emploi avec
propriétés et événements.
Il a les caractéristiques suivantes :
 Purement orienté objet : tout est classe.
 Types précisément conformes à l’architecture .NET et vérifications de type plus
élaborées.
 Gestion automatique de la mémoire (ramasses miettes).
Pas d’héritage multiple mais plusieurs interfaces.
1.2.2. Asp.Net
ASP.NET est la nouvelle version d’Active Server Pages (ASP) et fait partie intégrante du
Framework .NET.
C’est un ensemble de technologies de programmation Web créé par Microsoft. Les
programmeurs peuvent utiliser ASP.NET pour créer des sites Web dynamiques, des
applications Web ou des Web services XML. La technologie est accessible grâce à
l'installation d'un serveur Web compatible ASP (IIS).
1.2.3. ADO.Net
ADO.Net est conçu pour charger des données à partir d’une source de données et pour
les utiliser ensuite dans un état déconnecté.
Cet état déconnecté permet principalement de réduire le trafic sur le réseau. ADO.Net
utilise le langage XML (Extensible Markup language) comme format de transmission
universel, garantissant une interopérabilité avec n’importe quelle plate-forme sur laquelle
est installé un analyseur XML.
1.3. Framework Asp.Net MVC
Compte tenu du choix effectué au niveau de la technologie adopté pour le
développement de notre système : on nous a recommandé le Framework Microsoft
Asp.NET MVC version 5.0 qui permet d’organiser le développement selon le design
pattern MVC.

53. CHAPITRE 4 : RÉALISATION
54
1.3.1. Présentation du Framework Asp.Net MVC
ASP.NET MVC est l’implémentation du design pattern MVC pour la conception
d’applications web.
Ce design pattern permet le découpage de notre application en 3 couches distinctes :
Model, View et Controller.
Cette séparation permet de coupler faiblement chacune de ces parties entre elles. Elle
permet :
 De faciliter le développement de l’application, afin de répartir des tâches de
conception et de développement de l’application entre les différentes personnes
d’une équipe de développement.
 De bien structurer l’application, afin de faciliter son développement, ainsi que sa
maintenance.
 De faciliter les tests de l’application, afin de mieux réaliser les tests unitaires,
fonctionnels et de non régression.
 Structure de notre projet ASP.NET MVC
Figure 25 - Structure de l’application PBE
1.3.2. Modèle MVC
Le modèle MVC est constitué des éléments suivants :
 Le Modèle : représente la couche métier d’une application, présentant des classes
permettant de créer les objets contenant des données métier manipulées par
l’application au travers de traitements, constituant les services métiers.
 La Vue : elle constitue les éléments d’interface utilisateurs : pages web, contrôles
Web…
 Le Contrôleur : permettant de piloter l’application, il interprète les actions à
réaliser et ordonne leur exécution (lecture, traitement de données et mises à
jour).
Ici se trouve toutes les
classes de manipulation
de données. Modèle
Edmx.
Ce dossier contiendra
les classes qui feront
office de contrôleur.
Dans ce dossier se
trouve toutes les
vues.
Le Global.asax
contient toutes les
informations sur les «
Routes ».
Le Web.config
contient toutes les
informations sur la
connexion de base de
données le type de
compilation, le type
d'authentification et
les versions utilisés.

54. CHAPITRE 4 : RÉALISATION
55
Les relations entre ces trois éléments sont les suivantes :
Figure 26 - Modèle MVC
1.4. JQWidgets
Figure 27 - Logo de jQWidgets
JQWidgets fournit une solution complète pour la construction de sites web professionnels
et les applications mobiles. Elle est entièrement construite sur des normes ouvertes et
des technologies comme HTML5, CSS, JavaScript et jQuery. JQWidgets permet le
développement web réactif, de créer des applications et des sites Web qui paraissent
beaux ordinateurs de bureau, les tablettes et les téléphones intelligents.
JQWidgets est un cadre complet de fonctionnalités avec des widgets professionnels
tactiles jQuery, les thèmes, la validation des entrées, des plug-ins de drag & drop et des
adaptateurs de données.
1.5. Ajax
AJAX (Asynchronous Javascript And XML, traduisez Javascript asynchrone et XML) est
une méthode de développement web basée sur l'utilisation d'un script Javascript pour
effectuer des requêtes web à l'intérieur d'une page web sans recharger la page. AJAX
rend plus interactifs les sites web et offre une meilleure ergonomie ainsi qu'une réactivité
amélioré en permettant de modifier interactivement une partie de l'interface web
seulement. En effet, le modèle web traditionnel est basé sur une suite de requêtes et de
réponses successives, c'est-à-dire une navigation séquentielle de page web en page web.
AJAX permet de ne modifier que la partie de la page web qui nécessite d'être mise à jour
en créant une requête HTTP locale et en modifiant tout ou partie de la page web en

55. CHAPITRE 4 : RÉALISATION
56
fonction de la requête HTTP récupérée. L'architecture informatique Ajax (acronyme
d'Asynchronous JavaScript and XML) permet de construire des applications Web et des
sites web dynamiques interactifs sur le poste client en se servant de différentes
technologies.
2. Outils de travail
Les outils de travail utilisés dans la réalisation de projet se présentent comme suit :
2.1. Visual Studio 2013
Pour faciliter la tâche du développement, Microsoft propose un environnement de
développement logiciel de collaboration, de métrique et de reporting. Avec Visual Studio
le développement .NET devient beaucoup plus rapide et simple.
En effet avec Visual Studio on peut :
 gérer l'évolution des besoins tout au long du projet ;
 renforcer la communication entre les chefs de projet, les développeurs et les
testeurs ;
 tester avec précision la qualité et la fiabilité des applications ;
 respecter la stratégie internationale de développement, les obligations légales et
les exigences de conformité.
2.2. SQL Server 2012
SQL Server 2012 est un système de gestion de bases de données relationnelles. Cette
version de SQL Server intègre de nouvelles fonctionnalités et des améliorations qui
augmentent la puissance et la productivité des développeurs et des administrateurs qui
conçoivent, développent et maintiennent des systèmes de stockage de données
(Améliorations de la sécurité, Améliorations de la disponibilité).
Pour mettre les bases de données d’application dans un environnement d’entreprise à
l’abri de périodes d’inactivité planifiées et non planifiées, SQL Server 2012 propose la
fonctionnalité Groupes de disponibilité AlwaysOn et d’autres améliorations garantissant
un haut niveau de disponibilité.
2.3. IIS 8.0 Express
Le Framework ASP.NET MVC dépend du routage ASP.NET pour router les requêtes
provenant du navigateur vers les actions du contrôleur. Dans le but de tirer profit du
routage ASP.NET, nous avons donc opté pour le système d’exploitation Windows Seven
qui inclut le serveur web IIS version 8.
2.4. SQL Server Integration Services : SSIS
SQL Server Integration Services (SSIS) est un ETL (Extract Transform Download)
permettant de se connecter à toute source de données Tiers. L’ETL permet donc de
collecter, transformer, et alimenter les données nécessaires à l'analyse décisionnelle dans
une ou plusieurs bases de données dédiées (relationnelles ou multidimensionnelles)
Integration Services est une plateforme qui permet de créer des solutions de
transformation de données et d'intégration de données au niveau de l'entreprise.

56. CHAPITRE 4 : RÉALISATION
57
Integration Services vous permet de résoudre des problèmes professionnels complexes
en copiant ou en téléchargeant des fichiers, en envoyant des messages électroniques en
réponse à des événements, en mettant à jour des entrepôts de données, en nettoyant et
en explorant des données et en gérant des données et des objets SQL Server.
Les packages peuvent fonctionner en mode autonome ou de concert avec d'autres
packages en réponse à des besoins professionnels complexes. Integration Services peut
extraire et transformer des données à partir d'un éventail de sources, par exemple des
fichiers de données XML, des fichiers plats et des sources de données relationnelles, puis
charger les données dans une ou plusieurs destinations.
Figure 27 - Modèle ETL (SSIS)
2.4.1. Avantages de SSIS
- Outil complètement intégré dans Visual Studio
- Nombreux connecteurs disponibles (Oracle, Teradata, SAP…)
- Facilité de prise en main
- Outil visuel
- Possibilité de créer de nouveaux modules
- Gestion des évènements.

57. CHAPITRE 4 : RÉALISATION
58
2.4.2. Package BIAT: Téléchargement et rattachement automatique des pièces bancaires avec les mouvements bancaires.
Connexion au serveur FTP et téléchargement des pièces bancaires (BIAT) puis organisation des fichiers téléchargés dans des dossiers
nommés par date enfin le rattachement automatique avec les mouvements.
Figure 29 - Exemple d’une tâche SSIS

58. CHAPITRE 4 : RÉALISATION
59
La réception des pièces bancaires est faite dans un dossier selon sa date.
Figure 30 - Architecture des dossiers de réception des pièces bancaires

59. CHAPITRE 4 : RÉALISATION
60
3. Illustration de l’utilisation de l’application
Dans cette section nous présentons les interfaces fonctionnelles de notre application.
3.1. Interface d’authentification
La figure ci-dessous présente la page de connexion de l’application PBE qui permet à chaque utilisateur de se connecter en introduisant
ses infos de connexion pour bénéficier des différents services.
Figure 31 - Interface d’authentification

60. CHAPITRE 4 : RÉALISATION
61
3.2. Interface d’administration
Figure 32 – Interface administrateur (Tableau de bord)

61. CHAPITRE 4 : RÉALISATION
62
L’interface de l’administrateur lui permet de gérer les utilisateurs (ajout, suppression, modification, recherche), de régler les droits d’accès et de modifier
toutes informations.
Figure 33 – Interface administrateur (ajouter un utilisateur)

62. CHAPITRE 4 : RÉALISATION
63
L’administrateur peut regrouper les utilisateurs par société dans le menu (Drop down List). L’administrateur peut attribuer ou changer leur service
d’accueil.
Figure 34 – Interface administrateur (Groupe utilisateur)

63. CHAPITRE 4 : RÉALISATION
64
L’administrateur peut consulter tous les utilisateurs et les codes des comptes bancaires associés, il peut aussi changer le type d’un
utilisateur avec un menu «Drop Down List».
Figure 35 – Interface administrateur (Utilisateur compte)

64. CHAPITRE 4 : RÉALISATION
65
L’interface Flux contient tous les mouvements de chaque banque selon le type de flux (TVA, commission…). L’administrateur peut modifier s’il y a des fautes
les modifications en ligne sont autorisé.
Figure 36 – Interface administrateur (Flux)

65. CHAPITRE 4 : RÉALISATION
66
Interface Banque qui contient tous les banques, l’administrateur peut modifier ou ajouter une banque via l’interface, la suppression est faite dans la base de
données pour éviter les erreurs fautives, la case à cocher électronique si la banque envoi les pièces bancaires via serveur FTP.
Figure 37 – Interface administrateur (Banque)

66. CHAPITRE 4 : RÉALISATION
67
3.3. Interface de la réception et rattachement de pièce bancaire
L’agent réception peut recevoir les mouvements choisis (Package BIAT Figure 29), pour les rattacher (en cas de rattachement manuel) l’agent sélectionne
« parcourir un fichier » puis choisir son fichier après il clique sur rattacher, enregistrer et puis sur le bouton envoyer pour les envoyer à l’approbation.
L’agent peut supprimer un rattachement après sa création en cliquant sur le bouton rouge dans la colonne Sup PJ.
Figure 38 – Interface de réception et rattachement de pièce bancaire

67. CHAPITRE 4 : RÉALISATION
68
3.4. Interface de l’approbation
L’approbateur peut recevoir les mouvements envoyés de la part de l’agent siège, il peut consulter les mouvements en PDF en cliquant sur la pièce jointe et
pour confirmer l’approbation il faut cocher la colonne approuver, puis il clique sur le bouton ‘enregistrer’ pour sauvegarder les changements et sur «
envoyer » pour envoyer les mouvements à l’agent trésorerie.
Figure 39 – Interface d’approbation

68. CHAPITRE 4 : RÉALISATION
69
3.5. Interface de l’identification
L’agent trésorerie peut recevoir les mouvements de la part de l’approbateur, pour identifier une pièce l’agent vérifie les pièces en cliquant sur la colonne PJ
(pièces jointes) les mouvements vont s’ouvrir en format PDF sous adobe pour l’identifier il va sectionner les mouvements et cliquer sur « Identification ».
Figure 40 - Interface d’identification

69. CHAPITRE 4 : RÉALISATION
70
Le bouton Identification va le rediriger vers une autre interface de prévision ou il va régler la balance entre le montant de l’extrait bancaire et le montant du
rapprochement de la prévision ( il peut ajouter des mouvements de prévision « ajouter ligne »), il peut aussi consulter l’historique de la pièce en cliquant sur
le bouton « Historique Pièce » , ou la retourner la pièce pour révision en cliquant sur « Réviser Pièce » de suite la pièce va être renvoyer pour approbation
L’écart est mis à zéro, enfin il peut identifier la pièce en cliquant sur « Identifier » où la pièce va être envoyer à l’agent comptable.
Figure 41 – Interface d’identification (2)

70. CHAPITRE 4 : RÉALISATION
71
Conclusion
On a présenté dans ce chapitre une vue globale sur la réalisation du système de
suivi, et cela en décrivant l’environnement du travail, les différents outils et Framework
utilisés et quelques interfaces de l’application.

71. 72
Conclusion Générale
Ce stage nous a donné l’opportunité de travailler dans un nouveau domaine, et
nous permettant ainsi de nous adapter au langage de la trésorerie courant. Nous avons
aussi acquis une importante expérience dans la spécification des besoins de l’entreprise
pour concevoir un système d’information bien structuré.
Concernant le coté technologique, nous avons eu l’occasion de travailler avec une
nouvelle technologie de Microsoft : Asp.Net MVC, qui introduit pour la première fois le
concept Model View Control ayant comme caractéristique de travailler avec les plus
récentes normes mondiales.
Notre projet de fin d’études consistait en l’analyse, la conception, la réalisation et la
mise en œuvre d’un système de gestion de pièce bancaire, en passant par les différentes
étapes du cycle du développement d’un projet depuis l’étude de l’existant, la spécification
des besoins, le suivi de la modélisation du système, l’étude conceptuelle suivant le
langage UML, jusqu’au déploiement du système.
Et afin d’améliorer le système que nous avons conçu, il est utile d’ajouter :
- Des fonctionnalités de recherche
- Un menu regroupant toutes les fonctionnalités
- Des alertes afin d’avertir les responsables de toutes les actions faites
- De nouveaux tableaux de bord

72. 73
Webographie
[1] http://technet.microsoft.com/
[2] http://www.asp.net/
[3] http://www.dotnetguru.org/
[4] http://dotnet.developpez.com/cours/
[5] http://msdn.microsoft.com/en-us/library/ms229862.aspx
[6] http: // www.openclassroom.com/
[7] http://www.jqwidgets.com/
[8] http://stackoverflow.com/
[9] http://www.youtube.com/
[10] http://www.microsoftvirtualacademy.com/training-courses/administering-microsoft-
sql-server-2012-jump-start
[11] http://wikipedia.com/

73. 74